[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120427084015.cb7c8e00c7d9a4cd01faa5ae@nvidia.com>
Date: Fri, 27 Apr 2012 08:40:15 +0300
From: Hiroshi Doyu <hdoyu@...dia.com>
To: Russell King - ARM Linux <linux@....linux.org.uk>,
Arnd Bergmann <arnd@...db.de>
CC: Stephen Warren <swarren@...dotorg.org>,
Stephen Warren <swarren@...dia.com>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Felipe Balbi <balbi@...com>,
Grant Likely <grant.likely@...retlab.ca>,
Rob Herring <rob.herring@...xeda.com>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCHv3 1/4] ARM: tegra: Add AHB driver
On Thu, 26 Apr 2012 23:59:03 +0200
Russell King - ARM Linux <linux@....linux.org.uk> wrote:
> On Thu, Apr 26, 2012 at 01:51:28PM -0600, Stephen Warren wrote:
> > On 04/25/2012 05:07 AM, 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.
> > >
> > > Some of configuration param could be passed from DT too.
> >
> > I think this code looks reasonable. I'd like to see an ack from Russell,
> > Arnd, and Olof on the final location of the files though.
>
> Well, the big question which needs answering is whether this AHB software
> interface is something specific to Tegra or whether it really is something
> generic. There's been some hints in the previous thread that it's
> specific to Tegra, so it may not after all make sense for it to be a
> generic driver.
>
> However, we _have_ decided "no more drivers under arch/arm". So I really
> don't want to see "struct xxx_driver" appearing in any code under that
> subdirectory or one of its decendents. I don't have much more to say
> about location than that.
What about having this driver under "drivers/amba"?
If other similiar drivers are coming up, it's easy to find rather than
having this arch/arm/mach-*. There may be some possibility of
generalization later, then. Also it meets the requirement of no
"struct xxxx_driver" under arch/arm. Arnd?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists