atmel nand bindings vs. actual dts files

atmel nand bindings vs. actual dts files

[Alexander Dahl]

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/

Re: atmel nand bindings vs. actual dts files

[Alexander Dahl]

Hello,

Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
> 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?

> 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/

Re: atmel nand bindings vs. actual dts files

[Miquel Raynal]

Hi Alexander,

Sorry for the big delay.

Alexander Dahl <ada@thorsis.com> wrote on Thu, 07 Mar 2019 17:25:17
+0100:

> Hello,
> 
> Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
> > 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

> 
> > 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.

> 
> 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?

->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/

Re: atmel nand bindings vs. actual dts files

[Alexander Dahl]

Hello Miquèl,

Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:
> Alexander Dahl <ada@thorsis.com> wrote on Thu, 07 Mar 2019 17:25:17
> > Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:
> > > 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/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/

Re: atmel nand bindings vs. actual dts files

[Miquel Raynal]

Hi Alexander,

Alexander Dahl <ada@thorsis.com> wrote on Tue, 30 Apr 2019 11:24:44
+0200:

> Hello Miquèl,
> 
> Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:
> > Alexander Dahl <ada@thorsis.com> wrote on Thu, 07 Mar 2019 17:25:17  
> > > Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:  
> > > > 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/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? 

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/

Re: atmel nand bindings vs. actual dts files

[Alexandre Belloni]

On 30/04/2019 11:32:42+0200, Miquel Raynal wrote:
> Hi Alexander,
> 
> Alexander Dahl <ada@thorsis.com> wrote on Tue, 30 Apr 2019 11:24:44
> +0200:
> 
> > Hello Miquèl,
> > 
> > Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:
> > > Alexander Dahl <ada@thorsis.com> wrote on Thu, 07 Mar 2019 17:25:17  
> > > > Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:  
> > > > > 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/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? 
> 
> 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.


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

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

Re: atmel nand bindings vs. actual dts files

[Boris Brezillon]

On Tue, 4 Jun 2019 03:53:01 +0200
Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:

> On 30/04/2019 11:32:42+0200, Miquel Raynal wrote:
> > Hi Alexander,
> > 
> > Alexander Dahl <ada@thorsis.com> wrote on Tue, 30 Apr 2019 11:24:44
> > +0200:
> >   
> > > Hello Miquèl,
> > > 
> > > Am Montag, 29. April 2019, 11:55:40 CEST schrieb Miquel Raynal:  
> > > > Alexander Dahl <ada@thorsis.com> wrote on Thu, 07 Mar 2019 17:25:17    
> > > > > Am Mittwoch, 6. März 2019, 15:07:52 CET schrieb Alexander Dahl:    
> > > > > > 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/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?   
> > 
> > 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/