All of lore.kernel.org
 help / color / mirror / Atom feed
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??)

> 

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.