Re: [RFC PATCH] mmc: Enable wakeup_sources for mmc core

[Colin Cross]

On Fri, Jun 14, 2013 at 11:42 AM, Zoran Markovic
<zoran.markovic@xxxxxxxxxx> wrote:
>> I am not sure I understand why this patch is needed. When a new card
>> is inserted/removed and the upper levels gets notification about the
>> new card, triggering the mounting/un-mounting of the file system, why
>> should it be the lowest layer (mmc) that prevents the platform from
>> enter suspend/sleep? Why do we need to prevent it at all?
>>
>> Note that notifier handling in mmc_pm_notify, was if I remember
>> correctly, not completely developed when the original version of this
>> patch was being discussed. mmc_pm_notify prevents cards from being
>> inserted/removed in the middle of suspend->resume sequence, is that
>> not enough?
>
> I will try to speak on behalf of the original implementers in a hope
> they would provide the original motivation for the patch.
>
> My understanding is that any preemption in the procedure could be an
> opportunity to suspend, as there may be a suspend request racing with
> this code. This is why the calls to __pm_stay_awake() and
> queue_delayed_work() are so tightly coupled. It would be up to the
> delayed work procedure (mmc_rescan()) to decide whether or not it is
> safe to suspend. If there are no changes in the MMC state or all
> changes can be handled by mmc_rescan(), it is safe to call
> __pm_relax(). Otherwise, userland may take over processing of this
> event, and this is why the awake state needs to be extended by 1/2
> second.

The __pm_stay_awake() is required to prevent autosleep during the time
between the card detect interrupt and when the userspace process that
gets the notification runs.  The 1/2 second delay is used because it
is easier than trying to detect when the userspace process has
received the notification, at which time it should hold its own
wakelock and the mmc subsystem can call __pm_relax().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/