> 2011/4/12 George Kashperko <george@xxxxxxxxxxx>: > > > >> 2011/4/12 George Kashperko <george@xxxxxxxxxxx>: > >> > > >> >> 2011/4/12 George Kashperko <george@xxxxxxxxxxx>: > >> >> > > >> >> >> Hi, > >> >> >> > >> >> >> On Tue, Apr 12, 2011 at 01:57:07AM +0200, RafaÅ MiÅecki wrote: > >> >> >> > Cc: Michael BÃsch <mb@xxxxxxxxx> > >> >> >> > Cc: Larry Finger <Larry.Finger@xxxxxxxxxxxx> > >> >> >> > Cc: George Kashperko <george@xxxxxxxxxxx> > >> >> >> > Cc: Arend van Spriel <arend@xxxxxxxxxxxx> > >> >> >> > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > >> >> >> > Cc: Russell King <rmk@xxxxxxxxxxxxxxxx> > >> >> >> > Cc: Arnd Bergmann <arnd@xxxxxxxx> > >> >> >> > Cc: Andy Botting <andy@xxxxxxxxxxxxxxx> > >> >> >> > Cc: linuxdriverproject <devel@xxxxxxxxxxxxxxxxxxxxxx> > >> >> >> > Cc: linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx> > >> >> >> > Signed-off-by: RafaÅ MiÅecki <zajec5@xxxxxxxxx> > >> >> >> > --- > >> >> >> > 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 > >> >> >> [1] for a core IP which talks AXI and [2] 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. > >> >> >> > >> >> >> [1] http://gitorious.org/usb/usb/blobs/dwc3/drivers/usb/dwc3/core.c > >> >> >> [2] 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 > >> >> stuff. > >> > 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. > >> > >> Do you think that in my code only scanning is Broadcom specific? In > >> such a case we could keep it "axi", and just s/scan/bcmscan/. This is > >> only correct choice if the rest (addressing, core enabling, host > >> management) is AXI specific. > > We rely on core identification following its id/ven/rev/class layout > > from EROM. Corelink cores use different layout/location. Also core > > enabling/disabling are DMP related. Another _if_ here -- is DMP > > obligatory for all axi buses? > > Why do you use "Corelink" name? Do you mean AMBA AXI cores? Please, > try to keep it simple, do not introduce more things we need to make > clear for this discussion. > What do you mean by DMP? DMP, Device Management Plugin (mentioned several times here by Broadcom guys) - don't know for sure as there are no public docs at ARM regarding this thingy. I suppose its arm instrument used to build master ports for amba to talk to the interconnect on behalf of non-native (e. g. Broadcom proprietary) IP cores. Its my raw guess ofcourse but think I'm not that far from actual truth here. All that oobseloxxxx stuff in aidmp.h is that DMP. Among those peripherialid and componentid registers are documented in public corelink specs. Think it would be beneficial for you to do some research among those docs available publicly from arm (see Hauke Mertens message few mins ago for link) before claiming sumthing just related to axi as actual axi. Here I don't mean I know everything on the subject, just the time spent on clearing this question for myself make me think we deal with Broadcom-specific implementation but not the _real_ axi as it is. > > > >> >> > 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. > >> > >> This is SoC, we do not have any problems supporting multiple cores on > >> SoCs. All cores are available at the same time, without any sliding > >> windows. > >> > > Multicores have multiple slave ports bound to single master port > > (agent). Individual core driver must be confident of its "partner" > > device/driver and both must know who is permitted to > > enable/disable/reset and who is not or there should be some other > > technique for agent management. > > Let's leave that multi-core discussion for later, or I'll freak > Sure thing ;) Have nice day, George _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
