linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Fractional divider on the Atmel USART controller
@ 2017-02-06 11:56 Romain Izard
  2017-02-06 13:42 ` Ludovic Desroches
  2017-02-06 13:47 ` Richard Genoud
  0 siblings, 2 replies; 8+ messages in thread
From: Romain Izard @ 2017-02-06 11:56 UTC (permalink / raw)
  To: linux-arm-kernel, linux-serial, LKML, Ludovic Desroches, Nicolas Ferre
  Cc: Richard Genoud

Hello,

On Atmel SAMA5D2, when trying to configure a serial port for 3 Mbauds
operation, I do not always get the requested baud rate. If the hardware
flow control is disabled by software, the line works correctly. But if I
set the crtscts option, the line does not work, and after checking the
line I can observe that the signal is sent at 2.6 Mbauds.

This is due to the code used to manage fractional baud rate divisor: the
existing code prevents the fractional bits from being used if the line
is not configured in normal mode. This case occurs when the hardware
flow control or the RS485 mode is set.

If I apply the following patch to drivers/tty/serial/atmel_serial.c,
I get the required baudrate.

8<----------------------------------------------------------------

@@ -2204,14 +2204,13
      * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
      * Currently, OVER is always set to 0 so we get
      * baudrate = selected clock / (16 * (CD + FP / 8))
      * then
      * 8 CD + FP = selected clock / (2 * baudrate)
      */
-    if (atmel_port->has_frac_baudrate &&
-        (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
+    if (atmel_port->has_frac_baudrate) {
         div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
         cd = div >> 3;
         fp = div & ATMEL_US_FP_MASK;
     } else {
         cd = uart_get_divisor(port, baud);
     }

8<----------------------------------------------------------------

Unfortunately, I know that this will work on SAMA5D2, but this driver is
used for many other Atmel chips. I do not know if the existing code is
meant to respect a known limitation on other devices that use the same
controller, or if it is just a bug.

Ludovic, Nicolas,  what is your opinion on that matter? Should I just
propose this as a patch, or is it necessary to add a limitation for
supported devices only ?

Best regards,
-- 
Romain Izard

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fractional divider on the Atmel USART controller
  2017-02-06 11:56 Fractional divider on the Atmel USART controller Romain Izard
@ 2017-02-06 13:42 ` Ludovic Desroches
  2017-02-06 14:58   ` Richard Genoud
  2017-02-06 15:14   ` Romain Izard
  2017-02-06 13:47 ` Richard Genoud
  1 sibling, 2 replies; 8+ messages in thread
From: Ludovic Desroches @ 2017-02-06 13:42 UTC (permalink / raw)
  To: Romain Izard
  Cc: linux-arm-kernel, linux-serial, LKML, Ludovic Desroches,
	Nicolas Ferre, Richard Genoud

Hello Romain,

On Mon, Feb 06, 2017 at 12:56:42PM +0100, Romain Izard wrote:
> Hello,
> 
> On Atmel SAMA5D2, when trying to configure a serial port for 3 Mbauds
> operation, I do not always get the requested baud rate. If the hardware
> flow control is disabled by software, the line works correctly. But if I
> set the crtscts option, the line does not work, and after checking the
> line I can observe that the signal is sent at 2.6 Mbauds.
> 
> This is due to the code used to manage fractional baud rate divisor: the
> existing code prevents the fractional bits from being used if the line
> is not configured in normal mode. This case occurs when the hardware
> flow control or the RS485 mode is set.
> 
> If I apply the following patch to drivers/tty/serial/atmel_serial.c,
> I get the required baudrate.
> 
> 8<----------------------------------------------------------------
> 
> @@ -2204,14 +2204,13
>       * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
>       * Currently, OVER is always set to 0 so we get
>       * baudrate = selected clock / (16 * (CD + FP / 8))
>       * then
>       * 8 CD + FP = selected clock / (2 * baudrate)
>       */
> -    if (atmel_port->has_frac_baudrate &&
> -        (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
> +    if (atmel_port->has_frac_baudrate) {
>          div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
>          cd = div >> 3;
>          fp = div & ATMEL_US_FP_MASK;
>      } else {
>          cd = uart_get_divisor(port, baud);
>      }
> 
> 8<----------------------------------------------------------------
> 
> Unfortunately, I know that this will work on SAMA5D2, but this driver is
> used for many other Atmel chips. I do not know if the existing code is
> meant to respect a known limitation on other devices that use the same
> controller, or if it is just a bug.

It depends on the device used. In the SAMA5D4 datasheet, it is
mentionned: "This feature is only available when using USART normal mode".

In the SAMA5D2 datasheet, this constraint is no longer mentionned you
confirm that is works, that is great.

> 
> Ludovic, Nicolas,  what is your opinion on that matter? Should I just
> propose this as a patch, or is it necessary to add a limitation for
> supported devices only ?

Yes, only SAMA5D2 supports fractionnal baudrate in other modes than the
normal one. A new compatible string may be added, I am not sure you have
enough information in atmel_get_ip_name...

Regards

Ludovic

> 
> Best regards,
> -- 
> Romain Izard

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fractional divider on the Atmel USART controller
  2017-02-06 11:56 Fractional divider on the Atmel USART controller Romain Izard
  2017-02-06 13:42 ` Ludovic Desroches
@ 2017-02-06 13:47 ` Richard Genoud
  1 sibling, 0 replies; 8+ messages in thread
From: Richard Genoud @ 2017-02-06 13:47 UTC (permalink / raw)
  To: Romain Izard, linux-arm-kernel, linux-serial, LKML,
	Ludovic Desroches, Nicolas Ferre

Hi Romain,
On 06/02/2017 12:56, Romain Izard wrote:
> Hello,
> 
> On Atmel SAMA5D2, when trying to configure a serial port for 3 Mbauds
> operation, I do not always get the requested baud rate. If the hardware
> flow control is disabled by software, the line works correctly. But if I
> set the crtscts option, the line does not work, and after checking the
> line I can observe that the signal is sent at 2.6 Mbauds.
> 
> This is due to the code used to manage fractional baud rate divisor: the
> existing code prevents the fractional bits from being used if the line
> is not configured in normal mode. This case occurs when the hardware
> flow control or the RS485 mode is set.
> 
> If I apply the following patch to drivers/tty/serial/atmel_serial.c,
> I get the required baudrate.
> 
> 8<----------------------------------------------------------------
> 
> @@ -2204,14 +2204,13
>       * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
>       * Currently, OVER is always set to 0 so we get
>       * baudrate = selected clock / (16 * (CD + FP / 8))
>       * then
>       * 8 CD + FP = selected clock / (2 * baudrate)
>       */
> -    if (atmel_port->has_frac_baudrate &&
> -        (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
> +    if (atmel_port->has_frac_baudrate) {
>          div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
>          cd = div >> 3;
>          fp = div & ATMEL_US_FP_MASK;
>      } else {
>          cd = uart_get_divisor(port, baud);
>      }
> 
> 8<----------------------------------------------------------------
> 
> Unfortunately, I know that this will work on SAMA5D2, but this driver is
> used for many other Atmel chips. I do not know if the existing code is
> meant to respect a known limitation on other devices that use the same
> controller, or if it is just a bug.
> 
> Ludovic, Nicolas,  what is your opinion on that matter? Should I just
> propose this as a patch, or is it necessary to add a limitation for
> supported devices only ?
> 
> Best regards,
> 
Looking at the SAMA5D3 datasheet §44.7.1.2 Fractional Baud Rate in
Asynchronous Mode :
[...] This feature is only available when using USART
normal mode.
Same for SAM9G20 (§31.6.1.3 Fractional Baud Rate in Asynchronous Mode)

But this restriction doesn't seem to apply for SAMA5D2.
I guess it's a new feature in the FLEXCOM.

So, yes, your patch will break existing platforms, but something should
definitely be done to make that work on SAMA5D2.

One way to do that would be to modify the has_frac_baudrate into an enum
(no_support, partial_support and full_support) and then fill the value
according to the ATMEL_US_NAME/ATMEL_US_VERSION.
But I'm not sure if we have enough information to sort this.
I'll have a look on the different name/version we have on sama5D2 / D3 /
g20.

Richard.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fractional divider on the Atmel USART controller
  2017-02-06 13:42 ` Ludovic Desroches
@ 2017-02-06 14:58   ` Richard Genoud
  2017-02-06 15:37     ` Ludovic Desroches
  2017-02-06 15:14   ` Romain Izard
  1 sibling, 1 reply; 8+ messages in thread
From: Richard Genoud @ 2017-02-06 14:58 UTC (permalink / raw)
  To: Romain Izard, linux-arm-kernel, linux-serial, LKML,
	Ludovic Desroches, Nicolas Ferre

Hi Ludovic,

On 06/02/2017 14:42, Ludovic Desroches wrote:
> Hello Romain,
> 
> On Mon, Feb 06, 2017 at 12:56:42PM +0100, Romain Izard wrote:
>> Hello,
>>
>> On Atmel SAMA5D2, when trying to configure a serial port for 3 Mbauds
>> operation, I do not always get the requested baud rate. If the hardware
>> flow control is disabled by software, the line works correctly. But if I
>> set the crtscts option, the line does not work, and after checking the
>> line I can observe that the signal is sent at 2.6 Mbauds.
>>
>> This is due to the code used to manage fractional baud rate divisor: the
>> existing code prevents the fractional bits from being used if the line
>> is not configured in normal mode. This case occurs when the hardware
>> flow control or the RS485 mode is set.
>>
>> If I apply the following patch to drivers/tty/serial/atmel_serial.c,
>> I get the required baudrate.
>>
>> 8<----------------------------------------------------------------
>>
>> @@ -2204,14 +2204,13
>>       * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
>>       * Currently, OVER is always set to 0 so we get
>>       * baudrate = selected clock / (16 * (CD + FP / 8))
>>       * then
>>       * 8 CD + FP = selected clock / (2 * baudrate)
>>       */
>> -    if (atmel_port->has_frac_baudrate &&
>> -        (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
>> +    if (atmel_port->has_frac_baudrate) {
>>          div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
>>          cd = div >> 3;
>>          fp = div & ATMEL_US_FP_MASK;
>>      } else {
>>          cd = uart_get_divisor(port, baud);
>>      }
>>
>> 8<----------------------------------------------------------------
>>
>> Unfortunately, I know that this will work on SAMA5D2, but this driver is
>> used for many other Atmel chips. I do not know if the existing code is
>> meant to respect a known limitation on other devices that use the same
>> controller, or if it is just a bug.
> 
> It depends on the device used. In the SAMA5D4 datasheet, it is
> mentionned: "This feature is only available when using USART normal mode".

It seems you have an old datasheet version, because in table 60.2 (page 1784) of SAMA5D4 datasheet (rev D), there's :

Section 43.6.1.2 “Fractional Baud Rate in Asynchronous Mode”: added warning “When the value of field FP
is greater than 0...”; removed sentence “This feature is only available when using USART normal mode.”

So I guess this should also work on SAMA5D4 ? 


> In the SAMA5D2 datasheet, this constraint is no longer mentionned you
> confirm that is works, that is great.
> 
>>
>> Ludovic, Nicolas,  what is your opinion on that matter? Should I just
>> propose this as a patch, or is it necessary to add a limitation for
>> supported devices only ?
> 
> Yes, only SAMA5D2 supports fractionnal baudrate in other modes than the
> normal one. A new compatible string may be added, I am not sure you have
> enough information in atmel_get_ip_name...

I checked the version numbers on some atmel platforms I have:

AT91SAM9G35 / SAMA5D3: 0x502
AT91SAM9G20: 0x10330
SAMA5D2: 0x814

Ludovic, could you please check the version number of the SAMA5D4 USART (if you have one lying around) ?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fractional divider on the Atmel USART controller
  2017-02-06 13:42 ` Ludovic Desroches
  2017-02-06 14:58   ` Richard Genoud
@ 2017-02-06 15:14   ` Romain Izard
  2017-02-06 15:30     ` Romain Izard
  1 sibling, 1 reply; 8+ messages in thread
From: Romain Izard @ 2017-02-06 15:14 UTC (permalink / raw)
  To: Romain Izard, linux-arm-kernel, linux-serial, LKML,
	Nicolas Ferre, Richard Genoud, Ludovic Desroches

2017-02-06 14:42 GMT+01:00 Ludovic Desroches <ludovic.desroches@microchip.com>:
> Hello Romain,
>
> On Mon, Feb 06, 2017 at 12:56:42PM +0100, Romain Izard wrote:
>>
>> Unfortunately, I know that this will work on SAMA5D2, but this driver is
>> used for many other Atmel chips. I do not know if the existing code is
>> meant to respect a known limitation on other devices that use the same
>> controller, or if it is just a bug.
>
> It depends on the device used. In the SAMA5D4 datasheet, it is
> mentionned: "This feature is only available when using USART normal mode".
>
> In the SAMA5D2 datasheet, this constraint is no longer mentionned you
> confirm that is works, that is great.
>

For verification, I checked the SAMA5D2 datasheet, and (in rev. D) the
warning is still present in §41.7.1.2. Unfortunately, I did not test the
CTS/RTS mode directly, and I would not go as far as claiming that it
works without any reservation.

In my original use case, the hardware handshaking was activated
automatically when loading the HCILL line discipline to access the
Bluetooth part of a TI WL1831 chip. Fixing the baud rate issue was
enough to restore the Bluetooth stack to the working state I had when I
used the linux4sam 5.3 branch, but I am not sure of how the handshaking
is really used in practice.

Best regards,
-- 
Romain Izard

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fractional divider on the Atmel USART controller
  2017-02-06 15:14   ` Romain Izard
@ 2017-02-06 15:30     ` Romain Izard
  0 siblings, 0 replies; 8+ messages in thread
From: Romain Izard @ 2017-02-06 15:30 UTC (permalink / raw)
  To: Romain Izard, linux-arm-kernel, linux-serial, LKML,
	Nicolas Ferre, Richard Genoud, Ludovic Desroches

2017-02-06 16:14 GMT+01:00 Romain Izard <romain.izard.pro@gmail.com>:
>
> For verification, I checked the SAMA5D2 datasheet, and (in rev. D) the
> warning is still present in §41.7.1.2.

It looks like I got confused with between the versions. In fact, the warning
disappeared between versions C & D, and the last version (E) does not
have it.

-- 
Romain Izard

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fractional divider on the Atmel USART controller
  2017-02-06 14:58   ` Richard Genoud
@ 2017-02-06 15:37     ` Ludovic Desroches
  2017-02-09 13:33       ` Ludovic Desroches
  0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Desroches @ 2017-02-06 15:37 UTC (permalink / raw)
  To: Richard Genoud
  Cc: Romain Izard, linux-arm-kernel, linux-serial, LKML,
	Ludovic Desroches, Nicolas Ferre

On Mon, Feb 06, 2017 at 03:58:52PM +0100, Richard Genoud wrote:
> Hi Ludovic,
> 
> On 06/02/2017 14:42, Ludovic Desroches wrote:
> > Hello Romain,
> > 
> > On Mon, Feb 06, 2017 at 12:56:42PM +0100, Romain Izard wrote:
> >> Hello,
> >>
> >> On Atmel SAMA5D2, when trying to configure a serial port for 3 Mbauds
> >> operation, I do not always get the requested baud rate. If the hardware
> >> flow control is disabled by software, the line works correctly. But if I
> >> set the crtscts option, the line does not work, and after checking the
> >> line I can observe that the signal is sent at 2.6 Mbauds.
> >>
> >> This is due to the code used to manage fractional baud rate divisor: the
> >> existing code prevents the fractional bits from being used if the line
> >> is not configured in normal mode. This case occurs when the hardware
> >> flow control or the RS485 mode is set.
> >>
> >> If I apply the following patch to drivers/tty/serial/atmel_serial.c,
> >> I get the required baudrate.
> >>
> >> 8<----------------------------------------------------------------
> >>
> >> @@ -2204,14 +2204,13
> >>       * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
> >>       * Currently, OVER is always set to 0 so we get
> >>       * baudrate = selected clock / (16 * (CD + FP / 8))
> >>       * then
> >>       * 8 CD + FP = selected clock / (2 * baudrate)
> >>       */
> >> -    if (atmel_port->has_frac_baudrate &&
> >> -        (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
> >> +    if (atmel_port->has_frac_baudrate) {
> >>          div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
> >>          cd = div >> 3;
> >>          fp = div & ATMEL_US_FP_MASK;
> >>      } else {
> >>          cd = uart_get_divisor(port, baud);
> >>      }
> >>
> >> 8<----------------------------------------------------------------
> >>
> >> Unfortunately, I know that this will work on SAMA5D2, but this driver is
> >> used for many other Atmel chips. I do not know if the existing code is
> >> meant to respect a known limitation on other devices that use the same
> >> controller, or if it is just a bug.
> > 
> > It depends on the device used. In the SAMA5D4 datasheet, it is
> > mentionned: "This feature is only available when using USART normal mode".
> 
> It seems you have an old datasheet version, because in table 60.2 (page 1784) of SAMA5D4 datasheet (rev D), there's :
> 

Right, it seems there was an update of all sama5 datasheet to remove
this constraint. I don't know if it concerns also old devices, I'll try
to get more information.

> Section 43.6.1.2 “Fractional Baud Rate in Asynchronous Mode”: added warning “When the value of field FP
> is greater than 0...”; removed sentence “This feature is only available when using USART normal mode.”
> 
> So I guess this should also work on SAMA5D4 ? 
> 
> 
> > In the SAMA5D2 datasheet, this constraint is no longer mentionned you
> > confirm that is works, that is great.
> > 
> >>
> >> Ludovic, Nicolas,  what is your opinion on that matter? Should I just
> >> propose this as a patch, or is it necessary to add a limitation for
> >> supported devices only ?
> > 
> > Yes, only SAMA5D2 supports fractionnal baudrate in other modes than the
> > normal one. A new compatible string may be added, I am not sure you have
> > enough information in atmel_get_ip_name...
> 
> I checked the version numbers on some atmel platforms I have:
> 
> AT91SAM9G35 / SAMA5D3: 0x502
> AT91SAM9G20: 0x10330
> SAMA5D2: 0x814
> 
> Ludovic, could you please check the version number of the SAMA5D4 USART (if you have one lying around) ?
> 

SAMA5D4: 0x701

Regards

Ludovic

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fractional divider on the Atmel USART controller
  2017-02-06 15:37     ` Ludovic Desroches
@ 2017-02-09 13:33       ` Ludovic Desroches
  0 siblings, 0 replies; 8+ messages in thread
From: Ludovic Desroches @ 2017-02-09 13:33 UTC (permalink / raw)
  To: Richard Genoud, Romain Izard, linux-arm-kernel, linux-serial,
	LKML, Ludovic Desroches, Nicolas Ferre

On Mon, Feb 06, 2017 at 04:37:23PM +0100, Ludovic Desroches wrote:
> On Mon, Feb 06, 2017 at 03:58:52PM +0100, Richard Genoud wrote:
> > Hi Ludovic,
> > 
> > On 06/02/2017 14:42, Ludovic Desroches wrote:
> > > Hello Romain,
> > > 
> > > On Mon, Feb 06, 2017 at 12:56:42PM +0100, Romain Izard wrote:
> > >> Hello,
> > >>
> > >> On Atmel SAMA5D2, when trying to configure a serial port for 3 Mbauds
> > >> operation, I do not always get the requested baud rate. If the hardware
> > >> flow control is disabled by software, the line works correctly. But if I
> > >> set the crtscts option, the line does not work, and after checking the
> > >> line I can observe that the signal is sent at 2.6 Mbauds.
> > >>
> > >> This is due to the code used to manage fractional baud rate divisor: the
> > >> existing code prevents the fractional bits from being used if the line
> > >> is not configured in normal mode. This case occurs when the hardware
> > >> flow control or the RS485 mode is set.
> > >>
> > >> If I apply the following patch to drivers/tty/serial/atmel_serial.c,
> > >> I get the required baudrate.
> > >>
> > >> 8<----------------------------------------------------------------
> > >>
> > >> @@ -2204,14 +2204,13
> > >>       * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
> > >>       * Currently, OVER is always set to 0 so we get
> > >>       * baudrate = selected clock / (16 * (CD + FP / 8))
> > >>       * then
> > >>       * 8 CD + FP = selected clock / (2 * baudrate)
> > >>       */
> > >> -    if (atmel_port->has_frac_baudrate &&
> > >> -        (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
> > >> +    if (atmel_port->has_frac_baudrate) {
> > >>          div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
> > >>          cd = div >> 3;
> > >>          fp = div & ATMEL_US_FP_MASK;
> > >>      } else {
> > >>          cd = uart_get_divisor(port, baud);
> > >>      }
> > >>
> > >> 8<----------------------------------------------------------------
> > >>
> > >> Unfortunately, I know that this will work on SAMA5D2, but this driver is
> > >> used for many other Atmel chips. I do not know if the existing code is
> > >> meant to respect a known limitation on other devices that use the same
> > >> controller, or if it is just a bug.
> > > 
> > > It depends on the device used. In the SAMA5D4 datasheet, it is
> > > mentionned: "This feature is only available when using USART normal mode".
> > 
> > It seems you have an old datasheet version, because in table 60.2 (page 1784) of SAMA5D4 datasheet (rev D), there's :
> > 
> 
> Right, it seems there was an update of all sama5 datasheet to remove
> this constraint. I don't know if it concerns also old devices, I'll try
> to get more information.
> 

The restriction to normal mode is no longer needed for all products.
Datasheet of old SoCs have not been updated.

Limiting the fractional baudrate was too restrictive. It works with
other modes but there is a warning (section 44.10.24 in SAMA5D2
datasheet):
"Warning: When the value of field FP is greater than 0, the SCK
(oversampling clock) generates non-constant duty cycles.
The SCK high duration is increased by “selected clock” period from time
to time. The duty cycle depends on the value of
the CD field."

In some situations, it may cause problems especially with ISO7816 mode.

> > Section 43.6.1.2 “Fractional Baud Rate in Asynchronous Mode”: added warning “When the value of field FP
> > is greater than 0...”; removed sentence “This feature is only available when using USART normal mode.”
> > 
> > So I guess this should also work on SAMA5D4 ? 
> > 
> > 
> > > In the SAMA5D2 datasheet, this constraint is no longer mentionned you
> > > confirm that is works, that is great.
> > > 
> > >>
> > >> Ludovic, Nicolas,  what is your opinion on that matter? Should I just
> > >> propose this as a patch, or is it necessary to add a limitation for
> > >> supported devices only ?
> > > 

I think you can propose this as a patch. Adding the datasheet warning as
comment and commit message could be helpful.

Regards

Ludovic

> > > Yes, only SAMA5D2 supports fractionnal baudrate in other modes than the
> > > normal one. A new compatible string may be added, I am not sure you have
> > > enough information in atmel_get_ip_name...
> > 
> > I checked the version numbers on some atmel platforms I have:
> > 
> > AT91SAM9G35 / SAMA5D3: 0x502
> > AT91SAM9G20: 0x10330
> > SAMA5D2: 0x814
> > 
> > Ludovic, could you please check the version number of the SAMA5D4 USART (if you have one lying around) ?
> > 
> 
> SAMA5D4: 0x701
> 
> Regards
> 
> Ludovic

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-02-09 13:33 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-06 11:56 Fractional divider on the Atmel USART controller Romain Izard
2017-02-06 13:42 ` Ludovic Desroches
2017-02-06 14:58   ` Richard Genoud
2017-02-06 15:37     ` Ludovic Desroches
2017-02-09 13:33       ` Ludovic Desroches
2017-02-06 15:14   ` Romain Izard
2017-02-06 15:30     ` Romain Izard
2017-02-06 13:47 ` Richard Genoud

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).