[RFC][PATCH] axi: add AXI bus driver
george at znau.edu.ua
Tue Apr 12 15:12:29 EDT 2011
> 2011/4/12 George Kashperko <george at znau.edu.ua>:
> >> Hi,
> >> On Tue, Apr 12, 2011 at 01:57:07AM +0200, Rafał Miłecki wrote:
> >> > Cc: Michael Büsch <mb at bu3sch.de>
> >> > Cc: Larry Finger <Larry.Finger at lwfinger.net>
> >> > Cc: George Kashperko <george at znau.edu.ua>
> >> > Cc: Arend van Spriel <arend at broadcom.com>
> >> > Cc: linux-arm-kernel at lists.infradead.org
> >> > Cc: Russell King <rmk at arm.linux.org.uk>
> >> > Cc: Arnd Bergmann <arnd at arndb.de>
> >> > Cc: Andy Botting <andy at andybotting.com>
> >> > Cc: linuxdriverproject <devel at linuxdriverproject.org>
> >> > Cc: linux-kernel at vger.kernel.org <linux-kernel at vger.kernel.org>
> >> > Signed-off-by: Rafał Miłecki <zajec5 at gmail.com>
> >> > ---
> >> > V2: Rename to axi
> >> > Use DEFINE_PCI_DEVICE_TABLE in bridge
> >> > Make use of pr_fmt and pr_*
> >> > Store core class
> >> > Rename bridge to not b43 specific
> >> > Replace magic 0x1000 with BCMAI_CORE_SIZE
> >> > Remove some old "ssb" names and defines
> >> > Move BCMAI_ADDR_BASE def
> >> > Add drvdata field
> >> > V3: Fix reloading (kfree issue)
> >> > Add 14e4:0x4331
> >> > Fix non-initialized struct issue
> >> > Drop useless inline functions wrappers for pci core drv
> >> > Proper pr_* usage
> >> > V3.1: Include forgotten changes (pr_* and include related)
> >> > Explain why we dare to implement empty release function
> >> I'm not sure we need this. If you have an IP Core which talks AXI and
> >> you want to put it on a PCI bus, you will have a PCI Bus wrapper around
> >> that IP Core, so you should go and let the kernel know about that. See
> >>  for a core IP which talks AXI and  for a PCI bus glue layer.
> >> Besides, if you introduce this bus layer, it'll be more difficult for
> >> other licensees of the same core to re-use the same driver, since it's
> >> now talking a PCI emulated on top of AXI. The same can be achieved with
> >> the platform_bus which is more widely used, specially on ARM SoCs.
> >>  http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/core.c
> >>  http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/dwc3-haps.c
> > Already noticed earlier that AXI isnt really good name for
> > Broadcom-specific axi bus customization. As of tech docs available from
> > arm, corelink AXI cores use own identification registers which feature
> > different format and layout comparing to that we use for Broadcom cores.
> > Maybe there is something "standartized" by the DMP specs? If so I'm
> > curious if that DMP is obligatory for every axi bus ?
> > Naming particular Broadcom's implementation just axi limits other
> > licensees in reusing axi bus name/code or will require hacks/workarounds
> > from them to fit Broadcom-like core scanning/identificating techniques.
> > You use bus named AXI to group and manage Broadcom cores, while never
> > even publish device records for native axi cores Broadcom use to talk to
> > the interconnect through. Yet again, something like bcmb/bcmai looks
> > like better name for this bus.
> I don't know, I'm really tired of this. Earlier I was told to not use
> anything like bcmai, because it is not Broadcom specific. Now it seems
> (and I'm afraid I agree) there is quite a lot of Broadcom specific
Well, _if_ that "magic" EROM core layout is arm's "standard" for axi
ports identification _and_ _if_ that EROM core is obligatory axi
component then sure axi name is good one as soon as you consider
registering master port (agent) cores with device subsystem as well.
I have no clue here about how resolve those _if_'s, hopefully Broadcom
guys can enlighten us on the subject.
> > Also can't figure out how is this implementation supposed to manage
> > multicore devices.
> We have got ideas, but let's first find (wait for) such a device ;)
bcm4716 usb host ? Don't really know if there are any other multicores.
> > Any plans on embeddables' support ?
> Sure, if noone will come before me, I'll try to provide support for
> embedded devices. However basic support for PCI host in higher on my
> priority list. First I want to know it is working at all ;)
Have nice day,
More information about the linux-arm-kernel