From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hiroshi Doyu Subject: Re: [PATCH v2 1/3] ARM: tegra: Add AHB driver Date: Wed, 25 Apr 2012 08:37:47 +0300 Message-ID: <20120425083747.466f5c98330af8964d980b8c@nvidia.com> References: <1335269116-9578-1-git-send-email-hdoyu@nvidia.com> <20120424195645.GB3628@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120424195645.GB3628-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Russell King - ARM Linux Cc: "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Felipe Balbi , Arnd Bergmann , Colin Cross , Olof Johansson , Stephen Warren , Grant Likely , Rob Herring , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" List-Id: devicetree@vger.kernel.org On Tue, 24 Apr 2012 21:56:45 +0200 Russell King - ARM Linux wrote: > On Tue, Apr 24, 2012 at 03:05:14PM +0300, Hiroshi DOYU wrote: > > The AHB Bus conforms to the AMBA Specification (Rev 2.0) Advanced > > High-performance Bus (AHB) architecture. > > > > The AHB Arbiter controls AHB bus master arbitration. This effectively > > forms a second level of arbitration for access to the memory > > controller through the AHB Slave Memory device. The AHB pre-fetch > > logic can be configured to enhance performance for devices doing > > sequential access. Each AHB master is assigned to either the high or > > low priority bin. Both Tegra20/30 have this AHB bus. > > > > Signed-off-by: Hiroshi DOYU > > Cc: Felipe Balbi > > Cc: Arnd Bergmann > > --- > > Update: > > - Use platform_device to get info from dt dynamically.(Felipe/Arnd) > > --- > > arch/arm/mach-tegra/Makefile | 1 + > > arch/arm/mach-tegra/tegra-ahb.c | 285 +++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 286 insertions(+), 0 deletions(-) > > 1. I thought we weren't going to have any more drivers under > arch/arm Can this driver be located under "drivers/misc"? Or is there any better place? > 2. From the way you describe it above, this sounds like it should be some > kind of generic driver, which obtains the necessary settings to be > programmed into registers from (eg) DT. Agree.