"Cousson, Benoit" <b-cous...@ti.com> writes: > Hi Kevin, > >>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >>ow...@vger.kernel.org] On Behalf Of Kevin Hilman >> >>Hi Paul, >> >>In working with the UART conversion to hwmod, I noticed something I >>don't see when not using hwmod for managing the UARTs. >> >>Namely, in the idle path for PER we do disable the PER UART (via >>omap_uart_prepare_for_idle(2)) and then the GPIO context is saved via >>omap3_per_save_context(); >> >>When switching to use omap_hwmod, I noticed via crashes and then via >>lauterbach that as soon as UART3 clocks are disabled, PER goes idle. >>This causes the subsequent GPIO context save to fault since PER has >>gone idle. >> >>I seem to remember having a similar problem before when the problem >>was in the management of autodeps cause by a mis-merge. >> >>The patch below is a hack/workaround that just moves the UART idle after >>the GPIO context save because I haven't found the root cause yet. >> >>Any ideas what might be happening here? > > This is probably due to the PER HW supervised mode and the fact that there is > no sleep dependency by default between MPU and PER or between CORE and PER. > As soon as the latest peripherals inside the PER power domain is going to > idle, the clock domain and thus the power domain can transition to the next > power state, even if the CPU is running. > It can by avoided by enabling the dependency but then you will prevent the > PER to go to OFF mode even if not used. > > What was changed to trigger that behavior now? >
The primary change is using the omap_device API for managing UART PM in mach-omap2/serial.c instead of directly using clock API. I'll be posting the UART patches shortly. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
