From mboxrd@z Thu Jan 1 00:00:00 1970 From: arend@broadcom.com (Arend van Spriel) Date: Thu, 21 Apr 2011 16:38:09 +0200 Subject: [PATCH] drivers: brcmaxi: provide amba axi functionality in separate module In-Reply-To: <201104211612.49805.arnd@arndb.de> References: <1303331669-31293-1-git-send-email-arend@broadcom.com> <201104211612.49805.arnd@arndb.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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? 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