On Wed, Oct 12, 2011 at 2:36 AM, Kevin Hilman <khilman@xxxxxx> wrote:
> "Govindraj.R" <govindraj.raja@xxxxxx> 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 <govindraj.raja@xxxxxx>
>
> 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
--
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
