From: jh80.chung@samsung.com (Jaehoon Chung)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc
Date: Wed, 27 Aug 2014 12:55:09 +0900 [thread overview]
Message-ID: <53FD569D.60002@samsung.com> (raw)
In-Reply-To: <CAD=FV=VQWzhiSU+iULACj+Dp_tDf3SszQ8ELLEGqVEyJJRQy1Q@mail.gmail.com>
Hi.
On 08/26/2014 12:20 AM, Doug Anderson wrote:
> Ulf,
>
> On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote:
>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote:
>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card
>>>>> detection.But unfortunately CD# line is on the same voltage rails
>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card
>>>>> detection will break in these boards.
>>>>
>>>> I am not sure I follow here.
>>>>
>>>> Is the card detect mechanism handled internally by the dw_mmc controller?
>>>
>>> Yes
>>
>> Just out of curiosity.
>>
>> Do you know how the power to the actual dw_mmc controller is handled?
>> I expect it to be SoC specific and I am guessing power domain
>> regulators may be involved!?
>
> You can likely read the dw_mmc registers when vqmmc is off. Is that
> what you're asking? Certainly if vqmmc is not powered then the lines
> themselves will be useless, won't they? The "vqmmc" supply goes to
> the "VDDQ_MMC2" pin on 5420. In my 5420 user manual, I see that
> "clk", "cmd", "cd", "datN", "wp" and "biuvr" pins are all in this same
> voltage (VDDQ_MMC2) domain. Can you really read a pin without
> powering that part of the SoC?
It's not correct.
At TRM, described as same voltage domain. But CD-pin is used with "always-on" power.
In circuit, CD# pin is disconnected.
>
>
>>>> I thought HW engineers long time ago realized that this should be done
>>>> separately on a GPIO line to be able to save power while waiting for a
>>>> card to be inserted. But that's not case then?
>>>
>>> At least in my limited experience, this seems to be common among SoC
>>> vendors who are using dw_mmc, as we've seen this elsewhere as well and
>>> after seeing it here we know that we need to ignore the CD pin that's
>>> routed to dw_mmc and use a separately powered GPIO on the board, but
>>> still there are probably many SoCs/boards which are doing it this way.
>>>
>>>>>
>>>>> These hosts (obviously) need to keep vqmmc (and thus vmmc) on all the
>>>>> time, even when the mmc core tells them to power off. However, one
>>>>> problem is that these cards won't properly handle mmc_power_cycle().
>>>>> That's needed to handle error cases when trying to switch voltages
>>>>> (see 0797e5f mmc:core: Fixup signal voltage switch).
>>>>>
>>>>> This patch adds a new MMC_POWER_OFF_HARD mode when it's doing a power
>>>>> cycle. This mode differs from the normal MMC_POWER_OFF mode in that
>>>>> the mmc core will promise to power the slot back on before it expects
>>>>> the host to detect card insertion or removal.
>>>
>>> This patch is based off of one that Doug wrote (sent privately to
>>> Yuvaraj) which just modifies the MMC core, and should be split into
>>> two patches.
>>> One that modifies the mmc core and one that implements this in dw_mmc.
>>
>> I looked at the mmc core parts, it seems like the wrong approach.
>>
>> I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this
>> broken card detect mechanism. We even have a DT binding for that,
>> "broken-cd".
>
> I don't think this is possible, but let me explain why I think so and
> you can correct me.
Exynos series is using the external gpio-cd concept. So it need not to use MMC_CAP_NEEDS_POLL.
Can use the slot-gpio API. In my exynos5 board, it's working fine with the slot-gpio API.
Best Regards,
Jaehoon Chung
>
> The voltage domain of the "card detect" pin on the SoC is vqmmc,
> right? That means that you won't be able to read the pin without
> turning on vqmmc. Even if you could read the pin without turning on
> vqmmc, the pullup on this line is connected to vqmmc too. ...so if
> vqmmc is off then there's no pulup and you can't use card detect.
>
> Are you suggesting that we should flip the voltage of vqmmc (and thus
> vmmc to prevent damaging the card) during polling? That seems ugly.
>
>
> One other thing to mention: we didn't find any power savings by
> actually turning off vmmc and vqmmc when there was no card inserted.
> There's no current running through the lines when there is no card
> inserted and apparently everything is efficient enough that there was
> no problem.
>
> -Doug
>
prev parent reply other threads:[~2014-08-27 3:55 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 13:47 [PATCH V2 0/3] Adding UHS support for dw_mmc driver Yuvaraj Kumar C D
2014-08-22 13:47 ` [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators Yuvaraj Kumar C D
2014-08-25 12:32 ` Jaehoon Chung
2014-08-25 15:06 ` Doug Anderson
2014-08-29 11:34 ` Ulf Hansson
2014-09-29 12:31 ` Bartlomiej Zolnierkiewicz
2014-09-30 5:23 ` Jaehoon Chung
2014-10-01 13:57 ` Bartlomiej Zolnierkiewicz
2014-10-01 14:14 ` Bartlomiej Zolnierkiewicz
2014-09-30 17:22 ` Doug Anderson
2014-10-01 13:06 ` Bartlomiej Zolnierkiewicz
2014-10-01 15:38 ` Doug Anderson
2014-08-22 13:47 ` [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes Yuvaraj Kumar C D
2014-08-22 15:35 ` Ulf Hansson
2014-08-22 20:38 ` Doug Anderson
2014-08-25 8:31 ` Ulf Hansson
2014-08-25 20:59 ` Doug Anderson
2014-08-29 11:43 ` Ulf Hansson
2014-09-29 12:49 ` Bartlomiej Zolnierkiewicz
2014-08-22 13:47 ` [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc Yuvaraj Kumar C D
2014-08-22 15:31 ` Ulf Hansson
2014-08-22 18:27 ` Sonny Rao
2014-08-25 8:13 ` Ulf Hansson
2014-08-25 8:50 ` Jaehoon Chung
2014-08-25 15:25 ` Doug Anderson
2014-08-27 3:48 ` Jaehoon Chung
2014-08-27 4:14 ` Doug Anderson
2014-08-27 4:47 ` Jaehoon Chung
2014-08-27 15:49 ` Doug Anderson
2014-08-28 4:54 ` Yuvaraj Kumar
2014-08-28 8:43 ` Jaehoon Chung
2014-08-28 15:52 ` Doug Anderson
2014-08-25 15:20 ` Doug Anderson
2014-08-26 7:37 ` Ulf Hansson
2014-08-26 20:32 ` Doug Anderson
2014-08-27 11:17 ` Ulf Hansson
2014-08-27 11:20 ` Ulf Hansson
2014-08-27 15:52 ` Doug Anderson
2014-08-28 7:25 ` Ulf Hansson
2014-08-28 15:50 ` Doug Anderson
2014-08-28 17:50 ` Sonny Rao
2014-08-29 4:08 ` Doug Anderson
2014-08-27 3:55 ` Jaehoon Chung [this message]
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=53FD569D.60002@samsung.com \
--to=jh80.chung@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).