From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Sergiu.Moga@microchip.com
Cc: alexandre.belloni@bootlin.com, mturquette@baylibre.com,
LKML <linux-kernel@vger.kernel.org>,
admin@hifiphile.com, krzysztof.kozlowski+dt@linaro.org,
Jiri Slaby <jirislaby@kernel.org>,
linux-clk@vger.kernel.org, lee@kernel.org,
linux-serial <linux-serial@vger.kernel.org>,
devicetree@vger.kernel.org, Tudor.Ambarus@microchip.com,
radu_nicolae.pirea@upb.ro, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, richard.genoud@gmail.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-spi@vger.kernel.org, sboyd@kernel.org, broonie@kernel.org,
Kavyasree.Kotagiri@microchip.com, Claudiu.Beznea@microchip.com
Subject: Re: [PATCH v2 12/13] tty: serial: atmel: Make the driver aware of the existence of GCLK
Date: Wed, 7 Sep 2022 14:29:49 +0300 (EEST) [thread overview]
Message-ID: <caf05bb5-26df-68ca-59a1-e84983294de@linux.intel.com> (raw)
In-Reply-To: <f3e87d18-41aa-f1e2-e0fb-8944c9fb4910@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]
On Wed, 7 Sep 2022, Sergiu.Moga@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@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.
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-09-07 11:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 13:54 [PATCH v2 00/13] Make atmel serial driver aware of GCLK Sergiu Moga
2022-09-06 13:55 ` [PATCH v2 01/13] spi: dt-bindings: atmel,at91rm9200-spi: Add DMA related properties Sergiu Moga
2022-09-06 15:12 ` Mark Brown
2022-09-06 21:41 ` Rob Herring
2022-09-07 7:54 ` Sergiu.Moga
2022-09-08 12:23 ` Krzysztof Kozlowski
2022-09-06 13:55 ` [PATCH v2 02/13] ARM: dts: at91: sama7g5: Swap rx and tx for spi11 Sergiu Moga
2022-09-06 13:55 ` [PATCH v2 03/13] dt-bindings: mfd: atmel,sama5d2-flexcom: Add SPI child node ref binding Sergiu Moga
2022-09-08 12:23 ` Krzysztof Kozlowski
2022-09-06 13:55 ` [PATCH v2 04/13] ARM: dts: at91: sam9x60ek: Add DBGU compatibles to uart1 Sergiu Moga
2022-09-06 13:55 ` [PATCH v2 05/13] dt-bindings: serial: atmel,at91-usart: convert to json-schema Sergiu Moga
2022-09-08 12:29 ` Krzysztof Kozlowski
2022-09-08 15:06 ` Sergiu.Moga
2022-09-08 15:10 ` Krzysztof Kozlowski
2022-09-08 15:27 ` Sergiu.Moga
2022-09-08 16:05 ` Krzysztof Kozlowski
2022-09-06 13:55 ` [PATCH v2 06/13] dt-bindings: serial: atmel,at91-usart: Add SAM9260 compatibles to SAM9x60 Sergiu Moga
2022-09-08 12:30 ` Krzysztof Kozlowski
2022-09-08 15:15 ` Sergiu.Moga
2022-09-09 1:36 ` Rob Herring
2022-09-12 7:45 ` Sergiu.Moga
2022-09-12 10:44 ` Krzysztof Kozlowski
2022-09-12 13:09 ` Sergiu.Moga
2022-09-13 8:58 ` Krzysztof Kozlowski
2022-09-13 9:19 ` Sergiu.Moga
2022-09-13 9:30 ` Krzysztof Kozlowski
2022-09-13 9:35 ` Sergiu.Moga
2022-09-06 13:55 ` [PATCH v2 07/13] dt-bindings: mfd: atmel,sama5d2-flexcom: Add USART child node ref binding Sergiu Moga
2022-09-08 12:33 ` Krzysztof Kozlowski
2022-09-06 13:55 ` [PATCH v2 08/13] tty: serial: atmel: Define GCLK as USART baudrate source clock Sergiu Moga
2022-09-07 9:21 ` Ilpo Järvinen
2022-09-07 9:37 ` Sergiu.Moga
2022-09-06 13:55 ` [PATCH v2 09/13] tty: serial: atmel: Define BRSRCCK bitmask of UART IP's Mode Register Sergiu Moga
2022-09-07 9:24 ` Ilpo Järvinen
2022-09-06 13:55 ` [PATCH v2 10/13] tty: serial: atmel: Only divide Clock Divisor if the IP is USART Sergiu Moga
2022-09-07 9:23 ` Ilpo Järvinen
2022-09-07 9:34 ` Sergiu.Moga
2022-09-06 13:55 ` [PATCH v2 11/13] clk: at91: sama5d2: Add Generic Clocks for UART/USART Sergiu Moga
2022-09-06 13:55 ` [PATCH v2 12/13] tty: serial: atmel: Make the driver aware of the existence of GCLK Sergiu Moga
2022-09-07 9:36 ` Ilpo Järvinen
2022-09-07 11:11 ` Sergiu.Moga
2022-09-07 11:29 ` Ilpo Järvinen [this message]
2022-09-12 8:06 ` Claudiu.Beznea
2022-09-06 13:55 ` [PATCH v2 13/13] dt-bindings: serial: atmel,at91-usart: Add gclk as a possible USART clock Sergiu Moga
2022-09-08 12:35 ` Krzysztof Kozlowski
2022-09-08 15:33 ` Sergiu.Moga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=caf05bb5-26df-68ca-59a1-e84983294de@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Claudiu.Beznea@microchip.com \
--cc=Kavyasree.Kotagiri@microchip.com \
--cc=Sergiu.Moga@microchip.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=admin@hifiphile.com \
--cc=alexandre.belloni@bootlin.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=radu_nicolae.pirea@upb.ro \
--cc=richard.genoud@gmail.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).