Re: Writing SPI flash driver for Broadcom BCM53xx ARM SoC

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

On Fri, Aug 01, 2014 at 07:00:36PM -0700, Brian Norris wrote:

> You can probably write a pure SPI driver (drivers/spi/) that uses only
> the MSPI hardware to do (slow, single-I/O) true SPI, and hooks into
> m25p80.c.

This seems like a good first pass at any rate, it's uncontroversial and
at least functional even if slow.

> But if you want to integrate the accelerated BSPI for reads, it gets
> harder. You might be able to export a kind of 'lock' API from the MSPI
> driver, so that a BSPI driver can utilize the MSPI for most
> transactions, but then lock it down when doing BSPI/read operations. I
> think with a little bit of work, spi-nor.c can accomodate the right kind
> of callbacks to allow you to do this. But the coordination between
> drivers/spi/<MSPI> and drivers/mtd/spi-nor/<BSPI> would be the hardest
> to architect, I think.

Right, I think we'd need something that allowed the MTD controller to
take ownership of the device, lock out other users and then do what it
wants with the controller.  If we provide a way for the SPI and MTD
drivers to get hold of each other and pass around the underlying device
we probably don't even need to architect the interface too much, we can
just say it's a private arrangement between the two drivers, given that
I don't think we have a good picture of what a standard interface would
look like and the hardware seems to have a reasonable amount of
variation in how things are split this may actually be the most tasteful
thin we can do for the time being.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]