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-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
