linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Kryger <tim.kryger@gmail.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: Sachin Kamat <spk.linux@gmail.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexandre Courbot <gnurou@gmail.com>
Subject: Re: Possible regression with commit 52221610d
Date: Tue, 4 Nov 2014 07:31:34 -0800	[thread overview]
Message-ID: <CAD7vxxLmLsRpxrYqc30nV0m6atO7jyNgv1Wh4R8GCAy3+y-1dw@mail.gmail.com> (raw)
In-Reply-To: <545895B2.2000101@nvidia.com>

On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot <acourbot@nvidia.com> wrote:
> Hi Tim, thanks for your reply!
>
> On 11/04/2014 02:28 PM, Tim Kryger wrote:
>>
>> On Mon, Nov 3, 2014 at 7:05 PM, Alexandre Courbot <acourbot@nvidia.com>
>> wrote:
>>>
>>> Hi guys,
>>>
>>> On the NVIDIA shield (tegra114-roth) platform, I have noticed that MMC
>>> stopped working completely on recent kernels. MMC devices will not show
>>> up
>>> and the message "mmc1: Controller never released inhibit bit(s)." shows
>>> up
>>> repeatedly in the console.
>>>
>>> After bisecting I tracked commit 52221610dd84dc3e9196554f0292ca9e8ab3541d
>>> ("mmc: sdhci: Improve external VDD regulator support") as the one that
>>> introduced this issue, which seems somehow surprising to me since it has
>>> been around for a while and nobody else complained about this AFAICT.
>>
>>
>> I'm not too familiar with the Nvidia Shield so can you please confirm
>> the following?
>>
>> The controller in the Tegra114 is SDHCI compliant and as such
>> sdhci_tegra_probe calls sdhci_add_host.  External regulators are
>> sought in sdhci_add_host with a call to mmc_regulator_get_supply.
>
>
> This is correct.
>
>> Since no external regulators are specified in tegra114.dtsi or
>> tegra114-roth.dts, mmc->supply.vmmc and mmc->supply.vqmmc are set to
>> -ENODEV.
>
>
> Actually 2 of the MMC nodes in tegra114-roth.dts (for SD card and eMMC) have
> a vmmc-supply property, so for two of them at least mmc->supply.vmmc is a
> valid pointer.
>

I must have been looking at an old version of the file.  Thanks for
clearing this up.

> As explained above, vmmc is a valid pointer for 2 instances of the MMC
> controller. Interestingly, if I just remove the "return" line in the
> IS_ERR() block (without moving it around), the issue also seems to be fixed.
>
>>
>> Can you provide the relevant parts of the log before the problem occurs?
>
>
> There is not much unfortunately ; the only relevant log I have is this:
>
> [   12.246022] mmc2: Timeout waiting for hardware interrupt.
> [   12.264990] mmc2: Controller never released inhibit bit(s).
>
> Some hardware interrupt timed out. I don't know much about the MMC
> subsystem. but could it be because initially the controller is not in a
> powered-on state, and that return statement causes the function to leave it
> unpowered?

In a nutshell, the issue here is that the SDHCI spec demands that VMMC
be supplied by the controller itself with the specific voltage
configured using the SDHCI_POWER_CONTROL register but almost nobody
does this.  Many SoCs omit this capability from their controllers and
instead rely upon external regulators.  In such cases there isn't
normally any need to update the voltage bits of the power control
register.  It sounds like you are saying this isn't true for the
Tegra114.

  reply	other threads:[~2014-11-04 15:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04  3:05 Possible regression with commit 52221610d Alexandre Courbot
2014-11-04  5:28 ` Tim Kryger
2014-11-04  9:00   ` Alexandre Courbot
2014-11-04 15:31     ` Tim Kryger [this message]
2014-11-05  8:10       ` Alexandre Courbot
2014-11-05 15:27         ` Tim Kryger
2014-11-06  2:15           ` Alexandre Courbot
2014-12-14  7:22       ` Bjorn Andersson
2014-12-15  4:48         ` Tim Kryger
2014-12-16  6:27           ` Bjorn Andersson
2014-12-16 18:18             ` Bjorn Andersson
2014-12-17  6:20               ` Tim Kryger
2014-12-17 19:57                 ` Bjorn Andersson
2014-12-22  3:01                   ` Tim Kryger
2015-01-05 19:52                     ` Bjorn Andersson
2015-01-12 10:31                       ` Ulf Hansson
2015-01-13 16:00                         ` Tim Kryger
2015-01-13 15:59                       ` Tim Kryger
2015-01-14  5:00                     ` Tim Kryger
2014-12-16 18:46           ` 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=CAD7vxxLmLsRpxrYqc30nV0m6atO7jyNgv1Wh4R8GCAy3+y-1dw@mail.gmail.com \
    --to=tim.kryger@gmail.com \
    --cc=acourbot@nvidia.com \
    --cc=gnurou@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=spk.linux@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 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).