On Thu, Oct 13, 2011 at 5:30 AM, Kevin Hilman [off-list ref] wrote:

Govindraj [off-list ref] writes:

quoted

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

quoted

"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,

Ah, right. ?I forgot about that. ?Please update the changelog (and
comment in the code) to reflect that.

quoted

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.

So why not leave the driver out of it and solve it like the current code
does?

The current codes use the hwmod flags, then waits until the UART driver
is available (after omap_device_build) and uses omap_hwmod_idle() to do
an clean idle of the device.

Notably this is inside a console_lock/console_unlock block so that
prints are buffered.

The current code then does an omap_device_enable() to re-enable the
device, but you shouldn't need that after the driver is converted to
runtime PM.

Yes similar approach here, We are not doing hwmod idle
until console driver is available, once omap-serial is available
from probe doing hwmod_idle* and then get_sync.

hwmod idle in serial.c will still cause problems if ealryprintk tries to print
until omap-uart console driver is not available, as now with rumtime adaptation
only driver can enable back clocks. So have added a function pointer
to pdata which
calls hwmod_idle implemented in serial.c calling omap_hwmod_idle.

--
Thanks,
Govindraj.R

*function pointer implemented in serial.c not directly calling
omap_hmwod_idle API.