Re: [PATCH v2 0/2] serial: 8250_ingenic: Set UMR and UACR, add the X1600

[H. Nikolaus Schaller]

Hi,

> Am 25.10.2026 um 00:07 schrieb Olivier Louvignes <olivier@xxxxxxxxx>:
> 
> Ingenic UARTs carry a bit clock count (UMR) and a per-bit adjustment
> (UACR) that the driver never sets, so a UART runs with whatever was left
> there. On the X1600 of a HiBy R1 neither the vendor's 8 nor the reset
> value 0 gives the 16 clocks a bit the 8250 divisor assumes, and the
> Bluetooth chip on UART0 fails to set up. Patch 2 sets 16 and 0 at probe.

I am still not convinced that this is a x1600 kernel issue or something
that should be solved in kernel code.

On our LX16 board all 4 UARTs come up with UMR value 0x10.

> 
> Changes since v1:
> - Set UMR and UACR on every Ingenic UART rather than in an X1600 entry,
>  as Nikolaus asked: the JZ4725, JZ4740, JZ4755, JZ4760, X1000, X1830,
>  X2000 and X1600 programming manuals all have them at 0x24 and 0x28.

That was not what I have suggested. I asked to a mechanism that allows to
tailor this if the boot loader fails to provide the correct value.

> - Write 16 rather than the reset value: with UMR at 0 the R1's Bluetooth
>  chip fails just as it does with 8.

Ok, it would not harm our boards, but there we get the right value anyways.

> - The binding keeps the X1600 compatible with the X1000's as fallback;
>  the driver needs no entry of its own.
> - Rebased on tty-next.
> 
> I could only test the X1600. On the other SoCs this writes the value the
> divisor already assumes.

On our LX16 I find in U-Boot the default value 0x00 for UART0, 1 and 3 
and 0x10 for UART2 (which is the serial console activated by U-Boot):

lx16# 
lx16# md.l 10030024 1
10030024: 00000000                               ....
lx16# md.l 10031024 1
10031024: 00000000                               ....
lx16# md.l 10032024 1
10032024: 00000010                               ....
lx16# md.l 10033024 1
10033024: 00000000                               ....
lx16# 

But after booting into Linux (without your patch):

root@letux-lx16v0-3:~# devmem2 0x10030024
/dev/mem opened.
Memory mapped at address 0x77e61000.
Value at address 0x0x10030024 (0x77e61024): 0x10
root@letux-lx16v0-3:~# devmem2 0x10031024
/dev/mem opened.
Memory mapped at address 0x77e05000.
Value at address 0x0x10031024 (0x77e05024): 0x10
root@letux-lx16v0-3:~# devmem2 0x10032024
/dev/mem opened.
Memory mapped at address 0x77eb0000.
Value at address 0x0x10032024 (0x77eb0024): 0x10
root@letux-lx16v0-3:~# devmem2 0x10033024
/dev/mem opened.
Memory mapped at address 0x77ea1000.
Value at address 0x0x10033024 (0x77ea1024): 0x10
root@letux-lx16v0-3:~# 

So something is already setting the UMR register properly on our x1600
without your patch.

I am not at all a specialist for the 8250/16650 but I got the impression that
what we call UMR in x1600 language could be the UART_XR_EFR register
in 8250 language.

There is a function called default_setup() in 8250_exar.c which says that
some UARTs have an extra divisor register.

This all sounds like some standard code might already be responsible to set
the UMR registers to 0x10 for UARTs initialized on the x1600?

But that needs deeper analysis than I have done for now.

BR,
Nikolaus