RFC SPI-NAND support
Get series with b4
b4 am 20180625164656.6cb134c1@bbrezillonVersions newest first
- v1 RFC Latest0 of 20 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 20 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Quoted 7 lines · On Mon, 25 Jun 2018 19:58:37 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
- convert fsl-qspi to spi-mem
We're not targeting the fsl-qspi controller here but a simple SPI controller that is already upstreamed. But yes, the fsl-qspi driver will have to be patched to support the spi-mem interface at some point.
Can you point me that simple spi-mem controller driver?
It's not a controller that implements spi-mem operations but a simple SPI controller (one that knows how to do regular SPI transfers and nothing more). But the spi-mem layer knows how to send spi_mem_op using regular transfer and that's why it works without any modification at the driver level.
Quoted 38 lines
Quoted 38 lines
Quoted 20 lines
Quoted 9 lines
For spi-nor interface design, we have an example code here[2]
I've paused this [2] series because of dm conversion of spi-drivers otherwise I need add legacy code like
mmc-legacy.c, so if we really move to spi-mem design and okay with above design. I will try to move the current spi flash to add MTD driver-model so-that we can add spi-mem, spi-nand on top of it or we can work together to convert them all.Why can't we do things iteratively. I mean, if the long term goal is to convert everything to the driver model, then this patchset is going in the right direction:
- addition of DM helpers to theMTD_UCLASS
- addition of the spi-mem interface properly integrated in the DM model of the SPI framework
- addition of a SPI NAND driver, again properly integrated in the DM
- integration of DM-ready MTD drivers and old MTD drivers in a single view exposed by thecmd/mtd.ccommand setQuoted 7 lines
I'd really like to limit the scope of this development to these topics, which doesn't prevent you from converting other part of u-boot to the spi-mem approach (SPI NOR is one example).
I hope you understand our concerns and the fact that what you're asking us to do as a dependency of getting SPI NAND support +
cmd/mtd.cmerged is way more than we can actually provide.To answer all these questions, I think we need to decide whether we go for MTD dm abstraction or existing MTD layer.
When I say MTD dm abstraction, all mtd operation prototypes are in the form of udevice unlike existing MTD has
mtd_info. when I initially supporting spi-nor (during Linux early spi-nor) I've reused existing MTD and written something like what Miquel did usingmtd_infoops [3]. but then developers on ML, proposed the new drivers should be form of driver-model abstraction, so I've added mtd driver model ops [4].
Quoted 7 lines
Quoted 7 lines
I understand the new MTD dm abstraction in U-Boot is not possible for direct syncing from Linux, but we really want the u-boot way of handling drivers and trying to copy code from Linux by removing
__UBOOT__or any Linux specific macros. Since this is pretty much big task, ie the reason I'm asking for single driver from each MTD device so-that once the clear stack is ready other drivers can convert one-by-one.
I think I have to repeat my previous statement here. It would be very unfortunate if u-boot decides to take this direction (see Richard's reply), especially since I see absolutely no benefit in doing what you suggest. Having MTD devices registered to the uboot DM is something I can understand, deciding to no longer support the standard MTD API is something I don't.