From: Sudeep Holla <sudeep.holla@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: devicetree@vger.kernel.org,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: dts: juno: Fix DMA address translations by adding SOC bus node
Date: Thu, 28 Nov 2019 14:15:21 +0000 [thread overview]
Message-ID: <20191128141521.GA3333@bogus> (raw)
In-Reply-To: <d9b057ed-acfc-a9a1-a466-d3048f008568@arm.com>
On Thu, Nov 28, 2019 at 11:50:54AM +0000, Robin Murphy wrote:
> Hi Sudeep,
>
> On 2019-11-26 4:53 pm, Sudeep Holla wrote:
> > Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes")
> > reworked the logic such that of_dma_get_range() works correctly
> > starting from a bus node containing "dma-ranges".
> >
> > Since on Juno we don't have a SoC level bus node and "dma-ranges" is
> > present only in the root node, we get the following error:
> >
> > OF: translation of DMA address(0) to CPU address failed node(/sram@2e000000)
> > OF: translation of DMA address(0) to CPU address failed node(/uart@7ff80000)
> > ...
> > OF: translation of DMA address(0) to CPU address failed node(/mhu@2b1f0000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> >
> > Let's fix it by adding a SoC bus node and moving all the devices along
> > with the "dma-ranges" inside it.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Liviu Dudau <liviu.dudau@arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > arch/arm64/boot/dts/arm/juno-base.dtsi | 162 +++++++++---------
> > arch/arm64/boot/dts/arm/juno-clocks.dtsi | 2 +
> > arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 2 +
> > arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 2 +
> > 4 files changed, 88 insertions(+), 80 deletions(-)
> >
> > Hi Rob, Robin,
> >
> > Let me know if this is correct fix for the issue I am seeing with linux-next
> > on Juno. This patch is generated with -b for ease of review. With lots of
> > indentation, actual delta is:
> >
> > 4 files changed, 1274 insertions(+), 1266 deletions(-)
>
> Other than a few nits - the GIC should probably be under the soc node as
> it's an MMIO device, while the clocks shouldn't; the dtsi's could probably
> avoid churn with a "&soc {...}" phandle - I think this is a reasonable thing
> to do, as it's generally the preferred structure.
>
I agree and am still in confusion as what to put inside soc or not.
> The cruder but far simpler alternative would be to just drop the dma-ranges
> property - I'm not sure the effort to make all 64-bit platforms describe
> their dma-ranges has really panned out, and it isn't actually necessary for
> Juno (which is why it didn't seem like sufficient reason to do all this
> restructuring at the time, and instead I took a very liberal interpretation
> of the spec to sneak it into the root node).
>
I think I prefer that for v5.5 as a fix as this is much bigger churn. We
can do that for v5.6 if required. Let me know if you disagree. I can simply
revert your original patch adding dma-ranges for now and we can add it
later with all the soc structure.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Rob Herring <robh+dt@kernel.org>,
Liviu Dudau <liviu.dudau@arm.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH] arm64: dts: juno: Fix DMA address translations by adding SOC bus node
Date: Thu, 28 Nov 2019 14:15:21 +0000 [thread overview]
Message-ID: <20191128141521.GA3333@bogus> (raw)
In-Reply-To: <d9b057ed-acfc-a9a1-a466-d3048f008568@arm.com>
On Thu, Nov 28, 2019 at 11:50:54AM +0000, Robin Murphy wrote:
> Hi Sudeep,
>
> On 2019-11-26 4:53 pm, Sudeep Holla wrote:
> > Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes")
> > reworked the logic such that of_dma_get_range() works correctly
> > starting from a bus node containing "dma-ranges".
> >
> > Since on Juno we don't have a SoC level bus node and "dma-ranges" is
> > present only in the root node, we get the following error:
> >
> > OF: translation of DMA address(0) to CPU address failed node(/sram@2e000000)
> > OF: translation of DMA address(0) to CPU address failed node(/uart@7ff80000)
> > ...
> > OF: translation of DMA address(0) to CPU address failed node(/mhu@2b1f0000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> >
> > Let's fix it by adding a SoC bus node and moving all the devices along
> > with the "dma-ranges" inside it.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Liviu Dudau <liviu.dudau@arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > arch/arm64/boot/dts/arm/juno-base.dtsi | 162 +++++++++---------
> > arch/arm64/boot/dts/arm/juno-clocks.dtsi | 2 +
> > arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 2 +
> > arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 2 +
> > 4 files changed, 88 insertions(+), 80 deletions(-)
> >
> > Hi Rob, Robin,
> >
> > Let me know if this is correct fix for the issue I am seeing with linux-next
> > on Juno. This patch is generated with -b for ease of review. With lots of
> > indentation, actual delta is:
> >
> > 4 files changed, 1274 insertions(+), 1266 deletions(-)
>
> Other than a few nits - the GIC should probably be under the soc node as
> it's an MMIO device, while the clocks shouldn't; the dtsi's could probably
> avoid churn with a "&soc {...}" phandle - I think this is a reasonable thing
> to do, as it's generally the preferred structure.
>
I agree and am still in confusion as what to put inside soc or not.
> The cruder but far simpler alternative would be to just drop the dma-ranges
> property - I'm not sure the effort to make all 64-bit platforms describe
> their dma-ranges has really panned out, and it isn't actually necessary for
> Juno (which is why it didn't seem like sufficient reason to do all this
> restructuring at the time, and instead I took a very liberal interpretation
> of the spec to sneak it into the root node).
>
I think I prefer that for v5.5 as a fix as this is much bigger churn. We
can do that for v5.6 if required. Let me know if you disagree. I can simply
revert your original patch adding dma-ranges for now and we can add it
later with all the soc structure.
--
Regards,
Sudeep
next prev parent reply other threads:[~2019-11-28 14:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 16:53 [PATCH] arm64: dts: juno: Fix DMA address translations by adding SOC bus node Sudeep Holla
2019-11-26 16:53 ` Sudeep Holla
2019-11-28 11:50 ` Robin Murphy
2019-11-28 11:50 ` Robin Murphy
2019-11-28 14:15 ` Sudeep Holla [this message]
2019-11-28 14:15 ` Sudeep Holla
2019-11-28 16:15 ` Robin Murphy
2019-11-28 16:15 ` Robin Murphy
2019-11-28 16:38 ` Sudeep Holla
2019-11-28 16:38 ` Sudeep Holla
2019-11-28 15:42 ` [PATCH] Revert "arm64: dts: juno: add dma-ranges property" Sudeep Holla
2019-11-28 15:42 ` Sudeep Holla
2019-11-28 15:58 ` Robin Murphy
2019-11-28 15:58 ` Robin Murphy
2019-11-28 16:40 ` Sudeep Holla
2019-11-28 16:40 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191128141521.GA3333@bogus \
--to=sudeep.holla@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.