From: Arnd Bergmann <arnd@arndb.de>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
gnurou@gmail.com
Subject: Re: [PATCH v3 0/3] mmc: sdhci: Set DMA mask properly
Date: Fri, 04 Mar 2016 16:59:01 +0100 [thread overview]
Message-ID: <2058077.gkPpZ9jbXd@wuerfel> (raw)
In-Reply-To: <1457087925-992-1-git-send-email-acourbot@nvidia.com>
On Friday 04 March 2016 19:38:42 Alexandre Courbot wrote:
> Well that's far from the two-liner I had in mind to fix our bounce-buffers
> problem with Tegra, but it feels correct. Testing for ACPI and PCI would be
> appreciated (I am rather confident that ACPI will be ok, but the PCI part
> should be reviewed by someone who knows better).
>
> 64-bit capable devices are supposed to set their own DMA mask. Currently
> this does not happen for sdhci devices excepted for the two (sdhci-acpi
> and sdhci-pci) that define a enable_dma() hook and do it there. However
> this hook is called from several places while DMA mask is supposed to
> be set only once ; for instance the sdhci-acpi driver maintains a flag
> just to make sure the DMA mask is set only upon the first call of this
> hook.
>
> For the vast majority of drivers that do not define a enable_dma() hook, the
> default 32-bit DMA mask is used and there is a risk of using unneeded bounce
> buffers on hosts capable of 64-bit addressing.
>
> The first patch adds a default DMA mask setting function that is called when
> a DMA-capable host is added. It tries to set sane DMA masks according to the
> device's reported capabilities.
>
> The addition of this function seems to make the same code in sdhci-acpi and
> sdhci-pci redundant, so it is removed from these drivers. On top of making
> this series a negative line count, it also removes one usage of the obsolete
> pci_set_dma_mask() function.
>
> Thanks to Arnd for the insightful discussion that led to this.
Looks great overall, much simpler and saner in the new version. I found
one small bug, which appears to have been preexisting, but you moved
it to a different file now.
Arnd
prev parent reply other threads:[~2016-03-04 15:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 10:38 [PATCH v3 0/3] mmc: sdhci: Set DMA mask properly Alexandre Courbot
2016-03-04 10:38 ` [PATCH v3 1/3] mmc: sdhci: Set DMA mask when adding host Alexandre Courbot
2016-03-04 15:57 ` Arnd Bergmann
2016-03-07 2:06 ` Alexandre Courbot
2016-03-04 10:38 ` [PATCH v3 2/3] mmc: sdhci-acpi: Remove enable_dma() hook Alexandre Courbot
2016-03-04 15:57 ` Arnd Bergmann
2016-03-04 10:38 ` [PATCH v3 3/3] mmc: sdhci-pci: Do not set DMA mask in enable_dma() Alexandre Courbot
2016-03-04 15:58 ` Arnd Bergmann
2016-03-04 15:59 ` Arnd Bergmann [this message]
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=2058077.gkPpZ9jbXd@wuerfel \
--to=arnd@arndb.de \
--cc=acourbot@nvidia.com \
--cc=adrian.hunter@intel.com \
--cc=gnurou@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ulf.hansson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox