To handle uart clocks within uart driver we need the *semantics of clock enable API should not internally trigger any UART PORT operation* even before completing clock_enable. Ex: while configuring baud rate we may use runtime api's to enable uart port. get_sync -> printk -> call console uart to print For example, say we are calling Uart_configure baud to configure the baud-rate. Even before this operation completes, if there is print, we may switch to uart write operation which is undesirable. This occurs due to any printks called from omap_device ()/omap_hwmod ()/clk layers which come in the flow from pm_runtime_get_sync/ pm_runtime_put_autosuspend API's. 1. pm_runtime_get _sync -> printk -> console_write -> pm_runtime_get_sync 2. pm_runtime_ put_autosuspend -> rpm_suspend -> pm_generic suspend -> omap_device_disable -> debug prints -> console_write -> pm_runtime_get_sync This leads to a deadlock caused by contention of the power_lock from the same runtime API context. Work-around explored: -------------------- Use console lock aggressively around each get_sync/put_sync. Uart_configure baud { 1. Console_lock 2. pm_runtime_get_sync 3. Console_unlock (and send the prints accumulated in the log buffer to the console) which leads to a console_write . 4. This console_write in turn leads to a console_lock+pm_runtime_get_sync 5. Also Console_unlock is undesirable here since it jumps to console write even before baud config was complete. } Locking the console around a pm_runtime_get_sync()will make sure that all prints are sent to the log-buffer until the console in unlocked, thereby getting rid of recursively jumping from one port op to another even before current port operation is complete. However, this leads to: 1. Cant bind put_autosuspend with console lock as they get scheduled later put -> print -> console_write -> get_sync (one runtime API context we may enter another runtime API power lock contention) 2. Using console_lock wrapper everywhere in driver to suppress prints from get_sync is too aggressive in nature. 3. During Boot-up, console_lock is not available until uart driver completes its registration with kernel console_driver. Observing the semantics of console_lock/unlock, it seems undesirable to be used within uart driver. But can rather be used form global stand point to suppress uart prints. Example: 1. While system wide suspending 2. In cpu idle path., etc. Proposal: -------- 1. For the UART, follow the current approach of locking the console in Idle/Suspend path before cutting the clock but using pm_runtime_putsync. That is, continue using the prepare/resume Idle calls in idle path. 2. Other Approach would be adding conditions to debug prints from omap_device/ omap_hwmod/clock_framework avoid calling these debug prints for uart. Or Even a debug macro that would not debug prints if the context is from uart. Any further approaches are welcome. Have captured little more details compared to v1 posted erlier: http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg52707.html -- 1.7.4.1 -- 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