[U-Boot] [PATCH v3 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/02/2013 10:56 AM, Gupta, Pekon wrote:
>> On 08/29/2013 01:26 PM, Gupta, Pekon wrote:
>>>>
[snip]
>>>> I think we should move the selected message to a debug().
>>>>
>>> Second part of string "nand: selected OMAP_ECC_BCH8_CODE_HW" was
>>> specifically added in board_nand_init() because currently there is no way
>>> to identify the ECC scheme being used in u-boot. Unless digging into
>>>  source code and reviewing board file.
>>> And many time end-users face ECC scheme mis-match between u-boot
>>> and linux when flashing kernel and file-system from u-boot.
>>> Thus this print helps in identifying the ECC scheme being used from logs.
>>> So, please keep this print "nand: selected <ecc-scheme>" ..  ?
>>
>> I'd rather not as we should have left the mis-match problems in the
>> past.  We don't generally offer commands to switch ECC schemes as
>> everyone is using the same now.  When we do need to offer switching for
>> legacy reasons that's when we should say what we're on.
>>
> I think we should not deprecate the 'ecc_switching_utility', bcoz there are
> multiple scenarios even in newer devices where it is useful..
> 
> Example-1: using built-in NAND devices
[snip]

The ROM already needs to handle this mode and simply go with "on die
ECC" and we need to mirror this behaviour.

> Example-2: upgrading ECC on legacy devices
> There are many users with devices in production, who would like to
> upgrade to newer ECC schemes (like BCH16), only  when these drivers
> are stable. Such users depend on u-boot to switch newer ECC schemes
> (like BCH16) and then re-flash upgraded kernel and file-systems on 
> remote machines.
> In such cases also 'ecc_switching_utility' is helpful.

But they've got a problem today, which is that the ROM demands BCH16
already, so they have to use BCH16 or not be booting from NAND.

> Though I don't want to be stubborn here.. 
> But if your plan is to completely remove 'ecc_switching_utility' support
> then I would move back to V2 version of this patch, where ecc scheme
> is selected by #CONFIGS, so that only that code footprint gets optimized.
> 
> Please let me know, which way to go forward..
> - [Patch V2 xx] where ECC selection is via #CONFIGS
> - [Patch V3 xx] where ECC selection can be done via software
> 	 (ecc_switching_utility)
> 	 Incase you opt for [V3], my humble request is to keep
> 	 above prints and not to convert them into 'debug' (please) :-)

We need to do run-time detection of what ecc mode is to be used.  We
don't want to expose the 'nandecc' type command we have on OMAP3 without
a real case (and I don't count ones that can be constructed as an
example on beaglebone + capes, but I do count real hardware designs).

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSJyzJAAoJENk4IS6UOR1WfiQP/Rwr5Gcqvg4RP6Rp7ppN0HSm
suzbjCTgsWxY9SeSEO1L4GiGWRxZSAKkdE/KSYTPRPfjrdev+i6poZfoI6JlMK64
d/HnI37yAV4dOYA3tQImyXfZi+8teWKqm4vXyRsQqq9tJFmGppX4iRV9G8OVBUJv
lZVEw+OpW2Fktq+jcMskwGz3TKYmMTDh4GlcQnX3BHltkOGe1lkCMmQoxxyAYkfO
/O1gvwrvUhzkjgkRIG18rlHW34qMZqflAIfHNjSxXLpeuDYkCi6EsCJHTpelQuYG
3+9fAGY4zSleR+e29QfrgyuOSwR3s+ElZ1VmNRl7e0TeE9yb20frZCJhfYAq1vYu
wjeKJcfkscPRYaGTUc7jhyyMgK2hrCk9kVCOdRfUrJe+ElaqlhU1/ugOADQky8bN
QxqGwhSpPT8tLKBrUaIqix3DOMdt1yQXos+qhaFba73zMO+gwAtEHVWQELQIASLD
K3mAcs3vfDzMvLke95xPNLA7KP09O9LV892ND+5v8/6UVDUQX2IyEjTjLKDeG7Ae
P9OgE90UlbgxC7vEbtt1rxDLrhLr57EECigKjFhFsfFdSMkj+FEnyxb0Dmp+5JRY
s0QxaRAz4nvpFW1KcTY2fhIaqiYEgLEMRcgcwiQeVxqezQAtRFlK9xAX7DmCjw5K
zgzrEslpmfYxi3+DcF4Y
=K7aI
-----END PGP SIGNATURE-----