On Wed, Feb 11, 2015 at 03:12:55PM +0200, Heikki Krogerus wrote: > Hi David, Hi Heikki, > > > > > > 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). Agree with that. > > > 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. Probably because I'm asking this question in the wrong place. It is regarding patch 6/8. I resent the question there. Br, David -- 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
