From: Florian Fainelli <f.fainelli@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>, Zhen Lei <thunder.leizhen@huawei.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Ray Jui <rjui@broadcom.com>,
Scott Branden <sbranden@broadcom.com>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
Date: Fri, 16 Oct 2020 09:48:15 -0700 [thread overview]
Message-ID: <e27dc152-7aef-10df-f391-bf56e13e23df@gmail.com> (raw)
In-Reply-To: <CAK8P3a2TSmsNSi-XFpT6AQ3jvVxJ1AW7Uf5tAo477wtwXZwUzg@mail.gmail.com>
On 10/16/20 4:01 AM, Arnd Bergmann wrote:
> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>
>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>> property must have the same "#address-cells" and "#size-cells" values as
>> the parent node. Otherwise, the following warnings is reported:
>>
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #address-cells (1) differs from / (2)
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #size-cells (1) differs from / (2)
>>
>> Arnd Bergmann figured out why it's necessary:
>> Also note that the #address-cells=<1> means that any device under
>> this bus is assumed to only support 32-bit addressing, and DMA will
>> have to go through a slow swiotlb in the absence of an IOMMU.
>>
>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> I see that at least the 'bcd' and 'xhci' devices in fact try to
> use 64-bit DMA. It would be good to test this on actual
> hardware to ensure that it works correctly when this is enabled.
>
> Ideally avoiding the swiotlb bounce buffering should only
> make it faster here, but there are many chips on which
> 64-bit DMA is broken in some form.
Is this change really an improvement though? This 'usb' pseudo bus node
could just keep being defined with #address-cells = <1> and #size-cells
= <1> so as to satisfy the 'reg' definition however we could just adjust
dma-ranges to indicate full 64-bit addressing capability. Would not that
work?
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>, Zhen Lei <thunder.leizhen@huawei.com>
Cc: devicetree <devicetree@vger.kernel.org>,
Florian Fainelli <f.fainelli@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Scott Branden <sbranden@broadcom.com>,
Ray Jui <rjui@broadcom.com>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
Date: Fri, 16 Oct 2020 09:48:15 -0700 [thread overview]
Message-ID: <e27dc152-7aef-10df-f391-bf56e13e23df@gmail.com> (raw)
In-Reply-To: <CAK8P3a2TSmsNSi-XFpT6AQ3jvVxJ1AW7Uf5tAo477wtwXZwUzg@mail.gmail.com>
On 10/16/20 4:01 AM, Arnd Bergmann wrote:
> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>
>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>> property must have the same "#address-cells" and "#size-cells" values as
>> the parent node. Otherwise, the following warnings is reported:
>>
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #address-cells (1) differs from / (2)
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #size-cells (1) differs from / (2)
>>
>> Arnd Bergmann figured out why it's necessary:
>> Also note that the #address-cells=<1> means that any device under
>> this bus is assumed to only support 32-bit addressing, and DMA will
>> have to go through a slow swiotlb in the absence of an IOMMU.
>>
>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> I see that at least the 'bcd' and 'xhci' devices in fact try to
> use 64-bit DMA. It would be good to test this on actual
> hardware to ensure that it works correctly when this is enabled.
>
> Ideally avoiding the swiotlb bounce buffering should only
> make it faster here, but there are many chips on which
> 64-bit DMA is broken in some form.
Is this change really an improvement though? This 'usb' pseudo bus node
could just keep being defined with #address-cells = <1> and #size-cells
= <1> so as to satisfy the 'reg' definition however we could just adjust
dma-ranges to indicate full 64-bit addressing capability. Would not that
work?
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-16 16:48 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 9:08 [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64 Zhen Lei
2020-10-16 9:08 ` Zhen Lei
2020-10-16 9:08 ` [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges Zhen Lei
2020-10-16 9:08 ` Zhen Lei
[not found] ` <CAK8P3a2TSmsNSi-XFpT6AQ3jvVxJ1AW7Uf5tAo477wtwXZwUzg@mail.gmail.com>
2020-10-16 16:48 ` Florian Fainelli [this message]
2020-10-16 16:48 ` Florian Fainelli
[not found] ` <CAK8P3a13ywHh7igdfDSPQz9Bw8YAnKWFLKARkk2NL5u6=6yb=w@mail.gmail.com>
2020-10-16 19:27 ` Florian Fainelli
2020-10-16 19:27 ` Florian Fainelli
2020-10-18 2:10 ` Leizhen (ThunderTown)
2020-10-18 2:10 ` Leizhen (ThunderTown)
2020-10-23 7:17 ` Arnd Bergmann
2020-10-26 2:21 ` Leizhen (ThunderTown)
2020-10-26 2:21 ` Leizhen (ThunderTown)
2020-11-09 6:18 ` Leizhen (ThunderTown)
2020-11-09 6:18 ` Leizhen (ThunderTown)
2020-11-09 17:28 ` Florian Fainelli
2020-11-09 17:28 ` Florian Fainelli
2020-11-09 17:56 ` Arnd Bergmann
2020-11-09 17:56 ` Arnd Bergmann
2020-11-09 18:00 ` Florian Fainelli
2020-11-09 18:00 ` Florian Fainelli
2020-11-28 4:53 ` Florian Fainelli
2020-11-28 4:53 ` Florian Fainelli
2020-11-28 9:58 ` Arnd Bergmann
2020-11-28 9:58 ` Arnd Bergmann
2020-12-14 19:09 ` Ray Jui
2020-12-14 19:09 ` Ray Jui
2020-12-14 19:46 ` Arnd Bergmann
2020-12-14 19:46 ` Arnd Bergmann
2020-12-15 15:40 ` Florian Fainelli
2020-12-15 15:40 ` Florian Fainelli
[not found] ` <CACvutz9v+TBUbrCo3X-u5ebbs04nR0y0yQN3qWfSAyZVy9RM2g@mail.gmail.com>
2020-12-15 15:41 ` Florian Fainelli
2020-12-15 15:41 ` Florian Fainelli
2020-12-15 15:49 ` Arnd Bergmann
2020-12-15 15:49 ` Arnd Bergmann
2021-01-12 18:28 ` Ray Jui
2021-01-12 18:28 ` Ray Jui
2021-01-12 20:40 ` Arnd Bergmann
2021-01-12 20:40 ` Arnd Bergmann
2021-01-12 20:57 ` Ray Jui
2021-01-12 20:57 ` Ray Jui
2021-01-13 3:42 ` Bharat Gooty
2021-01-13 3:42 ` Bharat Gooty
2021-01-13 8:05 ` Arnd Bergmann
2021-01-13 8:05 ` Arnd Bergmann
2021-01-13 16:55 ` Florian Fainelli
2021-01-13 16:55 ` Florian Fainelli
2021-01-13 17:45 ` Ray Jui
2021-01-13 17:45 ` Ray Jui
2020-10-16 9:08 ` [PATCH v2 2/2] arm64: dts: qcom: " Zhen Lei
2020-10-16 9:08 ` Zhen Lei
2020-11-11 4:44 ` Bjorn Andersson
2020-11-11 4:44 ` Bjorn Andersson
2020-12-29 20:15 ` [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64 patchwork-bot+linux-arm-msm
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=e27dc152-7aef-10df-f391-bf56e13e23df@gmail.com \
--to=f.fainelli@gmail.com \
--cc=agross@kernel.org \
--cc=arnd@arndb.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjui@broadcom.com \
--cc=robh+dt@kernel.org \
--cc=sbranden@broadcom.com \
--cc=thunder.leizhen@huawei.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.