On Wed, 30 May 2018, Ulf Hansson wrote: > On 30 May 2018 at 11:54, Kai Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> wrote: > > Hi Alan, Ulf, > > > > [snipped] > >>> > >>> tsx_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(). > > > > > > Thanks. I think it's not the right path to take. > > > > > > [snipped] > >>> > >>> 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. > > > > > > I stripped out MMC_CAP_NEEDS_POLL, and use pm_request_resume(child) to > > resume the child mmc host from parent device. > > In the child's resume function, I use mmc_detect_change() to detect the card > > successfully. > > This may work for the card detect case (but still has problems), but > not for the card removal scenario. > > For example, what if the child is already runtime resumed, and a > detect has just be run, finding out that there is no card. The > following call to mmc_detect_change(), from the runtime resume > callback may not be executed then. > > > But the child's suspend function never gets called without > > MMC_CAP_NEEDS_POLL. > > Weird. Sure you didn't call pm_runtime_get(child) from the parent > device driver instead of pm_request_resume() > > > How do I let MMC core knows that the card is gone when the USB card reader > > doesn't support interrupt? > > So you are saying that the USB card reader (parent) is not able to > detect when a card is removed, only when it's inserted? > > Is that's the case, then polling is needed. > > Perhaps what is needed is to use polling, but only when the mmc host > has been runtime resumed. That sounds right. I have no idea how to tell the MMC core to do this, but it should make everything work correctly. 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