On Fri, 1 Jun 2018, Kai Heng Feng wrote:
> Hi Ulf,
>
> > On May 31, 2018, at 5:40 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> >
> > This series re-works the polling mechanism for the rtsx_usb_mmc driver,
> > which
> > currently relies on pure polling via MMC_CAP_NEEDS_POLL. The problem is
> > simply
> > that is wastes a lot of energy, while in fact the card detection logic
> > don't
> > need to use polling.
> >
> > Do note, this series doesn't work out of the box, as one addtional patch is
> > needed on the rtsx USB misc driver (runtime resuming the child at card
> > detect).
> > I leave that for Kai Heng Feng to implement and moreover I rely on tests
> > to be
> > done, as this series has only been compile tested.
>
> After applying this patch series, the
> rtsx_usb_sdmmc_runtime_{suspend,resume} constantly get called, so the
> parent device can no longer suspend/resume. Not sure what went wrong here
> but I'll take a look.
>
> Also, what do I need to do to use pm_runtime_idle()? I tried to add an idle
> function but it never gets called.
Basically, the PM core calls pm_runtime_idle() when it thinks the
driver might want to suspend the device. For example, after
pm_runtime_put() runs, the core would call pm_runtime_idle() if the
usage counter has dropped to 0.
pm_runtime_idle() is optional; if the callback doesn't exist then the
PM core will call pm_runtime_suspend().
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
