From: Bharat Gooty <bharat.gooty@broadcom.com> To: Ray Jui <ray.jui@broadcom.com>, Arnd Bergmann <arnd@kernel.org> Cc: Florian Fainelli <f.fainelli@gmail.com>, devicetree <devicetree@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Scott Branden <sbranden@broadcom.com>, Ray Jui <rjui@broadcom.com>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, 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>, Zhen Lei <thunder.leizhen@huawei.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Bharat Gooty <bharat.gooty@broadcom.com> Subject: RE: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges Date: Wed, 13 Jan 2021 09:12:28 +0530 [thread overview] Message-ID: <3fc2b0174965ec6b911ab4bd73da1525@mail.gmail.com> (raw) In-Reply-To: <8aaa7bb9-a81e-cd0e-8e67-360515313748@broadcom.com> [-- Attachment #1: Type: text/plain, Size: 4505 bytes --] Hello Ray, I had cross checked with Design and integration team. Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working. Thanks, -Bharat -----Original Message----- From: Ray Jui <ray.jui@broadcom.com> Sent: Wednesday, January 13, 2021 2:28 AM To: Arnd Bergmann <arnd@kernel.org> Cc: Florian Fainelli <f.fainelli@gmail.com>; Bharat Gooty <bharat.gooty@broadcom.com>; devicetree <devicetree@vger.kernel.org>; linux-kernel <linux-kernel@vger.kernel.org>; Arnd Bergmann <arnd@arndb.de>; Scott Branden <sbranden@broadcom.com>; Ray Jui <rjui@broadcom.com>; linux-arm-msm <linux-arm-msm@vger.kernel.org>; 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>; Zhen Lei <thunder.leizhen@huawei.com>; 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 On 1/12/2021 12:40 PM, Arnd Bergmann wrote: > On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote: >> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote: >>> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> >>> wrote: >>>> >>>> On 12/15/2020 5:19 AM, Bharat Gooty wrote: >>>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can >>>>> not >>>>> give the complete DDR for the USB DMA. >>>>> So restricting the usable DAM size to 4GB. >>>> >>>> Thanks, can you make this a proper patch submission along with a Fixes: >>>> tag that is: >>>> >>>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused >>>> by >>>> empty dma-ranges") >>> >>> Yes, that would be helpful, though I would appreciate a better >>> description >>> that explains what is actually going on: is it the device or the bus >>> that >>> has the 32-bit limitation, and if it is indeed a bug in the device, why >>> do >>> you pretend that this is a 64-bit device on a 32-bit bus instead (this >>> could also use a comment in the dts file)? >>> >>> Arnd >>> >> >> Sorry for the delay in reply. Bharat finally got time to do some >> investigation to confirm the following: >> >> These USB controllers indeed can address 64-bit. However, on the bus >> internally, only 40-bits are connected to the interconnect of CCN. As a >> result, the 'dma-ranges' should be modified to address 40-bit in size. > > a 40-bit range is effectively the same as a 64-bit range though, so I > think you'll still need a driver quirk if the device cannot use the whole > 40 > bit addressing but is limited to 32 bits because of a bug in its dma > engine. > Bharat can correct me if I'm wrong, but I don't think we have a bug in the USB DMA engine that causes it can only address 32-bit. I believe we can set dma-ranges size to 40-bit here. The dma-range property is though required to be specified, instead of leaving it as empty, with the use of IOMMU. That seems to be a v5.10 specific behavior as I described below. Thanks, Ray >> We also have a somewhat related question, is it true that since v5.10, >> defining of 'dma-ranges' on the bus node where its child device node has >> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now >> mandatory? My understanding is that the 'dma-ranges' in this scheme will >> define the IOVA address to system address mapping required by all >> devices on that bus. Please help to confirm if my understanding is >> correct > > I have not actually seen that change. In general, you should always > have a dma-ranges property in the parent of a DMA master, I think > we just never enforced that and fall back to a 32-bit mask by default. > > Arnd > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4166 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Bharat Gooty <bharat.gooty@broadcom.com> To: Ray Jui <ray.jui@broadcom.com>, Arnd Bergmann <arnd@kernel.org> Cc: devicetree <devicetree@vger.kernel.org>, Florian Fainelli <f.fainelli@gmail.com>, Scott Branden <sbranden@broadcom.com>, Arnd Bergmann <arnd@arndb.de>, Ray Jui <rjui@broadcom.com>, Zhen Lei <thunder.leizhen@huawei.com>, linux-kernel <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Andy Gross <agross@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>, Bharat Gooty <bharat.gooty@broadcom.com> Subject: RE: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges Date: Wed, 13 Jan 2021 09:12:28 +0530 [thread overview] Message-ID: <3fc2b0174965ec6b911ab4bd73da1525@mail.gmail.com> (raw) In-Reply-To: <8aaa7bb9-a81e-cd0e-8e67-360515313748@broadcom.com> [-- Attachment #1.1: Type: text/plain, Size: 4505 bytes --] Hello Ray, I had cross checked with Design and integration team. Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working. Thanks, -Bharat -----Original Message----- From: Ray Jui <ray.jui@broadcom.com> Sent: Wednesday, January 13, 2021 2:28 AM To: Arnd Bergmann <arnd@kernel.org> Cc: Florian Fainelli <f.fainelli@gmail.com>; Bharat Gooty <bharat.gooty@broadcom.com>; devicetree <devicetree@vger.kernel.org>; linux-kernel <linux-kernel@vger.kernel.org>; Arnd Bergmann <arnd@arndb.de>; Scott Branden <sbranden@broadcom.com>; Ray Jui <rjui@broadcom.com>; linux-arm-msm <linux-arm-msm@vger.kernel.org>; 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>; Zhen Lei <thunder.leizhen@huawei.com>; 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 On 1/12/2021 12:40 PM, Arnd Bergmann wrote: > On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote: >> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote: >>> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> >>> wrote: >>>> >>>> On 12/15/2020 5:19 AM, Bharat Gooty wrote: >>>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can >>>>> not >>>>> give the complete DDR for the USB DMA. >>>>> So restricting the usable DAM size to 4GB. >>>> >>>> Thanks, can you make this a proper patch submission along with a Fixes: >>>> tag that is: >>>> >>>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused >>>> by >>>> empty dma-ranges") >>> >>> Yes, that would be helpful, though I would appreciate a better >>> description >>> that explains what is actually going on: is it the device or the bus >>> that >>> has the 32-bit limitation, and if it is indeed a bug in the device, why >>> do >>> you pretend that this is a 64-bit device on a 32-bit bus instead (this >>> could also use a comment in the dts file)? >>> >>> Arnd >>> >> >> Sorry for the delay in reply. Bharat finally got time to do some >> investigation to confirm the following: >> >> These USB controllers indeed can address 64-bit. However, on the bus >> internally, only 40-bits are connected to the interconnect of CCN. As a >> result, the 'dma-ranges' should be modified to address 40-bit in size. > > a 40-bit range is effectively the same as a 64-bit range though, so I > think you'll still need a driver quirk if the device cannot use the whole > 40 > bit addressing but is limited to 32 bits because of a bug in its dma > engine. > Bharat can correct me if I'm wrong, but I don't think we have a bug in the USB DMA engine that causes it can only address 32-bit. I believe we can set dma-ranges size to 40-bit here. The dma-range property is though required to be specified, instead of leaving it as empty, with the use of IOMMU. That seems to be a v5.10 specific behavior as I described below. Thanks, Ray >> We also have a somewhat related question, is it true that since v5.10, >> defining of 'dma-ranges' on the bus node where its child device node has >> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now >> mandatory? My understanding is that the 'dma-ranges' in this scheme will >> define the IOVA address to system address mapping required by all >> devices on that bus. Please help to confirm if my understanding is >> correct > > I have not actually seen that change. In general, you should always > have a dma-ranges property in the parent of a DMA master, I think > we just never enforced that and fall back to a 32-bit mask by default. > > Arnd > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. [-- Attachment #1.2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4166 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ 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:[~2021-01-13 3:43 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 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 [this message] 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=3fc2b0174965ec6b911ab4bd73da1525@mail.gmail.com \ --to=bharat.gooty@broadcom.com \ --cc=agross@kernel.org \ --cc=arnd@arndb.de \ --cc=arnd@kernel.org \ --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=ray.jui@broadcom.com \ --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: linkBe 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.