Message-ID: <caf05bb5-26df-68ca-59a1-e84983294de@linux.intel.com>
Date:   Wed, 7 Sep 2022 14:29:49 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     Sergiu.Moga@...rochip.com
cc:     lee@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, Nicolas.Ferre@...rochip.com,
        alexandre.belloni@...tlin.com, Claudiu.Beznea@...rochip.com,
        richard.genoud@...il.com, radu_nicolae.pirea@....ro,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        broonie@...nel.org, mturquette@...libre.com, sboyd@...nel.org,
        Jiri Slaby <jirislaby@...nel.org>, admin@...iphile.com,
        Kavyasree.Kotagiri@...rochip.com, Tudor.Ambarus@...rochip.com,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        LKML <linux-kernel@...r.kernel.org>, linux-spi@...r.kernel.org,
        linux-serial <linux-serial@...r.kernel.org>,
        linux-clk@...r.kernel.org
Subject: Re: [PATCH v2 12/13] tty: serial: atmel: Make the driver aware of
 the existence of GCLK

On Wed, 7 Sep 2022, Sergiu.Moga@...rochip.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@...rochip.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.

Powered by blists - more mailing lists