Re: [PATCH] serial: mxs-auart: wait for DMA buffer to flush before shutdown

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

Hi Hector,

On Wed, Oct 02, 2013 at 10:46:28AM +0200, Hector Palacios wrote:
> On 10/02/2013 10:30 AM, Uwe Kleine-König wrote:
> >On Wed, Oct 02, 2013 at 10:09:10AM +0200, Hector Palacios wrote:
> >>On 10/02/2013 09:44 AM, Uwe Kleine-König wrote:
> >>>Ah, right. (BTW, uart_update_timeout should better round up instead of
> >>>round down, i.e.
> >>>-	port->timeout = (HZ * bits) / baud + HZ/50;
> >>>+	port->timeout = DIV_ROUND_UP(HZ * bits, baud) + HZ/50;
> >>>)
> >>>
> >>>>UART_XMIT_SIZE is the number of bytes in the DMA buffer, so I divide
> >>>>the max number of bytes in the FIFO by the FIFO size and multiply by
> >>>>the FIFO timeout.
> >>>ditto here, better round up. Although I think using a completion could
> >>>shorten the timeout considerably because there are often less than
> >>>UART_XMIT_SIZE chars in the buffer?!
> >>
> >>I'm not really waiting the full timeout. I'm checking for TX fifo
> >>empty every 1ms and for a maximum of 'to' ms.
> >Correct. Still using DIV_ROUND_UP would be better, right?
> 
> I think it is not really needed, after all the code is adding HZ/50
> of slop which acts like a round up, doesn't it?
> 
> 	/*
> 	 * Figure the timeout to send the above number of bits.
> 	 * Add .02 seconds of slop
> 	 */
> 	port->timeout = (HZ * bits) / baud + HZ/50;
According to my understanding (which could well be wrong) the slop of
HZ/50 isn't there to fix rounding issues in the previous division. But
yes, if it's calculated generously there is no technical need to fix the
rounding issue.

Still it might be worth to fix it to be a better reference. I don't care
much.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html