Message ID | 20181109070349.20464-6-chris.packham@alliedtelesis.co.nz (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | EDAC drivers for Armada XP L2 and DDR | expand |
On Fri, Nov 9, 2018 at 8:04 AM Chris Packham <chris.packham@alliedtelesis.co.nz> wrote: > > Add documentation for the marvell,ecc-enable and marvell,ecc-disable > properties which can be used to enable/disable ECC on the Marvell aurora > cache. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > --- Why do you need both enable and disable? Wouldn't one of them be enough here? Arnd
On Fri, Nov 09, 2018 at 12:40:06PM +0100, Arnd Bergmann wrote: > On Fri, Nov 9, 2018 at 8:04 AM Chris Packham > <chris.packham@alliedtelesis.co.nz> wrote: > > > > Add documentation for the marvell,ecc-enable and marvell,ecc-disable > > properties which can be used to enable/disable ECC on the Marvell aurora > > cache. > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > --- > > Why do you need both enable and disable? Wouldn't one of them be enough here? It isn't an "on when ecc-enable is present, off when not" because the current behaviour is to preserve these bits in the control register. If we were to implement it as "if no ecc-enable property, turn off ECC" then that would drastically change the behaviour - systems which were configured for ECC suddenly lose ECC support. Since we don't know which have it and which don't, we can't implement the option like that.
On Fri, Nov 9, 2018 at 12:48 PM Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > > On Fri, Nov 09, 2018 at 12:40:06PM +0100, Arnd Bergmann wrote: > > On Fri, Nov 9, 2018 at 8:04 AM Chris Packham > > <chris.packham@alliedtelesis.co.nz> wrote: > > > > > > Add documentation for the marvell,ecc-enable and marvell,ecc-disable > > > properties which can be used to enable/disable ECC on the Marvell aurora > > > cache. > > > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > > --- > > > > Why do you need both enable and disable? Wouldn't one of them be enough here? > > It isn't an "on when ecc-enable is present, off when not" because the > current behaviour is to preserve these bits in the control register. > > If we were to implement it as "if no ecc-enable property, turn off > ECC" then that would drastically change the behaviour - systems which > were configured for ECC suddenly lose ECC support. > > Since we don't know which have it and which don't, we can't implement > the option like that. What I meant was why we need support force-disabling it. I understand that we need to allow leaving it at the boot-time default as well as force-enabling it. Arnd
On 10/11/18 4:58 AM, Arnd Bergmann wrote: > On Fri, Nov 9, 2018 at 12:48 PM Russell King - ARM Linux > <linux@armlinux.org.uk> wrote: >> >> On Fri, Nov 09, 2018 at 12:40:06PM +0100, Arnd Bergmann wrote: >>> On Fri, Nov 9, 2018 at 8:04 AM Chris Packham >>> <chris.packham@alliedtelesis.co.nz> wrote: >>>> >>>> Add documentation for the marvell,ecc-enable and marvell,ecc-disable >>>> properties which can be used to enable/disable ECC on the Marvell aurora >>>> cache. >>>> >>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >>>> --- >>> >>> Why do you need both enable and disable? Wouldn't one of them be enough here? >> >> It isn't an "on when ecc-enable is present, off when not" because the >> current behaviour is to preserve these bits in the control register. >> >> If we were to implement it as "if no ecc-enable property, turn off >> ECC" then that would drastically change the behaviour - systems which >> were configured for ECC suddenly lose ECC support. >> >> Since we don't know which have it and which don't, we can't implement >> the option like that. > > What I meant was why we need support force-disabling it. I understand > that we need to allow leaving it at the boot-time default as well as > force-enabling it. I added ecc-disable because I was modeling it after arm,parity-enable/arm,parity-disable. The only reason I can imagine wanting to force disable this would be some mis-behaving SoC which has it enabled by default in hardware, to my knowledge no such system exists (that would use this driver). I'd be happy to drop the binding an implementation and send a v7 if you feel strongly that it marvell,ecc-disable should be removed.
On Fri, 9 Nov 2018 20:03:45 +1300, Chris Packham wrote: > Add documentation for the marvell,ecc-enable and marvell,ecc-disable > properties which can be used to enable/disable ECC on the Marvell aurora > cache. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > --- > > Notes: > Changes in v6: > - new (split binding doc from implementation). > > Documentation/devicetree/bindings/arm/l2c2x0.txt | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt b/Documentation/devicetree/bindings/arm/l2c2x0.txt index fbe6cb21f4cf..15a84f0ba9f1 100644 --- a/Documentation/devicetree/bindings/arm/l2c2x0.txt +++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt @@ -76,6 +76,8 @@ Optional properties: specified to indicate that such transforms are precluded. - arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310). - arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310). +- marvell,ecc-enable : enable ECC protection on the L2 cache +- marvell,ecc-disable : disable ECC protection on the L2 cache - arm,outer-sync-disable : disable the outer sync operation on the L2 cache. Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that will randomly hang unless outer sync operations are disabled.
Add documentation for the marvell,ecc-enable and marvell,ecc-disable properties which can be used to enable/disable ECC on the Marvell aurora cache. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> --- Notes: Changes in v6: - new (split binding doc from implementation). Documentation/devicetree/bindings/arm/l2c2x0.txt | 2 ++ 1 file changed, 2 insertions(+)