atmel nand bindings vs. actual dts files

DISCUSSION Alexander Dahl 4 participants 7 messages Mar 6, 2019 – Jun 4, 2019 Memory technology devices (MTD)

Share & tools

Alexander Dahl

author

2019-03-06 14:14 UTC #0 lore raw

Hei hei,

I'm currently adapting the at91-sama5d27_som1_ek.dts file for a custom modification of that board [1], and had a look at how sama5d3.dtsi, sama5d4.dtsi and boards including those define the nand controller and the nand chip. What puzzles me is the following. The atmel-nand devicetree binding docs say:

Required properties:
- reg: describes the CS lines assigned to the NAND device. If the NAND device exposes multiple CS lines (multi-dies chips), your reg property will contain X tuples of 3 entries.
1st entry: the CS line this NAND chip is connected to
2nd entry: the base offset of the memory region assigned to this
device (always 0)
3rd entry: the memory region size (always 0x800000)

However the actual node of e.g. at91-sama5d3_xplained.dts contains this:

                                nand@3 {
                                        reg = <0x3 0x0 0x2>;
                                        atmel,rb = <0>;
                                        nand-bus-width = <8>;
                                        nand-ecc-mode = "hw";
                                        nand-ecc-strength = <4>;
                                        nand-ecc-step-size = <512>;
                                        nand-on-flash-bbt;

So instead of "always 0x800000" that node has 0x2 as third entry for the 'reg' property. Why is that?

Bonus question: if the R/B line is not connected, how is that expressed in dts? As far as I understood that is possible, if the driver polls some status register instead of that line level, right?

Greets
Alex

[1] we piggyback soldered a raw NAND flash to the som1 module with some enameled copper wire for evaluation, NAND is already responding in a modified U-Boot ;-)

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Alexander Dahl

author

2019-03-07 16:25 UTC #1 lore raw

Hello,

Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:

Quoted 2 lines

So instead of "always 0x800000" that node has 0x2 as third entry for the 'reg' property. Why is that?

I didn't investigate that further yet, but I'm curious, so if anyone knows?

Quoted 3 lines

Bonus question: if the R/B line is not connected, how is that expressed in dts? As far as I understood that is possible, if the driver polls some status register instead of that line level, right?

Or just waits until a certain timeout …

For v4.19.25 (this is the currently latest base for PREEMPT RT patches) I found this:

https://elixir.bootlin.com/linux/v4.19.25/source/include/linux/mtd/
rawnand.h#L1195

It says:

* @dev_ready: [BOARDSPECIFIC] hardwarespecific function for accessing
* device ready/busy line. If set to NULL no access to
* ready/busy is available and the ready/busy information
* is read from the chip status register.

However I see no way to explicitly set this to NULL via device tree for the atmel raw nand driver, or did I miss something?

I guess that's no recommended hardware setup?

Greets
Alex

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Miquel Raynal

maintainer

2019-04-29 09:55 UTC #2 lore raw

Hi Alexander,

Sorry for the big delay.

Alexander Dahl <[email protected]> wrote on Thu, 07 Mar 2019 17:25:17 +0100:

Quoted 7 lines

Hello,
Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
Quoted 2 lines
So instead of "always 0x800000" that node has 0x2 as third entry for the 'reg' property. Why is that?
I didn't investigate that further yet, but I'm curious, so if anyone knows?

I suppose the bindings [1] explain the situation.

[1] https://elixir.bootlin.com/linux/v5.0/source/Documentation/devicetree/bindings/mtd/atmel-nand.txt#L32

Quoted 4 lines

Quoted 4 lines
Bonus question: if the R/B line is not connected, how is that expressed in dts? As far as I understood that is possible, if the driver polls some status register instead of that line level, right?

There is an atmel,rb property with the ready/busy GPIO line. If it is missing, I think the driver will do a MMIO read instead.

Quoted 16 lines

Or just waits until a certain timeout …
For v4.19.25 (this is the currently latest base for PREEMPT RT patches) I found this:
https://elixir.bootlin.com/linux/v4.19.25/source/include/linux/mtd/
rawnand.h#L1195
It says:
* @dev_ready: [BOARDSPECIFIC] hardwarespecific function for accessing
* device ready/busy line. If set to NULL no access to
* ready/busy is available and the ready/busy information
* is read from the chip status register.

Quoted 4 lines

However I see no way to explicitly set this to NULL via device tree for the atmel raw nand driver, or did I miss something?
I guess that's no recommended hardware setup?

->dev_ready() is a legacy hook. Now we use ->exec_op() and the wait periods are directly handled inside it (see atmel_nfc_wait()).

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Alexander Dahl

author

2019-04-30 09:33 UTC #3 lore raw

Hello Miquèl,

Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:

Quoted 5 lines

Alexander Dahl <[email protected]> wrote on Thu, 07 Mar 2019 17:25:17
Quoted 4 lines
Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
Quoted 2 lines
So instead of "always 0x800000" that node has 0x2 as third entry for the 'reg' property. Why is that?

Quoted 8 lines

Quoted 2 lines
I didn't investigate that further yet, but I'm curious, so if anyone knows?
I suppose the bindings [1] explain the situation.
[1]
https://elixir.bootlin.com/linux/v5.0/source/Documentation/devicetree/bindi
ngs/mtd/atmel-nand.txt#L32

No, that was not what I wanted to know. The bindings says for that reg
property: “3rd entry: the memory region size (always 0x800000)”

This is true for some dts files including this nand node, but not for all, some have this:

	nand@3 {
		reg = <0x3 0x0 0x800000>;

Others have this:

	nand@3 {
		reg = <0x3 0x0 0x2>;

The second contradicts the binding doc. Most of this was changed when switching from the old bindings in changeset v4.12-rc1-7-g1004a2977bdc by Boris Brezillon. I wanted to know why the difference?

Greets
Alex

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Miquel Raynal

maintainer

2019-04-30 09:33 UTC #4 lore raw

Hi Alexander,

Alexander Dahl <[email protected]> wrote on Tue, 30 Apr 2019 11:24:44 +0200:

Quoted 26 lines

Hello Miquèl,
Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:
Quoted 5 lines
Alexander Dahl <[email protected]> wrote on Thu, 07 Mar 2019 17:25:17
Quoted 4 lines
Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
Quoted 2 lines
So instead of "always 0x800000" that node has 0x2 as third entry for the 'reg' property. Why is that?
Quoted 8 lines
Quoted 2 lines
I didn't investigate that further yet, but I'm curious, so if anyone knows?
I suppose the bindings [1] explain the situation.
[1]
https://elixir.bootlin.com/linux/v5.0/source/Documentation/devicetree/bindi
ngs/mtd/atmel-nand.txt#L32
No, that was not what I wanted to know. The bindings says for that reg
property: “3rd entry: the memory region size (always 0x800000)”
This is true for some dts files including this nand node, but not for all, some have this:
	nand@3 {
		reg = <0x3 0x0 0x800000>;

Quoted 8 lines

Others have this:
	nand@3 {
		reg = <0x3 0x0 0x2>;
The second contradicts the binding doc. Most of this was changed when switching from the old bindings in changeset v4.12-rc1-7-g1004a2977bdc by Boris Brezillon. I wanted to know why the difference?

Indeed. Adding Alexandre who might also have an idea and Tudor for reference.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Alexandre Belloni

2019-06-04 01:53 UTC #5 lore raw

Quoted 36 lines · Miquel Raynal

Hi Alexander,
Alexander Dahl <[email protected]> wrote on Tue, 30 Apr 2019 11:24:44 +0200:
Quoted 31 lines
Hello Miquèl,
Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:
Quoted 5 lines
Alexander Dahl <[email protected]> wrote on Thu, 07 Mar 2019 17:25:17
Quoted 4 lines
Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
Quoted 2 lines
So instead of "always 0x800000" that node has 0x2 as third entry for the 'reg' property. Why is that?
Quoted 8 lines
Quoted 2 lines
I didn't investigate that further yet, but I'm curious, so if anyone knows?
I suppose the bindings [1] explain the situation.
[1]
https://elixir.bootlin.com/linux/v5.0/source/Documentation/devicetree/bindi
ngs/mtd/atmel-nand.txt#L32
No, that was not what I wanted to know. The bindings says for that reg
property: “3rd entry: the memory region size (always 0x800000)”
This is true for some dts files including this nand node, but not for all, some have this:
	nand@3 {
		reg = <0x3 0x0 0x800000>;
Others have this:
	nand@3 {
		reg = <0x3 0x0 0x2>;

Quoted 7 lines

Quoted 3 lines
The second contradicts the binding doc. Most of this was changed when switching from the old bindings in changeset v4.12-rc1-7-g1004a2977bdc by Boris Brezillon. I wanted to know why the difference?
Indeed. Adding Alexandre who might also have an idea and Tudor for reference.

I'd say that <0x3 0x0 0x2> only works because ioremap will always map a 4k page and DMA is used so we are not accessing anything beyond that page using the virtual address.

Signature · 7 lines

Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Boris Brezillon

2019-06-04 07:43 UTC #6 lore raw

Quoted 41 lines · On Tue, 4 Jun 2019 03:53:01 +0200 Alexandre Belloni…

Quoted 40 lines · Miquel Raynal
Hi Alexander,
Alexander Dahl <[email protected]> wrote on Tue, 30 Apr 2019 11:24:44 +0200:
Quoted 34 lines
Hello Miquèl,
Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:
Quoted 5 lines
Alexander Dahl <[email protected]> wrote on Thu, 07 Mar 2019 17:25:17
Quoted 4 lines
Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
Quoted 2 lines
So instead of "always 0x800000" that node has 0x2 as third entry for the 'reg' property. Why is that?
Quoted 8 lines
Quoted 2 lines
I didn't investigate that further yet, but I'm curious, so if anyone knows?
I suppose the bindings [1] explain the situation.
[1]
https://elixir.bootlin.com/linux/v5.0/source/Documentation/devicetree/bindi
ngs/mtd/atmel-nand.txt#L32
No, that was not what I wanted to know. The bindings says for that reg
property: “3rd entry: the memory region size (always 0x800000)”
This is true for some dts files including this nand node, but not for all, some have this:
	nand@3 {
		reg = <0x3 0x0 0x800000>;
Others have this:
	nand@3 {
		reg = <0x3 0x0 0x2>;
The second contradicts the binding doc. Most of this was changed when switching from the old bindings in changeset v4.12-rc1-7-g1004a2977bdc by Boris Brezillon. I wanted to know why the difference?

Quoted 7 lines

Quoted 3 lines
Indeed. Adding Alexandre who might also have an idea and Tudor for reference.
I'd say that <0x3 0x0 0x2> only works because ioremap will always map a 4k page and DMA is used so we are not accessing anything beyond that page using the virtual address.

Actually, we really need only 2 bytes not the full address range assigned to the EBI slot, even if you access the device in PIO mode. That's because NANDs are not directly addressable, and you'll have to issue command/address cycles before you can get real data on the bus. Those command and address words/bytes go through the same IO pins as actual data, and the maximum bus width for a NAND is 16-bits (hence the 2 bytes reserved here).

The rationale for not having the full EBI slot range mapped is that iomap regions have a cost (more entries in the MMU page table, and it also takes space in the virtual address, which is limited on 32 bits systems). IIRC, when I reworked the driver, Nicolas was trying to limit the size of all io-mapped regions, which is probably why we went for this "reserve only 2 bytes" approach.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/