From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alexandre Courbot
<acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-mmc <linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] mmc: sdhci-tegra: Set DMA mask
Date: Fri, 26 Feb 2016 12:31:36 +0100 [thread overview]
Message-ID: <6561324.RvoTsUTSRM@wuerfel> (raw)
In-Reply-To: <CAAVeFuLL-SP3_x2GC4UWcH4KEVora6r-e5xmORQdVfjcjfWDOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Friday 26 February 2016 16:24:34 Alexandre Courbot wrote:
> On Thu, Feb 25, 2016 at 11:52 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >> Actually even if we specify a dma-ranges on the parent DT node, the
> >> DMA range will still be limited to 32 bits because of the following
> >> code in of_dma_configure():
> >>
> >> /*
> >> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> >> * setup the correct supported mask.
> >> */
> >> if (!dev->coherent_dma_mask)
> >> dev->coherent_dma_mask = DMA_BIT_MASK(32);
> >>
> >> /*
> >> * Set it to coherent_dma_mask by default if the architecture
> >> * code has not set it.
> >> */
> >> if (!dev->dma_mask)
> >> dev->dma_mask = &dev->coherent_dma_mask;
> >>
> >> ....
> >> /* gets dma-ranges into dma_addr and size */
> >> ....
> >>
> >>
> >> *dev->dma_mask = min((*dev->dma_mask),
> >> DMA_BIT_MASK(ilog2(dma_addr + size)));
> >>
> >> So unless the DMA mask is set on the device before of_dma_configure()
> >> is called, the min() statement will choose the 32 bits mask that has
> >> been previously set. So IIUC in any case, the driver will need to call
> >> dma_set_mask()
> >
> > Yes, the driver definitely has to call dma_set_mask(), the property of
> > the parent bus is used to make that fail when the bus doesn't support
> > it.
>
> And that's where things seem to stop working: the driver's probe
> function is invoked by the platform bus, *after* of_dma_configure() is
> called. So unless I am missing something there is no way for the
> driver to set the DMA mask in such a way that of_dma_configure() can
> see it and do the right thing.
>
> In other words, most of the DMA mask logic in of_dma_configure()
> doesn't seem to have any effect (and a 32 bits mask will be set), at
> least on the platform bus.
That is correct: of_dma_configure has to set a 32-bit DMA mask
because that is the default that we expect to see in Linux drivers.
A lot of drivers don't call dma_set_mask() at all, so this is
the most reasonable value that typically works, unless the
device is more limited, or you want the extra performance you
get on devices that actually support a bigger mask.
> >> Can I have your thoughts on this? Am I missing something?
> >
> > One point: I think the dma_set_mask() probably should be in the
> > generic part of the sdhci driver, not the tegra specific portion.
>
> Ok, but then how does the generic part of the driver knows which DMA
> mask applies to the device?
If dma_set_mask() succeeds when passed a 64-bit mask, the driver
can pass high addresses into dma_map_*() and put the result into
the 64-bit DMA registers of the device. That is all the driver
needs to know here.
When the bus is more limited than the device, we either have
an swiotlb/iommu that will use bounce buffers to map dma_map_* work
anyway (using low DMA addresses for high memory), or we don't have
an swiotlb and the dma_set_mask() operation has to fail.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Alexandre Courbot <gnurou@gmail.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
linux-mmc <linux-mmc@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: sdhci-tegra: Set DMA mask
Date: Fri, 26 Feb 2016 12:31:36 +0100 [thread overview]
Message-ID: <6561324.RvoTsUTSRM@wuerfel> (raw)
In-Reply-To: <CAAVeFuLL-SP3_x2GC4UWcH4KEVora6r-e5xmORQdVfjcjfWDOw@mail.gmail.com>
On Friday 26 February 2016 16:24:34 Alexandre Courbot wrote:
> On Thu, Feb 25, 2016 at 11:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> Actually even if we specify a dma-ranges on the parent DT node, the
> >> DMA range will still be limited to 32 bits because of the following
> >> code in of_dma_configure():
> >>
> >> /*
> >> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> >> * setup the correct supported mask.
> >> */
> >> if (!dev->coherent_dma_mask)
> >> dev->coherent_dma_mask = DMA_BIT_MASK(32);
> >>
> >> /*
> >> * Set it to coherent_dma_mask by default if the architecture
> >> * code has not set it.
> >> */
> >> if (!dev->dma_mask)
> >> dev->dma_mask = &dev->coherent_dma_mask;
> >>
> >> ....
> >> /* gets dma-ranges into dma_addr and size */
> >> ....
> >>
> >>
> >> *dev->dma_mask = min((*dev->dma_mask),
> >> DMA_BIT_MASK(ilog2(dma_addr + size)));
> >>
> >> So unless the DMA mask is set on the device before of_dma_configure()
> >> is called, the min() statement will choose the 32 bits mask that has
> >> been previously set. So IIUC in any case, the driver will need to call
> >> dma_set_mask()
> >
> > Yes, the driver definitely has to call dma_set_mask(), the property of
> > the parent bus is used to make that fail when the bus doesn't support
> > it.
>
> And that's where things seem to stop working: the driver's probe
> function is invoked by the platform bus, *after* of_dma_configure() is
> called. So unless I am missing something there is no way for the
> driver to set the DMA mask in such a way that of_dma_configure() can
> see it and do the right thing.
>
> In other words, most of the DMA mask logic in of_dma_configure()
> doesn't seem to have any effect (and a 32 bits mask will be set), at
> least on the platform bus.
That is correct: of_dma_configure has to set a 32-bit DMA mask
because that is the default that we expect to see in Linux drivers.
A lot of drivers don't call dma_set_mask() at all, so this is
the most reasonable value that typically works, unless the
device is more limited, or you want the extra performance you
get on devices that actually support a bigger mask.
> >> Can I have your thoughts on this? Am I missing something?
> >
> > One point: I think the dma_set_mask() probably should be in the
> > generic part of the sdhci driver, not the tegra specific portion.
>
> Ok, but then how does the generic part of the driver knows which DMA
> mask applies to the device?
If dma_set_mask() succeeds when passed a 64-bit mask, the driver
can pass high addresses into dma_map_*() and put the result into
the 64-bit DMA registers of the device. That is all the driver
needs to know here.
When the bus is more limited than the device, we either have
an swiotlb/iommu that will use bounce buffers to map dma_map_* work
anyway (using low DMA addresses for high memory), or we don't have
an swiotlb and the dma_set_mask() operation has to fail.
Arnd
next prev parent reply other threads:[~2016-02-26 11:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 9:11 [PATCH] mmc: sdhci-tegra: Set DMA mask Alexandre Courbot
[not found] ` <1456305079-27779-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-24 12:37 ` Arnd Bergmann
2016-02-24 12:37 ` Arnd Bergmann
2016-02-25 9:49 ` Alexandre Courbot
2016-02-25 14:52 ` Arnd Bergmann
2016-02-26 7:24 ` Alexandre Courbot
[not found] ` <CAAVeFuLL-SP3_x2GC4UWcH4KEVora6r-e5xmORQdVfjcjfWDOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-26 11:31 ` Arnd Bergmann [this message]
2016-02-26 11:31 ` Arnd Bergmann
2016-03-01 4:21 ` Alexandre Courbot
2016-02-24 17:08 ` Stephen Warren
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=6561324.RvoTsUTSRM@wuerfel \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
/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.