ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled
Subsystems (4)
Tony Lindgren
maintainerPATCH 1/1 ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled
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. 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.
arch/arm/mach-omap2/omap_hwmod.c +4 -0
@@ -2185,6 +2185,8 @@ static int _enable(struct omap_hwmod *oh) oh->mux->pads_dynamic))) {omap_hwmod_mux (oh->mux, _HWMOD_STATE_ENABLED);_reconfigure_io_chain (); + } else if (oh->flags & HWMOD_FORCE_MSTANDBY) { +_reconfigure_io_chain (); }_add_initiator_dep (oh, mpu_oh);
@@ -2291,6 +2293,8 @@ static int _idle(struct omap_hwmod *oh)if (oh->mux && oh->mux->pads_dynamic) {omap_hwmod_mux (oh->mux, _HWMOD_STATE_IDLE);_reconfigure_io_chain (); + }else if (oh->flags &HWMOD_FORCE_MSTANDBY ) { +_reconfigure_io_chain (); } oh->_state = _HWMOD_STATE_IDLE;
Paul Walmsley
maintainerPATCH 1/1 ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled
Quoted 5 lines · Tony Lindgren
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?
Quoted 13 lines
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_data0andhsusb0_data1support 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_chainso callingreconfigure_io_chainshould not be needed from the hwmod code for other events.
Quoted 4 lines
So let's limit the hwmod rearming of iochain only to
HWMOD_FORCE_MSTANDBYwhere 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.
regards
- Paul
Quoted 17 lines
Cc Paul Walmsley <[email protected]>Signed-off-by Tony Lindgren <[email protected]>arch/arm/mach-omap2/omap_hwmod.c +2
-0@@ -2185,6 +2185,8 @@ static int _enable(struct omap_hwmod *oh) oh->mux->pads_dynamic))) {omap_hwmod_mux (oh->mux, _HWMOD_STATE_ENABLED);_reconfigure_io_chain (); + } else if (oh->flags & HWMOD_FORCE_MSTANDBY) { +_reconfigure_io_chain (); }_add_initiator_dep (oh, mpu_oh);
arch/arm/mach-omap2/omap_hwmod.c static int _idle(struct omap_hwmod *oh) · line 2300
Quoted 8 lines
arch/arm/mach-omap2/omap_hwmod.c +2
-0@@ -2291,6 +2293,8 @@ static int _idle(struct omap_hwmod *oh)if (oh->mux && oh->mux->pads_dynamic) {omap_hwmod_mux (oh->mux, _HWMOD_STATE_IDLE);_reconfigure_io_chain (); + }else if (oh->flags &HWMOD_FORCE_MSTANDBY ) { +_reconfigure_io_chain (); } oh->_state = _HWMOD_STATE_IDLE;
- Paul
Tony Lindgren
maintainerPATCH 1/1 ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled
Quoted 10 lines · Paul Walmsley
Quoted 5 lines · Tony Lindgren
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.
Quoted 18 lines
Quoted 13 lines
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_data0andhsusb0_data1support 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_chainso callingreconfigure_io_chainshould not be needed from the hwmod code for other events.Quoted 4 lines
So let's limit the hwmod rearming of iochain only to
HWMOD_FORCE_MSTANDBYwhere MUSB is currently the only user of it. If we see other devices needing similar changes we can add more checks for it.
Quoted 7 lines
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 setHWMOD_FORCE_MSTANDBYfor 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