Thread (2 messages) 2 messages, 2 authors, 2011-10-12
STALE5361d

[PATCH v6 15/16] OMAP2+: UART: Enable back uart clocks with runtime API for early console

From: Kevin Hilman <hidden>
Date: 2011-10-11 21:06:16
Also in: linux-omap, linux-serial

"Govindraj.R" [off-list ref] writes:
For the early console probing we had avoided hwmod reset and idling
and uart was idled using hwmod API and enabled back using omap_device API
after omap_device registration.

Now since we are using runtime API's to enable back uart, move hwmod
idling and use runtime API to enable back UART.

Signed-off-by: Govindraj.R <redacted>
Now that the driver is using runtime PM.  Why do we still need
HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET?

The comment in the code says:

		/*
		 * During UART early init, device need to be probed
		 * to determine SoC specific init before omap_device
		 * is ready.  Therefore, don't allow idle here
		 */

This was true when using the 8250 driver because it was not using
runtime PM so could not know how to (re)enable the device.

However, since the driver is now runtime PM adapted, any device access
should be contained within a runtime PM get/put block, so there should
no longer be a reason not allow the IP blocks to be reset during boot.

Kevin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help