Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On Fri, Jul 06, 2018 at 05:45:02PM +0530, Jagan Teki wrote:
> On Fri, Jul 6, 2018 at 5:36 PM, Miquel Raynal
> wrote:
> > Hi Jagan,
> >
> > Jagan Teki wrote on Fri, 6 Jul 2018
> > 17:13:21 +0530:
> >
> >> 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. Then,
> >> > he contributed a generic SPI-NAND driver, making use of this NAND core,
> >> > as well as some vendor code to drive a few chips.
> >> >
> >> > On top of this work, I added an 'mtd' U-Boot command to handle all sort
> >> > of MTD devices. This should become the default command instead of having
> >> > one per flash flavor ('sf', 'nand', 'spi-nand' ?).
> >> >
> >> > The series has been tested on an Ocelot board PCB123 (VSC7514),
> >> > featuring a Macronix SPI NAND chip.
> >> >
> >> > TL;DR: the series contains:
> >> > - Various fixes and re-organization of the MTD subsystem.
> >> > - The introduction of the SPI-mem interface.
> >> > - The addition of the generic SPI-NAND driver (and its bindings).
> >> > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> >> > - A new 'mtd' command.
> >> > - DT changes to make use of a SPI NAND on the Ocelot board.
> >> >
> >> > Any comments on the code, the organization and the respect of U-Boot
> >> > driver model will be welcome.
> >> >
> >> > Thanks,
> >> > Miquèl
> >> >
> >> >
> >> > Boris Brezillon (6):
> >> > mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
> >> > mtd: nand: Add core infrastructure to deal with NAND devices
> >> > mtd: nand: Pass mode information to nand_page_io_req
> >> > spi: Extend the core to ease integration of SPI memory controllers
> >> > mtd: spinand: Add initial support for the MX35LF1GE4AB chip
> >> > dt-bindings: Add bindings for SPI NAND devices
> >> >
> >> > Brian Norris (1):
> >> > mtd: add get/set of_node/flash_node helpers
> >> >
> >> > Frieder Schrempf (1):
> >> > mtd: spinand: Add initial support for Winbond W25M02GV
> >> >
> >> > Miquel Raynal (10):
> >> > mtd: fix build issue with includes
> >> > mtd: move definitions to enlarge their range
> >> > mtd: move all flash categories inside MTD submenu
> >> > mtd: move NAND fiels into a raw/ subdirectory
> >> > mtd: rename nand into rawnand in Kconfig prompt
> >> > mtd: spinand: Add initial support for the MX35LF2GE4AB chip
> >> > mtd: uclass: add probe function
> >> > cmd: mtd: add 'mtd' command
> >> > mips: dts: ocelot: describe SPI CS pins
> >> > mips: dts: ocelot: add the SPI NAND node
> >> >
> >> > Peter Pan (2):
> >> > mtd: nand: Add core infrastructure to support SPI NANDs
> >> > mtd: spinand: Add initial support for Micron MT29F2G01ABAGD
> >>
> >> I have reviewed and commented most of the stuff that are in my
> >> control, except few spi-nand code, which I would like to give a try to
> >> other people in the list. Hope to seen the fine-tuning patches on next
> >> version.
> >
> > Thanks for taking the time to review all this; I'm on it.
> >
> > About spi-nand, reviews from other contributors are welcome, but it's
> > mostly a copy from Linux framework that I just applied to nand/next.
> > There have been 9 versions of it before that so I think it's pretty
> > well reviewed.
>
> OK, that's fine then.
If everyone is agreeable I would like to see this in the v2018.09
release. Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On Fri, Jul 6, 2018 at 5:36 PM, Miquel Raynal wrote:
> Hi Jagan,
>
> Jagan Teki wrote on Fri, 6 Jul 2018
> 17:13:21 +0530:
>
>> 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. Then,
>> > he contributed a generic SPI-NAND driver, making use of this NAND core,
>> > as well as some vendor code to drive a few chips.
>> >
>> > On top of this work, I added an 'mtd' U-Boot command to handle all sort
>> > of MTD devices. This should become the default command instead of having
>> > one per flash flavor ('sf', 'nand', 'spi-nand' ?).
>> >
>> > The series has been tested on an Ocelot board PCB123 (VSC7514),
>> > featuring a Macronix SPI NAND chip.
>> >
>> > TL;DR: the series contains:
>> > - Various fixes and re-organization of the MTD subsystem.
>> > - The introduction of the SPI-mem interface.
>> > - The addition of the generic SPI-NAND driver (and its bindings).
>> > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
>> > - A new 'mtd' command.
>> > - DT changes to make use of a SPI NAND on the Ocelot board.
>> >
>> > Any comments on the code, the organization and the respect of U-Boot
>> > driver model will be welcome.
>> >
>> > Thanks,
>> > Miquèl
>> >
>> >
>> > Boris Brezillon (6):
>> > mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
>> > mtd: nand: Add core infrastructure to deal with NAND devices
>> > mtd: nand: Pass mode information to nand_page_io_req
>> > spi: Extend the core to ease integration of SPI memory controllers
>> > mtd: spinand: Add initial support for the MX35LF1GE4AB chip
>> > dt-bindings: Add bindings for SPI NAND devices
>> >
>> > Brian Norris (1):
>> > mtd: add get/set of_node/flash_node helpers
>> >
>> > Frieder Schrempf (1):
>> > mtd: spinand: Add initial support for Winbond W25M02GV
>> >
>> > Miquel Raynal (10):
>> > mtd: fix build issue with includes
>> > mtd: move definitions to enlarge their range
>> > mtd: move all flash categories inside MTD submenu
>> > mtd: move NAND fiels into a raw/ subdirectory
>> > mtd: rename nand into rawnand in Kconfig prompt
>> > mtd: spinand: Add initial support for the MX35LF2GE4AB chip
>> > mtd: uclass: add probe function
>> > cmd: mtd: add 'mtd' command
>> > mips: dts: ocelot: describe SPI CS pins
>> > mips: dts: ocelot: add the SPI NAND node
>> >
>> > Peter Pan (2):
>> > mtd: nand: Add core infrastructure to support SPI NANDs
>> > mtd: spinand: Add initial support for Micron MT29F2G01ABAGD
>>
>> I have reviewed and commented most of the stuff that are in my
>> control, except few spi-nand code, which I would like to give a try to
>> other people in the list. Hope to seen the fine-tuning patches on next
>> version.
>
> Thanks for taking the time to review all this; I'm on it.
>
> About spi-nand, reviews from other contributors are welcome, but it's
> mostly a copy from Linux framework that I just applied to nand/next.
> There have been 9 versions of it before that so I think it's pretty
> well reviewed.
OK, that's fine then.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Hi Jagan,
Jagan Teki wrote on Fri, 6 Jul 2018
17:13:21 +0530:
> 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. Then,
> > he contributed a generic SPI-NAND driver, making use of this NAND core,
> > as well as some vendor code to drive a few chips.
> >
> > On top of this work, I added an 'mtd' U-Boot command to handle all sort
> > of MTD devices. This should become the default command instead of having
> > one per flash flavor ('sf', 'nand', 'spi-nand' ?).
> >
> > The series has been tested on an Ocelot board PCB123 (VSC7514),
> > featuring a Macronix SPI NAND chip.
> >
> > TL;DR: the series contains:
> > - Various fixes and re-organization of the MTD subsystem.
> > - The introduction of the SPI-mem interface.
> > - The addition of the generic SPI-NAND driver (and its bindings).
> > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> > - A new 'mtd' command.
> > - DT changes to make use of a SPI NAND on the Ocelot board.
> >
> > Any comments on the code, the organization and the respect of U-Boot
> > driver model will be welcome.
> >
> > Thanks,
> > Miquèl
> >
> >
> > Boris Brezillon (6):
> > mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
> > mtd: nand: Add core infrastructure to deal with NAND devices
> > mtd: nand: Pass mode information to nand_page_io_req
> > spi: Extend the core to ease integration of SPI memory controllers
> > mtd: spinand: Add initial support for the MX35LF1GE4AB chip
> > dt-bindings: Add bindings for SPI NAND devices
> >
> > Brian Norris (1):
> > mtd: add get/set of_node/flash_node helpers
> >
> > Frieder Schrempf (1):
> > mtd: spinand: Add initial support for Winbond W25M02GV
> >
> > Miquel Raynal (10):
> > mtd: fix build issue with includes
> > mtd: move definitions to enlarge their range
> > mtd: move all flash categories inside MTD submenu
> > mtd: move NAND fiels into a raw/ subdirectory
> > mtd: rename nand into rawnand in Kconfig prompt
> > mtd: spinand: Add initial support for the MX35LF2GE4AB chip
> > mtd: uclass: add probe function
> > cmd: mtd: add 'mtd' command
> > mips: dts: ocelot: describe SPI CS pins
> > mips: dts: ocelot: add the SPI NAND node
> >
> > Peter Pan (2):
> > mtd: nand: Add core infrastructure to support SPI NANDs
> > mtd: spinand: Add initial support for Micron MT29F2G01ABAGD
>
> I have reviewed and commented most of the stuff that are in my
> control, except few spi-nand code, which I would like to give a try to
> other people in the list. Hope to seen the fine-tuning patches on next
> version.
Thanks for taking the time to review all this; I'm on it.
About spi-nand, reviews from other contributors are welcome, but it's
mostly a copy from Linux framework that I just applied to nand/next.
There have been 9 versions of it before that so I think it's pretty
well reviewed.
Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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. Then,
> he contributed a generic SPI-NAND driver, making use of this NAND core,
> as well as some vendor code to drive a few chips.
>
> On top of this work, I added an 'mtd' U-Boot command to handle all sort
> of MTD devices. This should become the default command instead of having
> one per flash flavor ('sf', 'nand', 'spi-nand' ?).
>
> The series has been tested on an Ocelot board PCB123 (VSC7514),
> featuring a Macronix SPI NAND chip.
>
> TL;DR: the series contains:
> - Various fixes and re-organization of the MTD subsystem.
> - The introduction of the SPI-mem interface.
> - The addition of the generic SPI-NAND driver (and its bindings).
> - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> - A new 'mtd' command.
> - DT changes to make use of a SPI NAND on the Ocelot board.
>
> Any comments on the code, the organization and the respect of U-Boot
> driver model will be welcome.
>
> Thanks,
> Miquèl
>
>
> Boris Brezillon (6):
> mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
> mtd: nand: Add core infrastructure to deal with NAND devices
> mtd: nand: Pass mode information to nand_page_io_req
> spi: Extend the core to ease integration of SPI memory controllers
> mtd: spinand: Add initial support for the MX35LF1GE4AB chip
> dt-bindings: Add bindings for SPI NAND devices
>
> Brian Norris (1):
> mtd: add get/set of_node/flash_node helpers
>
> Frieder Schrempf (1):
> mtd: spinand: Add initial support for Winbond W25M02GV
>
> Miquel Raynal (10):
> mtd: fix build issue with includes
> mtd: move definitions to enlarge their range
> mtd: move all flash categories inside MTD submenu
> mtd: move NAND fiels into a raw/ subdirectory
> mtd: rename nand into rawnand in Kconfig prompt
> mtd: spinand: Add initial support for the MX35LF2GE4AB chip
> mtd: uclass: add probe function
> cmd: mtd: add 'mtd' command
> mips: dts: ocelot: describe SPI CS pins
> mips: dts: ocelot: add the SPI NAND node
>
> Peter Pan (2):
> mtd: nand: Add core infrastructure to support SPI NANDs
> mtd: spinand: Add initial support for Micron MT29F2G01ABAGD
I have reviewed and commented most of the stuff that are in my
control, except few spi-nand code, which I would like to give a try to
other people in the list. Hope to seen the fine-tuning patches on next
version.
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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 forward, > one 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. Jagan. -- Jagan Teki Senior Linux Kernel Engineer | Amarula Solutions U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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 forward, > one 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. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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 spi_mem_op 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 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 the MTD_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 the cmd/mtd.c command set >> > >> >> > >> 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.c merged >> > >> 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 using mtd_info ops [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]. >> > > >> > > 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. > > 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? [4] https://patchwork.ozlabs.org/user/todo/uboot/?series=20450 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On 25.06.2018 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 spi_mem_op 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 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 the MTD_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 the cmd/mtd.c command set 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.c merged 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 using mtd_info ops [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]. 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. 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 wholeheartedly agree on this. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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 spi_mem_op 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 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 the MTD_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 the cmd/mtd.c command set > > >> > > >> 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.c merged > > >> 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 using mtd_info ops [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]. > > > > > > 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. 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. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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 spi_mem_op 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 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 the MTD_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 the cmd/mtd.c command set > >> > >> 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.c merged > >> 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 using mtd_info ops [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]. > > > > 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. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
+ 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 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 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 ULASS_SPI_NOR driver bind happen, the uclass >>> driver of spinor will pass MTD_IF_TYPE_SPI_NOR >>> 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 mtd_info 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. > > 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 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 the MTD_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 the cmd/mtd.c command set >> >> 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.c merged >> is way more than we can actually
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
+ 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 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 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 ULASS_SPI_NOR driver bind happen, the uclass >> driver of spinor will pass MTD_IF_TYPE_SPI_NOR >> 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 mtd_info 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. 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 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 the MTD_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 the cmd/mtd.c command set > > 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.c merged > 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
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
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 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 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 ULASS_SPI_NOR driver bind happen, the uclass > > driver of spinor will pass MTD_IF_TYPE_SPI_NOR > > 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 mtd_info 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 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 the MTD_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 the cmd/mtd.c command set > > 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.c merged > is way more than we can actually provide. +1 As someone who is concerned that UBI and UBIFS are sane within u-boot I'm not at all in favor of adding such a layer. The current MTD framework does not need another abstraction level. It will make keeping u-boot in sync
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
+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 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 ULASS_SPI_NOR driver bind happen, the uclass > driver of spinor will pass MTD_IF_TYPE_SPI_NOR > 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 mtd_info 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 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 the MTD_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 the cmd/mtd.c command set 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.c merged is way more than we can actually provide. Regards, Boris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Miquel and Brois, thanks for working on this. On Thu, Jun 7, 2018 at 2:11 PM, Miquel Raynal wrote: > Hi Jagan, > > On 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. Then, >> > he contributed a generic SPI-NAND driver, making use of this NAND core, >> > as 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: > http://lists.infradead.org/pipermail/linux-mtd/2018-April/080225.html > > SPI-NAND: > http://lists.infradead.org/pipermail/linux-mtd/2018-May/081005.html 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: > https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ > >> >> 3) If so is fsl_qspi 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] https://patchwork.ozlabs.org/project/uboot/list/?series=20450 > > 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 > mtd_dread() function, all the operations in the mtd_d*() helpers are > already handled by mtd/mtdcore.c, no? > > And the mtd_ops 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 ULASS_SPI_NOR driver bind happen, the uclass driver of spinor will pass MTD_IF_TYPE_SPI_NOR 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 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
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Hi Stefan,
On Tue, 12 Jun 2018 16:14:19 +0200, Stefan Roese wrote:
> Hi Miquèl,
>
> On 06.06.2018 17:30, 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. Then,
> > he contributed a generic SPI-NAND driver, making use of this NAND core,
> > as well as some vendor code to drive a few chips.
> > > On top of this work, I added an 'mtd' U-Boot command to handle all sort
> > of MTD devices. This should become the default command instead of having
> > one per flash flavor ('sf', 'nand', 'spi-nand' ?).
>
> Interesting. I like this idea.
>
> BTW: I also would like to see the ubifs commands being supported
> by the common file commands, like "ls" and "load". But this just
> came to my mind right now (again) and definitely has nothing to
> do with your current work on SPI NAND.
>
> > The series has been tested on an Ocelot board PCB123 (VSC7514),
> > featuring a Macronix SPI NAND chip.
> > > TL;DR: the series contains:
> > - Various fixes and re-organization of the MTD subsystem.
> > - The introduction of the SPI-mem interface.
> > - The addition of the generic SPI-NAND driver (and its bindings).
> > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> > - A new 'mtd' command.
> > - DT changes to make use of a SPI NAND on the Ocelot board.
> > > Any comments on the code, the organization and the respect of U-Boot
> > driver model will be welcome.
>
> Many thanks for working on this. I might get access to a new
> platform in a few days, requiring SPI NAND support. So I tried to
Thanks, testing will be appreciated!
> apply your patches on top of current mainline, which unfortunately
> fails with some patches.
>
> Would it be possible for you to rebase your patches on top
> of current mainline U-Boot? Best would be to also push a git
> branch with your patches / changes. This way you don't need
> to re-send all those patches to the list, without any real
> changes done.
Mmmh. Sorry for that. Please have a look at this branch, the work is
based on top of v2018.03:
https://github.com/miquelraynal/u-boot/commits/public/spi-nand
>
> Thanks,
> Stefan
Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Hi Jagan, On Thu, 7 Jun 2018 10:41:35 +0200 Miquel Raynal wrote: > Hi Jagan, > > On 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. Then, > > > he contributed a generic SPI-NAND driver, making use of this NAND core, > > > as 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: > http://lists.infradead.org/pipermail/linux-mtd/2018-April/080225.html > > SPI-NAND: > http://lists.infradead.org/pipermail/linux-mtd/2018-May/081005.html > > > > > 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: > https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ > > > > > 3) If so is fsl_qspi 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] https://patchwork.ozlabs.org/project/uboot/list/?series=20450 > > 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 > mtd_dread() function, all the operations in the mtd_d*() helpers are > already handled by mtd/mtdcore.c, no? > > And the mtd_ops 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Hi Miquèl,
On 06.06.2018 17:30, 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. Then,
he contributed a generic SPI-NAND driver, making use of this NAND core,
as well as some vendor code to drive a few chips.
On top of this work, I added an 'mtd' U-Boot command to handle all sort
of MTD devices. This should become the default command instead of having
one per flash flavor ('sf', 'nand', 'spi-nand' ?).
Interesting. I like this idea.
BTW: I also would like to see the ubifs commands being supported
by the common file commands, like "ls" and "load". But this just
came to my mind right now (again) and definitely has nothing to
do with your current work on SPI NAND.
The series has been tested on an Ocelot board PCB123 (VSC7514),
featuring a Macronix SPI NAND chip.
TL;DR: the series contains:
- Various fixes and re-organization of the MTD subsystem.
- The introduction of the SPI-mem interface.
- The addition of the generic SPI-NAND driver (and its bindings).
- Several SPI NAND chip drivers (Macronix, Micron, Winbond).
- A new 'mtd' command.
- DT changes to make use of a SPI NAND on the Ocelot board.
Any comments on the code, the organization and the respect of U-Boot
driver model will be welcome.
Many thanks for working on this. I might get access to a new
platform in a few days, requiring SPI NAND support. So I tried to
apply your patches on top of current mainline, which unfortunately
fails with some patches.
Would it be possible for you to rebase your patches on top
of current mainline U-Boot? Best would be to also push a git
branch with your patches / changes. This way you don't need
to re-send all those patches to the list, without any real
changes done.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Hi Jagan, On 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. Then, > > he contributed a generic SPI-NAND driver, making use of this NAND core, > > as 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: http://lists.infradead.org/pipermail/linux-mtd/2018-April/080225.html SPI-NAND: http://lists.infradead.org/pipermail/linux-mtd/2018-May/081005.html > > 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: https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ > > 3) If so is fsl_qspi 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] https://patchwork.ozlabs.org/project/uboot/list/?series=20450 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 mtd_dread() function, all the operations in the mtd_d*() helpers are already handled by mtd/mtdcore.c, no? And the mtd_ops 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). Regards, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
+ 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. Then, > he contributed a generic SPI-NAND driver, making use of this NAND core, > as 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 fsl_qspi 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] https://patchwork.ozlabs.org/project/uboot/list/?series=20450 Jagan. -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 00/20] SPI-NAND support
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. Then,
he contributed a generic SPI-NAND driver, making use of this NAND core,
as well as some vendor code to drive a few chips.
On top of this work, I added an 'mtd' U-Boot command to handle all sort
of MTD devices. This should become the default command instead of having
one per flash flavor ('sf', 'nand', 'spi-nand' ?).
The series has been tested on an Ocelot board PCB123 (VSC7514),
featuring a Macronix SPI NAND chip.
TL;DR: the series contains:
- Various fixes and re-organization of the MTD subsystem.
- The introduction of the SPI-mem interface.
- The addition of the generic SPI-NAND driver (and its bindings).
- Several SPI NAND chip drivers (Macronix, Micron, Winbond).
- A new 'mtd' command.
- DT changes to make use of a SPI NAND on the Ocelot board.
Any comments on the code, the organization and the respect of U-Boot
driver model will be welcome.
Thanks,
Miquèl
Boris Brezillon (6):
mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
mtd: nand: Add core infrastructure to deal with NAND devices
mtd: nand: Pass mode information to nand_page_io_req
spi: Extend the core to ease integration of SPI memory controllers
mtd: spinand: Add initial support for the MX35LF1GE4AB chip
dt-bindings: Add bindings for SPI NAND devices
Brian Norris (1):
mtd: add get/set of_node/flash_node helpers
Frieder Schrempf (1):
mtd: spinand: Add initial support for Winbond W25M02GV
Miquel Raynal (10):
mtd: fix build issue with includes
mtd: move definitions to enlarge their range
mtd: move all flash categories inside MTD submenu
mtd: move NAND fiels into a raw/ subdirectory
mtd: rename nand into rawnand in Kconfig prompt
mtd: spinand: Add initial support for the MX35LF2GE4AB chip
mtd: uclass: add probe function
cmd: mtd: add 'mtd' command
mips: dts: ocelot: describe SPI CS pins
mips: dts: ocelot: add the SPI NAND node
Peter Pan (2):
mtd: nand: Add core infrastructure to support SPI NANDs
mtd: spinand: Add initial support for Micron MT29F2G01ABAGD
arch/mips/dts/mscc,ocelot.dtsi| 20 +
arch/mips/dts/mscc,ocelot_pcb.dtsi|9 +
cmd/Kconfig |5 +
cmd/Makefile |1 +
cmd/mtd.c | 280 ++
doc/device-tree-bindings/mtd/spi-nand.txt | 27 +
drivers/mtd/Kconfig |4 +-
drivers/mtd/Makefile |4 +-
drivers/mtd/mtd-uclass.c |9 +
drivers/mtd/mtdcore.c | 31 +-
drivers/mtd/mtdcore.h |6 -
drivers/mtd/mtdpart.c |6 +-
drivers/mtd/nand/Kconfig | 241 +
drivers/mtd/nand/Makefile | 81 +-
drivers/mtd/nand/bbt.c| 132 +++
drivers/mtd/nand/core.c | 243 +
drivers/mtd/nand/raw/Kconfig | 239 +
drivers/mtd/nand/raw/Makefile | 78 ++
drivers/mtd/nand/{ => raw}/am335x_spl_bch.c |0
drivers/mtd/nand/{ => raw}/arasan_nfc.c |0
drivers/mtd/nand/{ => raw}/atmel_nand.c |0
drivers/mtd/nand/{ => raw}/atmel_nand_ecc.h |0
drivers/mtd/nand/{ => raw}/davinci_nand.c |0
drivers/mtd/nand/{ => raw}/denali.c |0
drivers/mtd/nand/{ => raw}/denali.h |0
drivers/mtd/nand/{ => raw}/denali_dt.c|0
drivers/mtd/nand/{ => raw}/denali_spl.c |0
drivers/mtd/nand/{ => raw}/fsl_elbc_nand.c|0
drivers/mtd/nand/{ => raw}/fsl_elbc_spl.c |0
drivers/mtd/nand/{ => raw}/fsl_ifc_nand.c |0
drivers/mtd/nand/{ => raw}/fsl_ifc_spl.c |0
drivers/mtd/nand/{ => raw}/fsl_upm.c |0
drivers/mtd/nand/{ => raw}/fsmc_nand.c|0
drivers/mtd/nand/{ => raw}/kb9202_nand.c |0
drivers/mtd/nand/{ => raw}/kirkwood_nand.c|0
drivers/mtd/nand/{ => raw}/kmeter1_nand.c |0
drivers/mtd/nand/{ => raw}/lpc32xx_nand_mlc.c |0
drivers/mtd/nand/{ => raw}/lpc32xx_nand_slc.c |0
drivers/mtd/nand/{ => raw}/mxc_nand.c |0
drivers/mtd/nand/{ => raw}/mxc_nand.h |0
drivers/mtd/nand/{ => raw}/mxc_nand_spl.c |0
drivers/mtd/nand/{ => raw}/mxs_nand.c |0
drivers/mtd/nand/{ => raw}/mxs_nand_spl.c |0
drivers/mtd/nand/{ => raw}/nand.c |0
drivers/mtd/nand/{ => raw}/nand_base.c| 56 --
drivers/mtd/nand/{ => raw}/nand_bbt.c |0
drivers/mtd/nand/{ => raw}/nand_bch.c |0
drivers/mtd/nand/{ =>
