[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