Re: Keep rtsx_usb_ms runtime suspended when polling for cards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 24 May 2018, Ulf Hansson wrote:

> >> Ok, now I understand a bit more of what you want to do. Let me
> >> elaborate on the mmc case (the memstick works the similar).
> >>
> >> So, depending on what card detect mechanism the mmc host supports, it
> >> may set different host capabilities to inform the mmc core about a
> >> desired behavior.
> >>
> >> In this case, rtsx_usb_sdmmc has set MMC_CAP_NEEDS_POLL, because the
> >> driver consider its HW to *not* support a remote wakeup for card
> >> detect. Hence the core schedules a work for polling, meaning that it
> >> will wakeup the mmc host (pm_runtime_get_sync()) and then try to
> >> initialize a card. When there is no card, it will fail and let the
> >> host go back to sleep (pm_runtime_put) and re-schedule a new work.
> >
> >
> > Thanks for the explanation.
> >
> >>
> >>> It's unnecessary because the card reader has remote wakeup capability, it
> >>> wakes up when there's a card gets plugged into slot.
> >>
> >>
> >> Can you please elaborate on how card detect works for your case.
> >>
> >> The common way to do that for mmc, is to use a separate GPIO card
> >> detect pin. Is possibly that what is used in your case as well - or do
> >> you have another external logic serving the remote wakeup?
> >
> >
> > From what I understand from Realtek, it's USB remote wakeup signaling.
> > The card reader gets woken up when a card gets plugged into its slot.
> 
> I don't know USB good enough, but I am sure the remote wakeup
> signaling at least needs to be activated and configured some how.

The USB core will automatically activate remote wakeup during runtime
suspend if any of the device's interface drivers requests it.  A driver
requests remote wakeup by setting the intf->needs_remote_wakeup flag in
its probe routine.  (But don't set the flag if the device doesn't
support remote wakeup -- in that case core will never allow the device
to be runtime suspended!)

> And more precisely, who wakes up the mmc host? Things just doesn't happen. :-)

A runtime resume of a child device automatically causes the parent to
be runtime-resumed as well (unless pm_suspend_ignore_children() was
called for the parent).  But if the the mmc host isn't an ancestor of
the card reader, the card reader's driver would have to wake up the mmc
host explicitly.

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



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux