[PATCH v2 12/13] tty: serial: atmel: Make the driver aware of the existence of GCLK

[Ilpo Järvinen]

On Wed, 7 Sep 2022, Sergiu.Moga at microchip.com wrote:

> On 07.09.2022 12:36, Ilpo Järvinen wrote:
> > On Tue, 6 Sep 2022, Sergiu Moga wrote:
> > 
> >> Previously, the atmel serial driver did not take into account the
> >> possibility of using the more customizable generic clock as its
> >> baudrate generator. Unless there is a Fractional Part available to
> >> increase accuracy, there is a high chance that we may be able to
> >> generate a baudrate closer to the desired one by using the GCLK as the
> >> clock source. Now, depending on the error rate between
> >> the desired baudrate and the actual baudrate, the serial driver will
> >> fallback on the generic clock. The generic clock must be provided
> >> in the DT node of the serial that may need a more flexible clock source.
> >>
> >> Signed-off-by: Sergiu Moga <sergiu.moga at microchip.com>
> >> ---

> > Is percent accurate enough or would you perhaps want something slightly
> > more accurate?
> > 
> 
> 
> It is accurate enough for the all the baudrates I have tested. It 
> usually taps into the GCLK whenever high baudrates such as 921600 are 
> used. For 115200 for example, the error rate was slightly better in the 
> case of the peripheral clock and it acted accordingly, choosing the 
> latter as its baudrate source clock. I do not think that a higher 
> accuracy than this would be needed though. Say that using percent 
> accuracy yields that the error rates are equal, but the gclk would have 
> been better in this case by, say, a few 10 ^ -4, but the code logic does 
> not see it so it proceeds using the peripheral clock. In that case, the 
> error rate of the peripheral clock would still be low enough relative to 
> the desired baudrate for the communication to function properly.
> 
> The higher the baudrate, the lower the error rate must be in order for 
> things to go smoothly. For example, for a baudrate of 57600 I noticed 
> that even an error rate as big as 6% is still enough for the 
> communication to work properly, while in the case of 921600 anything 
> bigger than 2% and things do not go smoothly anymore. So I guess that it 
> would be safe to say that, unless you go for baudrates as high as tens 
> of millions, things should work well with just percent accuracy. A 
> higher accuracy always definetely helps, but I believe it is not needed 
> in this case.
> 
> 
> > Given you've abs() at the caller side, the error rate could be
> > underestimated, is underestimating OK?
> > 
> 
> 
> Yes, this should be fine. While (both empirically and after looking 
> stuff up) I noticed that in the case of negative error rates, their 
> absolute value needs to be smaller than the one of positive error rates, 
> it must be so by a very small margin that is negligible when estimating 
> through percent accuracy.

OK. Thanks for checking.


-- 
 i.