Re: [PATCH v4 6/6] mtd: update the ABI document about the ecc step size

[Huang Shijie <shijie8@gmail.com>]

On Sat, Aug 17, 2013 at 11:14:47AM -0700, Brian Norris wrote:
> On Fri, Aug 16, 2013 at 11:26:47PM -0400, Huang Shijie wrote:
> 
> I took pieces of your message and rewrote it myself. Diff pasted below
> (I edited ecc_strength to be less redundant and added a few details that
> were worth mentioning). Let me know if you want to revise it, but I'll

thanks a lot!

I really appreciate it. I always feel embarrassed when i descibe
something in English :(


> push it to l2-mtd.git.
> 
> Brian
> 
> ---
>  Documentation/ABI/testing/sysfs-class-mtd | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
> index 3105644..a795582 100644
> --- a/Documentation/ABI/testing/sysfs-class-mtd
> +++ b/Documentation/ABI/testing/sysfs-class-mtd
> @@ -128,9 +128,8 @@ KernelVersion:	3.4
>  Contact:	linux-mtd@lists.infradead.org
>  Description:
>  		Maximum number of bit errors that the device is capable of
> -		correcting within each region covering an ecc step.  This will
> -		always be a non-negative integer.  Note that some devices will
> -		have multiple ecc steps within each writesize region.
> +		correcting within each region covering an ECC step (see
> +		ecc_step_size).  This will always be a non-negative integer.
>  
>  		In the case of devices lacking any ECC capability, it is 0.
>  
> @@ -173,3 +172,16 @@ Description:
>  		This is generally applicable only to NAND flash devices with ECC
>  		capability.  It is ignored on devices lacking ECC capability;
>  		i.e., devices for which ecc_strength is zero.
> +
> +What:		/sys/class/mtd/mtdX/ecc_step_size
> +Date:		May 2013
> +KernelVersion:	3.10
> +Contact:	linux-mtd@lists.infradead.org
> +Description:
> +		The size of a single region covered by ECC, known as the ECC
> +		step.  Devices may have several equally sized ECC steps within
> +		each writesize region.  The step size counts only the data area,
> +		not the spare area.

Maybe this sentence is not accurate enough.

As far as i know, when the gpmi does the hardware ECC, the last ECC step
will use parts of the spare area. Just like:

----------------------------------------------------------------------------------
	 *    |                          P                            |
	 *    |<----------------------------------------------------->|
	 *    |                                                       |
	 *    |                                        (Block Mark)   |
	 *    |                      P'                      |      | |     |
	 *    |<-------------------------------------------->|  D   | |  O' |
	 *    |                                              |<---->| |<--->|
	 *    V                                              V      V V     V
	 *    +---+----------+-+----------+-+----------+-+----------+-+-----+
	 *    | M |   data   |E|   data   |E|   data   |E|   data   |E|     |
	 *    +---+----------+-+----------+-+----------+-+----------+-+-----+
	 *                                                   ^              ^
	 *                                                   |      O       |
	 *                                                   |<------------>|
	 *
	 *	P : the page size for BCH module.
	 *	E : The ECC strength.
	 *	G : the length of Galois Field.
	 *	N : The chunk count of per page.
	 *	M : the metasize of per page.
	 *	C : the ecc chunk size, aka the "data" above.
	 *	P': the nand chip's page size.
	 *	O : the nand chip's oob size.
	 *	O': the free oob.
----------------------------------------------------------------------------------
 In this diagram, the "O" stands for the spare area, and the last ECC
 step will use part of the spare area, the "Block Mark" is the boundary
 for the page and OOB.

thanks
Huang Shijie