From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>, Florian Fainelli <f.fainelli@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>, 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 1/2] arm64: dts: broadcom: remove an unused property dma-ranges
Date: Wed, 14 Oct 2020 21:36:03 +0800 [thread overview]
Message-ID: <b25dd804-c691-b987-9f6a-de043aa45755@huawei.com> (raw)
In-Reply-To: <CAK8P3a3MtCDpbCgNEnLf1QcE+1O0oGZtob2KY7G-77oA95bLJQ@mail.gmail.com>
On 2020/10/14 15:38, Arnd Bergmann wrote:
> On Wed, Oct 14, 2020 at 5:15 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 10/12/2020 11:06 PM, Zhen Lei wrote:
>>> stingray-usb.dtsi is finally included by three dts files:
>>> bcm958802a802x.dts, bcm958742k.dts and bcm958742t.dts. I searched all
>>> these three entire expanded dts files, and each of them contains only one
>>> dma-ranges. No conversion range is specified, so it cannot work properly.
>>> I think this property "dma-ranges" is added by mistake, just remove it.
>>> Otherwise, the following error will be reported when any YAML detection
>>> is performed on arm64.
>>>
>>> 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)
>>>
>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>
>> This looks fine to me, Scott, Ray do you want to Ack this patch before I
>> take it?
>
> Does it mean that there are no devices on this bus that can do DMA?
>
> Usually there should be a dma-ranges property to identify that DMA
> is possible and what the limits are, though we have failed to enforce
> that.
Documentation/devicetree/bindings/iommu/iommu.txt +79
When an "iommus" property is specified in a device tree node, the IOMMU will
be used for address translation. If a "dma-ranges" property exists in the
device's parent node it will be ignored. An exception to this rule is if the
referenced IOMMU is disabled, in which case the "dma-ranges" property of the
parent shall take effect.
The dma-ranges is only required by IOMMU disabled case. And should exist in
the parent node of IOMMU device. But this deleted dma-ranges is under the usb
bus node.
>
> 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.
The dma_alloc_coherent() will allocate memory with GFP_DMA32 flag and
try the 0-4G first. The reserved swiotlb buffer memory is used only
when the allocation failed.
memory@80000000:
device_type: ["memory"]
reg: [[0x0, 0x80000000, 0x0, 0x80000000], [0x8, 0x80000000, 0x1, 0x80000000]]
If this is the actual physical memory size, the #address-cells should be set to <1>.
>
> Arnd
>
> .
>
next prev parent reply other threads:[~2020-10-14 13:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 6:06 [PATCH 0/2] eliminate two common errors reported by any yaml on arm64 Zhen Lei
2020-10-13 6:06 ` [PATCH 1/2] arm64: dts: broadcom: remove an unused property dma-ranges Zhen Lei
2020-10-14 3:12 ` Florian Fainelli
2020-10-14 7:38 ` Arnd Bergmann
2020-10-14 13:36 ` Leizhen (ThunderTown) [this message]
2020-10-14 13:43 ` Leizhen (ThunderTown)
2020-10-14 14:02 ` Arnd Bergmann
2020-10-16 7:06 ` Leizhen (ThunderTown)
2020-10-16 7:53 ` Leizhen (ThunderTown)
2020-10-13 6:06 ` [PATCH 2/2] arm64: dts: qcom: " Zhen Lei
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=b25dd804-c691-b987-9f6a-de043aa45755@huawei.com \
--to=thunder.leizhen@huawei.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=f.fainelli@gmail.com \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).