On Fri, 25 May 2018, Kai-Heng Feng wrote: > 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. I agree with Ulf, you probably should not call pm_suspend_ignore_children(). > >> 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? No; all you have to do is make the resume routine in the rtsx_usb driver call pm_request_resume(the child mmc host device). That tells the PM core to create a workqueue entry which will do a runtime resume of the mmc host device. 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
