I've been having some trouble recently when trying to mount a SPI flash chip with the command: mount -t ext2 -r /dev/mtdblock4 /mnt/spi Resulting in the error: mount: mounting /dev/mtdblock4 on /mnt/spi failed: Invalid argument Running embedded Linux on an OMAP L138. We've recently upgraded our SPI NOR flash chips for a few prototype boards. Until recently we were using Winbond W25Q128 chips and moved to Micron N25Q256 chips due to space requirements, obsolescence, etc.
Motor drivers. Power management. I was trying to run the SDK Host tool --- SPI flash writer (spi-flash-writer.out) with CCS V5 on my DM8148 EVM board, and I got this error If I bypass this idcode check, I am able to write bytes into SPI flash using Winbond, but I always got the error. Apr 20, 2018 - Winbond spi-nor flash 32MB and larger have an 'Extended Address Register' as one option for. Drivers/mtd/spi-nor/spi-nor.c| 14 ++++++++++++++ include/linux/mtd/spi-nor.h| 2 ++ 2 files changed, 16 insertions(+) diff --git.
I've already gone through UBoot and the Linux kernel, adding an array entry for the N25Q256 chip with size, ID, etc. Below is the startup printout which leads me to believe the chip is seen and setup correctly in /dev, leading me to believe I'm missing something more subtle. 1) Have you enabled 'ext2' filesystem support in kernel through 'make menuconfig'?
To check that whether the ext2 filesystem enabled or not cat /proc/filesystem Note: I hope you can't mount filesystem in 'ext2' or 'ext3' or 'ext4' format in SPI NOR flash and This 'extended filesystem (ext)' is applicable only for MMC/SD or eMMC devices only since 'mtdblock' is different partition. 2) Try to use 'jffs2' filesystem (please enable jffs2 fs support in kernel) 3) Please use 'flasheraseall /dev/mtd4' to erase the partition and then try to mount. Root@target:/# flasheraseall /dev/mtd4 root@target:/# mount -t jffs2 /dev/mtdblock4 /mnt.
In reply to: 1) After double checking I can confirm it is indeed enabled. It's also an almost identical kernel to the one for our 16MB Winbond flash products, with the only changes being adding SPI flash entries for the new manufacturer and chip size. 2) The command mount -t jffs2 -r /dev/mtdblock4 /mnt/spi/ Succeeds, and appears to mount properly based on the following output from mount: /dev/mtdblock4 on /mnt/spi type jffs2 (ro,relatime) 3) I have not yet attempted this as the flash. commands are not currently included in our Linux filesystem. All content and materials on this site are provided 'as is'.
TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI. Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.
June 7, 2018, 5:51 a.m. + Boris + Suneel (who helped in DM MTD) + Siva, Michal (zynq qspi) On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal wrote: During the last months, Boris Brezillon shared his work to support serial flashes within Linux. First, he delivered (and merged) a new layer called spi-mem. He also initiated in Linux MTD subsystem the move of all 'raw' NAND related code to a raw/ subdirectory, adding at the same time a NAND core that would be shared with all NAND devices. Thenhe contributed a generic SPI-NAND driver, making use of this NAND coreas well as some vendor code to drive a few chips. 1) Can you pointed us the Linux changes along with discussion thread about spi-mem, and spi-nand.
2) If my understanding was correct, spi-mem is replacement for spi-nor controller drivers from driver/mtd/spi-nor in Linux. 3) If so is fslqspi spi-nor driver moves to drivers/spi area? Yes then how does flash changes handled by spi-mem. 4) we have zynq qspi controller which has extensive features like dual flash(stacked and parallel) does spi-mem support these flash specific changes? 5) Better to send spi-mem and spi-nand changes separately, for better reviewing. 6) We have DM MTD layer in ML, better to send the changes on-top 1 1 Jagan.
June 18, 2018, 8:07 a.m. Hi Jagan, On Thu, 7 Jun 2018 10:41:35 +0200 Miquel Raynal wrote: Hi JaganOn Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki wrote: + Boris + Suneel (who helped in DM MTD) + Siva, Michal (zynq qspi) On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal wrote: During the last months, Boris Brezillon shared his work to support serial flashes within Linux. First, he delivered (and merged) a new layer called spi-mem. He also initiated in Linux MTD subsystem the move of all 'raw' NAND related code to a raw/ subdirectory, adding at the same time a NAND core that would be shared with all NAND devices.
Thenhe contributed a generic SPI-NAND driver, making use of this NAND coreas well as some vendor code to drive a few chips. 1) Can you pointed us the Linux changes along with discussion thread about spi-mem, and spi-nand. Sure, you can have a look there: SPI-mem: SPI-NAND: 2) If my understanding was correct, spi-mem is replacement for spi-nor controller drivers from driver/mtd/spi-nor in Linux. It is not 'exactly' a replacement for spi-nor controller drivers but that's the idea. I suggest you to have a look at Boris' blog post about it: 3) If so is fslqspi spi-nor driver moves to drivers/spi area?
Yes then how does flash changes handled by spi-mem. This series does not migrate the SPI-NOR stack to spi-mem. It focuses on SPI-NAND for now. And I don't understand the second sentence.
4) we have zynq qspi controller which has extensive features like dual flash(stacked and parallel) does spi-mem support these flash specific changes? This controller is very specific and such support has not yet been added. 5) Better to send spi-mem and spi-nand changes separately, for better reviewing. It would mean sending 3 or 4 distinct series, I thought better to give the whole picture but that's your choice.
6) We have DM MTD layer in ML, better to send the changes on-top 1 1 This is great to see such effort being made to develop U-Boot driver-model but is there a real need for yet another layer on top of the MTD stack? I'm looking at mtd-uclass.c for instance, I don't get the need for a mtddread function, all the operations in the mtdd. helpers are already handled by mtd/mtdcore.c, no? And the mtdops structure does not bring a lot.
Should not we keep it simple and avoid such intermediate layer? Also, there is the introduction of a spinor command (what about the existing 'sf'?), which is exactly the opposite of what the MTD abstraction would told us to do (thus, the 'mtd' generic command). Any chance you can comment on Miquel's reply? That's really important to have your feedback on these questions since your answers might heavily impact the work we'll have to do to get things merged (especially question #6). Thanks, Boris.
June 25, 2018, 8:29 a.m. Miquel and Brois, thanks for working on this. On Thu, Jun 7, 2018 at 2:11 PM, Miquel Raynal wrote: Hi JaganOn Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki wrote: + Boris + Suneel (who helped in DM MTD) + Siva, Michal (zynq qspi) On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal wrote: During the last months, Boris Brezillon shared his work to support serial flashes within Linux. First, he delivered (and merged) a new layer called spi-mem. He also initiated in Linux MTD subsystem the move of all 'raw' NAND related code to a raw/ subdirectory, adding at the same time a NAND core that would be shared with all NAND devices. Thenhe contributed a generic SPI-NAND driver, making use of this NAND coreas well as some vendor code to drive a few chips.
1) Can you pointed us the Linux changes along with discussion thread about spi-mem, and spi-nand. Sure, you can have a look there: SPI-mem: SPI-NAND: This is really nice, look like this design handling any kind of controller features by abstracting spi core so-that controller hacks shouldn't touch the common core code. Unfortunately I missed Linux ML during submission. 2) If my understanding was correct, spi-mem is replacement for spi-nor controller drivers from driver/mtd/spi-nor in Linux. It is not 'exactly' a replacement for spi-nor controller drivers but that's the idea.
I suggest you to have a look at Boris' blog post about it: 3) If so is fslqspi spi-nor driver moves to drivers/spi area? Yes then how does flash changes handled by spi-mem.
This series does not migrate the SPI-NOR stack to spi-mem. It focuses on SPI-NAND for now. And I don't understand the second sentence. 4) we have zynq qspi controller which has extensive features like dual flash(stacked and parallel) does spi-mem support these flash specific changes?
This controller is very specific and such support has not yet been added. 5) Better to send spi-mem and spi-nand changes separately, for better reviewing. It would mean sending 3 or 4 distinct series, I thought better to give the whole picture but that's your choice. 6) We have DM MTD layer in ML, better to send the changes on-top 1 1 This is great to see such effort being made to develop U-Boot driver-model but is there a real need for yet another layer on top of the MTD stack? I'm looking at mtd-uclass.c for instance, I don't get the need for a mtddread function, all the operations in the mtdd. helpers are already handled by mtd/mtdcore.c, no?
And the mtdops structure does not bring a lot. Should not we keep it simple and avoid such intermediate layer? Also, there is the introduction of a spinor command (what about the existing 'sf'?), which is exactly the opposite of what the MTD abstraction would told us to do (thus, the 'mtd' generic command).
I've looked the code on the respective patches, look like most of the code copy from Linux by adding UBOOT. I have no issue with Linux copy but we need to structure the code according to U-Boot in the form of driver-model (this series lack with that). Here are my suggestions, based the MTD work so-far First we need to design MTD driver-model which can capable to drive one driver from each interface. (not converting all interface drivers at once, that is taking more time and other issues) Like Linux MTD, U-Boot should have MTD dm for underlying flash devices like nand, parallel nor, spinor etc. So to drive this theory with driver model(with an example of block layer) mtd is common device interaction for most of memory technology flashes like nand, parallel nor, spinor etc, these are treated as interface types wrt u-boot driver model. Once the respective interface driver bind happen, the uclass driver will pass an 'interface type' to mtd layer to create device for it, for example once spinor ULASSSPINOR driver bind happen, the uclass driver of spinor will pass MTDIFTYPESPINOR interface type to create mtd device for spinor devices.
So If we add this design to SPI-NAND changes, we need to implement - MTD dm core that can driver all interfaces - one driver for raw nand - one driver for spinand - spi-mem - convert fsl-qspi to spi-mem - implement command to handle For spi-nor interface design, we have an example code here2 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. June 25, 2018, 9:09 a.m. +Richard to comment on the MTD abstraction stuff and how uboot port of UBI might be impacted by some changes requested here.
Hi Jagan, On Mon, 25 Jun 2018 13:59:37 +0530 Jagan Teki wrote: I've looked the code on the respective patches, look like most of the code copy from Linux by adding UBOOT. I have no issue with Linux copy but we need to structure the code according to U-Boot in the form of driver-model (this series lack with that). Here are my suggestions, based the MTD work so-far First we need to design MTD driver-model which can capable to drive one driver from each interface. (not converting all interface drivers at once, that is taking more time and other issues) Like Linux MTD, U-Boot should have MTD dm for underlying flash devices like nand, parallel nor, spinor etc. So to drive this theory with driver model(with an example of block layer) mtd is common device interaction for most of memory technology flashes like nandparallel nor, spinor etc, these are treated as interface types wrt u-boot driver model. Once the respective interface driver bind happen, the uclass driver will pass an 'interface type' to mtd layer to create device for itfor example once spinor ULASSSPINOR driver bind happen, the uclass driver of spinor will pass MTDIFTYPESPINOR interface type to create mtd device for spinor devices.
So If we add this design to SPI-NAND changes, we need to implement - MTD dm core that can driver all interfaces That's already what the MTD framework provides, and Miquel even added some stuff to integrate the MTD layer even further in the DM. It's probably not perfect yet, but the changes are, IMHO, going in the right direction. Now, if you're talking about the new MTD API that creates helper functions prefixed with dm, sorry, but I don't see the point. We already have plenty of MTD users in u-boot, they all manipulate MTD objects and go through the standard MTD API to do that. What you suggest would make things messier for several reasons: 1/ we won't be able to easily port Linux code to u-boot.
Look at the JFFS2 UBI support. They all use mtdinfo objects. What's the point of changing that except making things harder to port. 2/ Not all MTD providers will be converted to the device model at once, so how do you plan to deal with that? 3/ What's the benefit of exposing yet another way to manipulate MTD devices?
- one driver for raw nand Unfortunately, that's not how it works right now, and clearly, we don't have time to work on this raw NAND rework right now. - one driver for spinand I think that's already the case. - spi-mem It's also what Miquel is doing in this series. - 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. - implement command to handle This I don't get. What do you mean by 'implement command to handle'? Are we talking about cmd/mtd.c? I think the work Miquel has done is already a good start, what's missing in there? For spi-nor interface design, we have an example code here2 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. June 25, 2018, 12:38 p.m. Am Montag, 25. Juni 2018, 11:09:41 CEST schrieb Boris Brezillon: +Richard to comment on the MTD abstraction stuff and how uboot port of UBI might be impacted by some changes requested here. Hi JaganOn Mon, 25 Jun 2018 13:59:37 +0530 Jagan Teki wrote: I've looked the code on the respective patches, look like most of the code copy from Linux by adding UBOOT.
I have no issue with Linux copy but we need to structure the code according to U-Boot in the form of driver-model (this series lack with that). Here are my suggestions, based the MTD work so-far First we need to design MTD driver-model which can capable to drive one driver from each interface. (not converting all interface drivers at once, that is taking more time and other issues) Like Linux MTD, U-Boot should have MTD dm for underlying flash devices like nand, parallel nor, spinor etc. So to drive this theory with driver model(with an example of block layer) mtd is common device interaction for most of memory technology flashes like nandparallel nor, spinor etc, these are treated as interface types wrt u-boot driver model. Once the respective interface driver bind happen, the uclass driver will pass an 'interface type' to mtd layer to create device for itfor example once spinor ULASSSPINOR driver bind happen, the uclass driver of spinor will pass MTDIFTYPESPINOR interface type to create mtd device for spinor devices. So If we add this design to SPI-NAND changes, we need to implement - MTD dm core that can driver all interfaces That's already what the MTD framework provides, and Miquel even added some stuff to integrate the MTD layer even further in the DM.
It's probably not perfect yet, but the changes are, IMHO, going in the right direction. Now, if you're talking about the new MTD API that creates helper functions prefixed with dm, sorry, but I don't see the point. We already have plenty of MTD users in u-boot, they all manipulate MTD objects and go through the standard MTD API to do that. What you suggest would make things messier for several reasons: 1/ we won't be able to easily port Linux code to u-boot.
Look at the JFFS2 UBI support. They all use mtdinfo objects. What's the point of changing that except making things harder to port. 2/ Not all MTD providers will be converted to the device model at onceso how do you plan to deal with that? 3/ What's the benefit of exposing yet another way to manipulate MTD devices? - one driver for raw nand Unfortunately, that's not how it works right now, and clearly, we don't have time to work on this raw NAND rework right now. - one driver for spinand I think that's already the case.
- spi-mem It's also what Miquel is doing in this series. - 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. - implement command to handle This I don't get. What do you mean by 'implement command to handle'?
Are we talking about cmd/mtd.c? I think the work Miquel has done is already a good start, what's missing in there? For spi-nor interface design, we have an example code here2 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. June 25, 2018, 2:27 p.m. + Simon + Tom (suggesting MTD driver model abstraction layer) On Mon, Jun 25, 2018 at 2:39 PM, Boris Brezillon wrote: +Richard to comment on the MTD abstraction stuff and how uboot port of UBI might be impacted by some changes requested here. Hi JaganOn Mon, 25 Jun 2018 13:59:37 +0530 Jagan Teki wrote: I've looked the code on the respective patches, look like most of the code copy from Linux by adding UBOOT.
I have no issue with Linux copy but we need to structure the code according to U-Boot in the form of driver-model (this series lack with that). Here are my suggestions, based the MTD work so-far First we need to design MTD driver-model which can capable to drive one driver from each interface. (not converting all interface drivers at once, that is taking more time and other issues) Like Linux MTD, U-Boot should have MTD dm for underlying flash devices like nand, parallel nor, spinor etc.
So to drive this theory with driver model(with an example of block layer) mtd is common device interaction for most of memory technology flashes like nandparallel nor, spinor etc, these are treated as interface types wrt u-boot driver model. Once the respective interface driver bind happen, the uclass driver will pass an 'interface type' to mtd layer to create device for itfor example once spinor ULASSSPINOR driver bind happen, the uclass driver of spinor will pass MTDIFTYPESPINOR interface type to create mtd device for spinor devices. So If we add this design to SPI-NAND changes, we need to implement - MTD dm core that can driver all interfaces That's already what the MTD framework provides, and Miquel even added some stuff to integrate the MTD layer even further in the DM. It's probably not perfect yet, but the changes are, IMHO, going in the right direction. Now, if you're talking about the new MTD API that creates helper functions prefixed with dm, sorry, but I don't see the point.
We already have plenty of MTD users in u-boot, they all manipulate MTD objects and go through the standard MTD API to do that. What you suggest would make things messier for several reasons: 1/ we won't be able to easily port Linux code to u-boot.
Look at the JFFS2 UBI support. They all use mtdinfo objects. What's the point of changing that except making things harder to port. 2/ Not all MTD providers will be converted to the device model at onceso how do you plan to deal with that? 3/ What's the benefit of exposing yet another way to manipulate MTD devices? - one driver for raw nand Unfortunately, that's not how it works right now, and clearly, we don't have time to work on this raw NAND rework right now.
- one driver for spinand I think that's already the case. - spi-mem It's also what Miquel is doing in this series. - 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? - implement command to handle This I don't get. What do you mean by 'implement command to handle'? Are we talking about cmd/mtd.c? I think the work Miquel has done is already a good start, what's missing in there? For spi-nor interface design, we have an example code here2 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. June 25, 2018, 2:28 p.m. + Simon + Tom On Mon, Jun 25, 2018 at 7:57 PM, Jagan Teki wrote: + Simon + Tom (suggesting MTD driver model abstraction layer) On Mon, Jun 25, 2018 at 2:39 PM, Boris Brezillon wrote: +Richard to comment on the MTD abstraction stuff and how uboot port of UBI might be impacted by some changes requested here. Hi JaganOn Mon, 25 Jun 2018 13:59:37 +0530 Jagan Teki wrote: I've looked the code on the respective patches, look like most of the code copy from Linux by adding UBOOT.
I have no issue with Linux copy but we need to structure the code according to U-Boot in the form of driver-model (this series lack with that). Here are my suggestions, based the MTD work so-far First we need to design MTD driver-model which can capable to drive one driver from each interface. (not converting all interface drivers at once, that is taking more time and other issues) Like Linux MTD, U-Boot should have MTD dm for underlying flash devices like nand, parallel nor, spinor etc. So to drive this theory with driver model(with an example of block layer) mtd is common device interaction for most of memory technology flashes like nandparallel nor, spinor etc, these are treated as interface types wrt u-boot driver model.
Once the respective interface driver bind happen, the uclass driver will pass an 'interface type' to mtd layer to create device for itfor example once spinor ULASSSPINOR driver bind happen, the uclass driver of spinor will pass MTDIFTYPESPINOR interface type to create mtd device for spinor devices. So If we add this design to SPI-NAND changes, we need to implement - MTD dm core that can driver all interfaces That's already what the MTD framework provides, and Miquel even added some stuff to integrate the MTD layer even further in the DM. It's probably not perfect yet, but the changes are, IMHO, going in the right direction.
Now, if you're talking about the new MTD API that creates helper functions prefixed with dm, sorry, but I don't see the point. We already have plenty of MTD users in u-boot, they all manipulate MTD objects and go through the standard MTD API to do that. What you suggest would make things messier for several reasons: 1/ we won't be able to easily port Linux code to u-boot. Look at the JFFS2 UBI support. They all use mtdinfo objects. What's the point of changing that except making things harder to port.
2/ Not all MTD providers will be converted to the device model at onceso how do you plan to deal with that? 3/ What's the benefit of exposing yet another way to manipulate MTD devices? - one driver for raw nand Unfortunately, that's not how it works right now, and clearly, we don't have time to work on this raw NAND rework right now.
- one driver for spinand I think that's already the case. - spi-mem It's also what Miquel is doing in this series. - 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? - implement command to handle This I don't get. What do you mean by 'implement command to handle'? Are we talking about cmd/mtd.c? I think the work Miquel has done is already a good start, what's missing in there? For spi-nor interface design, we have an example code here2 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. June 25, 2018, 2:36 p.m. Am Montag, 25. Juni 2018, 16:27:45 CEST schrieb Jagan Teki: 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. Do you have the man power to massage/backport all Linux changes/fixes to u-boot?
Thanks, //richard. June 25, 2018, 2:46 p.m. On Mon, 25 Jun 2018 19:58:37 +0530 Jagan Teki wrote: - 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 spimemop using regular transfer and that's why it works without any modification at the driver level.
For spi-nor interface design, we have an example code here2 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. June 25, 2018, 2:55 p.m. On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote: On Mon, 25 Jun 2018 19:58:37 +0530 Jagan Teki wrote: - 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 spimemop using regular transfer and that's why it works without any modification at the driver level. For spi-nor interface design, we have an example code here2 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.
June 25, 2018, 2:59 p.m. On 16:55, Tom Rini wrote: On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote: On Mon, 25 Jun 2018 19:58:37 +0530 Jagan Teki wrote: - 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 spimemop using regular transfer and that's why it works without any modification at the driver level. For spi-nor interface design, we have an example code here2 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. June 25, 2018, 6:37 p.m. On Mon, Jun 25, 2018 at 8:25 PM, Tom Rini wrote: On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote: On Mon, 25 Jun 2018 19:58:37 +0530 Jagan Teki wrote: - 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 spimemop using regular transfer and that's why it works without any modification at the driver level. For spi-nor interface design, we have an example code here2 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. June 25, 2018, 7:58 p.m.
On Tue, 26 Jun 2018 00:07:10 +0530 Jagan Teki wrote: 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. I agree. We want U-Boot to be able to leverage as much as possible from the Linux kernel with as little re-working as possible. I'm not denying that, but the basic design flow must follow u-boot driver model.
This is what everyone told from the beginning when I started spi-nor work. Initially I did the design like this and leverage with existing MTD, everyone NAK and suggested to use driver-model on each stage with MTD dm abstraction. So - After 2 years of work - With nearly 10 versions 4 - Adding MIGRATION expire date for spi drivers dm conversion - Simon Reviewed-by and - Planning to apply after v2018.09. but now all want the existing MTD, I don't understand what I can do further on this?
I didn't follow the initial discussion, but I can understand your frustration. Still, I think there's a misunderstanding here. I recommend that you have a second look at the different patches in this series. You'll see that everything Miquel did complies with the DM, and that the thing you're complaining about (MTD API not using udevice and not prefixed with dm) is just a tiny detail compared to the rest. Keeping the MTD API is not incompatible with the conversion of all MTD provider drivers to the DM. I think we all agree on that MTD providers should be converted to the DM progressively, and the work Miquel did allows such a smooth transition because both non-DM drivers and DM-compliant drivers can co-exist without impacting MTD users.
Sorry to say that, but your approach based on full-conversion is just an utopia. There's no way we can do that in a single step.
So the question here is more, should we block all developments until we have a perfect solution (I don't think perfection can be achieved without trying things and making mistake), or should we move forward, one step after the other and keep the 'conversion of all MTD drivers to the DM' as a long term goal? June 25, 2018, 8:01 p.m. On Mon, Jun 25, 2018 at 09:58:39PM +0200, Boris Brezillon wrote: On Tue, 26 Jun 2018 00:07:10 +0530 Jagan Teki wrote: 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. I agree.
We want U-Boot to be able to leverage as much as possible from the Linux kernel with as little re-working as possible. I'm not denying that, but the basic design flow must follow u-boot driver model.
This is what everyone told from the beginning when I started spi-nor work. Initially I did the design like this and leverage with existing MTD, everyone NAK and suggested to use driver-model on each stage with MTD dm abstraction.
So - After 2 years of work - With nearly 10 versions 4 - Adding MIGRATION expire date for spi drivers dm conversion - Simon Reviewed-by and - Planning to apply after v2018.09. but now all want the existing MTD, I don't understand what I can do further on this?
I didn't follow the initial discussion, but I can understand your frustration. Still, I think there's a misunderstanding here. I recommend that you have a second look at the different patches in this series. You'll see that everything Miquel did complies with the DM, and that the thing you're complaining about (MTD API not using udevice and not prefixed with dm) is just a tiny detail compared to the rest. Keeping the MTD API is not incompatible with the conversion of all MTD provider drivers to the DM.
I think we all agree on that MTD providers should be converted to the DM progressively, and the work Miquel did allows such a smooth transition because both non-DM drivers and DM-compliant drivers can co-exist without impacting MTD users. Sorry to say that, but your approach based on full-conversion is just an utopia. There's no way we can do that in a single step. So the question here is more, should we block all developments until we have a perfect solution (I don't think perfection can be achieved without trying things and making mistake), or should we move forwardone step after the other and keep the 'conversion of all MTD drivers to the DM' as a long term goal? And furthermore, we really need to get this area un-blocked. I feel bad that Jagan's series went on for so long, but I think it also highlights the problem with a convert-everything-at-once-try-and-be-perfect approach.
June 27, 2018, 11:43 a.m. On Tue, Jun 26, 2018 at 1:28 AM, Boris Brezillon wrote: On Tue, 26 Jun 2018 00:07:10 +0530 Jagan Teki wrote: 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. I agree. We want U-Boot to be able to leverage as much as possible from the Linux kernel with as little re-working as possible. I'm not denying that, but the basic design flow must follow u-boot driver model. This is what everyone told from the beginning when I started spi-nor work. Initially I did the design like this and leverage with existing MTD, everyone NAK and suggested to use driver-model on each stage with MTD dm abstraction. So - After 2 years of work - With nearly 10 versions 4 - Adding MIGRATION expire date for spi drivers dm conversion - Simon Reviewed-by and - Planning to apply after v2018.09.
but now all want the existing MTD, I don't understand what I can do further on this? I didn't follow the initial discussion, but I can understand your frustration. Still, I think there's a misunderstanding here. I recommend that you have a second look at the different patches in this series.
You'll see that everything Miquel did complies with the DM, and that the thing you're complaining about (MTD API not using udevice and not prefixed with dm) is just a tiny detail compared to the rest. Keeping the MTD API is not incompatible with the conversion of all MTD provider drivers to the DM.
I think we all agree on that MTD providers should be converted to the DM progressively, and the work Miquel did allows such a smooth transition because both non-DM drivers and DM-compliant drivers can co-exist without impacting MTD users. Sorry to say that, but your approach based on full-conversion is just an utopia. There's no way we can do that in a single step. So the question here is more, should we block all developments until we have a perfect solution (I don't think perfection can be achieved without trying things and making mistake), or should we move forwardone step after the other and keep the 'conversion of all MTD drivers to the DM' as a long term goal? Thanks for explaining all these Boris.
I agree on the context of 'not to block the development' for the sake of new improvement solution. Yes I will start reviewing these stuff, even thought these are not compatible with MTD DM providers. Mean while I will keep moving spi-nor development with MTD DM providers along with Linux changes and it should be a starting point for full DM conversion for MTD layer.