From: Jon Hunter <jonathanh@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Alexandre Courbot <gnurou@gmail.com>,
linux-mmc@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, Lucas Stach <dev@lynxeye.de>
Subject: Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30
Date: Tue, 10 May 2016 18:16:08 +0100 [thread overview]
Message-ID: <57321758.5020308@nvidia.com> (raw)
In-Reply-To: <57320DA8.1090809@wwwdotorg.org>
On 10/05/16 17:34, Stephen Warren wrote:
> On 05/10/2016 10:13 AM, Jon Hunter wrote:
[snip]
>> Stephen, for your u-boot testing, do you are set the bit in the vendor
>> misc register to enable version 3.0 support for sdhci on tegra30? This
>> is what the above quirk is doing (and has done so for a very long time).
>
> I don't see anything in the U-Boot driver that is equivalent to the
> kernel's NVQUIRK_ENABLE_SDHCI_SPEC_300. I assume that means the
> controller advertises an early spec version when in U-Boot, which simply
> means U-Boot doesn't know to take advantage of any faster transfer modes
> enabled by later specification versions, but I'm not entirely sure what
> effect the following kernel code has on the HW:
>
>> /* Erratum: Enable SDHCI spec v3.00 support */
>> if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
>> misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
Do you see it touch the SDHCI_TEGRA_VENDOR_MISC_CTRL register?
The TRM states ...
"SDMMC_SPARE0[4] : When set, SD3.0 support is advertised in
SDMMC_SLOT_INTERRUPT_STATUS_0_SPECIFICATION_VERSION_NUMBER Otherwise,
only SD2.0 support is advertised"
So I *believe* this means that the sdhci version will now appear as 3.0
and so the host->version == SDHCI_SPEC_300. There are many places in the
sdhci driver where it is checking ...
if (host->version >= SDHCI_SPEC_300)
...
> Perhaps the kernel driver should pulse the controller's CAR reset signal
> in probe() to ensure that the HW is in a known state?
I will take a look.
Jon
WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Alexandre Courbot <gnurou@gmail.com>, <linux-mmc@vger.kernel.org>,
<linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Lucas Stach <dev@lynxeye.de>
Subject: Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30
Date: Tue, 10 May 2016 18:16:08 +0100 [thread overview]
Message-ID: <57321758.5020308@nvidia.com> (raw)
In-Reply-To: <57320DA8.1090809@wwwdotorg.org>
On 10/05/16 17:34, Stephen Warren wrote:
> On 05/10/2016 10:13 AM, Jon Hunter wrote:
[snip]
>> Stephen, for your u-boot testing, do you are set the bit in the vendor
>> misc register to enable version 3.0 support for sdhci on tegra30? This
>> is what the above quirk is doing (and has done so for a very long time).
>
> I don't see anything in the U-Boot driver that is equivalent to the
> kernel's NVQUIRK_ENABLE_SDHCI_SPEC_300. I assume that means the
> controller advertises an early spec version when in U-Boot, which simply
> means U-Boot doesn't know to take advantage of any faster transfer modes
> enabled by later specification versions, but I'm not entirely sure what
> effect the following kernel code has on the HW:
>
>> /* Erratum: Enable SDHCI spec v3.00 support */
>> if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
>> misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
Do you see it touch the SDHCI_TEGRA_VENDOR_MISC_CTRL register?
The TRM states ...
"SDMMC_SPARE0[4] : When set, SD3.0 support is advertised in
SDMMC_SLOT_INTERRUPT_STATUS_0_SPECIFICATION_VERSION_NUMBER Otherwise,
only SD2.0 support is advertised"
So I *believe* this means that the sdhci version will now appear as 3.0
and so the host->version == SDHCI_SPEC_300. There are many places in the
sdhci driver where it is checking ...
if (host->version >= SDHCI_SPEC_300)
...
> Perhaps the kernel driver should pulse the controller's CAR reset signal
> in probe() to ensure that the HW is in a known state?
I will take a look.
Jon
next prev parent reply other threads:[~2016-05-10 17:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 15:15 [PATCH] mmc: tegra: Disable UHS-I modes for tegra30 Jon Hunter
2016-05-09 15:15 ` Jon Hunter
[not found] ` <1462806903-13860-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-10 6:25 ` Ulf Hansson
2016-05-10 6:25 ` Ulf Hansson
2016-05-10 7:09 ` Lucas Stach
2016-05-10 7:09 ` Lucas Stach
[not found] ` <1462864193.13327.2.camel-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2016-05-10 11:15 ` Jon Hunter
2016-05-10 11:15 ` Jon Hunter
2016-05-10 16:13 ` Jon Hunter
2016-05-10 16:13 ` Jon Hunter
2016-05-10 16:34 ` Stephen Warren
2016-05-10 17:16 ` Jon Hunter [this message]
2016-05-10 17:16 ` Jon Hunter
2016-05-10 17:49 ` 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=57321758.5020308@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=adrian.hunter@intel.com \
--cc=dev@lynxeye.de \
--cc=gnurou@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
--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 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.