[U-Boot] [PATCH resend V2 1/3] mtd: nand: mxs support oobsize bigger than 512

[Peng Fan <b51431@freescale.com>]

Hi Scott,

Do you have plan to pick the 3 patches?

https://patchwork.ozlabs.org/patch/498050/
https://patchwork.ozlabs.org/patch/498049/
https://patchwork.ozlabs.org/patch/498048/

If not, then I prefer these 3 patches can go throught i.mx tree.

Thanks,
Peng.

On Sun, Aug 02, 2015 at 11:18:38AM +0800, Peng Fan wrote:
>On Sat, Aug 01, 2015 at 01:54:48PM -0500, Scott Wood wrote:
>>On Sat, 2015-08-01 at 20:38 +0200, Marek Vasut wrote:
>>> On Saturday, August 01, 2015 at 08:32:07 PM, Scott Wood wrote:
>>> > On Sat, 2015-08-01 at 17:18 +0200, Marek Vasut wrote:
>>> > > On Saturday, August 01, 2015 at 07:56:39 AM, Peng Fan wrote:
>>> > > > On Fri, Jul 31, 2015 at 09:36:45PM -0500, Scott Wood wrote:
>>> > > > > On Sat, 2015-08-01 at 09:15 +0800, Peng Fan wrote:
>>> > > > > > On Fri, Jul 31, 2015 at 12:07:50PM -0500, Scott Wood wrote:
>>> > > > > > > On Tue, 2015-07-21 at 16:15 +0800, Peng Fan wrote:
>>> > > > > > > > If ecc chunk data size is 512 and oobsize is bigger than 512,
>>> > > > > > > > there
>>> > > > > > > > is a chance that block_mark_bit_offset conflicts with bch ecc
>>> > > > > > > > area.
>>> > > > > > > > 
>>> > > > > > > > The following graph is modified from kernel gpmi-nand.c driver
>>> > > > > > > > with
>>> > > > > > > > each data block 512 bytes. We can see that Block Mark 
>>> > > > > > > > conflicts
>>> > > > > > > > with
>>> > > > > > > > ecc area from bch view. We can enlarge the ecc chunk size to
>>> > > > > > > > avoid this problem to those oobsize which is larger than 512.
>>> > > > > > > 
>>> > > > > > > Enlarge it by how much?  What does the layout look like in that
>>> > > > > > > case?
>>> > > > > > 
>>> > > > > > Enlarge it to 1024 bytes.
>>> > > > > 
>>> > > > > Then say so in the changelog.
>>> > > > 
>>> > > > You mean I need to add this in commit msg and send out a new patch
>>> > > > version?
>>> > > > Or you pick this one?
>>> > > 
>>> > > This discussion is becoming ridiculous, can we please get this bugfix
>>> > > applied ?
>>> > > If you don't like some minor details in the commit message, can you
>>> > > please fix
>>> > > them while applying ?
>>> > 
>>> > Yes, I can edit the changelog while applying, but that doesn't mean I'm 
>>> > not
>>> > going to complain about a difficult-to-understand changelog, and I still
>>> > would like to understand what is actually going on here.  Don't assume I'm
>>> > familiar with this hardware or its unusual page layout.  You can help by
>>> > explaining things, or you can not help by throwing a fit...
>>> 
>>> I can point you to MX28 datasheet [1] chapter 16.2.2 and onward if you want
>>> to educate yourself, it's all explained there, concisely and clearly.
>>> 
>>> [1] http://free-electrons.com/~maxime/pub/datasheet/MCIMX28RM.pdf
>>
>>Thanks.  That preempted a question I was just about to ask Peng, because it 
>>wasn't clear that the meta area was covered by ECC.
>
>In mxs_nand.c driver, we use "Combined Metadata & Block 0, unbalanced ECC coverage" layout from chapter 16.2.2 of MX28 datasheet.
>
>Peng.
>>
>>-Scott
>>
>
>-- 

--