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

Frieder Schrempf frieder.schrempf at exceet.de
Thu Dec 21 03:48:16 PST 2017


Hello Boris,

>>>> So shouldn't there be an spinand_die_select_op in the SPI NAND core that
>>>> is executed when necessary and skipped if there's only one die.
>>>
>>> Sure, I was arguing against a ->select_chip() at the generic NAND
>>> level. That's something you can add in the SPI NAND framework.

I added an op to send the die selection command and call it, where I 
think it is needed: [1]

Accessing both dies on the Winbond SPI NAND works fine like this.

While running tests I came across some problems:

* On accessing the BBT in RAM via nanddev_bbt_[set/get]_block_status, 
the calculation of position and offset seems to be wrong.
My fix is here: [2]

* On calculating the row address for read/program/erase via 
nanddev_pos_to_row, it seems like the eraseblock_addr_shift is wrong.

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

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.

Regards,

Frieder

[1]: 
https://github.com/fschrempf/linux-0day/compare/4f8472ea05f27d55ebb2e42eadc9ed59d7036f4c...fschrempf:2c5471c1f1e04fa91ff80c95276b4828b99c4f94

[2]: 
https://github.com/fschrempf/linux-0day/commit/937a16248570368fe05e15b1f70e753e202b6ae6

[3]: 
https://github.com/fschrempf/linux-0day/commit/8013696e0394960bfc36625d277f0d2425262939

[4]: 
https://github.com/fschrempf/linux-0day/commit/28ffc7211745dd124702358c24ddccff8e6f2d95



More information about the linux-mtd mailing list