On Wed, Oct 12, 2011 at 2:36 AM, Kevin Hilman [off-list ref] wrote:

"Govindraj.R" [off-list ref] writes:

quoted

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.

Forgot to add, this is still needed for
earlyprintk(CONFIG_EARLY_PRINTK) use case,

The initial boot prints until a console driver is available is from
"arch/arm/kernel/early_printk.c" which does a tx on uart console
and relies on configuration from bootloader.

during bootup earlyprink does a tx on uart console and if  uart driver
is not available yet
uart reset or idle done by hwmod layer can cause boot failures.

--> put_char from earlyprintk.c
     --> reset/idle from hwmod layer
          --> put_char from earlyprintk.c


So console_uart reset or clock gating must be done only after uart
driver is available or be prevented
using these available hwmod_flags.

omap_serial_early_init should be now be binded with CONFIG_SERIAL_OMAP macro ?

--
Thanks,
Govindraj.R