Add DT support for NAND to LCDK
Subsystems (4)
cover Add DT support for NAND to LCDK
Hi,
This does not use the same way the current da8xx boards do, instead it is using the more generic and DT friendly memory driver ti-aemif. I can do the same for the da850-evm and retire the dts nandcs3 instances.
Karl Beldan (4):
memory: ti-aemif: Get a named clock rather than an unnamed one
ARM: dts: da850: Add an aemif node
ARM: dts: da850-lcdk: Add NAND to DT
ARM: davinci_all_defconfig: Enable AEMIF as a module
arch/arm/boot/dts/da850-lcdk.dts | 108 +++++++++++++++++++++++++++++++++ arch/arm/boot/dts/da850.dtsi | 10 +++ arch/arm/configs/davinci_all_defconfig | 2 + drivers/memory/ti-aemif.c | 2 +- 4 files changed, 121 insertions(+), 1 deletion(-)
Signature · 1 line
2.9.2
PATCH 1/4 memory: ti-aemif: Get a named clock rather than an unnamed one
Many davinci boards (da830 and da850 families) don't have their clocks in DT yet and won't be successful in getting an unnamed aemif clock. Also the sole current users of ti-aemif (keystone boards) use 'aemif' as their aemif device clock clock-name and should remain unaffected.
--- drivers/memory/ti-aemif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/memory/ti-aemif.c +1 -1
@@ -345,7 +345,7 @@ static int aemif_probe(struct platform_device *pdev)platform_set_drvdata (pdev, aemif); - aemif->clk =devm_clk_get (dev,NULL ); + aemif->clk =devm_clk_get (dev,"aemif" );if (IS_ERR (aemif->clk)) {dev_err (dev,"cannot get clock 'aemif'\n" );return PTR_ERR (aemif->clk);
Signature · 1 line
2.9.2
Re: [PATCH 1/4] memory: ti-aemif: Get a named clock rather than an unnamed one
Quoted 15 lines · Karl Beldan
Many davinci boards (da830 and da850 families) don't have their clocks in DT yet and won't be successful in getting an unnamed aemif clock. Also the sole current users of ti-aemif (keystone boards) use 'aemif' as their aemif device clock clock-name and should remain unaffected.
Signed-off-by Karl Beldan <[email protected]>--- drivers/memory/ti-aemif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/memory/ti-aemif.c +0
-0
drivers/memory/ti-aemif.c static int aemif_probe(struct platform_device *pdev) · line 348
Quoted 5 lines
drivers/memory/ti-aemif.c +1
-1@@ -345,7 +345,7 @@ static int aemif_probe(struct platform_device *pdev)platform_set_drvdata (pdev, aemif); - aemif->clk =devm_clk_get (dev,NULL ); + aemif->clk =devm_clk_get (dev,"aemif" );
Looking further it seems to me that the struct clk_lookup da850_clks registered by davinci_clk_init() should be enough to clk_get() unnamed clocks using only the dev name. I look into what's going on but it would make this patch unnecessary.
Karl
Re: [PATCH 1/4] memory: ti-aemif: Get a named clock rather than an unnamed one
Quoted 19 lines · Karl Beldan
Quoted 18 lines · Karl Beldan
Many davinci boards (da830 and da850 families) don't have their clocks in DT yet and won't be successful in getting an unnamed aemif clock. Also the sole current users of ti-aemif (keystone boards) use 'aemif' as their aemif device clock clock-name and should remain unaffected.
Signed-off-by Karl Beldan <[email protected]>--- drivers/memory/ti-aemif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/memory/ti-aemif.c +0
-0@@ -345,7 +345,7 @@ static int aemif_probe(struct platform_device *pdev)platform_set_drvdata (pdev, aemif);
Quoted 8 lines
drivers/memory/ti-aemif.c static int aemif_probe(struct platform_device *pdev) · line 348
Quoted 2 lines
drivers/memory/ti-aemif.c +1
-1- aemif->clk =devm_clk_get (dev,NULL ); + aemif->clk =devm_clk_get (dev,"aemif" );Looking further it seems to me that the struct
clk_lookupda850_clksregistered bydavinci_clk_init()should be enough toclk_get()unnamed clocks using only the dev name. I look into what's going on but it would make this patch unnecessary.
Ok, just saw what's happening, this patch is unnecessary, v2 will follow.
Karl
PATCH 2/4 ARM: dts: da850: Add an aemif node
In reply to Karl BeldanCurrently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/arm/boot/dts/da850.dtsi +10 -0
@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>; + status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ff
Signature · 1 line
2.9.2
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 21 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +3
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>;
arch/arm/boot/dts/da850.dtsi line 426
Quoted 10 lines
arch/arm/boot/dts/da850.dtsi +7
-0+ #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>; + status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ff
The nand node should be part of aemif node like it is done for keystone boards.
Regards,
Sekhar
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;
Quoted 9 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Hmm, this is exactly what I have done.
Karl
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
In reply to Sekhar NoriQuoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;
Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of da850.dtsi completely. Its much better to keep da850.dtsi restricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.
Similarly, can you move the NAND pinmux definitions too to the da850-evm.dts file?
There is advantage in keeping common pinmux definitions in da850.dtsi so each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.
Thanks,
Sekhar
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 41 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.
Quoted 9 lines
Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.
This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.
Karl
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 51 lines · Karl Beldan
Quoted 41 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Quoted 9 lines
Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.
Quoted 3 lines
This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.
Yes please. We dont want duplication of data between da850.dtsi and da850-lcdk.dts files.
Thanks,
Sekhar
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 52 lines · Sekhar Nori
Quoted 51 lines · Karl Beldan
Quoted 50 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.
Quoted 7 lines
Quoted 3 lines
This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.
Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the nand_cs3 together.
Karl
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 57 lines · Karl Beldan
Quoted 56 lines · Sekhar Nori
Quoted 54 lines · Karl Beldan
Quoted 41 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Quoted 9 lines
Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.
Quoted 5 lines
Quoted 3 lines
Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the
nand_cs3together.
No, I prefer the fixup happens first. In the same series, you can first fixup existing EVM and then add LCDK support.
Regards,
Sekhar
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 58 lines · Sekhar Nori
Quoted 57 lines · Karl Beldan
Quoted 56 lines · Sekhar Nori
Quoted 54 lines · Karl Beldan
Quoted 41 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Quoted 9 lines
Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the
nand_cs3together.No, I prefer the fixup happens first. In the same series, you can first fixup existing EVM and then add LCDK support.
Well in that case you'll have to do the testing since I only have an LCDK. I should be able to send the series within the hour.
Karl
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 65 lines · Karl Beldan
Quoted 64 lines · Sekhar Nori
Quoted 62 lines · Karl Beldan
Quoted 52 lines · Sekhar Nori
Quoted 51 lines · Karl Beldan
Quoted 50 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.Quoted 7 lines
Quoted 3 lines
This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the
nand_cs3together.
Quoted 6 lines
Quoted 3 lines
No, I prefer the fixup happens first. In the same series, you can first fixup existing EVM and then add LCDK support.
Well in that case you'll have to do the testing since I only have an LCDK. I should be able to send the series within the hour.
Sure. I can test it.
Regards,
Sekhar
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
Quoted 66 lines · Sekhar Nori
Quoted 65 lines · Karl Beldan
Quoted 64 lines · Sekhar Nori
Quoted 62 lines · Karl Beldan
Quoted 52 lines · Sekhar Nori
Quoted 51 lines · Karl Beldan
Quoted 50 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.Quoted 7 lines
Quoted 3 lines
This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the
nand_cs3together.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
No, I prefer the fixup happens first. In the same series, you can first fixup existing EVM and then add LCDK support.
Well in that case you'll have to do the testing since I only have an LCDK. I should be able to send the series within the hour.
Sure. I can test it.
The aemif/davinci_nand drivers don't configure AWCCR, yet davinci_nand relies on EM_WAIT for RDY/nBUSY, so for the moment I keep the default settings, but I configure the EM_WAIT pins in the pinctrl. I did it for the LCDK, and it is not done for the EVM. Since the EVM schematics are not public can you tell which EM_WAIT pins are connected ?
Karl
PATCH 2/4 ARM: dts: da850: Add an aemif node
Quoted 74 lines · Karl Beldan
Quoted 73 lines · Sekhar Nori
Quoted 71 lines · Karl Beldan
Quoted 58 lines · Sekhar Nori
Quoted 57 lines · Karl Beldan
Quoted 56 lines · Sekhar Nori
Quoted 54 lines · Karl Beldan
Quoted 41 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Quoted 9 lines
Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the
nand_cs3together.No, I prefer the fixup happens first. In the same series, you can first fixup existing EVM and then add LCDK support.
Well in that case you'll have to do the testing since I only have an LCDK. I should be able to send the series within the hour.
Quoted 7 lines
Quoted 2 lines
Sure. I can test it.
The aemif/davinci_nand drivers don't configure AWCCR, yet
davinci_nandrelies onEM_WAITfor RDY/nBUSY, so for the moment I keep the default settings, but I configure theEM_WAITpins in the pinctrl. I did it for the LCDK, and it is not done for the EVM. Since the EVM schematics are not public can you tell whichEM_WAITpins are connected ?
On the EVM, the NAND ready/busy output is connected to EMA_WAIT0.
Regards,
Sekhar
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
In reply to Karl BeldanQuoted 74 lines · Karl Beldan
Quoted 73 lines · Sekhar Nori
Quoted 71 lines · Karl Beldan
Quoted 58 lines · Sekhar Nori
Quoted 57 lines · Karl Beldan
Quoted 56 lines · Sekhar Nori
Quoted 54 lines · Karl Beldan
Quoted 41 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif at 68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3 at 62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Quoted 9 lines
Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the
nand_cs3together.No, I prefer the fixup happens first. In the same series, you can first fixup existing EVM and then add LCDK support.
Well in that case you'll have to do the testing since I only have an LCDK. I should be able to send the series within the hour.
Quoted 8 lines
Quoted 2 lines
Sure. I can test it.
The aemif/davinci_nand drivers don't configure AWCCR, yet
davinci_nandrelies onEM_WAITfor RDY/nBUSY, so for the moment I keep the default settings, but I configure theEM_WAITpins in the pinctrl. I did it for the LCDK, and it is not done for the EVM. Since the EVM schematics are not public can you tell whichEM_WAITpins are connected ?
Also the device name is nand_cs3 but the pin muxing also enables CS4 both in Linux and U-Boot, can you tell whether it is needed ? Or maybe you can share the schematics and I'll check it myself ?
Karl
Re: [PATCH 2/4] ARM: dts: da850: Add an aemif node
In reply to Sekhar NoriQuoted 66 lines · Sekhar Nori
Quoted 65 lines · Karl Beldan
Quoted 64 lines · Sekhar Nori
Quoted 62 lines · Karl Beldan
Quoted 52 lines · Sekhar Nori
Quoted 51 lines · Karl Beldan
Quoted 50 lines · Sekhar Nori
Quoted 27 lines · Sekhar Nori
Quoted 26 lines · Karl Beldan
Currently the davinci da8xx boards use the mach-davinci aemif code. Instantiating an aemif node into the DT allows to use the ti-aemif memory driver and is another step to better DT support. Also it will allow to properly pass the emif timings via DT.
Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/boot/dts/da850.dtsi +8
-0@@ -411,6 +411,16 @@ dma-names = "tx", "rx"; }; }; + aemif: aemif@68000000 { + compatible = "ti,da850-aemif"; + #address-cells = <2>; + #size-cells = <1>; + + reg = <0x68000000 0x00008000>; + ranges = <0 0 0x60000000 0x08000000 + 1 0 0x68000000 0x00008000>;Quoted 8 lines
arch/arm/boot/dts/da850.dtsi line 426
Quoted 5 lines
arch/arm/boot/dts/da850.dtsi +2
-0+ status = "disabled"; + }; nand_cs3@62000000 { compatible = "ti,davinci-nand"; reg = <0x62000000 0x807ffThe nand node should be part of aemif node like it is done for keystone boards.
Actually, can you move the nand node out of
da850.dtsicompletely. Its much better to keepda850.dtsirestricted to soc-internal devices and keep the board level devices like NAND flash in <board>.dts file.Similarly, can you move the NAND pinmux definitions too to the
da850-evm.dtsfile?There is advantage in keeping common pinmux definitions in
da850.dtsiso each board doe not have to repeat them. But AEMIF is an exception as its usage can really be varied (NAND, NOR, SRAM, other). Plus, different boards are likely to use different chip selects so coming up with some pinmux definitions which will be reused widely is really unlikely.Quoted 7 lines
Quoted 3 lines
This is exactly what I just did for the LCDK.
If everybody is happy with it I will do the same for the evm as I put it in the cover letter.Yes please. We dont want duplication of data between
da850.dtsiandda850-lcdk.dtsfiles.Then I'll wait for this series to be applied and then apply my changes to the EVM while retiring the
nand_cs3together.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
No, I prefer the fixup happens first. In the same series, you can first fixup existing EVM and then add LCDK support.
Well in that case you'll have to do the testing since I only have an LCDK. I should be able to send the series within the hour.
Sure. I can test it.
Yesterday I got my hands on an EVM TI just sent and could test it on it. The change proper is fine, but I was surprised mainline was broken wrt 4-bit ECC on top of 8bits NANDs, so I tested with 1-bit ECC, 'enough' for this device.
FYI, the NAND socket had a
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
nand: Micron MT29F4G08AAC
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Karl
PATCH 3/4 ARM: dts: da850-lcdk: Add NAND to DT
In reply to Karl BeldanThis adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
This passed elementary tests hashing a 20MB file on top of ubifs on my LCDK.
--- arch/arm/boot/dts/da850-lcdk.dts | 108 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+)
arch/arm/boot/dts/da850-lcdk.dts +108 -0
@@ -27,6 +27,27 @@ &pmx_core { status = "okay"; + + nand_pins: nand_pins { + pinctrl-single,bits = < + /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[3] */ + 0x1c 0x10110010 0xf0ff00f0 + /* + * EMA_D[0], EMA_D[1], EMA_D[2], + * EMA_D[3], EMA_D[4], EMA_D[5], + * EMA_D[6], EMA_D[7] + */ + 0x24 0x11111111 0xffffffff + /* + * EMA_D[8], EMA_D[9], EMA_D[10], + * EMA_D[11], EMA_D[12], EMA_D[13], + * EMA_D[14], EMA_D[15] + */ + 0x20 0x11111111 0xffffffff + /* EMA_A[1], EMA_A[2] */ + 0x30 0x01100000 0x0ff00000 + >; + }; }; &serial2 {
@@ -68,3 +89,90 @@ cd-gpios = <&gpio 64 GPIO_ACTIVE_HIGH>; status = "okay"; }; + +&aemif { + pinctrl-names = "default"; + pinctrl-0 = <&nand_pins>; + status = "ok"; + cs2 { + #address-cells = <2>; + #size-cells = <1>; + clock-ranges; + ranges; + + ti,cs-chipselect = <2>; + + nand at 2000000,0 { + compatible = "ti,davinci-nand"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0 0x02000000 0x02000000 + 1 0x00000000 0x00008000>; + + ti,davinci-chipselect = <1>; + ti,davinci-mask-ale = <0>; + ti,davinci-mask-cle = <0>; + ti,davinci-mask-chipsel = <0>; + + /* + * nand_ecc_strength_good will emit a warning + * but the LCDK ships with these settings [1]. + * Also HW 4bits ECC with 16bits NAND seems to + * require some attention. + * + * ATM nand_davinci_probe handling of nand-ecc-* + * is broken, e.g. + * chip.ecc.strength = pdata->ecc_bits occurs after + * scan_ident(), otherwise I would have used: + * nand-ecc-mode = "hw"; + * nand-ecc-strength = <1>; + * nand-ecc-step-size = <512>; + */ + ti,davinci-ecc-mode = "hw"; + ti,davinci-ecc-bits = <1>; + + nand-bus-width= <16>; + nand-on-flash-bbt; + + /* + * LCDK original partitions: + * 0x000000000000-0x000000020000 : "u-boot env" + * 0x000000020000-0x0000000a0000 : "u-boot" + * 0x0000000a0000-0x0000002a0000 : "kernel" + * 0x0000002a0000-0x000020000000 : "filesystem" + * + * The 1st NAND block being guaranted to be valid w/o ECC (> 1k cycles), + * it makes a perfect candidate as an SPL for the BootROM to jump to. + * However the OMAP-L132/L138 Bootloader doc SPRAB41E reads: + * "To boot from NAND Flash, the AIS should be written to NAND block 1 + * (NAND block 0 is not used by default)", which matches the LCDK + * original partitioning. + * Also, the LCDK ships with only the u-boot partition provisioned and + * boots on it in its default configuration while using the MMC for the + * kernel and rootfs, so preserve that one as is for now. + * [1]: Ensuring for example that U-Boot LCDK SPL can handle it properly + * and a proper boot chain ROM->SPL->U-Boot->Linux wrt ECC, would allow + * for a better partitioning. + */ + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition at 0 { + label = "u-boot env"; + reg = <0 0x020000>; + }; + partition at 0x020000 { + /* The LCDK defaults to booting from this partition */ + label = "u-boot"; + reg = <0x020000 0x080000>; + }; + partition at 0x0a0000 { + label = "space"; + reg = <0x0a0000 0>; + }; + }; + }; + }; +};
Signature · 1 line
2.9.2
PATCH 3/4 ARM: dts: da850-lcdk: Add NAND to DT
Quoted 4 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that.
If driver is broken for 4-bit ECC, please fix that up first.
Quoted 4 lines
This passed elementary tests hashing a 20MB file on top of ubifs on my LCDK.
Signed-off-by Karl Beldan <[email protected]>
Thanks,
Sekhar
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
Quoted 11 lines · Sekhar Nori
Quoted 4 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that.
I am not saying we _need_ to be compatible.
Quoted 2 lines
If driver is broken for 4-bit ECC, please fix that up first.
Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies.
I took note that you are likely to not apply without the ECC fix.
Karl
Quoted 7 lines
Quoted 4 lines
This passed elementary tests hashing a 20MB file on top of ubifs on my LCDK.
Signed-off-by Karl Beldan <[email protected]>Thanks,
Sekhar
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
Quoted 7 lines · Karl Beldan
Quoted 6 lines · Sekhar Nori
Quoted 4 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
Quoted 6 lines
Quoted 5 lines
I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that.
I am not saying we _need_ to be compatible.
Alright then, please drop references to what software the board ships with in the commit message and in the patch itself.
Quoted 8 lines
Quoted 3 lines
If driver is broken for 4-bit ECC, please fix that up first.
Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies.
I took note that you are likely to not apply without the ECC fix.
Yeah, I would not like to apply with 1-bit ECC now and then change to 4-bit ECC soon after.
Regards,
Sekhar
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
Quoted 13 lines · Sekhar Nori
Quoted 12 lines · Karl Beldan
Quoted 11 lines · Sekhar Nori
Quoted 4 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that.
Quoted 5 lines
Quoted 1 line
I am not saying we _need_ to be compatible.
Alright then, please drop references to what software the board ships with in the commit message and in the patch itself.
I hadn't seen this comment before sending v2.
Quoted 12 lines
Quoted 8 lines
Quoted 3 lines
If driver is broken for 4-bit ECC, please fix that up first.
Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies.
I took note that you are likely to not apply without the ECC fix.Yeah, I would not like to apply with 1-bit ECC now and then change to 4-bit ECC soon after.
Both mityomapl138 from mainline and hawkboard from TI's BSP release include the comment:
- "4 bit mode is not supported with 16 bit NAND"
It is not clear whether they imply that the HW has issues or if it's SW only, but 4-bits ECC is a different matter and I hope you'll integrate the current changes prior to tackling it.
Karl
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
Quoted 31 lines · Karl Beldan
Quoted 13 lines · Sekhar Nori
Quoted 12 lines · Karl Beldan
Quoted 11 lines · Sekhar Nori
Quoted 4 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that.
Quoted 5 lines
Quoted 1 line
I am not saying we _need_ to be compatible.
Alright then, please drop references to what software the board ships with in the commit message and in the patch itself.
I hadn't seen this comment before sending v2.
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
If driver is broken for 4-bit ECC, please fix that up first.
Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies.
I took note that you are likely to not apply without the ECC fix.
Quoted 8 lines
Quoted 3 lines
Yeah, I would not like to apply with 1-bit ECC now and then change to 4-bit ECC soon after.
Both mityomapl138 from mainline and hawkboard from TI's BSP release include the comment:
- "4 bit mode is not supported with 16 bit NAND"
It is not clear whether they imply that the HW has issues or if it's SW
At least the TRM says "The EMIFA supports 4-bit ECC on 8-bit/16-bit NAND Flash.". And then the TRM goes on to describe how 4-bit ECC is supposed to work for 16-bit NAND. I could not find any errata related to this in the errata document.
Quoted 2 lines
only, but 4-bits ECC is a different matter and I hope you'll integrate the current changes prior to tackling it.
Lets apply everything together. This is a new feature, not a bug fix. There is no need to rush it. Also, for the NAND part on LCDK, per the micron datasheet, minimum of 4-bit ECC is needed.
I will take a look at other patches in this series.
Regards,
Sekhar
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
Quoted 46 lines · Sekhar Nori
Quoted 31 lines · Karl Beldan
Quoted 13 lines · Sekhar Nori
Quoted 12 lines · Karl Beldan
Quoted 11 lines · Sekhar Nori
Quoted 4 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that.
Quoted 5 lines
Quoted 1 line
I am not saying we _need_ to be compatible.
Alright then, please drop references to what software the board ships with in the commit message and in the patch itself.
I hadn't seen this comment before sending v2.
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
If driver is broken for 4-bit ECC, please fix that up first.
Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies.
I took note that you are likely to not apply without the ECC fix.Quoted 8 lines
Quoted 3 lines
Yeah, I would not like to apply with 1-bit ECC now and then change to 4-bit ECC soon after.
Both mityomapl138 from mainline and hawkboard from TI's BSP release include the comment:
- "4 bit mode is not supported with 16 bit NAND"
It is not clear whether they imply that the HW has issues or if it's SWAt least the TRM says "The EMIFA supports 4-bit ECC on 8-bit/16-bit NAND Flash.". And then the TRM goes on to describe how 4-bit ECC is supposed to work for 16-bit NAND. I could not find any errata related to this in the errata document.
Quoted 7 lines
Quoted 2 lines
only, but 4-bits ECC is a different matter and I hope you'll integrate the current changes prior to tackling it.
Lets apply everything together. This is a new feature, not a bug fix. There is no need to rush it. Also, for the NAND part on LCDK, per the micron datasheet, minimum of 4-bit ECC is needed.
FYI my patches are related to a small contracting work spanning 20 days amounting to 15 real days (from scratch). ATM my SoW not only doesn't include this 'new feature' but excludes it. So I cannot promise I'll look into it, though it shouldn't be too big a thing.
It seemed clear that you wanted to squeeze it with the rest, but after setting things up for the EVM and observing mainline was broken with 4bits ECC on an 8bits NAND I thought it was impossible nobody hadn't noticed it .. so I dug in the mail archive, only to find there had already been some alerts raised some months ago on the list, so I picked up my next item.
Quoted 2 lines
I will take a look at other patches in this series.
Ok, thanks.
Rgds,
Karl
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
Quoted 55 lines · Karl Beldan
Quoted 46 lines · Sekhar Nori
Quoted 31 lines · Karl Beldan
Quoted 13 lines · Sekhar Nori
Quoted 12 lines · Karl Beldan
Quoted 11 lines · Sekhar Nori
Quoted 4 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
I disagree that we need to be compatible to the software that ships with the board. Thats software was last updated 3 years ago. Instead I would concern with what the hardware supports. So, if the hardware can support 4-bit ECC, I would use that.
Quoted 5 lines
Quoted 1 line
I am not saying we _need_ to be compatible.
Alright then, please drop references to what software the board ships with in the commit message and in the patch itself.
I hadn't seen this comment before sending v2.
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
If driver is broken for 4-bit ECC, please fix that up first.
Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies.
I took note that you are likely to not apply without the ECC fix.Quoted 8 lines
Quoted 3 lines
Yeah, I would not like to apply with 1-bit ECC now and then change to 4-bit ECC soon after.
Both mityomapl138 from mainline and hawkboard from TI's BSP release include the comment:
- "4 bit mode is not supported with 16 bit NAND"
It is not clear whether they imply that the HW has issues or if it's SWAt least the TRM says "The EMIFA supports 4-bit ECC on 8-bit/16-bit NAND Flash.". And then the TRM goes on to describe how 4-bit ECC is supposed to work for 16-bit NAND. I could not find any errata related to this in the errata document.
Quoted 7 lines
Quoted 2 lines
only, but 4-bits ECC is a different matter and I hope you'll integrate the current changes prior to tackling it.
Lets apply everything together. This is a new feature, not a bug fix. There is no need to rush it. Also, for the NAND part on LCDK, per the micron datasheet, minimum of 4-bit ECC is needed.
Quoted 4 lines
FYI my patches are related to a small contracting work spanning 20 days amounting to 15 real days (from scratch). ATM my SoW not only doesn't include this 'new feature' but excludes it. So I cannot promise I'll look into it, though it shouldn't be too big a thing.
I took a look at it yesterday, cf. https://lkml.org/lkml/2016/8/29/71
Karl
Quoted 14 lines
It seemed clear that you wanted to squeeze it with the rest, but after setting things up for the EVM and observing mainline was broken with 4bits ECC on an 8bits NAND I thought it was impossible nobody hadn't noticed it .. so I dug in the mail archive, only to find there had already been some alerts raised some months ago on the list, so I picked up my next item.
Quoted 2 lines
I will take a look at other patches in this series.
Ok, thanks.
Rgds,
Karl
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
In reply to Karl BeldanQuoted 45 lines · Karl Beldan
This adds DT support for the NAND connected to the SoC AEMIF. The parameters (timings, ecc) are the same as what the board ships with (default AEMIF timings, 1bit ECC) and improvements will be handled in due course.
This passed elementary tests hashing a 20MB file on top of ubifs on my LCDK.Signed-off-by Karl Beldan <[email protected]>--- arch/arm/boot/dts/da850-lcdk.dts | 108 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+)arch/arm/boot/dts/da850-lcdk.dts +21
-0@@ -27,6 +27,27 @@ &pmx_core { status = "okay"; + + nand_pins: nand_pins { + pinctrl-single,bits = < + /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[3] */ + 0x1c 0x10110010 0xf0ff00f0 + /* + * EMA_D[0], EMA_D[1], EMA_D[2], + * EMA_D[3], EMA_D[4], EMA_D[5], + * EMA_D[6], EMA_D[7] + */ + 0x24 0x11111111 0xffffffff + /* + * EMA_D[8], EMA_D[9], EMA_D[10], + * EMA_D[11], EMA_D[12], EMA_D[13], + * EMA_D[14], EMA_D[15] + */ + 0x20 0x11111111 0xffffffff + /* EMA_A[1], EMA_A[2] */ + 0x30 0x01100000 0x0ff00000 + >; + }; }; &serial2 {
arch/arm/boot/dts/da850-lcdk.dts line 97
Quoted 9 lines
arch/arm/boot/dts/da850-lcdk.dts +6
-0@@ -68,3 +89,90 @@ cd-gpios = <&gpio 64 GPIO_ACTIVE_HIGH>; status = "okay"; }; + +&aemif { + pinctrl-names = "default"; + pinctrl-0 = <&nand_pins>; + status = "ok"; + cs2 {
Typo, should be cs3.
Karl
Quoted 84 lines
arch/arm/boot/dts/da850-lcdk.dts +81
-0+ #address-cells = <2>; + #size-cells = <1>; + clock-ranges; + ranges; + + ti,cs-chipselect = <2>; + + nand at 2000000,0 { + compatible = "ti,davinci-nand"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0 0x02000000 0x02000000 + 1 0x00000000 0x00008000>; + + ti,davinci-chipselect = <1>; + ti,davinci-mask-ale = <0>; + ti,davinci-mask-cle = <0>; + ti,davinci-mask-chipsel = <0>; + + /* + * nand_ecc_strength_good will emit a warning + * but the LCDK ships with these settings [1]. + * Also HW 4bits ECC with 16bits NAND seems to + * require some attention. + * + * ATM nand_davinci_probe handling of nand-ecc-* + * is broken, e.g. + * chip.ecc.strength = pdata->ecc_bits occurs after + * scan_ident(), otherwise I would have used: + * nand-ecc-mode = "hw"; + * nand-ecc-strength = <1>; + * nand-ecc-step-size = <512>; + */ + ti,davinci-ecc-mode = "hw"; + ti,davinci-ecc-bits = <1>; + + nand-bus-width= <16>; + nand-on-flash-bbt; + + /* + * LCDK original partitions: + * 0x000000000000-0x000000020000 : "u-boot env" + * 0x000000020000-0x0000000a0000 : "u-boot" + * 0x0000000a0000-0x0000002a0000 : "kernel" + * 0x0000002a0000-0x000020000000 : "filesystem" + * + * The 1st NAND block being guaranted to be valid w/o ECC (> 1k cycles), + * it makes a perfect candidate as an SPL for the BootROM to jump to. + * However the OMAP-L132/L138 Bootloader doc SPRAB41E reads: + * "To boot from NAND Flash, the AIS should be written to NAND block 1 + * (NAND block 0 is not used by default)", which matches the LCDK + * original partitioning. + * Also, the LCDK ships with only the u-boot partition provisioned and + * boots on it in its default configuration while using the MMC for the + * kernel and rootfs, so preserve that one as is for now. + * [1]: Ensuring for example that U-Boot LCDK SPL can handle it properly + * and a proper boot chain ROM->SPL->U-Boot->Linux wrt ECC, would allow + * for a better partitioning. + */ + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition at 0 { + label = "u-boot env"; + reg = <0 0x020000>; + }; + partition at 0x020000 { + /* The LCDK defaults to booting from this partition */ + label = "u-boot"; + reg = <0x020000 0x080000>; + }; + partition at 0x0a0000 { + label = "space"; + reg = <0x0a0000 0>; + }; + }; + }; + }; +};Signature · 1 line
2.9.2
PATCH 4/4 ARM: davinci_all_defconfig: Enable AEMIF as a module
In reply to Karl BeldanThis enables the use of the memory/ti-aemif.c driver.
ATM most davinci boards use the mach-davinci aemif code which gets in the way of genericity and proper DT boot.
--- arch/arm/configs/davinci_all_defconfig | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/configs/davinci_all_defconfig +2 -0
@@ -192,6 +192,8 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_OMAP=m CONFIG_DMADEVICES=y CONFIG_TI_EDMA=y +CONFIG_MEMORY=y +CONFIG_TI_AEMIF=m CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_XFS_FS=m
Signature · 1 line
2.9.2