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 :-) > 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. -- balbi -- 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
