Govindraj <govindraj.ti@xxxxxxxxx> writes: > On Thu, May 5, 2011 at 2:13 AM, Kevin Hilman <khilman@xxxxxx> wrote: >> "Govindraj.R" <govindraj.raja@xxxxxx> writes: >> >>> Acquire console lock before enabling and writing to console-uart >>> to avoid any recursive prints from console write. >>> for ex: >>> Â Â Â --> printk >>> Â Â Â Â --> uart_console_write >>> Â Â Â Â Â --> get_sync >>> Â Â Â Â Â Â --> printk from omap_device enable >>> Â Â Â Â Â Â Â --> uart_console write >> >> By this time, since the device's runtime PM hooks have been called, the >> device's rutime PM state should be set to RPM_SUSPENDING (not yet >> RPM_SUSPENDED). >> >> In addition to the console lock, you should be able to use that flag to >> avoid console writes while the console is in the process of suspending. >> > > Yes RPM_SUSPENDING check helps along with console lock Great! > << Changes as below >> > --------------- > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c > index 59f548f..71964c3 100644 > --- a/drivers/tty/serial/omap-serial.c > +++ b/drivers/tty/serial/omap-serial.c > @@ -1040,6 +1040,18 @@ serial_omap_console_write(struct console *co, > const char *s, > if (console_trylock()) > console_lock = 1; > > + /* > + * If console_lock is not available and we are in suspending > + * state then we can avoid the console usage scenario > + * as this may introduce recursive prints. > + * Basically this scenario occurs during boot while > + * printing debug bootlogs. > + */ > + > + if (!console_lock && > + up->pdev->dev.power.runtime_status == RPM_SUSPENDING) > + return; > + > local_irq_save(flags); > if (up->port.sysrq) > locked = 0; > > ------------ > > Is it ok to check the RPM_SUSPENDING flag in driver ? > I can't find any API currently available under runtime.h to use. I would propose a new API in pm_runtime.h similar to pm_runtime_suspended() that checks for this. Kevin -- 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
