| Message ID | 20190907161634.27378-1-marek.vasut@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| 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 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",