One other comment.. On Fri, 3 Feb 2012, NeilBrown wrote:
> On Thu, 2 Feb 2012 22:45:53 -0700 (MST) Paul Walmsley <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
