Re: Possible regression with commit 52221610d

[Tim Kryger]

On Wed, Nov 5, 2014 at 12:10 AM, Alexandre Courbot <acourbot@xxxxxxxxxx> wrote:
> On 11/05/2014 12:31 AM, Tim Kryger wrote:
>>
>> On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot <acourbot@xxxxxxxxxx>
>> 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@xxxxxxxxxx>
>>>> 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.
>
>
> Thanks for your explanation, it makes sense now.
>
> Looking at other Tegra boards .dts I noticed that SHIELD is the only one
> using a vmmc-supply. Maybe this is the part that is wrong? I wrote this DTS
> and cannot exclude I misread the schematics. Maybe that regulator is used
> for some other (still sdmmc-related) purpose but the actual power provider
> is the controller itself.
>
> If you can confirm that the driver is performing as it should, I will look
> in that direction and revise my DTS.

I believe it is working as intended.  Is the schematic publicly available?

>
> Thanks!
> Alex.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/