From: Karl Beldan <hidden> Date: 2016-08-09 17:16:32
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(-)
--
2.9.2
From: Karl Beldan <hidden> Date: 2016-08-09 17:15:24
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 <redacted>
---
drivers/memory/ti-aemif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Karl Beldan <hidden> Date: 2016-08-10 18:09:40
On Tue, Aug 09, 2016 at 05:15:15PM +0000, Karl Beldan wrote:
quoted hunk
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 <redacted>
---
drivers/memory/ti-aemif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -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
From: Karl Beldan <hidden> Date: 2016-08-10 20:23:45
On Wed, Aug 10, 2016 at 07:00:20AM +0000, Karl Beldan wrote:
On Tue, Aug 09, 2016 at 05:15:15PM +0000, Karl Beldan wrote:
quoted
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 <redacted>
---
drivers/memory/ti-aemif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -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.
Ok, just saw what's happening, this patch is unnecessary, v2 will
follow.
Karl
From: Karl Beldan <hidden> Date: 2016-08-09 17:15:27
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
From: Sekhar Nori <hidden> Date: 2016-08-10 18:43:25
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted hunk
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
From: Sekhar Nori <hidden> Date: 2016-08-10 18:58:11
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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
From: Karl Beldan <hidden> Date: 2016-08-10 19:00:29
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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
From: Sekhar Nori <hidden> Date: 2016-08-10 20:10:06
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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
From: Karl Beldan <hidden> Date: 2016-08-10 20:03:44
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
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
From: Sekhar Nori <hidden> Date: 2016-08-10 18:26:47
On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
Then I'll wait for this series to be applied and then apply my changes
to the EVM while retiring the nand_cs3 together.
No, I prefer the fixup happens first. In the same series, you can first
fixup existing EVM and then add LCDK support.
Regards,
Sekhar
From: Karl Beldan <hidden> Date: 2016-08-10 19:57:08
On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
Then I'll wait for this series to be applied and then apply my changes
to the EVM while retiring the nand_cs3 together.
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
From: Sekhar Nori <hidden> Date: 2016-08-10 18:17:58
On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
Then I'll wait for this series to be applied and then apply my changes
to the EVM while retiring the nand_cs3 together.
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.
From: Karl Beldan <hidden> Date: 2016-08-10 19:33:12
On Wed, Aug 10, 2016 at 02:04:48PM +0530, Sekhar Nori wrote:
On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
Then I'll wait for this series to be applied and then apply my changes
to the EVM while retiring the nand_cs3 together.
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
From: Sekhar Nori <hidden> Date: 2016-08-10 09:38:39
On Wednesday 10 August 2016 02:58 PM, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 02:04:48PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
Then I'll wait for this series to be applied and then apply my changes
to the EVM while retiring the nand_cs3 together.
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 ?
On the EVM, the NAND ready/busy output is connected to EMA_WAIT0.
Regards,
Sekhar
From: Karl Beldan <hidden> Date: 2016-08-10 18:35:00
On Wed, Aug 10, 2016 at 09:28:48AM +0000, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 02:04:48PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
Then I'll wait for this series to be applied and then apply my changes
to the EVM while retiring the nand_cs3 together.
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 ?
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
From: Karl Beldan <hidden> Date: 2016-08-13 11:42:39
On Wed, Aug 10, 2016 at 02:04:48PM +0530, Sekhar Nori wrote:
On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
The 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.
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.
Then I'll wait for this series to be applied and then apply my changes
to the EVM while retiring the nand_cs3 together.
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
From: Karl Beldan <hidden> Date: 2016-08-10 19:12:30
On Wed, Aug 10, 2016 at 01:18:51PM +0530, Sekhar Nori wrote:
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
From: Karl Beldan <hidden> Date: 2016-08-09 17:15:43
This 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.
Signed-off-by: Karl Beldan <redacted>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
From: Karl Beldan <hidden> Date: 2016-08-09 17:15:48
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 <redacted>
---
arch/arm/boot/dts/da850-lcdk.dts | 108 +++++++++++++++++++++++++++++++++++++++
1 file changed, 108 insertions(+)
@@ -68,3 +89,90 @@cd-gpios=<&gpio64GPIO_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>;++nandat2000000,0{+compatible="ti,davinci-nand";+#address-cells=<1>;+#size-cells=<1>;+reg=<00x020000000x02000000+10x000000000x00008000>;++ti,davinci-chipselect=<1>;+ti,davinci-mask-ale=<0>;+ti,davinci-mask-cle=<0>;+ti,davinci-mask-chipsel=<0>;++/*+*nand_ecc_strength_goodwillemitawarning+*buttheLCDKshipswiththesesettings[1].+*AlsoHW4bitsECCwith16bitsNANDseemsto+*requiresomeattention.+*+*ATMnand_davinci_probehandlingofnand-ecc-*+*isbroken,e.g.+*chip.ecc.strength=pdata->ecc_bitsoccursafter+*scan_ident(),otherwiseIwouldhaveused:+*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;++/*+*LCDKoriginalpartitions:+*0x000000000000-0x000000020000:"u-boot env"+*0x000000020000-0x0000000a0000:"u-boot"+*0x0000000a0000-0x0000002a0000:"kernel"+*0x0000002a0000-0x000020000000:"filesystem"+*+*The1stNANDblockbeingguarantedtobevalidw/oECC(>1kcycles),+*itmakesaperfectcandidateasanSPLfortheBootROMtojumpto.+*HowevertheOMAP-L132/L138BootloaderdocSPRAB41Ereads:+*"To boot from NAND Flash, the AIS should be written to NAND block 1+*(NANDblock0isnotusedbydefault)", which matches the LCDK+*originalpartitioning.+*Also,theLCDKshipswithonlytheu-bootpartitionprovisionedand+*bootsonitinitsdefaultconfigurationwhileusingtheMMCforthe+*kernelandrootfs,sopreservethatoneasisfornow.+*[1]:EnsuringforexamplethatU-BootLCDKSPLcanhandleitproperly+*andaproperbootchainROM->SPL->U-Boot->LinuxwrtECC,wouldallow+*forabetterpartitioning.+*/+partitions{+compatible="fixed-partitions";+#address-cells=<1>;+#size-cells=<1>;++partitionat0{+label="u-boot env";+reg=<00x020000>;+};+partitionat0x020000{+/* The LCDK defaults to booting from this partition */+label="u-boot";+reg=<0x0200000x080000>;+};+partitionat0x0a0000{+label="space";+reg=<0x0a00000>;+};+};+};+};+};
From: Sekhar Nori <hidden> Date: 2016-08-10 08:31:57
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
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.
This passed elementary tests hashing a 20MB file on top of ubifs on my
LCDK.
Signed-off-by: Karl Beldan <redacted>
From: Karl Beldan <hidden> Date: 2016-08-10 18:03:52
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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.
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
This passed elementary tests hashing a 20MB file on top of ubifs on my
LCDK.
Signed-off-by: Karl Beldan <redacted>
From: Sekhar Nori <hidden> Date: 2016-08-10 20:38:22
On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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.
Alright then, please drop references to what software the board ships
with in the commit message and in the patch itself.
quoted
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
From: Karl Beldan <hidden> Date: 2016-08-10 18:32:48
On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote:
On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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.
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
quoted
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
From: Sekhar Nori <hidden> Date: 2016-08-10 18:36:28
On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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.
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
quoted
quoted
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
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.
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
From: Karl Beldan <hidden> Date: 2016-08-16 23:19:46
On Wed, Aug 10, 2016 at 05:23:23PM +0530, Sekhar Nori wrote:
On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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.
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
quoted
quoted
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
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
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.
I will take a look at other patches in this series.
From: Karl Beldan <hidden> Date: 2016-08-29 07:49:38
On Tue, Aug 16, 2016 at 11:20:29PM +0000, Karl Beldan wrote:
On Wed, Aug 10, 2016 at 05:23:23PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote:
quoted
On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote:
quoted
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
quoted
On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
quoted
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.
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
quoted
quoted
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
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
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
I will take a look at other patches in this series.
From: Karl Beldan <hidden> Date: 2016-08-10 18:49:27
On Tue, Aug 09, 2016 at 05:15:17PM +0000, Karl Beldan wrote:
quoted hunk
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 <redacted>
---
arch/arm/boot/dts/da850-lcdk.dts | 108 +++++++++++++++++++++++++++++++++++++++
1 file changed, 108 insertions(+)