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

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

On 07.09.2022 12:36, Ilpo Järvinen wrote:

quoted

On Tue, 6 Sep 2022, Sergiu Moga wrote:

quoted

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 <redacted>
---

quoted

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.

quoted

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.