> 2013/5/16 Gupta, Pekon <pekon@xxxxxx>:
> >> >
> >>
> >> OMAP_ECC_BCH4_CODE_HW_DETECTION_SW and
> >> OMAP_ECC_BCH4_CODE_HW
> >> seems to exist in the code, but are not in the changelog, and not in
> >> the device tree binding documentation.
> >>
> >
> > Yes, I plan to omit them from code also, in next series as it does not
> > make sense to support both BCH4 and BCH8 at same time, when most
> > users would opt for BCH8.
> > Also, BCH4 was kept for legacy purposes, and was not tested on all
> devices.
> > Therefore I have purposely omitted it from documentation.
> >
>
> We have shipped devices with BCH4 nand. This would be a regression
> for us.
>
[Pekon]: May I know the following details so that I can prioritize BCH4 testing
- Which TI device have you productized ?
- Which kernel version you are using ? (Is it from mainline or SDK release)
- Which BCH4 ECC implementation you are using ?
BCH4_HW (using both GPMC and ELM H/W engines)
BCH4_HW_DETECTION_SW (using GPMC H/W and bch.h S/W libraries)
- Is there a specific reason why you opted for BCH4 instead of BCH8 ?
(Though its only recent that OMAP_ECC_BCHx support is mainlined
But, BCH8 support was available in TI SDK releases from quite sometime.)
I'll try to see if I can help you here, but going forward its always recommended
to use higher ECC schemes (like BCH8), so that flash's lifetime is extended on field.
> Regards,
> Jean-Philippe François.
>
with regards, pekon
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
