public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 0/4]  mtd: nand: omap: add support for BCH16_ECC
@ 2014-05-19  7:54 Pekon Gupta
  2014-05-19  7:54 ` [PATCH v4 1/4] mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates Pekon Gupta
                   ` (4 more replies)
  0 siblings, 5 replies; 9+ messages in thread
From: Pekon Gupta @ 2014-05-19  7:54 UTC (permalink / raw)
  To: Brian Norris, Tony Lindgren
  Cc: linux-mtd, linux-omap, Ezequiel Garcia, Stefan Roese,
	Felipe Balbi, Pekon Gupta

As this series touches both linux-mtd and linux-omap (GPMC) sub-systems but in
independent patch-sets, so looping both maintainers. 'Ack' from maintainers would
help in getting this series accepted for 3.16

*changes v3 -> v4*
[PATCH v4 1/4]: minor update in comments
[PATCH v4 2/4]: fixed coding style to keep it generic for big/little endianess
[PATCH v4 3/4]: no change
[PATCH v4 4/4]: use plain english (non linux stuff)


*changes v2 -> v3*
[PATCH v2 3/4] rebased to http://lists.infradead.org/pipermail/linux-mtd/2014-March/052655.html
- no change in other patches


*changes v1 -> v2*
 rebased and cleaned on following versions of pending patches
  (1) [PATCH v8 0/6] mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemes
  http://lists.infradead.org/pipermail/linux-mtd/2014-February/052092.html

  (2) [PATCH v6 0/4] mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemes
  http://lists.infradead.org/pipermail/linux-mtd/2014-February/052272.html

  (3) [PATCH v5 0/4] mtd: nand: omap: optimize chip->ecc.hwctl() for H/W ECC schemes
  http://lists.infradead.org/pipermail/linux-mtd/2014-March/052327.html

  (4) [PATCH v6 0/4] mtd: devices: elm: add checks ELM H/W constrains, driver code cleanup
  http://lists.infradead.org/pipermail/linux-mtd/2014-March/052455.html
 
 Tested on Beaglebone-LT(white) NAND cape having NAND Device with
       bus-width=16, block-size=256k, page-size=4k, oob-size=224


*original v1*
http://lists.infradead.org/pipermail/linux-mtd/2013-July/047562.html

With increase in NAND flash densities and shrinking of technology
NAND flash has become more suspectible to multiple bit-flips.
Thus stronger ECC schemes are required for detecting and correcting multiple
simultaneous bit-flips in same NAND page. But stronger ECC schemes have large
ECC syndrome which require more space in OOB/Spare.

This patch add support for BCH16 ecc-scheme on OMAP NAND driver:
(a) BCH16 ecc-scheme can correct 16 bit-flips per 512Bytes of data.
(b) BCH16 ecc-scheme generates 26-bytes of ECC syndrome / 512B.

Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page >= 26 * (page-size / 512)


Pekon Gupta (4):
  mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates
  mtd: nand: omap: add support for BCH16_ECC - ELM driver updates
  mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
  mtd: nand: omap: Documentation: How to select correct ECC scheme for
    your device ?

 .../devicetree/bindings/mtd/gpmc-nand.txt          | 45 +++++++++++
 arch/arm/mach-omap2/gpmc.c                         | 15 ++++
 drivers/mtd/devices/elm.c                          | 36 +++++++++
 drivers/mtd/nand/omap2.c                           | 94 ++++++++++++++++++++++
 include/linux/platform_data/elm.h                  |  3 +-
 include/linux/platform_data/mtd-nand-omap2.h       |  5 ++
 6 files changed, 197 insertions(+), 1 deletion(-)

-- 
1.8.5.1.163.gd7aced9


^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: [PATCH v4 3/4] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
@ 2014-05-22 17:56 Gupta, Pekon
  0 siblings, 0 replies; 9+ messages in thread
From: Gupta, Pekon @ 2014-05-22 17:56 UTC (permalink / raw)
  To: Brian Norris
  Cc: Tony Lindgren, linux-mtd, linux-omap, Ezequiel Garcia,
	Stefan Roese, Balbi, Felipe, Quadros, Roger

Hi Brian,

>From: Brian Norris
>>On Mon, May 19, 2014 at 01:24:41PM +0530, Pekon Gupta wrote:
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1201,6 +1219,41 @@ static int __maybe_unused omap_calculate_ecc_bch(struct mtd_info
>*mtd,
>>  			*ecc_code++ = ((bch_val1 >> 4) & 0xFF);
>>  			*ecc_code++ = ((bch_val1 & 0xF) << 4);
>>  			break;
>> +		case OMAP_ECC_BCH16_CODE_HW:
>> +			val = readl(gpmc_regs->gpmc_bch_result6[i]);
>
>For all of these 'gpmc_bch_resultX' fields, couldn't you make this into
>a 2-D array? So to access BCH result 6 at sector i, it would be:
>
>			val = readl(gpmc_regs->gpmc_bch_result[6][i];
>
>This could help you to rewrite some of this stuff as loops, instead of
>giant blocks of copy-paste-modify.
>

Thanks for excepting the series. With this series OMAP NAND driver
comes to a stable point supporting NAND boot on all latest platforms.

I had earlier experimented with something similar to your suggestions
but these clean-ups require update in multiple drivers (GPMC, NAND, ...),
and it was becoming messy, so I dropped it. There are some practical
challenges to this type of clean-up like;

(1) GPMC register addresses here "gpmc_regs" are initialized in GPMC driver
 So your suggested changes will affect multiple subsystems, hence
This type of clean-up is bit deferred from sometime.


(2) The register space for gpmc_bch_results is not contiguous.
GPMC_BCH_RESULT_0	RW	0x240-0x2B0
GPMC_BCH_RESULT_1	RW	0x244-0x2B4
GPMC_BCH_RESULT_2	RW	0x248-0x2B8
GPMC_BCH_RESULT_3	RW	0x24C-0x2BC
[...]
GPMC_BCH_RESULT_4	RW	0x300-0x370
GPMC_BCH_RESULT_5	RW	0x304-0x374
GPMC_BCH_RESULT_6	RW	0x308-0x378

This is because older version of GPMC hardware IP  (like in OMAP3)
supported only till BCH8 ecc-scheme. Later same hardware IP was
extended to support BCH16. So newer platforms have extended
register-map. So it was felt that instead of having separate for..loops
lets continue with replicating all 7 GPMC_BCH_RESULT registers.


>> +			ecc_code[0]  = ((val >>  8) & 0xFF);
>> +			ecc_code[1]  = ((val >>  0) & 0xFF);
>> +			val = readl(gpmc_regs->gpmc_bch_result5[i]);
>> +			ecc_code[2]  = ((val >> 24) & 0xFF);
>> +			ecc_code[3]  = ((val >> 16) & 0xFF);
>> +			ecc_code[4]  = ((val >>  8) & 0xFF);
>> +			ecc_code[5]  = ((val >>  0) & 0xFF);
>
>A lot of this code can be rewritten to use the endian swapping macros, I
>expect. Something like this looks equivalent:
>
>			*((uint32_t *)&ecc_code[2]) = cpu_to_be32(val);
>
>You could probably fix the types up to make this look a little nicer.
>

(3) BCH4 use different alignment than BCH8 and BCH16 as ECC syndrome
is not bytewise aligned (it's of 6 1/2 bytes = 13 nibbles).  So for BCH4
higher-nibble or reg1 is shifted and ORed with lower-nibble of reg2.
There is no byte-to-byte mapping. So generic implementation becomes messy.

However, Roger Quadros is planning GPMC driver clean-up, so looping him
in-case he can incorporate some of these things while re-factoring GPMC code.


with regards, pekon

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-05-22 17:57 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-19  7:54 [PATCH v4 0/4] mtd: nand: omap: add support for BCH16_ECC Pekon Gupta
2014-05-19  7:54 ` [PATCH v4 1/4] mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates Pekon Gupta
2014-05-19 22:35   ` Tony Lindgren
2014-05-19  7:54 ` [PATCH v4 2/4] mtd: nand: omap: add support for BCH16_ECC - ELM " Pekon Gupta
2014-05-19  7:54 ` [PATCH v4 3/4] mtd: nand: omap: add support for BCH16_ECC - NAND " Pekon Gupta
2014-05-21  1:36   ` Brian Norris
2014-05-19  7:54 ` [PATCH v4 4/4] mtd: nand: omap: Documentation: How to select correct ECC scheme for your device ? Pekon Gupta
2014-05-21  1:05 ` [PATCH v4 0/4] mtd: nand: omap: add support for BCH16_ECC Brian Norris
  -- strict thread matches above, loose matches on Subject: below --
2014-05-22 17:56 [PATCH v4 3/4] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates Gupta, Pekon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox