On 27 August 2014 17:52, Doug Anderson <dianders@xxxxxxxxxx> wrote: > Ulf, > > On Wed, Aug 27, 2014 at 4:17 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |