From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 4 Sep 2013 08:51:21 -0400 Subject: [U-Boot] [PATCH v3 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA0AA07@DBDE04.ent.ti.com> References: <1377773805-8751-1-git-send-email-pekon@ti.com> <20130829160611.GT17898@bill-the-cat> <20980858CB6D3A4BAE95CA194937D5E73EA07FF2@DBDE04.ent.ti.com> <521F892C.3000001@ti.com> <20980858CB6D3A4BAE95CA194937D5E73EA0AA07@DBDE04.ent.ti.com> Message-ID: <52272CC9.9080602@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----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 " .. ? >> >> 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-----