All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Ray Jui <ray.jui@broadcom.com>
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
Date: Tue, 12 Jan 2021 21:40:16 +0100	[thread overview]
Message-ID: <CAK8P3a2+EfOKAo3HLb+_qd-gnqWD55dyW0juSw1TM8jHKiZYoQ@mail.gmail.com> (raw)
In-Reply-To: <18112862-a42e-95b1-39a3-2e414667f39b@broadcom.com>

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.

> 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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Ray Jui <ray.jui@broadcom.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Bharat Gooty <bharat.gooty@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	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>, Arnd Bergmann <arnd@arndb.de>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.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
Date: Tue, 12 Jan 2021 21:40:16 +0100	[thread overview]
Message-ID: <CAK8P3a2+EfOKAo3HLb+_qd-gnqWD55dyW0juSw1TM8jHKiZYoQ@mail.gmail.com> (raw)
In-Reply-To: <18112862-a42e-95b1-39a3-2e414667f39b@broadcom.com>

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.

> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-12 21:49 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 [this message]
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=CAK8P3a2+EfOKAo3HLb+_qd-gnqWD55dyW0juSw1TM8jHKiZYoQ@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=agross@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bharat.gooty@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: 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.