Improve the accuracy of the baud rate generator by using round-to-closest instead of truncating when calculating baud rate divisors.

[Johan Hovold <johan@kernel.org>]

On Thu, Nov 15, 2018 at 09:24:49AM +0100, Johan Hovold wrote:
> On Tue, Nov 13, 2018 at 08:19:44PM +0100, Nikolaj Fogh wrote:
> > On 11/12/18 10:54 AM, Johan Hovold wrote:
> > > On Wed, Oct 31, 2018 at 09:16:48PM +0100, Nikolaj Fogh wrote:
> > >> I have experienced that the ftdi_sio driver gives less-than-optimal
> > >> baud rates as the driver truncates instead of rounds to nearest
> > >> during baud rate divisor calculation.
> 
> > >> This patch improves on the baud rate generation. The generated baud
> > >> rate corresponds to the optimal baud rate achievable with the chip.
> > >> This is what the windows driver gives as well.
> > >
> > > How did you verify this? Did you trace and compare the divisors
> > > actually requested by the Windows driver, or did you measure the
> > > resulting rates using a scope?
> 
> > I verified it by scope. Granted, I only verified it for one baud rate
> > (961200). Whether it gives the same as the Windows driver in general,
> > I'm not sure. However, I would think that rounding instead of flooring
> > would always yield the most accurate result.
> 
> I'm not so sure in this case. The driver uses "sub-integer" divisors and
> looks like it depends on truncation rather than rounding. Some
> background here:
> 
> 	https://www.ftdichip.com/Support/Knowledgebase/index.html?whatbaudratesareachieveabl.htm

After taking a closer look at the driver, I think your patch may be
fine. It shouldn't change 921600 baud, though, but I see now that you
wrote *961200* above. Was that intentional?

> If you want to change these calculations you need to make a stronger
> case for it and verify that we don't mess up some other rate
> inadvertently.

This still stands though, you need a better description of why this
is needed and correct. Mention which device and rate that was off, and
by how much. Determining the theoretical difference may be interesting
too, while making sure we don't introduce larger errors for other rates.

Thanks,
Johan