Thread (43 messages) 43 messages, 6 authors, 2014-10-01
STALE4292d

[PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

From: Doug Anderson <hidden>
Date: 2014-08-28 15:50:25
Also in: linux-mmc, linux-samsung-soc

Ulf,

On Thu, Aug 28, 2014 at 12:25 AM, Ulf Hansson [off-list ref] wrote:
On 27 August 2014 17:52, Doug Anderson [off-list ref] wrote:
quoted
Ulf,

On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson [off-list ref] wrote:
quoted
quoted
Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be
called to check the card detect line, but with vmmc and vqmmc off.  It
will be unable to return a sensible value without actually turning on
vmmc and vqmmc.
Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule
itself with HZ interval. This to check for card insert/removal.

Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback
to check whether it's worth to continue initialization sequence or if
it should re-schedule itself again.

If your host driver can distinguish whether a card is inserted, which
in this case are when vccq is turned off, your ->get_cd() callback need
to return 1. That will allow mmc_rescan() to continue it's
initialization sequence and do mmc_power_up().
As per my other email, we can't tell whether a card is inserted when
vqmmc is off.
I understand.

The solution I proposed above, is:

1) Enable MMC_CAP_NEEDS_POLL.
2) Make ->get_cd() return 1, when you can't distinguish if the card is inserted.

That will solve this issue and without messing up the mmc core.
Ah, I see!  So every 1 second, we'll do the following:

1. Call get_cd(), which returns 1.

2. MMC core will power everything up (turn on all regulators) for MMC.

3. We'll start to initialize a card.

4. We'll notice that, oops, there's no card there.

5. MMC core will shut things down again.


That seems awfully expensive to do every second when the card detect
line actually does work (as long as you keep power lines).  Is the
patch to separate out the concepts of "power off because no card is
inserted" and "power off because we're power cycling the card" really
bad enough to warrant forcing us to use the above?

I'm not an EE, but cycling regulators on and off every second doesn't
seem super ideal, but maybe they're designed for it?


Personally, I'd be tempted to just leave the power on all the time and
if a card somehow needs to be power cycled (because UHS negotiation
failed?) then that card just isn't supported.  This could be done in
the dts by saying that the regulator is "always on" and no need to
pollute any source files.


-Doug
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help