| Message ID | 1448709248-21177-5-git-send-email-sebastian.hesselbarth@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Nov 28, 2015 at 12:14:08PM +0100, Sebastian Hesselbarth wrote: > The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection. > Add the corresponding properties to the NAND node. > > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Andrew
Sebastian, Adding Ezequiel Garcia in Cc. On Sat, 28 Nov 2015 12:14:08 +0100, Sebastian Hesselbarth wrote: > The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection. > Add the corresponding properties to the NAND node. If the ONFI information from the NAND flash say that it requires 4 bits per 512, then there should be no need to add this information to the Device Tree as the pxa3xx_nand driver by default uses the ONFI information. Those properties are only needed when for some reason the vendor has chosen to use a ECC strength that doesn't match with the one advertised by the flash in its ONFI information (either stronger or weaker). But in this case, your commit log is confusing, because it says that the "NAND device ... uses 4-bit BCH ECC protection". If it really does, then the patch is not needed :-) Best regards, Thomas
On 29.11.2015 15:35, Thomas Petazzoni wrote: > Adding Ezequiel Garcia in Cc. > > On Sat, 28 Nov 2015 12:14:08 +0100, Sebastian Hesselbarth wrote: >> The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection. >> Add the corresponding properties to the NAND node. > > If the ONFI information from the NAND flash say that it requires 4 bits > per 512, then there should be no need to add this information to the > Device Tree as the pxa3xx_nand driver by default uses the ONFI > information. Thomas, as said in the cover letter, this is also DT cleanup with barebox bootloader in mind. I do not accept what Linux' pxa3xx_nand driver is doing as a reference here ;) > Those properties are only needed when for some reason the vendor has > chosen to use a ECC strength that doesn't match with the one advertised > by the flash in its ONFI information (either stronger or weaker). But > in this case, your commit log is confusing, because it says that the > "NAND device ... uses 4-bit BCH ECC protection". If it really does, > then the patch is not needed :-) I agree that if ONFI is already advertising 4/512 ECC (and it is), we do not need the properties. Anyway, IIRC barebox does not yet properly parse ONFI or at least it does not derive minimum ECC settings from it. I'll have to have a closer look at barebox' ONFI parsing capabilites and can live with this patch not applied even though it does no harm. Sebastian
Hi Sebastian, On lun., nov. 30 2015, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote: > On 29.11.2015 15:35, Thomas Petazzoni wrote: >> Adding Ezequiel Garcia in Cc. >> >> On Sat, 28 Nov 2015 12:14:08 +0100, Sebastian Hesselbarth wrote: >>> The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection. >>> Add the corresponding properties to the NAND node. >> >> If the ONFI information from the NAND flash say that it requires 4 bits >> per 512, then there should be no need to add this information to the >> Device Tree as the pxa3xx_nand driver by default uses the ONFI >> information. > > Thomas, > > as said in the cover letter, this is also DT cleanup with barebox > bootloader in mind. I do not accept what Linux' pxa3xx_nand driver > is doing as a reference here ;) > >> Those properties are only needed when for some reason the vendor has >> chosen to use a ECC strength that doesn't match with the one advertised >> by the flash in its ONFI information (either stronger or weaker). But >> in this case, your commit log is confusing, because it says that the >> "NAND device ... uses 4-bit BCH ECC protection". If it really does, >> then the patch is not needed :-) > > I agree that if ONFI is already advertising 4/512 ECC (and it is), we > do not need the properties. Anyway, IIRC barebox does not yet properly > parse ONFI or at least it does not derive minimum ECC settings from it. > > I'll have to have a closer look at barebox' ONFI parsing capabilites > and can live with this patch not applied even though it does no harm. So for now, I don't apply it. Thanks, Gregory
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts index 13cf69a8d0fb..e4bf83c4bd2f 100644 --- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts @@ -150,6 +150,8 @@ marvell,nand-keep-config; marvell,nand-enable-arbiter; nand-on-flash-bbt; + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; partitions { #address-cells = <1>;
The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection. Add the corresponding properties to the NAND node. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> --- Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: Kumar Gala <galak@codeaurora.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Benoit Masson <yahoo@perenite.com> Cc: linux-arm-kernel@lists.infradead.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 2 ++ 1 file changed, 2 insertions(+)