[PATCH v6 00/15] A SPI NAND framework under generic NAND framework
Peter Pan
peterpansjtu at gmail.com
Thu Dec 21 16:49:42 PST 2017
Hi Frieder,
On Thu, Dec 21, 2017 at 7:48 PM, Frieder Schrempf
<frieder.schrempf at exceet.de> wrote:
> 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]
I think we should add die_select_op in vendor's file and call a hook in core.c
since the die select command implementation is different by vendors.
Thanks
Peter Pan
>
> 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