* Felipe Balbi <balbi@xxxxxxxxxx> [161208 12:10]: > > Hi, > > Tony Lindgren <tony@xxxxxxxxxxx> writes: > >> nothing against it. Would be nice if TI could confirm this is needed and > >> check if other families might also need it. > > > > But as we currently are not using the WRAPRESET bit, the reset > > function is nop except for the delay. So this just papers over > > the problem with the delay. We are not really resetting anything > > until WRAPRESET and probably also CORE_SW_RESET reset are used. > > > > I'm now thinking the original $subject patch for dwc3-omap.c > > is the way to go for the fix. Or possibly even writing to the > > CORE_SW_RESET bit in dwc3-omap.c probe. The driver needs to be > > able to initialize the hardware no matter what it's state is > > in probe :) > > in theory, yeah. In practice, this doesn't work always. For starters, > we'd probably loose connection to host while handing over IP from > e.g. u-boot to kernel. > > Not to mention tht with dwc3 we can't simply read EP registers and > figure out what's the state of the EP. EP registers are a command > interface to some HW-based command parser/processor. IOW, we can't > extrapolate internal state machine from a read of the registers. > > All this to say, that we rely on properly reset HW from probe(). At > least in the context of dwc3 :-) Yeah I agree we should reset it properly also from PM point of view to get things into sane state after the bootloader. > > Then later on we can add separate resets for the wrapper module > > and dwc3 core. But that's way too intrusive for a fix for sure. > > yeah, that's something for v4.11. Let's go with your fix that just > clears interrupts early on. Once proper resets are added, then we should > revert that change. OK Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
