* Paul Walmsley <paul@xxxxxxxxx> [140827 09:38]: > On Mon, 25 Aug 2014, Tony Lindgren wrote: > > > Looks like MUSB cable removal can cause wake-up interrupts to > > stop working for device tree based booting at least for UART3 > > even as nothing is dynamically remuxed. This can be fixed by > > calling reconfigure_io_chain() for device tree based booting > > in hwmod code. > > Weird, nice find. Do you know if this applies to all OMAPs, or just > OMAP3? I guess it may also apply to others too, but so far I've only seen this on omap3 occasionally. > > Note that we already do that for legacy booting > > if the legacy mux is configured. > > > > My guess is that this is related to UART3 and MUSB ULPI > > hsusb0_data0 and hsusb0_data1 support for Carkit mode that > > somehow affect the configured IO chain for UART3 and require > > rearming the wake-up interrupts. > > > > In general, for device tree based booting, pinctrl-single > > calls the rearm hook that in turn calls reconfigure_io_chain > > so calling reconfigure_io_chain should not be needed from the > > hwmod code for other events. > > > > So let's limit the hwmod rearming of iochain only to > > HWMOD_FORCE_MSTANDBY where MUSB is currently the only user > > of it. If we see other devices needing similar changes we can > > add more checks for it. > > Could you please add a new hwmod flag for this case? Maybe something like > HWMOD_RECONFIG_IO_CHAIN? I think that would make the code easier to read > and more maintainable, since the workaround would then be explicitly > connected with that particular workaround's flag. Looks like we have > several flag bits left. Plus if we wind up having to set > HWMOD_FORCE_MSTANDBY for other devices that might not need the I/O chain > reconfiguration, we won't have to reimplement this flag workaround. OK that's a good idea as this may not be always HWMOD_FORCE_MSTANDBY. I guess I initially assumed that this was always related to HWMOD_FORCE_MSTANDBY as that's what seemed to hang the system until I figured it was just the wake-up events that stopped working :) I'll do that as a follow-up patch as I already sent the pull request for the $subject one as it was hanging my tests occasionally. Regards, 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
