lkml.org 
[lkml]   [2011]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] drivers: brcmaxi: provide amba axi functionality in separate module
Date
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?

> +/* 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.

Arnd
--
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:15    [W:0.048 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site