MMC error on Exynos4210 board

MMC error on Exynos4210 board

[Sachin Kamat]

Hi Tim,

I see the below error on Exynos4210 based Origen board with linux-next
(20140618).
Reverting the below commit works fine.

Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"

Any ideas?

***************

-- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
[    2.075059] sdhci: Copyright(c) Pierre Ossman
[    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
node '/sdhci@12510000[0]'
[    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
(50000000 Hz)
[    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
node '/sdhci@12510000[0]'
[    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
node '/sdhci@12510000[0]'
[    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
[    2.118117] mmc0: Hardware doesn't report any support voltages.
[    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
[    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
node '/sdhci@12530000[0]'
[    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
(16666667 Hz)
[    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
node '/sdhci@12530000[0]'
[    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
node '/sdhci@12530000[0]'
[    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
[    2.168464] mmc0: Hardware doesn't report any support voltages.
[    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
[    2.180281] Synopsys Designware Multimedia Card Interface Driver
[    2.188131] usbcore: registered new interface driver usbhid
[    2.192287] usbhid: USB HID core driver
[    2.196329] TCP: cubic registered
[    2.199362] NET: Registered protocol family 17
[    2.203917] NET: Registered protocol family 15
[    2.208404] Registering SWP/SWPB emulation handler
[    2.214357] of_get_named_gpiod_flags exited with status 0
[    2.218430] of_get_named_gpiod_flags exited with status 0
[    2.223803] of_get_named_gpiod_flags exited with status 0
[    2.229170] of_get_named_gpiod_flags exited with status 0
[    2.234560] of_get_named_gpiod_flags exited with status 0
[    2.239953] gpio-229: gpiod_set_debounce: missing set() or
set_debounce() operations
[    2.247773] gpio-230: gpiod_set_debounce: missing set() or
set_debounce() operations
[    2.255473] gpio-228: gpiod_set_debounce: missing set() or
set_debounce() operations
[    2.263221] gpio-227: gpiod_set_debounce: missing set() or
set_debounce() operations
[    2.270918] gpio-226: gpiod_set_debounce: missing set() or
set_debounce() operations
[    2.278899] input: gpio_keys as /devices/gpio_keys/input/input0
[    2.285196] s3c-rtc 10070000.rtc: setting system clock to
2000-01-01 00:00:00 UTC (946684800)
[    2.295072] VDD_G3D_1.1V: disabling
[    2.304744] VADC_3.3V: disabling
[    2.312095] VDD_AUD_1.8V: disabling
[    2.319714] VMIPI_1.1V: disabling
[    2.327193] VDD_ABB_3.3V: disabling
[    2.332779] VMEM_VDD_2.8V: disabling
[    2.336148] Waiting for root device /dev/mmcblk0p1...

*************
Regards,
Sachin.

Re: MMC error on Exynos4210 board

[Tim Kryger]

On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
> Hi Tim,
>
> I see the below error on Exynos4210 based Origen board with linux-next
> (20140618).
> Reverting the below commit works fine.
>
> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>
> Any ideas?
>
> ***************
>
> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
> [    2.075059] sdhci: Copyright(c) Pierre Ossman
> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
> node '/sdhci@12510000[0]'
> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
> (50000000 Hz)
> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
> node '/sdhci@12510000[0]'
> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
> node '/sdhci@12510000[0]'
> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
> [    2.118117] mmc0: Hardware doesn't report any support voltages.
> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
> node '/sdhci@12530000[0]'
> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
> (16666667 Hz)
> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
> node '/sdhci@12530000[0]'
> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
> node '/sdhci@12530000[0]'
> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
> [    2.168464] mmc0: Hardware doesn't report any support voltages.
> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
> [    2.180281] Synopsys Designware Multimedia Card Interface Driver
> [    2.188131] usbcore: registered new interface driver usbhid
> [    2.192287] usbhid: USB HID core driver
> [    2.196329] TCP: cubic registered
> [    2.199362] NET: Registered protocol family 17
> [    2.203917] NET: Registered protocol family 15
> [    2.208404] Registering SWP/SWPB emulation handler
> [    2.214357] of_get_named_gpiod_flags exited with status 0
> [    2.218430] of_get_named_gpiod_flags exited with status 0
> [    2.223803] of_get_named_gpiod_flags exited with status 0
> [    2.229170] of_get_named_gpiod_flags exited with status 0
> [    2.234560] of_get_named_gpiod_flags exited with status 0
> [    2.239953] gpio-229: gpiod_set_debounce: missing set() or
> set_debounce() operations
> [    2.247773] gpio-230: gpiod_set_debounce: missing set() or
> set_debounce() operations
> [    2.255473] gpio-228: gpiod_set_debounce: missing set() or
> set_debounce() operations
> [    2.263221] gpio-227: gpiod_set_debounce: missing set() or
> set_debounce() operations
> [    2.270918] gpio-226: gpiod_set_debounce: missing set() or
> set_debounce() operations
> [    2.278899] input: gpio_keys as /devices/gpio_keys/input/input0
> [    2.285196] s3c-rtc 10070000.rtc: setting system clock to
> 2000-01-01 00:00:00 UTC (946684800)
> [    2.295072] VDD_G3D_1.1V: disabling
> [    2.304744] VADC_3.3V: disabling
> [    2.312095] VDD_AUD_1.8V: disabling
> [    2.319714] VMIPI_1.1V: disabling
> [    2.327193] VDD_ABB_3.3V: disabling
> [    2.332779] VMEM_VDD_2.8V: disabling
> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>
> *************
> Regards,
> Sachin.

Would you mind reverting just this part of the commit to see if it
clears up your trouble?

>         if (host->ocr_mask)
> -               ocr_avail = host->ocr_mask;
> +               ocr_avail &= host->ocr_mask;
>
>         mmc->ocr_avail = ocr_avail;
>         mmc->ocr_avail_sdio = ocr_avail;

Thanks,
Tim Kryger

Re: MMC error on Exynos4210 board

[Sachin Kamat]

On Wed, Jun 18, 2014 at 7:41 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>> Hi Tim,
>>
>> I see the below error on Exynos4210 based Origen board with linux-next
>> (20140618).
>> Reverting the below commit works fine.
>>
>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>>
>> Any ideas?
>>
>> ***************
>>
>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>> node '/sdhci@12510000[0]'
>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>> (50000000 Hz)
>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>> node '/sdhci@12510000[0]'
>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>> node '/sdhci@12510000[0]'
>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>> node '/sdhci@12530000[0]'
>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>> (16666667 Hz)
>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>> node '/sdhci@12530000[0]'
>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>> node '/sdhci@12530000[0]'
>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>> [    2.180281] Synopsys Designware Multimedia Card Interface Driver
>> [    2.188131] usbcore: registered new interface driver usbhid
>> [    2.192287] usbhid: USB HID core driver
>> [    2.196329] TCP: cubic registered
>> [    2.199362] NET: Registered protocol family 17
>> [    2.203917] NET: Registered protocol family 15
>> [    2.208404] Registering SWP/SWPB emulation handler
>> [    2.214357] of_get_named_gpiod_flags exited with status 0
>> [    2.218430] of_get_named_gpiod_flags exited with status 0
>> [    2.223803] of_get_named_gpiod_flags exited with status 0
>> [    2.229170] of_get_named_gpiod_flags exited with status 0
>> [    2.234560] of_get_named_gpiod_flags exited with status 0
>> [    2.239953] gpio-229: gpiod_set_debounce: missing set() or
>> set_debounce() operations
>> [    2.247773] gpio-230: gpiod_set_debounce: missing set() or
>> set_debounce() operations
>> [    2.255473] gpio-228: gpiod_set_debounce: missing set() or
>> set_debounce() operations
>> [    2.263221] gpio-227: gpiod_set_debounce: missing set() or
>> set_debounce() operations
>> [    2.270918] gpio-226: gpiod_set_debounce: missing set() or
>> set_debounce() operations
>> [    2.278899] input: gpio_keys as /devices/gpio_keys/input/input0
>> [    2.285196] s3c-rtc 10070000.rtc: setting system clock to
>> 2000-01-01 00:00:00 UTC (946684800)
>> [    2.295072] VDD_G3D_1.1V: disabling
>> [    2.304744] VADC_3.3V: disabling
>> [    2.312095] VDD_AUD_1.8V: disabling
>> [    2.319714] VMIPI_1.1V: disabling
>> [    2.327193] VDD_ABB_3.3V: disabling
>> [    2.332779] VMEM_VDD_2.8V: disabling
>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>
>> *************
>> Regards,
>> Sachin.
>
> Would you mind reverting just this part of the commit to see if it
> clears up your trouble?
>
>>         if (host->ocr_mask)
>> -               ocr_avail = host->ocr_mask;
>> +               ocr_avail &= host->ocr_mask;

Reverting this did not help. I still get the above error. My diff:

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c23a87285a95..f4135094320d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3096,7 +3096,7 @@ int sdhci_add_host(struct sdhci_host *host)
                ocr_avail &= mmc->ocr_avail;

        if (host->ocr_mask)
-               ocr_avail &= host->ocr_mask;
+               ocr_avail = host->ocr_mask;

        mmc->ocr_avail = ocr_avail;
        mmc->ocr_avail_sdio = ocr_avail;

FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.

-- 
Regards,
Sachin.

Re: MMC error on Exynos4210 board

[Tim Kryger]

On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:

>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:

>>> I see the below error on Exynos4210 based Origen board with linux-next
>>> (20140618).
>>> Reverting the below commit works fine.
>>>
>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"

>>>
>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>> node '/sdhci@12510000[0]'
>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>> (50000000 Hz)
>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>> node '/sdhci@12510000[0]'
>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>> node '/sdhci@12510000[0]'
>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>> node '/sdhci@12530000[0]'
>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>> (16666667 Hz)
>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>> node '/sdhci@12530000[0]'
>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>> node '/sdhci@12530000[0]'
>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed

>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...

> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.

A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
| MMC_VDD_28_29.

The SDHCI capabilities register only indicates support of three voltage levels
  - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
  - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
  - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34

Even if all capability bits of the host controller were set, there
still wouldn't be any overlap.  Thus you see a "Hardware doesn't
report any support voltages" message.

Previously, this issue was being swept under the rug by cec2e21 mmc:
sdhci: Use regulator min/max voltage range according to spec.  That
change hacked up the voltage range checks such that with your 2.8v
fixed regulator, the driver would believe the host could support
MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
driver would start down the path of commanding 3.3v-3.4v (the highest
voltage range believed to be supported).  At the last second, the
driver would see the regulator was fixed and blindly skip over the set
voltage operation, saving it from failure.

Since my patch eliminates the bogus voltage range checks, your board
is now getting caught playing too loose with the SDHCI regulator
voltages.

Furthermore, the fixed regulator special-case logic that helped hide
your issue should also be considered for removal given that fixed
regulators now behave properly thanks to c00dc35 regulator: core:
Allow regulator_set_voltage for fixed regulators.

-Tim

Re: MMC error on Exynos4210 board

[Sachin Kamat]

+cc Some relevant guys from Samsung

On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>
>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>
>>>> I see the below error on Exynos4210 based Origen board with linux-next
>>>> (20140618).
>>>> Reverting the below commit works fine.
>>>>
>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>
>>>>
>>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>>> node '/sdhci@12510000[0]'
>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>>> (50000000 Hz)
>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>>> node '/sdhci@12510000[0]'
>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>>> node '/sdhci@12510000[0]'
>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>>> node '/sdhci@12530000[0]'
>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>>> (16666667 Hz)
>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>>> node '/sdhci@12530000[0]'
>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>>> node '/sdhci@12530000[0]'
>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>
>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>
>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.
>
> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
> | MMC_VDD_28_29.
>
> The SDHCI capabilities register only indicates support of three voltage levels
>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>
> Even if all capability bits of the host controller were set, there
> still wouldn't be any overlap.  Thus you see a "Hardware doesn't
> report any support voltages" message.
>
> Previously, this issue was being swept under the rug by cec2e21 mmc:
> sdhci: Use regulator min/max voltage range according to spec.  That
> change hacked up the voltage range checks such that with your 2.8v
> fixed regulator, the driver would believe the host could support
> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
> driver would start down the path of commanding 3.3v-3.4v (the highest
> voltage range believed to be supported).  At the last second, the
> driver would see the regulator was fixed and blindly skip over the set
> voltage operation, saving it from failure.
>
> Since my patch eliminates the bogus voltage range checks, your board
> is now getting caught playing too loose with the SDHCI regulator
> voltages.
>
> Furthermore, the fixed regulator special-case logic that helped hide
> your issue should also be considered for removal given that fixed
> regulators now behave properly thanks to c00dc35 regulator: core:
> Allow regulator_set_voltage for fixed regulators.

Thanks for the detailed explanation. What do you propose to get this fixed?

-- 
Regards,
Sachin.

Re: MMC error on Exynos4210 board

[Tim Kryger]

On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
> +cc Some relevant guys from Samsung
>
> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>
>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>
>>>>> I see the below error on Exynos4210 based Origen board with linux-next
>>>>> (20140618).
>>>>> Reverting the below commit works fine.
>>>>>
>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>>
>>>>>
>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>>>> node '/sdhci@12510000[0]'
>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>>>> (50000000 Hz)
>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>>>> node '/sdhci@12510000[0]'
>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>>>> node '/sdhci@12510000[0]'
>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>>>> node '/sdhci@12530000[0]'
>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>>>> (16666667 Hz)
>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>>>> node '/sdhci@12530000[0]'
>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>>>> node '/sdhci@12530000[0]'
>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>>
>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>
>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.
>>
>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
>> | MMC_VDD_28_29.
>>
>> The SDHCI capabilities register only indicates support of three voltage levels
>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>>
>> Even if all capability bits of the host controller were set, there
>> still wouldn't be any overlap.  Thus you see a "Hardware doesn't
>> report any support voltages" message.
>>
>> Previously, this issue was being swept under the rug by cec2e21 mmc:
>> sdhci: Use regulator min/max voltage range according to spec.  That
>> change hacked up the voltage range checks such that with your 2.8v
>> fixed regulator, the driver would believe the host could support
>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
>> driver would start down the path of commanding 3.3v-3.4v (the highest
>> voltage range believed to be supported).  At the last second, the
>> driver would see the regulator was fixed and blindly skip over the set
>> voltage operation, saving it from failure.
>>
>> Since my patch eliminates the bogus voltage range checks, your board
>> is now getting caught playing too loose with the SDHCI regulator
>> voltages.
>>
>> Furthermore, the fixed regulator special-case logic that helped hide
>> your issue should also be considered for removal given that fixed
>> regulators now behave properly thanks to c00dc35 regulator: core:
>> Allow regulator_set_voltage for fixed regulators.
>
> Thanks for the detailed explanation. What do you propose to get this fixed?

I'm not really sure of the best path forward.  I suppose you could
modify your device tree to lie about the voltage of the fixed
regulator.  Changing it to 3.0v should allow it to boot up but that is
definitely a hack.  It would be nice if the driver could be extended
to handle the peculiarities of your board in a deliberate manner but
limiting the common sdhci driver to supporting only the three voltages
from the spec also seems sensible.

-Tim

Re: MMC error on Exynos4210 board

[Sachin Kamat]

On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>> +cc Some relevant guys from Samsung
>>
>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>
>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>
>>>>>> I see the below error on Exynos4210 based Origen board with linux-next
>>>>>> (20140618).
>>>>>> Reverting the below commit works fine.
>>>>>>
>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>>>
>>>>>>
>>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>> node '/sdhci@12510000[0]'
>>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>>>>> (50000000 Hz)
>>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>> node '/sdhci@12510000[0]'
>>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>> node '/sdhci@12510000[0]'
>>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>>>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>> node '/sdhci@12530000[0]'
>>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>>>>> (16666667 Hz)
>>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>> node '/sdhci@12530000[0]'
>>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>> node '/sdhci@12530000[0]'
>>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>>>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>>>
>>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>>
>>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.
>>>
>>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
>>> | MMC_VDD_28_29.
>>>
>>> The SDHCI capabilities register only indicates support of three voltage levels
>>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>>>
>>> Even if all capability bits of the host controller were set, there
>>> still wouldn't be any overlap.  Thus you see a "Hardware doesn't
>>> report any support voltages" message.
>>>
>>> Previously, this issue was being swept under the rug by cec2e21 mmc:
>>> sdhci: Use regulator min/max voltage range according to spec.  That
>>> change hacked up the voltage range checks such that with your 2.8v
>>> fixed regulator, the driver would believe the host could support
>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
>>> driver would start down the path of commanding 3.3v-3.4v (the highest
>>> voltage range believed to be supported).  At the last second, the
>>> driver would see the regulator was fixed and blindly skip over the set
>>> voltage operation, saving it from failure.
>>>
>>> Since my patch eliminates the bogus voltage range checks, your board
>>> is now getting caught playing too loose with the SDHCI regulator
>>> voltages.
>>>
>>> Furthermore, the fixed regulator special-case logic that helped hide
>>> your issue should also be considered for removal given that fixed
>>> regulators now behave properly thanks to c00dc35 regulator: core:
>>> Allow regulator_set_voltage for fixed regulators.
>>
>> Thanks for the detailed explanation. What do you propose to get this fixed?
>
> I'm not really sure of the best path forward.  I suppose you could
> modify your device tree to lie about the voltage of the fixed
> regulator.  Changing it to 3.0v should allow it to boot up but that is
> definitely a hack.

Or I could simply remove the vmmc-supply property altogether (as it is optional)
and get the board to work.

> It would be nice if the driver could be extended
> to handle the peculiarities of your board in a deliberate manner but
> limiting the common sdhci driver to supporting only the three voltages
> from the spec also seems sensible.

Until such time that the driver gets fixed to handle 2.8V fixed supply your
current patch leaves several of Exynos boards broken for now.

-- 
Regards,
Sachin.

Re: MMC error on Exynos4210 board

[Jaehoon Chung]

On 06/19/2014 07:40 PM, Sachin Kamat wrote:
> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>> +cc Some relevant guys from Samsung
>>>
>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>
>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>
>>>>>>> I see the below error on Exynos4210 based Origen board with linux-next
>>>>>>> (20140618).
>>>>>>> Reverting the below commit works fine.
>>>>>>>
>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>>>>
>>>>>>>
>>>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>> node '/sdhci@12510000[0]'
>>>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>>>>>> (50000000 Hz)
>>>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>> node '/sdhci@12510000[0]'
>>>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>> node '/sdhci@12510000[0]'
>>>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>>>>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>> node '/sdhci@12530000[0]'
>>>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>>>>>> (16666667 Hz)
>>>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>> node '/sdhci@12530000[0]'
>>>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>> node '/sdhci@12530000[0]'
>>>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>>>>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>>>>
>>>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>>>
>>>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.
>>>>
>>>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
>>>> | MMC_VDD_28_29.
>>>>
>>>> The SDHCI capabilities register only indicates support of three voltage levels
>>>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34

Right. sdhci capabilities only indicated them.
But I think SoC can be support the specific VDD range.

>>>>
>>>> Even if all capability bits of the host controller were set, there
>>>> still wouldn't be any overlap.  Thus you see a "Hardware doesn't
>>>> report any support voltages" message.
>>>>
>>>> Previously, this issue was being swept under the rug by cec2e21 mmc:
>>>> sdhci: Use regulator min/max voltage range according to spec.  That
>>>> change hacked up the voltage range checks such that with your 2.8v
>>>> fixed regulator, the driver would believe the host could support
>>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
>>>> driver would start down the path of commanding 3.3v-3.4v (the highest
>>>> voltage range believed to be supported).  At the last second, the
>>>> driver would see the regulator was fixed and blindly skip over the set
>>>> voltage operation, saving it from failure.
>>>>
>>>> Since my patch eliminates the bogus voltage range checks, your board
>>>> is now getting caught playing too loose with the SDHCI regulator
>>>> voltages.
>>>>
>>>> Furthermore, the fixed regulator special-case logic that helped hide
>>>> your issue should also be considered for removal given that fixed
>>>> regulators now behave properly thanks to c00dc35 regulator: core:
>>>> Allow regulator_set_voltage for fixed regulators.
>>>
>>> Thanks for the detailed explanation. What do you propose to get this fixed?
>>
>> I'm not really sure of the best path forward.  I suppose you could
>> modify your device tree to lie about the voltage of the fixed
>> regulator.  Changing it to 3.0v should allow it to boot up but that is
>> definitely a hack.
I don't want to change the 3.0V at dt file...is it hack? i don't think so.
Almost exynos4 Series is used the fixed regulator(2.8V).
I didn't know exactly why we used the 2.8V. But i guess there is some reason.(H/W design).

If we need to change ocr value, 
then i will add the quirk or controlling function for exynos into sdhci-s3c.c
How about?

> 
> Or I could simply remove the vmmc-supply property altogether (as it is optional)
> and get the board to work.
Then is it supported the power "always-on"?
> 
>> It would be nice if the driver could be extended
>> to handle the peculiarities of your board in a deliberate manner but
>> limiting the common sdhci driver to supporting only the three voltages
>> from the spec also seems sensible.
> 
> Until such time that the driver gets fixed to handle 2.8V fixed supply your
> current patch leaves several of Exynos boards broken for now.

the all of exynos used the fixed-regulator(2.8v) should be broken.
(Maybe exynos4 series??)

> 

Re: MMC error on Exynos4210 board

[Sachin Kamat]

On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> On 06/19/2014 07:40 PM, Sachin Kamat wrote:
>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>> +cc Some relevant guys from Samsung
>>>>
>>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>>
>>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>>
>>>>>>>> I see the below error on Exynos4210 based Origen board with linux-next
>>>>>>>> (20140618).
>>>>>>>> Reverting the below commit works fine.
>>>>>>>>
>>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>>>>>
>>>>>>>>
>>>>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>>>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>>>>>>> (50000000 Hz)
>>>>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>>>>>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>>>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>>>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>>>>>>> (16666667 Hz)
>>>>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>>>>>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>>>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>>>>>
>>>>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>>>>
>>>>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
>>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.
>>>>>
>>>>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
>>>>> | MMC_VDD_28_29.
>>>>>
>>>>> The SDHCI capabilities register only indicates support of three voltage levels
>>>>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>>>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>>>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>
> Right. sdhci capabilities only indicated them.
> But I think SoC can be support the specific VDD range.
>
>>>>>
>>>>> Even if all capability bits of the host controller were set, there
>>>>> still wouldn't be any overlap.  Thus you see a "Hardware doesn't
>>>>> report any support voltages" message.
>>>>>
>>>>> Previously, this issue was being swept under the rug by cec2e21 mmc:
>>>>> sdhci: Use regulator min/max voltage range according to spec.  That
>>>>> change hacked up the voltage range checks such that with your 2.8v
>>>>> fixed regulator, the driver would believe the host could support
>>>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
>>>>> driver would start down the path of commanding 3.3v-3.4v (the highest
>>>>> voltage range believed to be supported).  At the last second, the
>>>>> driver would see the regulator was fixed and blindly skip over the set
>>>>> voltage operation, saving it from failure.
>>>>>
>>>>> Since my patch eliminates the bogus voltage range checks, your board
>>>>> is now getting caught playing too loose with the SDHCI regulator
>>>>> voltages.
>>>>>
>>>>> Furthermore, the fixed regulator special-case logic that helped hide
>>>>> your issue should also be considered for removal given that fixed
>>>>> regulators now behave properly thanks to c00dc35 regulator: core:
>>>>> Allow regulator_set_voltage for fixed regulators.
>>>>
>>>> Thanks for the detailed explanation. What do you propose to get this fixed?
>>>
>>> I'm not really sure of the best path forward.  I suppose you could
>>> modify your device tree to lie about the voltage of the fixed
>>> regulator.  Changing it to 3.0v should allow it to boot up but that is
>>> definitely a hack.
> I don't want to change the 3.0V at dt file...is it hack? i don't think so.
> Almost exynos4 Series is used the fixed regulator(2.8V).
> I didn't know exactly why we used the 2.8V. But i guess there is some reason.(H/W design).
>
> If we need to change ocr value,
> then i will add the quirk or controlling function for exynos into sdhci-s3c.c
> How about?

That sounds good compared to adding hacks in DT files.

>
>>
>> Or I could simply remove the vmmc-supply property altogether (as it is optional)
>> and get the board to work.
> Then is it supported the power "always-on"?

Atleast on Exynos 4210 and 4412 Origen boards the 2.8V MMC supply is derived
directly from the 5V input DC supply and hence it is always on.

>>
>>> It would be nice if the driver could be extended
>>> to handle the peculiarities of your board in a deliberate manner but
>>> limiting the common sdhci driver to supporting only the three voltages
>>> from the spec also seems sensible.
>>
>> Until such time that the driver gets fixed to handle 2.8V fixed supply your
>> current patch leaves several of Exynos boards broken for now.
>
> the all of exynos used the fixed-regulator(2.8v) should be broken.
> (Maybe exynos4 series??)

Probably. I haven't verified for the other boards. Hence would be good to handle
this case in the driver itself.

-- 
Regards,
Sachin.

Re: MMC error on Exynos4210 board

[Tim Kryger]

On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
> On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>> On 06/19/2014 07:40 PM, Sachin Kamat wrote:
>>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>>>
>>>>>>>>> I see the below error on Exynos4210 based Origen board with linux-next
>>>>>>>>> (20140618).
>>>>>>>>> Reverting the below commit works fine.
>>>>>>>>>
>>>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>>>>>>
>>>>>>>>>
>>>>>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>>>>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>>>>>>>> (50000000 Hz)
>>>>>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>>>>>>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>>>>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>>>>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>>>>>>>> (16666667 Hz)
>>>>>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>>>>>>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>>>>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>>>>>>
>>>>>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>>>>>
>>>>>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
>>>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.
>>>>>>
>>>>>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
>>>>>> | MMC_VDD_28_29.
>>>>>>
>>>>>> The SDHCI capabilities register only indicates support of three voltage levels
>>>>>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>>>>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>>>>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>>
>> Right. sdhci capabilities only indicated them.
>> But I think SoC can be support the specific VDD range.
>>
>>>>>>
>>>>>> Even if all capability bits of the host controller were set, there
>>>>>> still wouldn't be any overlap.  Thus you see a "Hardware doesn't
>>>>>> report any support voltages" message.
>>>>>>
>>>>>> Previously, this issue was being swept under the rug by cec2e21 mmc:
>>>>>> sdhci: Use regulator min/max voltage range according to spec.  That
>>>>>> change hacked up the voltage range checks such that with your 2.8v
>>>>>> fixed regulator, the driver would believe the host could support
>>>>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
>>>>>> driver would start down the path of commanding 3.3v-3.4v (the highest
>>>>>> voltage range believed to be supported).  At the last second, the
>>>>>> driver would see the regulator was fixed and blindly skip over the set
>>>>>> voltage operation, saving it from failure.
>>>>>>
>>>>>> Since my patch eliminates the bogus voltage range checks, your board
>>>>>> is now getting caught playing too loose with the SDHCI regulator
>>>>>> voltages.
>>>>>>
>>>>>> Furthermore, the fixed regulator special-case logic that helped hide
>>>>>> your issue should also be considered for removal given that fixed
>>>>>> regulators now behave properly thanks to c00dc35 regulator: core:
>>>>>> Allow regulator_set_voltage for fixed regulators.
>>>>>
>>>>> Thanks for the detailed explanation. What do you propose to get this fixed

>>>> It would be nice if the driver could be extended
>>>> to handle the peculiarities of your board in a deliberate manner but
>>>> limiting the common sdhci driver to supporting only the three voltages
>>>> from the spec also seems sensible.
>>>
>>> Until such time that the driver gets fixed to handle 2.8V fixed supply your
>>> current patch leaves several of Exynos boards broken for now.
>>
>> the all of exynos used the fixed-regulator(2.8v) should be broken.
>> (Maybe exynos4 series??)
>
> Probably. I haven't verified for the other boards. Hence would be good to handle
> this case in the driver itself.

The current external VDD regulator support in the SDHCI driver feels a
bit tacked on.

External regulators could reasonably support other voltage ranges,
like MMC_VDD_27_28 | MMC_VDD_28_29, but those never appear in the
final ocr_avail for the host. The driver only looks for the
intersection of the ranges implied by the capabilities register and
those of the external regulator.

Later, when it comes time to set a voltage, the driver will BUG if it
can't translate the requested voltage into one of the three voltage
levels supported by the SDHCI Power Control register.

I wonder if it is really necessary to constrain the driver this way.
It seems like if we are using an external regulator, the capabilities
of the host controller itself are irrelevant.  Also, must we touch the
Power Control register if we are using an external regulator?  I would
think not.

Can you give the following patch a try and see if it resolves the
issue you observed?

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c23a872..07a2426 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1226,6 +1226,13 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned char mode,
  struct mmc_host *mmc = host->mmc;
  u8 pwr = 0;

+ if (!IS_ERR(mmc->supply.vmmc)) {
+ spin_unlock_irq(&host->lock);
+ mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(&host->lock);
+ return;
+ }
+
  if (mode != MMC_POWER_OFF) {
  switch (1 << vdd) {
  case MMC_VDD_165_195:
@@ -1284,12 +1291,6 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned char mode,
  if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
  mdelay(10);
  }
-
- if (!IS_ERR(mmc->supply.vmmc)) {
- spin_unlock_irq(&host->lock);
- mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
- spin_lock_irq(&host->lock);
- }
 }

 /*****************************************************************************\
@@ -3092,8 +3093,9 @@ int sdhci_add_host(struct sdhci_host *host)
    SDHCI_MAX_CURRENT_MULTIPLIER;
  }

+ /* If OCR set by external regulators, use it instead */
  if (mmc->ocr_avail)
- ocr_avail &= mmc->ocr_avail;
+ ocr_avail = mmc->ocr_avail;

  if (host->ocr_mask)
  ocr_avail &= host->ocr_mask;

Re: MMC error on Exynos4210 board

[Sachin Kamat]

Hi Tim,

On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger <tim.kryger@gmail.com> wrote:
> On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>> On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>>> On 06/19/2014 07:40 PM, Sachin Kamat wrote:
>>>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@gmail.com> wrote:
>>>>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@gmail.com> wrote:
>>>>>>>
>>>>>>>>>> I see the below error on Exynos4210 based Origen board with linux-next
>>>>>>>>>> (20140618).
>>>>>>>>>> Reverting the below commit works fine.
>>>>>>>>>>
>>>>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture"
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller Interface driver
>>>>>>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>>>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2: mmc_busclk.2
>>>>>>>>>> (50000000 Hz)
>>>>>>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator found
>>>>>>>>>> [    2.118117] mmc0: Hardware doesn't report any support voltages.
>>>>>>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host() failed
>>>>>>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2
>>>>>>>>>> (16666667 Hz)
>>>>>>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios property of
>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator found
>>>>>>>>>> [    2.168464] mmc0: Hardware doesn't report any support voltages.
>>>>>>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
>>>>>>>
>>>>>>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>>>>>>
>>>>>>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC.
>>>>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details.
>>>>>>>
>>>>>>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28
>>>>>>> | MMC_VDD_28_29.
>>>>>>>
>>>>>>> The SDHCI capabilities register only indicates support of three voltage levels
>>>>>>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>>>>>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>>>>>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>>>
>>> Right. sdhci capabilities only indicated them.
>>> But I think SoC can be support the specific VDD range.
>>>
>>>>>>>
>>>>>>> Even if all capability bits of the host controller were set, there
>>>>>>> still wouldn't be any overlap.  Thus you see a "Hardware doesn't
>>>>>>> report any support voltages" message.
>>>>>>>
>>>>>>> Previously, this issue was being swept under the rug by cec2e21 mmc:
>>>>>>> sdhci: Use regulator min/max voltage range according to spec.  That
>>>>>>> change hacked up the voltage range checks such that with your 2.8v
>>>>>>> fixed regulator, the driver would believe the host could support
>>>>>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.  The
>>>>>>> driver would start down the path of commanding 3.3v-3.4v (the highest
>>>>>>> voltage range believed to be supported).  At the last second, the
>>>>>>> driver would see the regulator was fixed and blindly skip over the set
>>>>>>> voltage operation, saving it from failure.
>>>>>>>
>>>>>>> Since my patch eliminates the bogus voltage range checks, your board
>>>>>>> is now getting caught playing too loose with the SDHCI regulator
>>>>>>> voltages.
>>>>>>>
>>>>>>> Furthermore, the fixed regulator special-case logic that helped hide
>>>>>>> your issue should also be considered for removal given that fixed
>>>>>>> regulators now behave properly thanks to c00dc35 regulator: core:
>>>>>>> Allow regulator_set_voltage for fixed regulators.
>>>>>>
>>>>>> Thanks for the detailed explanation. What do you propose to get this fixed
>
>>>>> It would be nice if the driver could be extended
>>>>> to handle the peculiarities of your board in a deliberate manner but
>>>>> limiting the common sdhci driver to supporting only the three voltages
>>>>> from the spec also seems sensible.
>>>>
>>>> Until such time that the driver gets fixed to handle 2.8V fixed supply your
>>>> current patch leaves several of Exynos boards broken for now.
>>>
>>> the all of exynos used the fixed-regulator(2.8v) should be broken.
>>> (Maybe exynos4 series??)
>>
>> Probably. I haven't verified for the other boards. Hence would be good to handle
>> this case in the driver itself.
>
> The current external VDD regulator support in the SDHCI driver feels a
> bit tacked on.
>
> External regulators could reasonably support other voltage ranges,
> like MMC_VDD_27_28 | MMC_VDD_28_29, but those never appear in the
> final ocr_avail for the host. The driver only looks for the
> intersection of the ranges implied by the capabilities register and
> those of the external regulator.
>
> Later, when it comes time to set a voltage, the driver will BUG if it
> can't translate the requested voltage into one of the three voltage
> levels supported by the SDHCI Power Control register.
>
> I wonder if it is really necessary to constrain the driver this way.
> It seems like if we are using an external regulator, the capabilities
> of the host controller itself are irrelevant.  Also, must we touch the
> Power Control register if we are using an external regulator?  I would
> think not.

You argument above seems reasonable.

>
> Can you give the following patch a try and see if it resolves the
> issue you observed?
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index c23a872..07a2426 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1226,6 +1226,13 @@ static void sdhci_set_power(struct sdhci_host
> *host, unsigned char mode,
>   struct mmc_host *mmc = host->mmc;
>   u8 pwr = 0;
>
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> + return;
> + }
> +
>   if (mode != MMC_POWER_OFF) {
>   switch (1 << vdd) {
>   case MMC_VDD_165_195:
> @@ -1284,12 +1291,6 @@ static void sdhci_set_power(struct sdhci_host
> *host, unsigned char mode,
>   if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
>   mdelay(10);
>   }
> -
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
>  }
>
>  /*****************************************************************************\
> @@ -3092,8 +3093,9 @@ int sdhci_add_host(struct sdhci_host *host)
>     SDHCI_MAX_CURRENT_MULTIPLIER;
>   }
>
> + /* If OCR set by external regulators, use it instead */
>   if (mmc->ocr_avail)
> - ocr_avail &= mmc->ocr_avail;
> + ocr_avail = mmc->ocr_avail;
>
>   if (host->ocr_mask)
>   ocr_avail &= host->ocr_mask;

I can confirm that the above patch fixes the reported issue on
Exynos4210 and 4412
based origen boards that I have. Thanks for the fix.

-- 
Regards,
Sachin.

Re: MMC error on Exynos4210 board

[Ulf Hansson]

On 23 juni 2014 06:30:08 CEST, Sachin Kamat <spk.linux@gmail.com> wrote:
>Hi Tim,
>
>On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger <tim.kryger@gmail.com>
>wrote:
>> On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat <spk.linux@gmail.com>
>wrote:
>>> On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung
><jh80.chung@samsung.com> wrote:
>>>> On 06/19/2014 07:40 PM, Sachin Kamat wrote:
>>>>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@gmail.com>
>wrote:
>>>>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat
><spk.linux@gmail.com> wrote:
>>>>>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger
><tim.kryger@gmail.com> wrote:
>>>>>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat
><spk.linux@gmail.com> wrote:
>>>>>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat
><spk.linux@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>>> I see the below error on Exynos4210 based Origen board with
>linux-next
>>>>>>>>>>> (20140618).
>>>>>>>>>>> Reverting the below commit works fine.
>>>>>>>>>>>
>>>>>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator
>infrastucture"
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller
>Interface driver
>>>>>>>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>>>>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios
>property of
>>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2:
>mmc_busclk.2
>>>>>>>>>>> (50000000 Hz)
>>>>>>>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios
>property of
>>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios
>property of
>>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator
>found
>>>>>>>>>>> [    2.118117] mmc0: Hardware doesn't report any support
>voltages.
>>>>>>>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host()
>failed
>>>>>>>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios
>property of
>>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2:
>mmc_busclk.2
>>>>>>>>>>> (16666667 Hz)
>>>>>>>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios
>property of
>>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios
>property of
>>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator
>found
>>>>>>>>>>> [    2.168464] mmc0: Hardware doesn't report any support
>voltages.
>>>>>>>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host()
>failed
>>>>>>>>
>>>>>>>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>>>>>>>
>>>>>>>>> FYI, the board has a 2.8V fixed regulator supply connected to
>the MMC.
>>>>>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for
>more details.
>>>>>>>>
>>>>>>>> A 2.8v regulator results in mmc->ocr_avail being set to
>MMC_VDD_27_28
>>>>>>>> | MMC_VDD_28_29.
>>>>>>>>
>>>>>>>> The SDHCI capabilities register only indicates support of three
>voltage levels
>>>>>>>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>>>>>>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>>>>>>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>>>>
>>>> Right. sdhci capabilities only indicated them.
>>>> But I think SoC can be support the specific VDD range.
>>>>
>>>>>>>>
>>>>>>>> Even if all capability bits of the host controller were set,
>there
>>>>>>>> still wouldn't be any overlap.  Thus you see a "Hardware
>doesn't
>>>>>>>> report any support voltages" message.
>>>>>>>>
>>>>>>>> Previously, this issue was being swept under the rug by cec2e21
>mmc:
>>>>>>>> sdhci: Use regulator min/max voltage range according to spec. 
>That
>>>>>>>> change hacked up the voltage range checks such that with your
>2.8v
>>>>>>>> fixed regulator, the driver would believe the host could
>support
>>>>>>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. 
>The
>>>>>>>> driver would start down the path of commanding 3.3v-3.4v (the
>highest
>>>>>>>> voltage range believed to be supported).  At the last second,
>the
>>>>>>>> driver would see the regulator was fixed and blindly skip over
>the set
>>>>>>>> voltage operation, saving it from failure.
>>>>>>>>
>>>>>>>> Since my patch eliminates the bogus voltage range checks, your
>board
>>>>>>>> is now getting caught playing too loose with the SDHCI
>regulator
>>>>>>>> voltages.
>>>>>>>>
>>>>>>>> Furthermore, the fixed regulator special-case logic that helped
>hide
>>>>>>>> your issue should also be considered for removal given that
>fixed
>>>>>>>> regulators now behave properly thanks to c00dc35 regulator:
>core:
>>>>>>>> Allow regulator_set_voltage for fixed regulators.
>>>>>>>
>>>>>>> Thanks for the detailed explanation. What do you propose to get
>this fixed
>>
>>>>>> It would be nice if the driver could be extended
>>>>>> to handle the peculiarities of your board in a deliberate manner
>but
>>>>>> limiting the common sdhci driver to supporting only the three
>voltages
>>>>>> from the spec also seems sensible.
>>>>>
>>>>> Until such time that the driver gets fixed to handle 2.8V fixed
>supply your
>>>>> current patch leaves several of Exynos boards broken for now.
>>>>
>>>> the all of exynos used the fixed-regulator(2.8v) should be broken.
>>>> (Maybe exynos4 series??)
>>>
>>> Probably. I haven't verified for the other boards. Hence would be
>good to handle
>>> this case in the driver itself.
>>
>> The current external VDD regulator support in the SDHCI driver feels
>a
>> bit tacked on.
>>
>> External regulators could reasonably support other voltage ranges,
>> like MMC_VDD_27_28 | MMC_VDD_28_29, but those never appear in the
>> final ocr_avail for the host. The driver only looks for the
>> intersection of the ranges implied by the capabilities register and
>> those of the external regulator.
>>
>> Later, when it comes time to set a voltage, the driver will BUG if it
>> can't translate the requested voltage into one of the three voltage
>> levels supported by the SDHCI Power Control register.
>>
>> I wonder if it is really necessary to constrain the driver this way.
>> It seems like if we are using an external regulator, the capabilities
>> of the host controller itself are irrelevant.  Also, must we touch
>the
>> Power Control register if we are using an external regulator?  I
>would
>> think not.
>
>You argument above seems reasonable.
>
>>
>> Can you give the following patch a try and see if it resolves the
>> issue you observed?
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index c23a872..07a2426 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1226,6 +1226,13 @@ static void sdhci_set_power(struct sdhci_host
>> *host, unsigned char mode,
>>   struct mmc_host *mmc = host->mmc;
>>   u8 pwr = 0;
>>
>> + if (!IS_ERR(mmc->supply.vmmc)) {
>> + spin_unlock_irq(&host->lock);
>> + mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
>> + spin_lock_irq(&host->lock);
>> + return;
>> + }
>> +
>>   if (mode != MMC_POWER_OFF) {
>>   switch (1 << vdd) {
>>   case MMC_VDD_165_195:
>> @@ -1284,12 +1291,6 @@ static void sdhci_set_power(struct sdhci_host
>> *host, unsigned char mode,
>>   if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
>>   mdelay(10);
>>   }
>> -
>> - if (!IS_ERR(mmc->supply.vmmc)) {
>> - spin_unlock_irq(&host->lock);
>> - mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
>> - spin_lock_irq(&host->lock);
>> - }
>>  }
>>
>> 
>/*****************************************************************************\
>> @@ -3092,8 +3093,9 @@ int sdhci_add_host(struct sdhci_host *host)
>>     SDHCI_MAX_CURRENT_MULTIPLIER;
>>   }
>>
>> + /* If OCR set by external regulators, use it instead */
>>   if (mmc->ocr_avail)
>> - ocr_avail &= mmc->ocr_avail;
>> + ocr_avail = mmc->ocr_avail;
>>
>>   if (host->ocr_mask)
>>   ocr_avail &= host->ocr_mask;
>
>I can confirm that the above patch fixes the reported issue on
>Exynos4210 and 4412
>based origen boards that I have. Thanks for the fix.

Hi Tim/Sachin,

Great that you seemed to have work out issues. Could you please resend a the patch in proper format, thus I can apply it as a fix for 3.16.

Kind regards
Uffe

Re: MMC error on Exynos4210 board

[Tim Kryger]

Sure thing.  I'll try to get it sent out later today.

-Tim

On Tue, Jun 24, 2014 at 4:11 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
>
> On 23 juni 2014 06:30:08 CEST, Sachin Kamat <spk.linux@gmail.com> wrote:
>>Hi Tim,
>>
>>On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger <tim.kryger@gmail.com>
>>wrote:
>>> On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat <spk.linux@gmail.com>
>>wrote:
>>>> On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung
>><jh80.chung@samsung.com> wrote:
>>>>> On 06/19/2014 07:40 PM, Sachin Kamat wrote:
>>>>>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@gmail.com>
>>wrote:
>>>>>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat
>><spk.linux@gmail.com> wrote:
>>>>>>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger
>><tim.kryger@gmail.com> wrote:
>>>>>>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat
>><spk.linux@gmail.com> wrote:
>>>>>>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat
>><spk.linux@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>>> I see the below error on Exynos4210 based Origen board with
>>linux-next
>>>>>>>>>>>> (20140618).
>>>>>>>>>>>> Reverting the below commit works fine.
>>>>>>>>>>>>
>>>>>>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator
>>infrastucture"
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -- [    2.068992] sdhci: Secure Digital Host Controller
>>Interface driver
>>>>>>>>>>>> [    2.075059] sdhci: Copyright(c) Pierre Ossman
>>>>>>>>>>>> [    2.079762] of_get_named_gpiod_flags: can't parse gpios
>>property of
>>>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>>>> [    2.088021] s3c-sdhci 12510000.sdhci: clock source 2:
>>mmc_busclk.2
>>>>>>>>>>>> (50000000 Hz)
>>>>>>>>>>>> [    2.095322] of_get_named_gpiod_flags: can't parse gpios
>>property of
>>>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>>>> [    2.103794] of_get_named_gpiod_flags: can't parse gpios
>>property of
>>>>>>>>>>>> node '/sdhci@12510000[0]'
>>>>>>>>>>>> [    2.112478] s3c-sdhci 12510000.sdhci: No vqmmc regulator
>>found
>>>>>>>>>>>> [    2.118117] mmc0: Hardware doesn't report any support
>>voltages.
>>>>>>>>>>>> [    2.124004] s3c-sdhci 12510000.sdhci: sdhci_add_host()
>>failed
>>>>>>>>>>>> [    2.130080] of_get_named_gpiod_flags: can't parse gpios
>>property of
>>>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>>>> [    2.138352] s3c-sdhci 12530000.sdhci: clock source 2:
>>mmc_busclk.2
>>>>>>>>>>>> (16666667 Hz)
>>>>>>>>>>>> [    2.145661] of_get_named_gpiod_flags: can't parse gpios
>>property of
>>>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>>>> [    2.154139] of_get_named_gpiod_flags: can't parse gpios
>>property of
>>>>>>>>>>>> node '/sdhci@12530000[0]'
>>>>>>>>>>>> [    2.162834] s3c-sdhci 12530000.sdhci: No vqmmc regulator
>>found
>>>>>>>>>>>> [    2.168464] mmc0: Hardware doesn't report any support
>>voltages.
>>>>>>>>>>>> [    2.174349] s3c-sdhci 12530000.sdhci: sdhci_add_host()
>>failed
>>>>>>>>>
>>>>>>>>>>>> [    2.336148] Waiting for root device /dev/mmcblk0p1...
>>>>>>>>>
>>>>>>>>>> FYI, the board has a 2.8V fixed regulator supply connected to
>>the MMC.
>>>>>>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for
>>more details.
>>>>>>>>>
>>>>>>>>> A 2.8v regulator results in mmc->ocr_avail being set to
>>MMC_VDD_27_28
>>>>>>>>> | MMC_VDD_28_29.
>>>>>>>>>
>>>>>>>>> The SDHCI capabilities register only indicates support of three
>>voltage levels
>>>>>>>>>   - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195
>>>>>>>>>   - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31
>>>>>>>>>   - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34
>>>>>
>>>>> Right. sdhci capabilities only indicated them.
>>>>> But I think SoC can be support the specific VDD range.
>>>>>
>>>>>>>>>
>>>>>>>>> Even if all capability bits of the host controller were set,
>>there
>>>>>>>>> still wouldn't be any overlap.  Thus you see a "Hardware
>>doesn't
>>>>>>>>> report any support voltages" message.
>>>>>>>>>
>>>>>>>>> Previously, this issue was being swept under the rug by cec2e21
>>mmc:
>>>>>>>>> sdhci: Use regulator min/max voltage range according to spec.
>>That
>>>>>>>>> change hacked up the voltage range checks such that with your
>>2.8v
>>>>>>>>> fixed regulator, the driver would believe the host could
>>support
>>>>>>>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34.
>>The
>>>>>>>>> driver would start down the path of commanding 3.3v-3.4v (the
>>highest
>>>>>>>>> voltage range believed to be supported).  At the last second,
>>the
>>>>>>>>> driver would see the regulator was fixed and blindly skip over
>>the set
>>>>>>>>> voltage operation, saving it from failure.
>>>>>>>>>
>>>>>>>>> Since my patch eliminates the bogus voltage range checks, your
>>board
>>>>>>>>> is now getting caught playing too loose with the SDHCI
>>regulator
>>>>>>>>> voltages.
>>>>>>>>>
>>>>>>>>> Furthermore, the fixed regulator special-case logic that helped
>>hide
>>>>>>>>> your issue should also be considered for removal given that
>>fixed
>>>>>>>>> regulators now behave properly thanks to c00dc35 regulator:
>>core:
>>>>>>>>> Allow regulator_set_voltage for fixed regulators.
>>>>>>>>
>>>>>>>> Thanks for the detailed explanation. What do you propose to get
>>this fixed
>>>
>>>>>>> It would be nice if the driver could be extended
>>>>>>> to handle the peculiarities of your board in a deliberate manner
>>but
>>>>>>> limiting the common sdhci driver to supporting only the three
>>voltages
>>>>>>> from the spec also seems sensible.
>>>>>>
>>>>>> Until such time that the driver gets fixed to handle 2.8V fixed
>>supply your
>>>>>> current patch leaves several of Exynos boards broken for now.
>>>>>
>>>>> the all of exynos used the fixed-regulator(2.8v) should be broken.
>>>>> (Maybe exynos4 series??)
>>>>
>>>> Probably. I haven't verified for the other boards. Hence would be
>>good to handle
>>>> this case in the driver itself.
>>>
>>> The current external VDD regulator support in the SDHCI driver feels
>>a
>>> bit tacked on.
>>>
>>> External regulators could reasonably support other voltage ranges,
>>> like MMC_VDD_27_28 | MMC_VDD_28_29, but those never appear in the
>>> final ocr_avail for the host. The driver only looks for the
>>> intersection of the ranges implied by the capabilities register and
>>> those of the external regulator.
>>>
>>> Later, when it comes time to set a voltage, the driver will BUG if it
>>> can't translate the requested voltage into one of the three voltage
>>> levels supported by the SDHCI Power Control register.
>>>
>>> I wonder if it is really necessary to constrain the driver this way.
>>> It seems like if we are using an external regulator, the capabilities
>>> of the host controller itself are irrelevant.  Also, must we touch
>>the
>>> Power Control register if we are using an external regulator?  I
>>would
>>> think not.
>>
>>You argument above seems reasonable.
>>
>>>
>>> Can you give the following patch a try and see if it resolves the
>>> issue you observed?
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index c23a872..07a2426 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -1226,6 +1226,13 @@ static void sdhci_set_power(struct sdhci_host
>>> *host, unsigned char mode,
>>>   struct mmc_host *mmc = host->mmc;
>>>   u8 pwr = 0;
>>>
>>> + if (!IS_ERR(mmc->supply.vmmc)) {
>>> + spin_unlock_irq(&host->lock);
>>> + mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
>>> + spin_lock_irq(&host->lock);
>>> + return;
>>> + }
>>> +
>>>   if (mode != MMC_POWER_OFF) {
>>>   switch (1 << vdd) {
>>>   case MMC_VDD_165_195:
>>> @@ -1284,12 +1291,6 @@ static void sdhci_set_power(struct sdhci_host
>>> *host, unsigned char mode,
>>>   if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
>>>   mdelay(10);
>>>   }
>>> -
>>> - if (!IS_ERR(mmc->supply.vmmc)) {
>>> - spin_unlock_irq(&host->lock);
>>> - mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
>>> - spin_lock_irq(&host->lock);
>>> - }
>>>  }
>>>
>>>
>>/*****************************************************************************\
>>> @@ -3092,8 +3093,9 @@ int sdhci_add_host(struct sdhci_host *host)
>>>     SDHCI_MAX_CURRENT_MULTIPLIER;
>>>   }
>>>
>>> + /* If OCR set by external regulators, use it instead */
>>>   if (mmc->ocr_avail)
>>> - ocr_avail &= mmc->ocr_avail;
>>> + ocr_avail = mmc->ocr_avail;
>>>
>>>   if (host->ocr_mask)
>>>   ocr_avail &= host->ocr_mask;
>>
>>I can confirm that the above patch fixes the reported issue on
>>Exynos4210 and 4412
>>based origen boards that I have. Thanks for the fix.
>
> Hi Tim/Sachin,
>
> Great that you seemed to have work out issues. Could you please resend a the patch in proper format, thus I can apply it as a fix for 3.16.
>
> Kind regards
> Uffe
>