diff mbox series

arm64: dts: renesas: Add /soc dma-ranges

Message ID 20190907161634.27378-1-marek.vasut@gmail.com (mailing list archive)
State Under Review
Delegated to: Geert Uytterhoeven
Headers show
Series arm64: dts: renesas: Add /soc dma-ranges | expand

Commit Message

Marek Vasut Sept. 7, 2019, 4:16 p.m. UTC
From: Marek Vasut <marek.vasut+renesas@gmail.com>

Add dma-ranges property into /soc node to describe the DMA capabilities
of the bus. This is currently needed to translate PCI DMA ranges, which
are limited to 32bit addresses.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: devicetree@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
To: linux-arm-kernel@lists.infradead.org
---
NOTE: This is needed for the following patches to work correctly:
      https://patchwork.ozlabs.org/patch/1144870/
      https://patchwork.ozlabs.org/patch/1144871/
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 1 +
 arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 1 +
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
 3 files changed, 3 insertions(+)

Comments

Geert Uytterhoeven Sept. 9, 2019, 8:19 a.m. UTC | #1
Hi Marek,

On Sat, Sep 7, 2019 at 6:16 PM <marek.vasut@gmail.com> wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Add dma-ranges property into /soc node to describe the DMA capabilities
> of the bus. This is currently needed to translate PCI DMA ranges, which
> are limited to 32bit addresses.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Thanks for your patch!

> NOTE: This is needed for the following patches to work correctly:
>       https://patchwork.ozlabs.org/patch/1144870/
>       https://patchwork.ozlabs.org/patch/1144871/

What happens with the above patches applied, and without this one?

As PCI/OF driver patches go in through different trees, is it safe to apply
this patch now?
Should they go in together?

>  arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 1 +
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 1 +
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +

Do we need similar patches for the other R-Car Gen3 and RZ/G2 DTS files?
What about R-Car Gen2 and RZ/G1?

Thanks!

Gr{oetje,eeting}s,

                        Geert
Marek Vasut Sept. 9, 2019, 8:42 a.m. UTC | #2
On 9/9/19 10:19 AM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

> On Sat, Sep 7, 2019 at 6:16 PM <marek.vasut@gmail.com> wrote:
>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>
>> Add dma-ranges property into /soc node to describe the DMA capabilities
>> of the bus. This is currently needed to translate PCI DMA ranges, which
>> are limited to 32bit addresses.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> 
> Thanks for your patch!
> 
>> NOTE: This is needed for the following patches to work correctly:
>>       https://patchwork.ozlabs.org/patch/1144870/
>>       https://patchwork.ozlabs.org/patch/1144871/
> 
> What happens with the above patches applied, and without this one?

It triggers https://patchwork.kernel.org/patch/11087391/#22811745

> As PCI/OF driver patches go in through different trees, is it safe to apply
> this patch now?
> Should they go in together?

I didn't get any feedback on the other two patches, but this one here is
safe to go in either way.

>>  arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 1 +
>>  arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 1 +
>>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
> 
> Do we need similar patches for the other R-Car Gen3 and RZ/G2 DTS files?
> What about R-Car Gen2 and RZ/G1?
I suspect we need such patches for any ARM64 machine with PCIe with this
32bit limitation.
Geert Uytterhoeven Sept. 9, 2019, 9:05 a.m. UTC | #3
Hi Marek,

On Mon, Sep 9, 2019 at 10:42 AM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 9/9/19 10:19 AM, Geert Uytterhoeven wrote:
> > On Sat, Sep 7, 2019 at 6:16 PM <marek.vasut@gmail.com> wrote:
> >> From: Marek Vasut <marek.vasut+renesas@gmail.com>
> >>
> >> Add dma-ranges property into /soc node to describe the DMA capabilities
> >> of the bus. This is currently needed to translate PCI DMA ranges, which
> >> are limited to 32bit addresses.
> >>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >
> > Thanks for your patch!
> >
> >> NOTE: This is needed for the following patches to work correctly:
> >>       https://patchwork.ozlabs.org/patch/1144870/
> >>       https://patchwork.ozlabs.org/patch/1144871/
> >
> > What happens with the above patches applied, and without this one?
>
> It triggers https://patchwork.kernel.org/patch/11087391/#22811745

Sure. But what does that mean?
PCI devices just not working?
Random memory corruption?
System lockup?
Anything else?

> > As PCI/OF driver patches go in through different trees, is it safe to apply
> > this patch now?
> > Should they go in together?
>
> I didn't get any feedback on the other two patches, but this one here is
> safe to go in either way.
>
> >>  arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 1 +
> >>  arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 1 +
> >>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
> >
> > Do we need similar patches for the other R-Car Gen3 and RZ/G2 DTS files?
> > What about R-Car Gen2 and RZ/G1?
> I suspect we need such patches for any ARM64 machine with PCIe with this
> 32bit limitation.

What about R-Car Gen2 and RZ/G1, which are ARM32, with LPAE?

Thanks!

Gr{oetje,eeting}s,

                        Geert
Marek Vasut Sept. 9, 2019, 9:12 a.m. UTC | #4
On 9/9/19 11:05 AM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

> On Mon, Sep 9, 2019 at 10:42 AM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 9/9/19 10:19 AM, Geert Uytterhoeven wrote:
>>> On Sat, Sep 7, 2019 at 6:16 PM <marek.vasut@gmail.com> wrote:
>>>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>
>>>> Add dma-ranges property into /soc node to describe the DMA capabilities
>>>> of the bus. This is currently needed to translate PCI DMA ranges, which
>>>> are limited to 32bit addresses.
>>>>
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>
>>> Thanks for your patch!
>>>
>>>> NOTE: This is needed for the following patches to work correctly:
>>>>       https://patchwork.ozlabs.org/patch/1144870/
>>>>       https://patchwork.ozlabs.org/patch/1144871/
>>>
>>> What happens with the above patches applied, and without this one?
>>
>> It triggers https://patchwork.kernel.org/patch/11087391/#22811745
> 
> Sure. But what does that mean?
> PCI devices just not working?
> Random memory corruption?
> System lockup?
> Anything else?

Instead of translating the PCI DMA range to 0x40000000-0xffffffff , the
PCI code in the aforementioned patches defaults to maximum range, which
prevents various devices from working correctly, as the buffers get
allocated above the 32bit boundary.

>>> As PCI/OF driver patches go in through different trees, is it safe to apply
>>> this patch now?
>>> Should they go in together?
>>
>> I didn't get any feedback on the other two patches, but this one here is
>> safe to go in either way.
>>
>>>>  arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 1 +
>>>>  arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 1 +
>>>>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
>>>
>>> Do we need similar patches for the other R-Car Gen3 and RZ/G2 DTS files?
>>> What about R-Car Gen2 and RZ/G1?
>> I suspect we need such patches for any ARM64 machine with PCIe with this
>> 32bit limitation.
> 
> What about R-Car Gen2 and RZ/G1, which are ARM32, with LPAE?

Presumably we need that too ?
Geert Uytterhoeven Sept. 9, 2019, 11:18 a.m. UTC | #5
Hi Marek,

On Sat, Sep 7, 2019 at 6:16 PM <marek.vasut@gmail.com> wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Add dma-ranges property into /soc node to describe the DMA capabilities
> of the bus. This is currently needed to translate PCI DMA ranges, which
> are limited to 32bit addresses.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -330,6 +330,7 @@
>                 #address-cells = <2>;
>                 #size-cells = <2>;
>                 ranges;
> +               dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;

Shouldn't the length be 0x80000000 (for all SoCs)?
Or should we allow DMA to internal System RAM, too?

Gr{oetje,eeting}s,

                        Geert
Rob Herring (Arm) Sept. 13, 2019, 3:14 p.m. UTC | #6
On Sat, Sep 7, 2019 at 5:16 PM <marek.vasut@gmail.com> wrote:
>
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Add dma-ranges property into /soc node to describe the DMA capabilities
> of the bus. This is currently needed to translate PCI DMA ranges, which
> are limited to 32bit addresses.

FYI, I've started working on this problem and issues around
dma-ranges/dma_mask. Hopefully I'll get some patches out next week.

> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: devicetree@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-arm-kernel@lists.infradead.org
> ---
> NOTE: This is needed for the following patches to work correctly:
>       https://patchwork.ozlabs.org/patch/1144870/
>       https://patchwork.ozlabs.org/patch/1144871/

First I'm seeing those... Well, I do have v7 from 2+ years ago...

Not sure if these take into account the new dma_bus_mask, but that
should simplify solving the issue.

> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 1 +
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 1 +
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 95deff66eeb6..2102140a6723 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -330,6 +330,7 @@
>                 #address-cells = <2>;
>                 #size-cells = <2>;
>                 ranges;
> +               dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;

Is the limitation in the bus or the PCI bridge or both? The commit
message sounds like it's the PCI bridge in which case this is wrong
(or incomplete). 'dma-ranges' should be on the bus node where the
restriction/translation exists. For PCI devices, that's the PCI bridge
node. So a 32-bit only PCI bridge should have a dma-ranges size of
4GB. If the SoC bus has more restrictions, then that should be in the
PCI bridge parent assuming that restriction also applies to other
devices.

Rob
Marek Vasut Sept. 14, 2019, 3:50 p.m. UTC | #7
On 9/13/19 5:14 PM, Rob Herring wrote:
> On Sat, Sep 7, 2019 at 5:16 PM <marek.vasut@gmail.com> wrote:
>>
>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>
>> Add dma-ranges property into /soc node to describe the DMA capabilities
>> of the bus. This is currently needed to translate PCI DMA ranges, which
>> are limited to 32bit addresses.
> 
> FYI, I've started working on this problem and issues around
> dma-ranges/dma_mask. Hopefully I'll get some patches out next week.

Thanks

>> ---
>> NOTE: This is needed for the following patches to work correctly:
>>       https://patchwork.ozlabs.org/patch/1144870/
>>       https://patchwork.ozlabs.org/patch/1144871/
> 
> First I'm seeing those... Well, I do have v7 from 2+ years ago...

Right, this issue was dragging on for a very long time.

> Not sure if these take into account the new dma_bus_mask, but that
> should simplify solving the issue.

What's that about ?

>> ---
>>  arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 1 +
>>  arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 1 +
>>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
>>  3 files changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> index 95deff66eeb6..2102140a6723 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -330,6 +330,7 @@
>>                 #address-cells = <2>;
>>                 #size-cells = <2>;
>>                 ranges;
>> +               dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
> 
> Is the limitation in the bus or the PCI bridge or both? The commit
> message sounds like it's the PCI bridge in which case this is wrong
> (or incomplete).

I believe it is the PCI bridge too.

> 'dma-ranges' should be on the bus node where the
> restriction/translation exists. For PCI devices, that's the PCI bridge
> node. So a 32-bit only PCI bridge should have a dma-ranges size of
> 4GB. If the SoC bus has more restrictions, then that should be in the
> PCI bridge parent assuming that restriction also applies to other
> devices.

Would that mean the dma-ranges for /soc/pcie@fe000000/ [1], which is
already present in the DTSi, is the one that should be used to determine
the controller limitations ?

[1]
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm64/boot/dts/renesas/r8a7795.dtsi#L2653
Marek Vasut Sept. 14, 2019, 3:53 p.m. UTC | #8
On 9/9/19 1:18 PM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

> On Sat, Sep 7, 2019 at 6:16 PM Marek Vasut wrote:
>>
>> Add dma-ranges property into /soc node to describe the DMA capabilities
>> of the bus. This is currently needed to translate PCI DMA ranges, which
>> are limited to 32bit addresses.
> 
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -330,6 +330,7 @@
>>                 #address-cells = <2>;
>>                 #size-cells = <2>;
>>                 ranges;
>> +               dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
> 
> Shouldn't the length be 0x80000000 (for all SoCs)?

Or should that match the amount of DRAM below 32bit boundary ?

> Or should we allow DMA to internal System RAM, too?

I think we should include SRAM, yes.
Geert Uytterhoeven Sept. 14, 2019, 4:33 p.m. UTC | #9
Hi Marek,

On Sat, Sep 14, 2019 at 6:06 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 9/9/19 1:18 PM, Geert Uytterhoeven wrote:
> > On Sat, Sep 7, 2019 at 6:16 PM Marek Vasut wrote:
> >> Add dma-ranges property into /soc node to describe the DMA capabilities
> >> of the bus. This is currently needed to translate PCI DMA ranges, which
> >> are limited to 32bit addresses.
> >
> >> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >> @@ -330,6 +330,7 @@
> >>                 #address-cells = <2>;
> >>                 #size-cells = <2>;
> >>                 ranges;
> >> +               dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
> >
> > Shouldn't the length be 0x80000000 (for all SoCs)?
>
> Or should that match the amount of DRAM below 32bit boundary ?

Which is 0x80000000, according to the memory area section for the
various R-Car Gen3 SoCs.

> > Or should we allow DMA to internal System RAM, too?
>
> I think we should include SRAM, yes.

So that needs a separate range.

Gr{oetje,eeting}s,

                        Geert
Marek Vasut Sept. 14, 2019, 4:45 p.m. UTC | #10
On 9/14/19 6:33 PM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

> On Sat, Sep 14, 2019 at 6:06 PM Marek Vasut wrote:
>> On 9/9/19 1:18 PM, Geert Uytterhoeven wrote:
>>> On Sat, Sep 7, 2019 at 6:16 PM Marek Vasut wrote:
>>>> Add dma-ranges property into /soc node to describe the DMA capabilities
>>>> of the bus. This is currently needed to translate PCI DMA ranges, which
>>>> are limited to 32bit addresses.
>>>
>>>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> @@ -330,6 +330,7 @@
>>>>                 #address-cells = <2>;
>>>>                 #size-cells = <2>;
>>>>                 ranges;
>>>> +               dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
>>>
>>> Shouldn't the length be 0x80000000 (for all SoCs)?
>>
>> Or should that match the amount of DRAM below 32bit boundary ?
> 
> Which is 0x80000000, according to the memory area section for the
> various R-Car Gen3 SoCs.

What if you have a system with 1 GiB of DRAM ?

>>> Or should we allow DMA to internal System RAM, too?
>>
>> I think we should include SRAM, yes.
> 
> So that needs a separate range.

Let's see how the discussion pans out about the placement of the
dma-ranges in the first place.
Geert Uytterhoeven Sept. 15, 2019, 1:11 p.m. UTC | #11
Hi Marek,

On Sat, Sep 14, 2019 at 6:45 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 9/14/19 6:33 PM, Geert Uytterhoeven wrote:
> > On Sat, Sep 14, 2019 at 6:06 PM Marek Vasut wrote:
> >> On 9/9/19 1:18 PM, Geert Uytterhoeven wrote:
> >>> On Sat, Sep 7, 2019 at 6:16 PM Marek Vasut wrote:
> >>>> Add dma-ranges property into /soc node to describe the DMA capabilities
> >>>> of the bus. This is currently needed to translate PCI DMA ranges, which
> >>>> are limited to 32bit addresses.
> >>>
> >>>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >>>> @@ -330,6 +330,7 @@
> >>>>                 #address-cells = <2>;
> >>>>                 #size-cells = <2>;
> >>>>                 ranges;
> >>>> +               dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
> >>>
> >>> Shouldn't the length be 0x80000000 (for all SoCs)?
> >>
> >> Or should that match the amount of DRAM below 32bit boundary ?
> >
> > Which is 0x80000000, according to the memory area section for the
> > various R-Car Gen3 SoCs.
>
> What if you have a system with 1 GiB of DRAM ?

Should be covered by 0x80000000, no?
Linux will never ask a PCI device to do bus mastering to an area not
backed by populated memory, will it?

However, you ask a good question: does this property specify the limits
of the bridge, or the limits of the bridge combined with the actual
populated or available memory?

In the former case, offset and length should be "0 0x0" resp. "1 0x00000000".
In the latter case, it depends on the actual board (SiP is board, too)
configuration.
Which means U-Boot may need to update this ("AND" mask the value we
specify here?), based on what it writes into the memory node?

> >>> Or should we allow DMA to internal System RAM, too?
> >>
> >> I think we should include SRAM, yes.
> >
> > So that needs a separate range.
>
> Let's see how the discussion pans out about the placement of the
> dma-ranges in the first place.

Yep.

Gr{oetje,eeting}s,

                        Geert
Rob Herring (Arm) Sept. 23, 2019, 10:33 p.m. UTC | #12
On Fri, Sep 13, 2019 at 10:14 AM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Sep 7, 2019 at 5:16 PM <marek.vasut@gmail.com> wrote:
> >
> > From: Marek Vasut <marek.vasut+renesas@gmail.com>
> >
> > Add dma-ranges property into /soc node to describe the DMA capabilities
> > of the bus. This is currently needed to translate PCI DMA ranges, which
> > are limited to 32bit addresses.
>
> FYI, I've started working on this problem and issues around
> dma-ranges/dma_mask. Hopefully I'll get some patches out next week.

I've pushed out a branch here:

git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dma-masks

Can you test it on Renesas. I don't have a real platform having the issue.

Rob
Marek Vasut Sept. 26, 2019, 8:02 p.m. UTC | #13
On 9/24/19 12:33 AM, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 10:14 AM Rob Herring <robh@kernel.org> wrote:
>>
>> On Sat, Sep 7, 2019 at 5:16 PM <marek.vasut@gmail.com> wrote:
>>>
>>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>
>>> Add dma-ranges property into /soc node to describe the DMA capabilities
>>> of the bus. This is currently needed to translate PCI DMA ranges, which
>>> are limited to 32bit addresses.
>>
>> FYI, I've started working on this problem and issues around
>> dma-ranges/dma_mask. Hopefully I'll get some patches out next week.
> 
> I've pushed out a branch here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dma-masks
> 
> Can you test it on Renesas. I don't have a real platform having the issue.

Due to ER/KR, I can only test it Monday-ish. I hope that's OK ?
Marek Vasut Sept. 30, 2019, 12:42 p.m. UTC | #14
On 9/24/19 12:33 AM, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 10:14 AM Rob Herring wrote:
>>
>> On Sat, Sep 7, 2019 at 5:16 PM wrote:
>>>
>>> From: Marek Vasut
>>>
>>> Add dma-ranges property into /soc node to describe the DMA capabilities
>>> of the bus. This is currently needed to translate PCI DMA ranges, which
>>> are limited to 32bit addresses.
>>
>> FYI, I've started working on this problem and issues around
>> dma-ranges/dma_mask. Hopefully I'll get some patches out next week.
> 
> I've pushed out a branch here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dma-masks
> 
> Can you test it on Renesas. I don't have a real platform having the issue.


With the following patches applied:
      https://patchwork.ozlabs.org/patch/1144870/
      https://patchwork.ozlabs.org/patch/1144871/
on R8A7795 Salvator-XS, works fine.
Rob Herring (Arm) Sept. 30, 2019, 3:08 p.m. UTC | #15
On Mon, Sep 30, 2019 at 7:45 AM Marek Vasut <marek.vasut@gmail.com> wrote:
>
> On 9/24/19 12:33 AM, Rob Herring wrote:
> > On Fri, Sep 13, 2019 at 10:14 AM Rob Herring wrote:
> >>
> >> On Sat, Sep 7, 2019 at 5:16 PM wrote:
> >>>
> >>> From: Marek Vasut
> >>>
> >>> Add dma-ranges property into /soc node to describe the DMA capabilities
> >>> of the bus. This is currently needed to translate PCI DMA ranges, which
> >>> are limited to 32bit addresses.
> >>
> >> FYI, I've started working on this problem and issues around
> >> dma-ranges/dma_mask. Hopefully I'll get some patches out next week.
> >
> > I've pushed out a branch here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dma-masks
> >
> > Can you test it on Renesas. I don't have a real platform having the issue.
>
>
> With the following patches applied:
>       https://patchwork.ozlabs.org/patch/1144870/

I'd rather not have yet another instance of {dma-}ranges parsing code.
With this series[1], dma-ranges gets parsed into resource list for
you.

>       https://patchwork.ozlabs.org/patch/1144871/

How can this one be applied? It would conflict horribly. Plus I think
it duplicates what's in my series.

Rob

> on R8A7795 Salvator-XS, works fine.

[1] https://lore.kernel.org/linux-arm-kernel/20190924214630.12817-7-robh@kernel.org/T/
Marek Vasut Sept. 30, 2019, 3:38 p.m. UTC | #16
On 9/30/19 5:08 PM, Rob Herring wrote:
> On Mon, Sep 30, 2019 at 7:45 AM Marek Vasut wrote:
>>
>> On 9/24/19 12:33 AM, Rob Herring wrote:
>>> On Fri, Sep 13, 2019 at 10:14 AM Rob Herring wrote:
>>>>
>>>> On Sat, Sep 7, 2019 at 5:16 PM wrote:
>>>>>
>>>>> From: Marek Vasut
>>>>>
>>>>> Add dma-ranges property into /soc node to describe the DMA capabilities
>>>>> of the bus. This is currently needed to translate PCI DMA ranges, which
>>>>> are limited to 32bit addresses.
>>>>
>>>> FYI, I've started working on this problem and issues around
>>>> dma-ranges/dma_mask. Hopefully I'll get some patches out next week.
>>>
>>> I've pushed out a branch here:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dma-masks
>>>
>>> Can you test it on Renesas. I don't have a real platform having the issue.
>>
>>
>> With the following patches applied:
>>       https://patchwork.ozlabs.org/patch/1144870/
> 
> I'd rather not have yet another instance of {dma-}ranges parsing code.
> With this series[1], dma-ranges gets parsed into resource list for
> you.
> 
>>       https://patchwork.ozlabs.org/patch/1144871/
> 
> How can this one be applied? It would conflict horribly. Plus I think
> it duplicates what's in my series.

I fixed it up real quick, but apparently these are not needed indeed.

[...]
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 95deff66eeb6..2102140a6723 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -330,6 +330,7 @@ 
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
 
 		rwdt: watchdog@e6020000 {
 			compatible = "renesas,r8a7795-wdt", "renesas,rcar-gen3-wdt";
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 3dc9d73f589a..d115ff34d0db 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -300,6 +300,7 @@ 
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
 
 		rwdt: watchdog@e6020000 {
 			compatible = "renesas,r8a7796-wdt",
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 4ae163220f60..74d934cfe44e 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -183,6 +183,7 @@ 
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
 
 		rwdt: watchdog@e6020000 {
 			compatible = "renesas,r8a77965-wdt",