On Thu, Oct 13, 2011 at 5:30 AM, Kevin Hilman <khilman@xxxxxx> wrote: > Govindraj <govindraj.ti@xxxxxxxxx> writes: > >> 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, > > Ah, right. I forgot about that. Please update the changelog (and > comment in the code) to reflect that. > >> 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. -- 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
