Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:49414 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751317Ab1DLS7d convert rfc822-to-8bit (ORCPT ); Tue, 12 Apr 2011 14:59:33 -0400 MIME-Version: 1.0 In-Reply-To: <1302634039.14216.10.camel@dev.znau.edu.ua> References: <1302566227-23788-1-git-send-email-zajec5@gmail.com> <20110412133633.GR15130@legolas.emea.dhcp.ti.com> <1302634039.14216.10.camel@dev.znau.edu.ua> Date: Tue, 12 Apr 2011 20:59:32 +0200 Message-ID: Subject: Re: [RFC][PATCH] axi: add AXI bus driver From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= To: George Kashperko Cc: balbi@ti.com, linux-wireless@vger.kernel.org, "John W. Linville" , b43-dev@lists.infradead.org, =?UTF-8?Q?Michael_B=C3=BCsch?= , Larry Finger , Arend van Spriel , linux-arm-kernel@lists.infradead.org, Russell King , Arnd Bergmann , Andy Botting , linuxdriverproject , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: 2011/4/12 George Kashperko : > >> Hi, >> >> On Tue, Apr 12, 2011 at 01:57:07AM +0200, Rafał Miłecki wrote: >> > Cc: Michael Büsch >> > Cc: Larry Finger >> > Cc: George Kashperko >> > Cc: Arend van Spriel >> > Cc: linux-arm-kernel@lists.infradead.org >> > Cc: Russell King >> > Cc: Arnd Bergmann >> > Cc: Andy Botting >> > Cc: linuxdriverproject >> > Cc: linux-kernel@vger.kernel.org >> > Signed-off-by: Rafał Miłecki >> > --- >> > 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. > 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 ;) > 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 ;) -- Rafał