Re: [PATCH v3 15/22] mtd: rawnand: fsmc: Stop implementing ->select_chip()

[Boris Brezillon <bbrezillon@xxxxxxxxxx>]

On Wed, 9 Jan 2019 21:41:24 +0100
Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:

> On Wed, Jan 9, 2019 at 8:45 PM Boris Brezillon <bbrezillon@xxxxxxxxxx> wrote:
> > [Me]  
> > > I will experiment with some delay valued and try to read some data
> > > sheets but if you already have hints on how to deal with this I'd
> > > like to hear!  
> >
> > Might be caused by a missing barrier: when de-asserting the CE line, we
> > must make sure all accesses to the ->data_va range have been done.
> > Can you try with the following diff applied?  
> 
> Tried it, but it sadly does not help :/
> 
> The machine crashes at the same place when doing ther first
> 64 bytes read.
> 
> I suppose the old code would hold CE enabled across all the
> commands?

For a read/write page accesses, yes.

> 
> Since the old code contained this:
> 
>        /* Support only one CS */
>        if (chipnr > 0)
>                return;
> 
> I guess that is normal for FSMC: only one CS. It seems a bit
> aggressive to toggle CS on/off between every command like this,
> I suspect the FSMC isn't really built for that but shakes apart
> or something.

Hm, that would be weird. There's indeed timing constraints on the NAND
chip side, but none infringing those constraints should not trigger an
external abort exception. Can you check which phys range is remapped at
0xcc960000?

> 
> I will send a version of your patch that keeps CS enabled
> for your consideration. (worksforme).

I guess that's fine to keep CE enabled if the bus is not shared with
other memories.

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