Hi Archit, On Thu, 17 Dec 2015 15:18:46 +0530 Archit Taneja <arch...@codeaurora.org> wrote:
> > > > > Note that you could put the oobfree area at the end of the OOB area, > > since this 10-10-10-16-10 representation is already a virtual > > representation of the OOB area (ECC bytes are actually interleaved with > > in-band data on the flash). > > But, when I read from the controller's internal buffer via DMA, I first > get the oobfree area, and only then the last step's ECC bytes. So, the > content in chip->oob_poi is in the same order as mentioned > above (10-10-10-16-10). > > If the upper layers uses MTD_OPS_AUTO_OOB, and if I have a different > layout as what it is in the oob_poi buffer, then it'll end up > reading/writing the wrong bytes in nand_transfer_oob/nand_fill_oob. > > Are you suggesting that I modify the contents of oob_poi by hand such > that it has a cleaner 10-10-10-10-16 representation? Hm, I thought you could just place the free oob bytes wherever you want since there's only one oobfree region. AFAICS, it's just a matter of passing ->oob_poi + 40 instead of passing ->oob_poi + 30 when preparing the DMA descriptor (30 and 40 are just numbers for this specific use case). Anyway, I won't complain if you address all comments but this one. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
