Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756442Ab1DLThd (ORCPT ); Tue, 12 Apr 2011 15:37:33 -0400 Received: from mail.academy.zt.ua ([82.207.120.245]:19734 "EHLO mail.academy.zt.ua" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756199Ab1DLThb (ORCPT ); Tue, 12 Apr 2011 15:37:31 -0400 X-MDAV-Processed: mail.academy.zt.ua, Tue, 12 Apr 2011 22:37:29 +0300 X-Spam-Processed: mail.academy.zt.ua, Tue, 12 Apr 2011 22:37:28 +0300 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: george@academy.zt.ua X-Return-Path: george@znau.edu.ua X-Envelope-From: george@znau.edu.ua Subject: Re: [RFC][PATCH] axi: add AXI bus driver From: George Kashperko To: =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= Cc: balbi@ti.com, linux-wireless@vger.kernel.org, "John W. Linville" , b43-dev@lists.infradead.org, Michael =?ISO-8859-1?Q?B=FCsch?= , Larry Finger , Arend van Spriel , linux-arm-kernel@lists.infradead.org, Russell King , Arnd Bergmann , Andy Botting , linuxdriverproject , "linux-kernel@vger.kernel.org" In-Reply-To: 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> <1302635550.14216.21.camel@dev.znau.edu.ua> Content-Type: text/plain; charset=UTF-8 Date: Tue, 12 Apr 2011 22:34:21 +0300 Message-Id: <1302636861.14216.28.camel@dev.znau.edu.ua> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5427 Lines: 114 > 2011/4/12 George Kashperko : > > > >> 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. > > 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? > > > >> > 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. Have nice day, George -- 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/