Message ID | 20180205220205.3528-1-boris.brezillon@bootlin.com |
---|---|
Headers | show |
Series | mtd: nand: Prepare things for SPI NAND support | expand |
On Mon, 5 Feb 2018 23:01:58 +0100 Boris Brezillon <boris.brezillon@bootlin.com> wrote: > Hello all, > > I'm finally posting a v7 of the SPI NAND preparation patches. That's on > my TODO list for quite some time, and I finally take the time to submit > things that are pending in my development branch and are ready for > submission (at least, that's my opinion :)). > > Patches adding SPI NAND support have been ommited because I'm still not > entirely happy with the SPI memories (NOR/NAND/SRAM) / QSPI controllers > situation, and, despite what I said earlier, I think it's worth > addressing the problem now. > > What made me change my mind is the rework of the FSL QSPI driver > initiated by Frieder to support NANDs. Looks like all other QSPI > drivers will have to implement the same kind of hack to support both > SPI NORs and SPI NANDs with a single driver, which implies a lot of > duplicated code. > > So, instead of making the situation worse by adding yet another level > of complexity, I'd like to see if we can expose all QSPI NOR > controllers as regular SPI controllers. Well, not exactly regular SPI > controllers, in that they would not be able to do random SPI transfers, > but instead high-level operations (an operation being a > CMD[+ADDRS][+DUMMY][+DATA] sequence). > > The idea is to extend the SPI framework to provide high-level APIs to > execute such SPI operations. Then, each SPI controller would be able > to implement the high-level interface directly (likely the chosen > approach for advanced SPI controllers) or rely on the default > implementation which creates regular SPI messages to do the operation. > > Note that this high-level spi-mem interface would replace the > spi_flash_read() APIs and handle optimizations of both read/write > paths. > > I'm currently working on a PoC to validate the feasability of this > approach (I pushed my work here [1], but it's not yet in a clean > state), but this will be part of a separate RFC. > > Back to the initial topic. The patch series contains > mechanical/straightforward changes to move existing NAND code to > the raw subdir (patches 1 to 6) and a patch adding the generic NAND > layer that is meant to be used by the SPI NAND framework, and at > some point, by the raw NAND and OneNAND framework. Applied the whole series.