Hi David, > > > > In order for phy to be functional, it does not depend only on toggling > > > > GPIOs. It depends on DWC3 going to reset state, then phy executes power > > > > on sequence, then DWC3 going out of reset state to sync clocks with phy. > > > > You're saying we should tell BIOS is concurrently mess with dwc3 > > > > together with dwc3 driver? > > > > > > I don't understand what you are saying here? > > > > TUSB1210 needs to come out of reset only when DWC3 is in reset state. > > This is how current code works in dwc3_core_soft_reset(): > > - dwc3 goes to reset > > - phy goes to reset > > - phy gets out of reset > > - dwc3 gets out of reset > > > > This is how you're proposing: > > - phy goes to reset (DSDT code, when loading module) > > - phy gets out of reset (DSDT code, when loading module) > > > > - dwc3 goes to reset (dwc3_core_soft_reset()) > > - dwc3 gets our of reset (dwc3_core_soft_reset()) > > > > Felipe, do you see a problem with this new context? If not, I'm > > satisfied with Heikki's ULPI bus proposal considering my comment below. > > Sorry, guess I spoke too soon :/ > I am satisfied with the phy case, but I forgot about the chicken/egg > problem I reported earlier: > DWC3 will not be functional when reloading the module after it went to > reset state. Then ULPI enumeration can't happen regardless DSDT code > powered on phy. One point here. If we have DSDT handling the gpios with the operation region, those gpio resources don't need to be given to any device (actually I think they really shouldn't be given to anything in that case). > Heikki, do you have a proposal for that? IMHO that's the main missing > point if we forget about BYT-CR legacy. I'm sorry but I'm still not sure about the scenario you are talking about. When we load dwc3, we end up autoloading phy-tusb1210 in this case and increasing the phy devices ref count i.e. preventing phy-tusb1210 module from being unloaded before dwc3 is unloaded. If we unload dwc3 we can also unload phy-tusb1210 if we like but if after that we load dwc3 again, the ULPI will be accessible the moment we register the ulpi interface as it was before. That I believe is actually a must in case of ULPI. When dwc3 is reset with GCTL or DCTL SoftReset, it will first write to the ULPI FunctionControl register's reset bit in order to but the PHY to reset (PHYSoftRst has no effect in case of ULPI), so ULPI really has to be accessible before the core is soft reset. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
