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:
signature.asc
Description: Digital signature
