On Tue, 13 Sep 2022, Anders Blomdell wrote:
> Seems like CPR/CPR2 does not affect baudrate, so maybe EFR bit 4 (enhance
> mode) is not set?
Thanks for assessing the problem. I've thought already it could be
misconfiguration.
> If CPR is stuck at 8 (1.0 scaling), it all makes sense, these corresponds to
> what the oscilloscope gives:
>
> 2400 -> tcr: 9, cpr: 18, quot: 1286
> 62500000/9/(8*.125)/1286 -> 5400
> 4800 -> tcr: 7, cpr: 23, quot: 647
> 2500000/7/(8*.125)/647 -> 13799
> 9600 -> tcr: 9, cpr: 9, quot: 643
> 62500000/9/(8*.125)/643 -> 10800.
> 19200 -> tcr: 8, cpr: 31, quot: 105
> 62500000/7/(8*.125)/105 -> 85034
> 38400 -> 62500000/14/(8*.125)/30 -> 148809
Agreed.
As the first debug aid could you please enable DEBUG_AUTOCONF at the top
of drivers/tty/serial/8250/8250_port.c and paste the relevant piece of
8250 initialisation recorded in the kernel log? This will confirm (or
contradict) correct operation of the port configuration sequence.
Also I have identified a code piece that handles the EFR in a destructive
manner, which I must have previously missed, namely a conditional block
guarded by UART_CAP_EFR in `serial8250_do_set_termios'. It should likely
be fixed, however it is supposed not to matter for OxSemi chips due to:
/* UART_CAP_EFR breaks billionon CF bluetooth card. */
.flags = UART_CAP_FIFO | UART_CAP_SLEEP,
which then leads to:
serial 0000:07:00.3: detected caps 00000700 should be 00000500
and consequently UART_CAP_EFR gets cleared and this code block isn't
supposed to be reached. Can you confirm the presence of a similar message
in your log?
NB it seems to me too big a hammer to have a generic serial port feature
globally disabled to work around an unidentified problem with an attached
particular serial device. Pavel, as the originator of commit d0694e2aeb81
("serial: unbreak billionton CF card") can you please explain what the
motivation was here?
I could only track down two message threads related to the problem:
<https://lore.kernel.org/lkml/20110106134254.68fa27ac@xxxxxxxxxxxxxxxxxxx/>
and:
<https://lore.kernel.org/linux-serial/4D001AF1.80902@xxxxxxxxxxxx/>
but no attempt to actually narrow the issue down (also ISTM like a feature
such as flow control ought to be controlled via a termios call rather than
globally disabled). Also could the corruption of the EFR in what is now
`serial8250_do_set_termios' (and used to be `serial8250_set_termios' then)
mentioned above be the culprit?
Maciej
