at 22:44, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
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!)
Yes the flag is set in rtsx_usb probe function.
If pm_suspend_ignore_children() is called in rtsx_usb, the parent can be
correctly woken up when a card gets plugged.
Realtek also confirmed that this device supports remote wakeup signaling.
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.
Right now I am trying to figure out how to let rtsx_usb (parent) tells
rtsx_usb_sdmmc (child, mmc host) to wake up mmc core.
Is an interrupt required here?
Kai-Heng
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
