linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
@ 2020-03-04  9:00 Roger Quadros
  2020-03-04 16:20 ` Tony Lindgren
  2020-03-05 16:04 ` Robin Murphy
  0 siblings, 2 replies; 8+ messages in thread
From: Roger Quadros @ 2020-03-04  9:00 UTC (permalink / raw)
  To: tony
  Cc: yan-liu, linux-omap, devicetree, linux-kernel, Roger Quadros,
	Christoph Hellwig, Robin Murphy, Rob Herring

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(-)

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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
  2020-03-04  9:00 [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled Roger Quadros
@ 2020-03-04 16:20 ` Tony Lindgren
  2020-03-05 12:05   ` Roger Quadros
  2020-03-05 16:04 ` Robin Murphy
  1 sibling, 1 reply; 8+ messages in thread
From: Tony Lindgren @ 2020-03-04 16:20 UTC (permalink / raw)
  To: Roger Quadros
  Cc: yan-liu, linux-omap, devicetree, linux-kernel, Christoph Hellwig,
	Robin Murphy, Rob Herring

* 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
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
  2020-03-04 16:20 ` Tony Lindgren
@ 2020-03-05 12:05   ` Roger Quadros
  2020-03-05 12:30     ` Robin Murphy
  0 siblings, 1 reply; 8+ messages in thread
From: Roger Quadros @ 2020-03-05 12:05 UTC (permalink / raw)
  To: Tony Lindgren, Christoph Hellwig
  Cc: yan-liu, linux-omap, devicetree, linux-kernel, Robin Murphy,
	Rob Herring, Nori, Sekhar

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
>>

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
  2020-03-05 12:05   ` Roger Quadros
@ 2020-03-05 12:30     ` Robin Murphy
  2020-03-05 15:16       ` Christoph Hellwig
  0 siblings, 1 reply; 8+ messages in thread
From: Robin Murphy @ 2020-03-05 12:30 UTC (permalink / raw)
  To: Roger Quadros, Tony Lindgren, Christoph Hellwig
  Cc: yan-liu, linux-omap, devicetree, linux-kernel, Rob Herring, Nori, Sekhar

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
>>>
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
  2020-03-05 12:30     ` Robin Murphy
@ 2020-03-05 15:16       ` Christoph Hellwig
  0 siblings, 0 replies; 8+ messages in thread
From: Christoph Hellwig @ 2020-03-05 15:16 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Roger Quadros, Tony Lindgren, Christoph Hellwig, yan-liu,
	linux-omap, devicetree, linux-kernel, Rob Herring, Nori, Sekhar

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..

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
  2020-03-04  9:00 [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled Roger Quadros
  2020-03-04 16:20 ` Tony Lindgren
@ 2020-03-05 16:04 ` Robin Murphy
  2020-03-05 16:46   ` Roger Quadros
  1 sibling, 1 reply; 8+ messages in thread
From: Robin Murphy @ 2020-03-05 16:04 UTC (permalink / raw)
  To: Roger Quadros, tony
  Cc: yan-liu, linux-omap, devicetree, linux-kernel, Christoph Hellwig,
	Rob Herring

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 */
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
  2020-03-05 16:04 ` Robin Murphy
@ 2020-03-05 16:46   ` Roger Quadros
  2020-03-06 15:08     ` Tony Lindgren
  0 siblings, 1 reply; 8+ messages in thread
From: Roger Quadros @ 2020-03-05 16:46 UTC (permalink / raw)
  To: Robin Murphy, tony, Nishanth Menon
  Cc: yan-liu, linux-omap, devicetree, linux-kernel, Christoph Hellwig,
	Rob Herring, Nori, Sekhar, Vignesh Raghavendra,
	Kishon Vijay Abraham I

+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 */
>>

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled
  2020-03-05 16:46   ` Roger Quadros
@ 2020-03-06 15:08     ` Tony Lindgren
  0 siblings, 0 replies; 8+ messages in thread
From: Tony Lindgren @ 2020-03-06 15:08 UTC (permalink / raw)
  To: Roger Quadros
  Cc: Robin Murphy, Nishanth Menon, yan-liu, linux-omap, devicetree,
	linux-kernel, Christoph Hellwig, Rob Herring, Nori, Sekhar,
	Vignesh Raghavendra, Kishon Vijay Abraham I

* 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-03-06 15:08 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-04  9:00 [PATCH] dra7: sata: Fix SATA with CONFIG_ARM_LPAE enabled Roger Quadros
2020-03-04 16:20 ` Tony Lindgren
2020-03-05 12:05   ` Roger Quadros
2020-03-05 12:30     ` Robin Murphy
2020-03-05 15:16       ` Christoph Hellwig
2020-03-05 16:04 ` Robin Murphy
2020-03-05 16:46   ` Roger Quadros
2020-03-06 15:08     ` Tony Lindgren

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).