Re: atmel nand bindings vs. actual dts files

[Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>]

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

> On 30/04/2019 11:32:42+0200, Miquel Raynal wrote:
> > Hi Alexander,
> > 
> > Alexander Dahl <ada@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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/