Re: [PATCH] drivers: brcmaxi: provide amba axi functionality inseparate module

[Arend van Spriel]

On Thu, 21 Apr 2011 16:12:49 +0200, Arnd Bergmann <arnd@xxxxxxxx> wrote:

> On Wednesday 20 April 2011, Arend van Spriel wrote:
> > The open-source community is looking for a library which will detect
> > cores in a chip using axi backplane. Another proposal has been
> > sent by RafaÅ MiÅecki, which registers detected cores in the linux
> > device tree to be claimed by device drivers. This implies cores will
> > always provide a system function to the kernel which is indepent from
> > other cores and have very loose or no coupling. If this is not true,
> > exceptions need to be added in the device registration process. This
> > means knowledge of specific devices from specific vendors is sitting
> > in a bus driver. Whether the exceptions are rarely or likely is a
> > pending question.
>
> Hi Arend,
>
> I have two very general comments about this:
>
> > To feed the discussion this implementation takes a different approach.
> > A calling entity (being a pci device driver, or SoC initialization
> > sequence) registers a table with core identities and a callback  
> > function.
> > It then starts the scan and for each detected core with a callback
> > function it does the call providing the core information. Apart from
> > that it provides some basic operations on the core.
> >
> > It has been tested using the brcmsmac driver (in  
> > drivers/staging/brcm80211).
>
> The API split between PCI and non-PCI devices appears to be
> unhelpful. Can't you abstract the interface so that a user
> would apply the exact same interfaces in both cases, and handle
> the differences internally?

Ok. that can be arranged ;-)

> > +/* Core Codes */
> > +#define	NODEV_CORE_ID		0x700	/* Invalid coreid */
> > +#define	CC_CORE_ID		0x800	/* chipcommon core */
> > +#define	ILINE20_CORE_ID		0x801	/* iline20 core */
> > +#define	SRAM_CORE_ID		0x802	/* sram core */
> > +#define	SDRAM_CORE_ID		0x803	/* sdram core */
> > +#define	PCI_CORE_ID		0x804	/* pci core */
> > +#define	MIPS_CORE_ID		0x805	/* mips core */
> > +#define	ENET_CORE_ID		0x806	/* enet mac core */
> > +#define	CODEC_CORE_ID		0x807	/* v90 codec core */
> > +#define	USB_CORE_ID		0x808	/* usb 1.1 host/device core */
> > +#define	ADSL_CORE_ID		0x809	/* ADSL core */
> > +#define	ILINE100_CORE_ID	0x80a	/* iline100 core */
> > +#define	IPSEC_CORE_ID		0x80b	/* ipsec core */
> > +#define	UTOPIA_CORE_ID		0x80c	/* utopia core */
> > +#define	PCMCIA_CORE_ID		0x80d	/* pcmcia core */
> > +#define	SOCRAM_CORE_ID		0x80e	/* internal memory core */
> > +#define	MEMC_CORE_ID		0x80f	/* memc sdram core */
> > +#define	OFDM_CORE_ID		0x810	/* OFDM phy core */
> > ...
>
> This list to me is a strong hint that the cores behind the AXI bridge
> should normally be actual devices in Linux, i.e. the approach that
> RafaÅ suggested.  The vast majority of these is something that in Linux
> would be operated by a device driver. The exceptions that I can see
> are CPU cores and bus bridges, both of which we typically also represent
> as devices in the flattened device tree, even though they typically
> don't have a Linux driver attached to them.

Fine. Your providing the kind of feedback I was looking for. The  
OFDM_CORE_ID is also an exception.

So could a device driver claim multiple cores/devices to assure other  
drivers are not accessing those? I would prefer that over having  
exceptions coded in the axi bus driver, like the chipcommon core  
(CC_CORE_ID). I assume it can be done by the device table. Is that correct?

RafaÅ,

Would it be possible to make chipcommon driver optional (not doing the  
initialization)?

Gr. AvS
--
"The world is indeed comic, but the joke is on mankind." â H.P. Lovecraft

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/