On 09/06/16 16:10, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq@xxxxxx> writes: >>> okay, so we actually want to power the hole thing down when in deep >>> sleep. What does deep sleep map to in linux parlance? suspend-to-ram? >>> suspend-to-disk? >> >> SoC standby == echo standby > /sys/power/state >> SoC deepsleep == echo mem > /sys/power/state > > understood. > >>> you didn't actually reach standby at all. >> >> Yeah ti-4.4 is still not there yet. I tried it on ti-4.1 with USB_DEFAULT_PERSIST >> disabled and I could see the devices disconnect and re-enumerate on am437x. >> I do see VBUS being turned off and need to figure out how to prevent that if >> we want to support the remote wakeup case. >> >> On dra7-evm I do see VBUS being left ON, but I do see the devices disconnect >> and re-enumerate on system resume. >> However, if I comment out the phy_exit()/init(), phy_power_off/on() part then >> I do see the devices resume correctly. > > okay, so in some cases we don't want phy_exit()/phy_init(), I can move > that elsewhere. Let me check. > >> So looks like we need better granularity for PHY power management as well? > > possibly :-) But for now, let's just avoid regressions while still > simplifying PM code. > >>>>> But DWC3 is not controlling VBUS, so that shouldn't matter in any >>>>> case. IIRC, your VBUS was controlled by a GPIO, right? >>>> >>>> Nope. VBUS is controlled internally, most likely via some XHCI integration >>>> logic. >>> >>> on the DRD port? Which Soc are you talking about? >> >> dra7xx SoC has a dedicated usb_drvvbus pin that controls the VBUS regulator. >> The ID and VBUS event input does come over a GPIO though. > > okay > >>> Well, AM437x has the DRVVBUS signal which, for the most part at least, >>> works fine in HW mode. There are some concerns about VBUS contention >>> (ping Dave K about that, btw. You wanna know about that). >>> >>> AM57x, however, has ID and VBUS tied to GPIOs (or was it only VBUS?) >> >> ID is over GPIO, VBUS input comes via PMIC. >> It does have usb_drvvbus as well that controls the VBUS regulator. > > alright, thanks for the refresher. I'll update my commit WRT > phy_init()/phy_exit() and resend it. You should probably not do it. I just wanted to point out my observation. I will need to re-visit this when I test more of remote wakeup. > >> So then even without the diff, host is working fine as re-enumeration is >> expected. >> However device is still broken with the below backtrace on dra7-evm. > > isn't that backtrace caused by another patch? That's what you said > previously. Also, if devices actually re-enumerate then it's not exactly > broken. Just has an annoying dump_stack() happening ;-) > I reported this on another patch but that was before I did a bisect. So sorry for any confusion. This patch causes that backtrace. cheers, -roger
Attachment:
signature.asc
Description: OpenPGP digital signature
