On 2015-04-03 22:36, Scott Wood wrote:
> On Fri, 2015-04-03 at 20:40 +0200, Stefan Agner wrote:
>> Support subpage writes using a custom implementation of write_subpage.
>> The driver loads the page into SRAM buffer using NAND_CMD_READ0, when
>> the framework requests the NAND_CMD_SEQIN command. Then, the buffer is
>> updated by the custom write_subpage implementation. Upon write, the
>> controller calculates the hardware ECC across the whole page before
>> programming the page.
>>
>> This method saves transferring the whole page over the bus to the NFC
>> IP, which would happen when using NAND_NO_SUBPAGE_WRITE.
>>
>> Signed-off-by: Stefan Agner <ste...@agner.ch>
>
> As previously discussed, please explain why subpage writes make sense
> with this controller.
I thought the subpage callback is just about writing an arbitrary amount
of data (e.g. 32 bytes) into a page.
I quickly checked, when doing
# nand write ${loadaddr} 0x10000 0x10
vf610_nfc_write_subpage gets actually called with a data_len of 16.
This is how I understand it:
Currently, subpage writes are supported by the MTD subsystem due to the
option NAND_NO_SUBPAGE_WRITE. Due to that option, nand_write_page in
nand_base.c calls write_page which copies always the whole page into the
SRAM buffer over the AHB bus to the NFC IP (vf610_nfc_write_page uses
memcpy uses mtd->writesize).
This patch supports it naively, which means that only the updated data
(according to offset and data_len parameter of write_subpage) get copied
over the AHB bus to the NFC IP (vf610_nfc_write_subpage uses memcpy to
only copy data_len). To have reasonable data for the rest of the page,
the page gets read back when calling NAND_CMD_SEQIN.
Since the whole page get programmed, this assumes that none of the page
has been programmed before (erased page). Hence, we essentially just
read 0xff. When I think about it now, reading the page back in SEQIN is
then probably just an expensive memset 0xff replacement.
I guess when having real subpages (e.g. 4x512bytes, each subpage with
its own ECC), I would have to make sure only the affected subpage gets
ECC'ed and written.
Even without having real subpages, if somebody only writes part of a
page, memset directly into SRAM & memcpy the subpage data is
theoretically faster then memset the whole page in DDR RAM and memcpy
the whole page....
Just checked what higher up the stack is actually happening:
nand_write_page anyway receives a whole page buffer as argument, which
is memset'ed with 0xff and the data to be written memcpy'ed.
I see, that this patch tries to improve something which anyway is taken
care of by the stack.
I will remove the page read on NAND_CMD_SEQIN, since we memcpy the full
page anyway. I also just realized that the page read actually happens
always and hence slows down even full page writes...
--
Stefan
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
