Re: nand_flash_detect_onfi error

[Renaud Barbier <renaud.barbier@ge.com>]

On 03/11/2015 21:18, Boris Brezillon wrote:
> On Tue, 3 Nov 2015 17:59:01 -0300
> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
> 
>> On 3 November 2015 at 17:25, Boris Brezillon
>> <boris.brezillon@free-electrons.com> wrote:
>> [..]
>>>
>>> Hm, sorry but I don't like this idea. ->cmdfunc() is not supposed to
>>> retrieve any data before ->read_xxx() is called. I know some
>>> controllers retrieve data ahead of time and then provide the previously
>>> stored data when ->read_buf() is called, but that's not a good practice
>>> to assume it will work this way on all controllers (actually I keep
>>> thinking the sane implementations are those waiting for the
>>> ->read_buf() call before starting retrieving the data from the NAND
>>> chip).
>>>
>>
>> Right. We've discussed this in the past, and although I don't recall
>> the details,
>> I recall you were right.
>>
>> In any case, I just wanted to mention that if Renaud is getting
>> a read beyond the buffer, then probably the driver needs fixing.
>>
> 
> My bad, I thought the "read beyond the buffer" thing mentioned by
> Renaud was something generic. Now I get your point, and I agree: it
> should be fixed in the NAND controller driver, either by increasing the
> read buffer or by reworking the implementation to delay data retrieval
> until ->read_buf() is called.
> 

My CPU is a Freescale P1014 supported by the driver
drivers/mtd/nand/fsl_ifc_nand.c. Based on your information it seems the
easiest path is to set the "read_bytes" count to 3 * 256 and program the
controller to use this byte count when the CMD_PARAM command is used.

Cheers.