| Message ID | 20200304090031.30360-1-rogerq@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled | expand |
* Roger Quadros <rogerq@ti.com> [200304 09:01]: > Even though the TRM says that SATA IP has 36 address bits > wired in the SoC, we see bus errors whenever any address > greater than 32-bit is given to the controller. > > This happens on dra7-EVM with 4G of RAM with CONFIG_ARM_LPAE=y. > > As a workaround we limit the DMA address range to 32-bits > for SATA. > > Cc: Christoph Hellwig <hch@lst.de> > Cc: Robin Murphy <robin.murphy@arm.com> > Cc: Rob Herring <robh+dt@kernel.org> > Reported-by: Yan Liu <yan-liu@ti.com> > Signed-off-by: Roger Quadros <rogerq@ti.com> > --- > > NOTE: Currently ARM dma-mapping code doesn't account for devices > bus_dma_limit. This is fixed in [1]. > > [1] https://lkml.org/lkml/2020/2/18/712 So is this dts patch safe to apply without the series above? And should this dts patch be applied as a fix or can it wait until the merge window? Regards, Tony > arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++--------- > 1 file changed, 16 insertions(+), 9 deletions(-) > > diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi > index d78b684e7fca..895462c22d1c 100644 > --- a/arch/arm/boot/dts/dra7.dtsi > +++ b/arch/arm/boot/dts/dra7.dtsi > @@ -642,15 +642,22 @@ > }; > > /* OCP2SCP3 */ > - sata: sata@4a141100 { > - compatible = "snps,dwc-ahci"; > - reg = <0x4a140000 0x1100>, <0x4a141100 0x7>; > - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; > - phys = <&sata_phy>; > - phy-names = "sata-phy"; > - clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; > - ti,hwmods = "sata"; > - ports-implemented = <0x1>; > + sata_aux_bus { > + #address-cells = <1>; > + #size-cells = <2>; > + compatible = "simple-bus"; > + ranges = <0x0 0x4a140000 0x0 0x1200>; > + dma-ranges = <0x0 0x0 0x1 0x00000000>; > + sata: sata@4a141100 { > + compatible = "snps,dwc-ahci"; > + reg = <0x0 0x0 0x1100>, <0x1100 0x0 0x7>; > + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; > + phys = <&sata_phy>; > + phy-names = "sata-phy"; > + clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; > + ti,hwmods = "sata"; > + ports-implemented = <0x1>; > + }; > }; > > /* OCP2SCP1 */ > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >
Tony, Christoph, On 04/03/2020 18:20, Tony Lindgren wrote: > * Roger Quadros <rogerq@ti.com> [200304 09:01]: >> Even though the TRM says that SATA IP has 36 address bits >> wired in the SoC, we see bus errors whenever any address >> greater than 32-bit is given to the controller. >> >> This happens on dra7-EVM with 4G of RAM with CONFIG_ARM_LPAE=y. >> >> As a workaround we limit the DMA address range to 32-bits >> for SATA. >> >> Cc: Christoph Hellwig <hch@lst.de> >> Cc: Robin Murphy <robin.murphy@arm.com> >> Cc: Rob Herring <robh+dt@kernel.org> >> Reported-by: Yan Liu <yan-liu@ti.com> >> Signed-off-by: Roger Quadros <rogerq@ti.com> >> --- >> >> NOTE: Currently ARM dma-mapping code doesn't account for devices >> bus_dma_limit. This is fixed in [1]. >> >> [1] https://lkml.org/lkml/2020/2/18/712 > > So is this dts patch safe to apply without the series above? > Yes. To my surprise this patch fixes the SATA issue even without [1]. Without this patch dev->bus_dma_limit was being set to 0 and with the patch it is being set to 0xffffffff. > And should this dts patch be applied as a fix or can it wait > until the merge window? I think we should mark it for stable and apply it right away as fix for v5.6. Cc: stable@kernel.org cheers, -roger > > Regards, > > Tony > >> arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++--------- >> 1 file changed, 16 insertions(+), 9 deletions(-) >> >> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi >> index d78b684e7fca..895462c22d1c 100644 >> --- a/arch/arm/boot/dts/dra7.dtsi >> +++ b/arch/arm/boot/dts/dra7.dtsi >> @@ -642,15 +642,22 @@ >> }; >> >> /* OCP2SCP3 */ >> - sata: sata@4a141100 { >> - compatible = "snps,dwc-ahci"; >> - reg = <0x4a140000 0x1100>, <0x4a141100 0x7>; >> - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; >> - phys = <&sata_phy>; >> - phy-names = "sata-phy"; >> - clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; >> - ti,hwmods = "sata"; >> - ports-implemented = <0x1>; >> + sata_aux_bus { >> + #address-cells = <1>; >> + #size-cells = <2>; >> + compatible = "simple-bus"; >> + ranges = <0x0 0x4a140000 0x0 0x1200>; >> + dma-ranges = <0x0 0x0 0x1 0x00000000>; >> + sata: sata@4a141100 { >> + compatible = "snps,dwc-ahci"; >> + reg = <0x0 0x0 0x1100>, <0x1100 0x0 0x7>; >> + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; >> + phys = <&sata_phy>; >> + phy-names = "sata-phy"; >> + clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; >> + ti,hwmods = "sata"; >> + ports-implemented = <0x1>; >> + }; >> }; >> >> /* OCP2SCP1 */ >> -- >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >>
On 05/03/2020 12:05 pm, Roger Quadros wrote: > Tony, Christoph, > > On 04/03/2020 18:20, Tony Lindgren wrote: >> * Roger Quadros <rogerq@ti.com> [200304 09:01]: >>> Even though the TRM says that SATA IP has 36 address bits >>> wired in the SoC, we see bus errors whenever any address >>> greater than 32-bit is given to the controller. >>> >>> This happens on dra7-EVM with 4G of RAM with CONFIG_ARM_LPAE=y. >>> >>> As a workaround we limit the DMA address range to 32-bits >>> for SATA. >>> >>> Cc: Christoph Hellwig <hch@lst.de> >>> Cc: Robin Murphy <robin.murphy@arm.com> >>> Cc: Rob Herring <robh+dt@kernel.org> >>> Reported-by: Yan Liu <yan-liu@ti.com> >>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>> --- >>> >>> NOTE: Currently ARM dma-mapping code doesn't account for devices >>> bus_dma_limit. This is fixed in [1]. >>> >>> [1] https://lkml.org/lkml/2020/2/18/712 >> >> So is this dts patch safe to apply without the series above? >> > > Yes. To my surprise this patch fixes the SATA issue even without [1]. > Without this patch dev->bus_dma_limit was being set to 0 and with the patch > it is being set to 0xffffffff. Right - LPAE configs should be getting dma-direct ops since 5.3, which already respect the limit. For non-LPAE configs it means you go from being broken from having no limit at all, to having a limit set but not respected, which is still equally broken, but no *more* so than before. Robin. >> And should this dts patch be applied as a fix or can it wait >> until the merge window? > > I think we should mark it for stable and apply it right away as fix for > v5.6. > > Cc: stable@kernel.org > > cheers, > -roger >> >> Regards, >> >> Tony >> >>> arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++--------- >>> 1 file changed, 16 insertions(+), 9 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi >>> index d78b684e7fca..895462c22d1c 100644 >>> --- a/arch/arm/boot/dts/dra7.dtsi >>> +++ b/arch/arm/boot/dts/dra7.dtsi >>> @@ -642,15 +642,22 @@ >>> }; >>> /* OCP2SCP3 */ >>> - sata: sata@4a141100 { >>> - compatible = "snps,dwc-ahci"; >>> - reg = <0x4a140000 0x1100>, <0x4a141100 0x7>; >>> - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; >>> - phys = <&sata_phy>; >>> - phy-names = "sata-phy"; >>> - clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; >>> - ti,hwmods = "sata"; >>> - ports-implemented = <0x1>; >>> + sata_aux_bus { >>> + #address-cells = <1>; >>> + #size-cells = <2>; >>> + compatible = "simple-bus"; >>> + ranges = <0x0 0x4a140000 0x0 0x1200>; >>> + dma-ranges = <0x0 0x0 0x1 0x00000000>; >>> + sata: sata@4a141100 { >>> + compatible = "snps,dwc-ahci"; >>> + reg = <0x0 0x0 0x1100>, <0x1100 0x0 0x7>; >>> + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; >>> + phys = <&sata_phy>; >>> + phy-names = "sata-phy"; >>> + clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; >>> + ti,hwmods = "sata"; >>> + ports-implemented = <0x1>; >>> + }; >>> }; >>> /* OCP2SCP1 */ >>> -- >>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >>> >
On Thu, Mar 05, 2020 at 12:30:56PM +0000, Robin Murphy wrote: > Right - LPAE configs should be getting dma-direct ops since 5.3, which > already respect the limit. For non-LPAE configs it means you go from being > broken from having no limit at all, to having a limit set but not > respected, which is still equally broken, but no *more* so than before. Actually, dma-direct doesn't automatically respect the bus limit. For various architectures including arm it uses the arch_dma_alloc callout, which for arm just uses the existing arm coherent allocator. Thay being said I'm still looking for reviewers for the arm dma coherent allocator bus limit fix..
On 04/03/2020 9:00 am, Roger Quadros wrote: > Even though the TRM says that SATA IP has 36 address bits > wired in the SoC, we see bus errors whenever any address > greater than 32-bit is given to the controller. Actually, is it really just SATA? I pulled up a couple of DRA7xx TRMs out of curiosity - thanks for having such easy-to-access documentation by the way :) - and they both give me a clear impression that the entire L3_MAIN interconnect is limited to 32-bit addresses and thus pretty much all the DMA masters should only be able to touch the lower 2GB of DRAM. Especially the bit that explicitly says "This is a high address range (Q8 – Q15) that requires an address greater than 32 bits. This space is visible only for the MPU Subsystem." Is it in fact the case that the SATA driver happens to be the only one to set a >32-bit DMA mask on your system? Robin. > This happens on dra7-EVM with 4G of RAM with CONFIG_ARM_LPAE=y. > > As a workaround we limit the DMA address range to 32-bits > for SATA. > > Cc: Christoph Hellwig <hch@lst.de> > Cc: Robin Murphy <robin.murphy@arm.com> > Cc: Rob Herring <robh+dt@kernel.org> > Reported-by: Yan Liu <yan-liu@ti.com> > Signed-off-by: Roger Quadros <rogerq@ti.com> > --- > > NOTE: Currently ARM dma-mapping code doesn't account for devices > bus_dma_limit. This is fixed in [1]. > > [1] https://lkml.org/lkml/2020/2/18/712 > > arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++--------- > 1 file changed, 16 insertions(+), 9 deletions(-) > > diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi > index d78b684e7fca..895462c22d1c 100644 > --- a/arch/arm/boot/dts/dra7.dtsi > +++ b/arch/arm/boot/dts/dra7.dtsi > @@ -642,15 +642,22 @@ > }; > > /* OCP2SCP3 */ > - sata: sata@4a141100 { > - compatible = "snps,dwc-ahci"; > - reg = <0x4a140000 0x1100>, <0x4a141100 0x7>; > - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; > - phys = <&sata_phy>; > - phy-names = "sata-phy"; > - clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; > - ti,hwmods = "sata"; > - ports-implemented = <0x1>; > + sata_aux_bus { > + #address-cells = <1>; > + #size-cells = <2>; > + compatible = "simple-bus"; > + ranges = <0x0 0x4a140000 0x0 0x1200>; > + dma-ranges = <0x0 0x0 0x1 0x00000000>; > + sata: sata@4a141100 { > + compatible = "snps,dwc-ahci"; > + reg = <0x0 0x0 0x1100>, <0x1100 0x0 0x7>; > + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; > + phys = <&sata_phy>; > + phy-names = "sata-phy"; > + clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; > + ti,hwmods = "sata"; > + ports-implemented = <0x1>; > + }; > }; > > /* OCP2SCP1 */ >
+Nishanth Robin, On 05/03/2020 18:04, Robin Murphy wrote: > On 04/03/2020 9:00 am, Roger Quadros wrote: >> Even though the TRM says that SATA IP has 36 address bits >> wired in the SoC, we see bus errors whenever any address >> greater than 32-bit is given to the controller. > > Actually, is it really just SATA? I pulled up a couple of DRA7xx TRMs out of curiosity - thanks for having such easy-to-access documentation by the way :) - and they both give me a clear impression that the entire L3_MAIN interconnect is limited to 32-bit addresses and thus pretty much all the DMA masters should only be able to touch the lower 2GB of DRAM. Especially the bit that explicitly says "This is a high address range (Q8 – Q15) that requires an address greater than 32 bits. This space is visible only for the MPU Subsystem." You are right that L3 interconnect can only access first 2GB of DRAM. Which means we should add the bus_dma_limit to the entire L3 bus instead of just SATA? > > Is it in fact the case that the SATA driver happens to be the only one to set a >32-bit DMA mask on your system? This looks like the case. Other device drivers might not be overriding dma_mask at all thus using the default 32-bit dma_mask. cheers, -roger > > Robin. > >> This happens on dra7-EVM with 4G of RAM with CONFIG_ARM_LPAE=y. >> >> As a workaround we limit the DMA address range to 32-bits >> for SATA. >> >> Cc: Christoph Hellwig <hch@lst.de> >> Cc: Robin Murphy <robin.murphy@arm.com> >> Cc: Rob Herring <robh+dt@kernel.org> >> Reported-by: Yan Liu <yan-liu@ti.com> >> Signed-off-by: Roger Quadros <rogerq@ti.com> >> --- >> >> NOTE: Currently ARM dma-mapping code doesn't account for devices >> bus_dma_limit. This is fixed in [1]. >> >> [1] https://lkml.org/lkml/2020/2/18/712 >> >> arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++--------- >> 1 file changed, 16 insertions(+), 9 deletions(-) >> >> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi >> index d78b684e7fca..895462c22d1c 100644 >> --- a/arch/arm/boot/dts/dra7.dtsi >> +++ b/arch/arm/boot/dts/dra7.dtsi >> @@ -642,15 +642,22 @@ >> }; >> /* OCP2SCP3 */ >> - sata: sata@4a141100 { >> - compatible = "snps,dwc-ahci"; >> - reg = <0x4a140000 0x1100>, <0x4a141100 0x7>; >> - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; >> - phys = <&sata_phy>; >> - phy-names = "sata-phy"; >> - clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; >> - ti,hwmods = "sata"; >> - ports-implemented = <0x1>; >> + sata_aux_bus { >> + #address-cells = <1>; >> + #size-cells = <2>; >> + compatible = "simple-bus"; >> + ranges = <0x0 0x4a140000 0x0 0x1200>; >> + dma-ranges = <0x0 0x0 0x1 0x00000000>; >> + sata: sata@4a141100 { >> + compatible = "snps,dwc-ahci"; >> + reg = <0x0 0x0 0x1100>, <0x1100 0x0 0x7>; >> + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; >> + phys = <&sata_phy>; >> + phy-names = "sata-phy"; >> + clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; >> + ti,hwmods = "sata"; >> + ports-implemented = <0x1>; >> + }; >> }; >> /* OCP2SCP1 */ >>
* Roger Quadros <rogerq@ti.com> [200305 16:47]: > +Nishanth > > Robin, > > On 05/03/2020 18:04, Robin Murphy wrote: > > On 04/03/2020 9:00 am, Roger Quadros wrote: > > > Even though the TRM says that SATA IP has 36 address bits > > > wired in the SoC, we see bus errors whenever any address > > > greater than 32-bit is given to the controller. > > > > Actually, is it really just SATA? I pulled up a couple of DRA7xx TRMs out of curiosity - thanks for having such easy-to-access documentation by the way :) - and they both give me a clear impression that the entire L3_MAIN interconnect is limited to 32-bit addresses and thus pretty much all the DMA masters should only be able to touch the lower 2GB of DRAM. Especially the bit that explicitly says "This is a high address range (Q8 – Q15) that requires an address greater than 32 bits. This space is visible only for the MPU Subsystem." > > You are right that L3 interconnect can only access first 2GB of DRAM. > Which means we should add the bus_dma_limit to the entire L3 bus > instead of just SATA? OK makes sense to me. > > Is it in fact the case that the SATA driver happens to be the only one to set a >32-bit DMA mask on your system? > > This looks like the case. Other device drivers might not be overriding > dma_mask at all thus using the default 32-bit dma_mask. OK Regards, Tony
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index d78b684e7fca..895462c22d1c 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -642,15 +642,22 @@ }; /* OCP2SCP3 */ - sata: sata@4a141100 { - compatible = "snps,dwc-ahci"; - reg = <0x4a140000 0x1100>, <0x4a141100 0x7>; - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; - phys = <&sata_phy>; - phy-names = "sata-phy"; - clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; - ti,hwmods = "sata"; - ports-implemented = <0x1>; + sata_aux_bus { + #address-cells = <1>; + #size-cells = <2>; + compatible = "simple-bus"; + ranges = <0x0 0x4a140000 0x0 0x1200>; + dma-ranges = <0x0 0x0 0x1 0x00000000>; + sata: sata@4a141100 { + compatible = "snps,dwc-ahci"; + reg = <0x0 0x0 0x1100>, <0x1100 0x0 0x7>; + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; + phys = <&sata_phy>; + phy-names = "sata-phy"; + clocks = <&l3init_clkctrl DRA7_L3INIT_SATA_CLKCTRL 8>; + ti,hwmods = "sata"; + ports-implemented = <0x1>; + }; }; /* OCP2SCP1 */
Even though the TRM says that SATA IP has 36 address bits wired in the SoC, we see bus errors whenever any address greater than 32-bit is given to the controller. This happens on dra7-EVM with 4G of RAM with CONFIG_ARM_LPAE=y. As a workaround we limit the DMA address range to 32-bits for SATA. Cc: Christoph Hellwig <hch@lst.de> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Rob Herring <robh+dt@kernel.org> Reported-by: Yan Liu <yan-liu@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> --- NOTE: Currently ARM dma-mapping code doesn't account for devices bus_dma_limit. This is fixed in [1]. [1] https://lkml.org/lkml/2020/2/18/712 arch/arm/boot/dts/dra7.dtsi | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-)