[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150916152421.GL11268@sirena.org.uk>
Date: Wed, 16 Sep 2015 16:24:21 +0100
From: Mark Brown <broonie@...nel.org>
To: Jagan Teki <jteki@...nedev.com>
Cc: devicetree@...r.kernel.org, hramrach@...il.com,
Russell King <linux@....linux.org.uk>,
Vignesh R <vigneshr@...com>, Tony Lindgren <tony@...mide.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-spi@...r.kernel.org, linux-omap@...r.kernel.org,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
Benoit Cousson <bcousson@...libre.com>,
Brian Norris <computersforpeace@...il.com>,
David Woodhouse <dwmw2@...radead.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/5] spi: introduce mmap read support for spi flash
devices
On Wed, Sep 16, 2015 at 06:16:55PM +0530, Jagan Teki wrote:
> On 15 September 2015 at 00:05, Mark Brown <broonie@...nel.org> wrote:
> > There seem to be a reasonable number of SPI controllers out there which
> > have as an extension the ability to do memory mapped reads but are
> > otherwise perfectly normal SPI controllers and which rely on that for
> > everything except reads.
> This is true, but exposing direct spi-nor arguments or features like
> read_opcode, addr_width or dummy_byte to spi layer isn't fine? because
> for spi layer there is a spi to flash transition mtd m25p80.c is there
> to handle is it?
The m25p80 driver is a generic, SPI level piece of code not a driver for
specific controller hardware. The controller hardware drivers live in
the SPI subsystem. In order to support this memory mapped feature we
need the controller drivers to expose an interface for controlling it.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists