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. > 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 ;-) -- balbi
Attachment:
signature.asc
Description: PGP signature
