lkml.org 
[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
Date
From
On Thu, 21 Apr 2011 16:12:49 +0200, Arnd Bergmann <arnd@arndb.de> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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