From: Adrian Hunter <adrian.hunter@intel.com>
To: Nicolin Chen <nicoleotsuka@gmail.com>,
ulf.hansson@linaro.org, thierry.reding@gmail.com,
jonathanh@nvidia.com
Cc: linux-mmc@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, vdumpa@nvidia.com
Subject: Re: [PATCH v2] mmc: tegra: Implement enable_dma() to set dma_mask
Date: Thu, 15 Aug 2019 14:48:20 +0300 [thread overview]
Message-ID: <09d9ba41-f4cd-e515-cd2d-0b4134648059@intel.com> (raw)
In-Reply-To: <20190814005741.13331-1-nicoleotsuka@gmail.com>
On 14/08/19 3:57 AM, Nicolin Chen wrote:
> [ Integrated the change and commit message made by Thierry Reding ]
>
> The SDHCI controller found in early Tegra SoCs (from Tegra20 through
> Tegra114) used an AHB interface to the memory controller, which allowed
> only 32 bits of memory to be addressed.
>
> Starting with Tegra124, this limitation was removed by making the SDHCI
> controllers native MCCIF clients, which means that they got increased
> bandwidth and better arbitration to the memory controller as well as an
> address range extended to 40 bits, out of which only 34 were actually
> used (bits 34-39 are tied to 0 in the controller).
>
> For Tegra186, all of the 40 bits can be used; For Tegra194, 39-bit can
> be used.
>
> So far, sdhci-tegra driver has been relying on sdhci core to configure
> the DMA_BIT_MASK between 32-bit or 64-bit, using one of quirks2 flags:
> SDHCI_QUIRK2_BROKEN_64_BIT_DMA. However, there is a common way, being
> mentioned in sdhci.c file, to set dma_mask via enable_dma() callback in
> the device driver directly.
>
> So this patch implements an enable_dma() callback in the sdhci-tegra,
> in order to set an accurate DMA_BIT_MASK, other than just 32/64 bits.
Is there a reason this cannot be done at probe time?
next prev parent reply other threads:[~2019-08-15 11:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 0:57 [PATCH v2] mmc: tegra: Implement enable_dma() to set dma_mask Nicolin Chen
2019-08-15 11:48 ` Adrian Hunter [this message]
2019-08-15 23:16 ` Nicolin Chen
2019-09-04 8:31 ` Adrian Hunter
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=09d9ba41-f4cd-e515-cd2d-0b4134648059@intel.com \
--to=adrian.hunter@intel.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=nicoleotsuka@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=ulf.hansson@linaro.org \
--cc=vdumpa@nvidia.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).