[PATCH v6 00/15] A SPI NAND framework under generic NAND framework

[Frieder Schrempf]

Hi Boris,

On 21.12.2017 14:01, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Thu, 21 Dec 2017 12:48:16 +0100
> Frieder Schrempf <frieder.schrempf at exceet.de> wrote:
>>
>> * On calculating the row address for read/program/erase via
>> nanddev_pos_to_row, it seems like the eraseblock_addr_shift is wrong.
> 
> My version was incorrect, but yours is not good either :-), should
> be:
> 
> 	nand->rowconv.eraseblock_addr_shift =
> 				fls(memorg->pages_per_eraseblock - 1);
> 
> otherwise it doesn't work when the number of pages per block is not a
> power of 2, and that can happen :-/.

Ok, makes sense.

>> * Also, I'm not sure if the LUN should be taken into account when
>> calculating the row address. At least when you select the LUN by issuing
>> a separate command, the row address sent to the chip should only contain
>> the page address.
> 
> The LUN id is part of the row address on parallel ONFI NANDs. Are you
> sure what you're trying to access is actually a LUN?
> 
> The ONFI spec says:
> "
> LUN (logical unit number)
> The minimum unit that can independently execute commands and report
> status. There are one or more LUNs per NAND Target.
> "
> 
> I suspect what you're trying to expose is a chip with 2 targets
> (target is a synonym for die). If this is the case, then you should
> have:
> 
> 	luns_per_target = 1;
> 	ntargets = 2;	/* ntargets <=> number of dies */

Indeed. It seems like I misunderstood the meaning of LUN.
Thank you for explaining.

I fixed my chip setup and refactored my die/target selection code 
accordingly.

> 
>> But I'm not sure if that's the case in general, or if some code is
>> needed to differentiate.
>>
>> See my changes of nanddev_pos_to_row here: [3]
>>
>> * I run into a mutex deadlock, when spinand_write_page fails (e.g.
>> because of a bad block) as the lock is not released in such cases. See
>> my fix here: [4]
> 
> This is a valid fix.
> 
>>
>> With these fixes applied and as far as I can tell everything seems to
>> work fine. I'll do some tests with UBI next and look into the ECC topic.
> 
> Okay cool.
> 
> I'll squash your fixes in the original commits and push an updated
> version on my repo.

Ok, great!

Thanks a lot,

Frieder