Re: MMC error on Exynos4210 board

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung <jh80.chung@xxxxxxxxxxx> wrote:
> On 06/19/2014 07:40 PM, Sachin Kamat wrote:
>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger <tim.kryger@xxxxxxxxx> wrote:
>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat <spk.linux@xxxxxxxxx> wrote:
>>>> +cc Some relevant guys from Samsung
>>>>
>>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger <tim.kryger@xxxxxxxxx> wrote:
>>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat <spk.linux@xxxxxxxxx> wrote:
>>>>>
>>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat <spk.linux@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux