From: Jaehoon Chung <jh80.chung@samsung.com>
To: Sachin Kamat <spk.linux@gmail.com>, Tim Kryger <tim.kryger@gmail.com>
Cc: Markus Mayer <markus.mayer@linaro.org>,
Matt Porter <mporter@linaro.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-mmc <linux-mmc@vger.kernel.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
Yuvaraj C D <yuvaraj.cd@samsung.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
"tgih.jun@samsung.com" <tgih.jun@samsung.com>
Subject: Re: MMC error on Exynos4210 board
Date: Thu, 19 Jun 2014 21:41:58 +0900 [thread overview]
Message-ID: <53A2DA96.3070500@samsung.com> (raw)
In-Reply-To: <CAK5sBcF=5NYd-tuvRrQk7Yq_r_oUYftpNuHcz7iJ8TGNWkG0iA@mail.gmail.com>
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??)
>
next prev parent reply other threads:[~2014-06-19 12:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 11:33 MMC error on Exynos4210 board Sachin Kamat
2014-06-18 14:11 ` Tim Kryger
2014-06-19 3:54 ` Sachin Kamat
2014-06-19 8:42 ` Tim Kryger
2014-06-19 8:49 ` Sachin Kamat
2014-06-19 9:10 ` Tim Kryger
2014-06-19 10:40 ` Sachin Kamat
2014-06-19 12:41 ` Jaehoon Chung [this message]
2014-06-20 3:33 ` Sachin Kamat
2014-06-20 21:01 ` Tim Kryger
2014-06-23 4:30 ` Sachin Kamat
2014-06-24 11:11 ` Ulf Hansson
2014-06-24 13:49 ` Tim Kryger
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=53A2DA96.3070500@samsung.com \
--to=jh80.chung@samsung.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=markus.mayer@linaro.org \
--cc=mporter@linaro.org \
--cc=spk.linux@gmail.com \
--cc=tgih.jun@samsung.com \
--cc=tim.kryger@gmail.com \
--cc=ulf.hansson@linaro.org \
--cc=yuvaraj.cd@samsung.com \
/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