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 stefan@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