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: Ulf Hansson <hidden>
Date: 2014-08-28 07:25:55
Also in: linux-mmc, linux-samsung-soc

On 27 August 2014 17:52, Doug Anderson [off-list ref] wrote:
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.
Does this mean that you have removed your objections to a solution
like Yuvaraj has posted?  We still need to break it into two patches
(the core part and the dwmmc part), but otherwise is it OK?  I can
post the original patch I sent Yuvaraj if it's helpful (or he can just
include my patch as part 1 of his series).
No. This can entirely be fixed in the host driver. As suggested above.

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