[lkml]   [2011]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] drivers: brcmaxi: provide amba axi functionality in separate module
On Thu, 21 Apr 2011 16:12:49 +0200, Arnd Bergmann <> 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?


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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-04-21 16:41    [W:0.059 / U:0.076 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site