One other comment.. On Fri, 3 Feb 2012, NeilBrown wrote: > On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> wrote: > > > On Fri, 3 Feb 2012, NeilBrown wrote: > > > > > I can remove this effect with: > > > > > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c > > > index f809041..c7ef760 100644 > > > --- a/drivers/tty/serial/omap-serial.c > > > +++ b/drivers/tty/serial/omap-serial.c > > > @@ -440,7 +440,8 @@ static unsigned int serial_omap_tx_empty(struct uart_port *port) > > > spin_lock_irqsave(&up->port.lock, flags); > > > ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0; > > > spin_unlock_irqrestore(&up->port.lock, flags); > > > - pm_runtime_put(&up->pdev->dev); > > > + pm_runtime_mark_last_busy(&up->pdev->dev); > > > + pm_runtime_put_autosuspend(&up->pdev->dev); > > > return ret; > > > } It's a little surprising that this helps. The pm_runtime_get*() and _put*() in serial_omap_tx_empty() are just intended to ensure that the UART's clocks are running for that LSR register read. Considering your theory that the UART clocks are being cut while there's still data in the FIFO, you might consider removing this code at the end of transmit_chars(): if (uart_circ_empty(xmit)) serial_omap_stop_tx(&up->port); - Paul -- 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
