| 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 |
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
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.
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
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 ?
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
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
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
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.
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
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.
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
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
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 ?
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.
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/
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 --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",