Message ID | cover.1603024480.git.baruch@tkos.co.il |
---|---|
Headers | show |
Series | mtd: pxa3xx_nand: add support for Armada 8k | expand |
Hi Baruch, On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach <baruch@tkos.co.il> wrote: > > This series adds NAND flash support to Aramda 8k systems. Patches make the > necessary changes to the pxa3xx_nand driver and DT files. > > v2: > Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand: > pxa3xx: Fix not calling dev_xxx with a device") > Is it worth looking at bringing in the newer marvell_nand driver from Linux? I suspect that it will be easier to keep in sync with changes for the Armada 8K. I have considered it in the past but it kind of fell off my radar. > Baruch Siach (2): > arm: dts: armada-cp110-master: update nand-controller > mtd: pxa3xx_nand: remove dead code > > Shmuel Hazan (3): > arm: dts: armada-cp110-slave: add missing cps_nand > mtd: pxa3xx_nand: port to use driver model > mtd: nand: pxa3xx: enable NAND controller if the SoC needs it > > arch/arm/dts/armada-cp110-master.dtsi | 15 ++- > arch/arm/dts/armada-cp110-slave.dtsi | 16 +++ > drivers/mtd/nand/raw/Kconfig | 2 + > drivers/mtd/nand/raw/pxa3xx_nand.c | 179 ++++++++++++++------------ > 4 files changed, 124 insertions(+), 88 deletions(-) > > -- > 2.28.0 >
Hi Chris, On Sun, Oct 18 2020, Chris Packham wrote: > On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach <baruch@tkos.co.il> wrote: >> >> This series adds NAND flash support to Aramda 8k systems. Patches make the >> necessary changes to the pxa3xx_nand driver and DT files. >> >> v2: >> Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand: >> pxa3xx: Fix not calling dev_xxx with a device") > > Is it worth looking at bringing in the newer marvell_nand driver from > Linux? I suspect that it will be easier to keep in sync with changes > for the Armada 8K. I have considered it in the past but it kind of > fell off my radar. The kernel raw nand API has seen some significant changes recently. It looks like the kernel marvell_nand driver relies on newer API. I'm not sure how easy would be syncing the drivers to a degree that makes porting of changes trivial. It would probably require many other changes in generic U-Boot raw NAND code. Maybe Miquel can shed some light on that. Unfortunately, the U-Boot MAINTAINERS NAND FLASH entry is marked "Orphaned (Since 2018-07)". baruch >> Baruch Siach (2): >> arm: dts: armada-cp110-master: update nand-controller >> mtd: pxa3xx_nand: remove dead code >> >> Shmuel Hazan (3): >> arm: dts: armada-cp110-slave: add missing cps_nand >> mtd: pxa3xx_nand: port to use driver model >> mtd: nand: pxa3xx: enable NAND controller if the SoC needs it >> >> arch/arm/dts/armada-cp110-master.dtsi | 15 ++- >> arch/arm/dts/armada-cp110-slave.dtsi | 16 +++ >> drivers/mtd/nand/raw/Kconfig | 2 + >> drivers/mtd/nand/raw/pxa3xx_nand.c | 179 ++++++++++++++------------ >> 4 files changed, 124 insertions(+), 88 deletions(-) >> >> -- >> 2.28.0 >>
Hi Baruch, Hi Chris, On 19.10.20 07:24, Baruch Siach wrote: > Hi Chris, > > On Sun, Oct 18 2020, Chris Packham wrote: >> On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach <baruch@tkos.co.il> wrote: >>> >>> This series adds NAND flash support to Aramda 8k systems. Patches make the >>> necessary changes to the pxa3xx_nand driver and DT files. >>> >>> v2: >>> Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand: >>> pxa3xx: Fix not calling dev_xxx with a device") >> >> Is it worth looking at bringing in the newer marvell_nand driver from >> Linux? I suspect that it will be easier to keep in sync with changes >> for the Armada 8K. I have considered it in the past but it kind of >> fell off my radar. > > The kernel raw nand API has seen some significant changes recently. It > looks like the kernel marvell_nand driver relies on newer API. I'm not > sure how easy would be syncing the drivers to a degree that makes > porting of changes trivial. It would probably require many other changes > in generic U-Boot raw NAND code. I agree that without a re-sync with a more recent Linux MTD (NAND) core code, this task might prove complex and failure prone. And sync'ing the MTD core is also a pretty complex task which needs to be done very carefully, to not break any existing platforms. FWICT, nobody is working on it right now and we can't wait for this to happen and stall the development here. So from my point of view, I'm okay with updates to the current PXA NAND driver. Testing of these patches on other platforms would be very welcome though. > Maybe Miquel can shed some light on that. > > Unfortunately, the U-Boot MAINTAINERS NAND FLASH entry is marked > "Orphaned (Since 2018-07)". Yes, this is unfortunate. Volunteers are always welcome. ;) Thanks, Stefan > baruch > >>> Baruch Siach (2): >>> arm: dts: armada-cp110-master: update nand-controller >>> mtd: pxa3xx_nand: remove dead code >>> >>> Shmuel Hazan (3): >>> arm: dts: armada-cp110-slave: add missing cps_nand >>> mtd: pxa3xx_nand: port to use driver model >>> mtd: nand: pxa3xx: enable NAND controller if the SoC needs it >>> >>> arch/arm/dts/armada-cp110-master.dtsi | 15 ++- >>> arch/arm/dts/armada-cp110-slave.dtsi | 16 +++ >>> drivers/mtd/nand/raw/Kconfig | 2 + >>> drivers/mtd/nand/raw/pxa3xx_nand.c | 179 ++++++++++++++------------ >>> 4 files changed, 124 insertions(+), 88 deletions(-) >>> >>> -- >>> 2.28.0 >>> > > Viele Grüße, Stefan
Hi Stefan, On Tue, Oct 20 2020, Stefan Roese wrote: > On 19.10.20 07:24, Baruch Siach wrote: >> On Sun, Oct 18 2020, Chris Packham wrote: >>> On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach <baruch@tkos.co.il> wrote: >>>> >>>> This series adds NAND flash support to Aramda 8k systems. Patches make the >>>> necessary changes to the pxa3xx_nand driver and DT files. >>>> >>>> v2: >>>> Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand: >>>> pxa3xx: Fix not calling dev_xxx with a device") >>> >>> Is it worth looking at bringing in the newer marvell_nand driver from >>> Linux? I suspect that it will be easier to keep in sync with changes >>> for the Armada 8K. I have considered it in the past but it kind of >>> fell off my radar. >> >> The kernel raw nand API has seen some significant changes recently. It >> looks like the kernel marvell_nand driver relies on newer API. I'm not >> sure how easy would be syncing the drivers to a degree that makes >> porting of changes trivial. It would probably require many other changes >> in generic U-Boot raw NAND code. > > I agree that without a re-sync with a more recent Linux MTD (NAND) core > code, this task might prove complex and failure prone. And sync'ing the > MTD core is also a pretty complex task which needs to be done very > carefully, to not break any existing platforms. FWICT, nobody is working > on it right now and we can't wait for this to happen and stall the > development here. So from my point of view, I'm okay with updates to > the current PXA NAND driver. Testing of these patches on other platforms > would be very welcome though. I should note that the same driver with these modifications was tested successfully on Armada 385 systems with NAND flash and UBIFS. Thanks, baruch >> Maybe Miquel can shed some light on that. >> >> Unfortunately, the U-Boot MAINTAINERS NAND FLASH entry is marked >> "Orphaned (Since 2018-07)". > > Yes, this is unfortunate. Volunteers are always welcome. ;) > > Thanks, > Stefan > >> baruch >> >>>> Baruch Siach (2): >>>> arm: dts: armada-cp110-master: update nand-controller >>>> mtd: pxa3xx_nand: remove dead code >>>> >>>> Shmuel Hazan (3): >>>> arm: dts: armada-cp110-slave: add missing cps_nand >>>> mtd: pxa3xx_nand: port to use driver model >>>> mtd: nand: pxa3xx: enable NAND controller if the SoC needs it >>>> >>>> arch/arm/dts/armada-cp110-master.dtsi | 15 ++- >>>> arch/arm/dts/armada-cp110-slave.dtsi | 16 +++ >>>> drivers/mtd/nand/raw/Kconfig | 2 + >>>> drivers/mtd/nand/raw/pxa3xx_nand.c | 179 ++++++++++++++------------ >>>> 4 files changed, 124 insertions(+), 88 deletions(-)
Hi Stefan, Stefan Roese <sr@denx.de> wrote on Tue, 20 Oct 2020 10:29:52 +0200: > Hi Baruch, > Hi Chris, > > On 19.10.20 07:24, Baruch Siach wrote: > > Hi Chris, > > > > On Sun, Oct 18 2020, Chris Packham wrote: > >> On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach <baruch@tkos.co.il> wrote: > >>> > >>> This series adds NAND flash support to Aramda 8k systems. Patches make the > >>> necessary changes to the pxa3xx_nand driver and DT files. > >>> > >>> v2: > >>> Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand: > >>> pxa3xx: Fix not calling dev_xxx with a device") > >> > >> Is it worth looking at bringing in the newer marvell_nand driver from > >> Linux? I suspect that it will be easier to keep in sync with changes > >> for the Armada 8K. I have considered it in the past but it kind of > >> fell off my radar. > > > > The kernel raw nand API has seen some significant changes recently. It > > looks like the kernel marvell_nand driver relies on newer API. I'm not > > sure how easy would be syncing the drivers to a degree that makes > > porting of changes trivial. It would probably require many other changes > > in generic U-Boot raw NAND code. > > I agree that without a re-sync with a more recent Linux MTD (NAND) core > code, this task might prove complex and failure prone. And sync'ing the > MTD core is also a pretty complex task which needs to be done very > carefully, to not break any existing platforms. FWICT, nobody is working > on it right now and we can't wait for this to happen and stall the > development here. So from my point of view, I'm okay with updates to > the current PXA NAND driver. Testing of these patches on other platforms > would be very welcome though. > > > Maybe Miquel can shed some light on that. Yes, the "new" marvell_nand.c driver is using the ->exec_op() interface which is the one that must be ported to U-Boot. Many changes have been brought to the raw NAND core but everything has been carefully patched to be easily ported (besides the huge number of potential dependencies that have not been brought to U-Boot already). Bringing-in this new interface does not affect the other controller drivers though, as the ->cmdfunc() and ->cmd_ctrl() interfaces are still functional. Thanks, Miquèl