Re: kernel 5.19.8: "Oxford Semiconductor Ltd OXPCIe952 Dual Native 950 UART" gets wrong baudrate (PCI ID 1415:c158)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Seems like CPR/CPR2 does not affect baudrate, so maybe EFR bit 4 (enhance mode) is not set?
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

/Anders

On 2022-09-13 18:19, Maciej W. Rozycki wrote:
Hi Anders,

  Sorry to cause you trouble.

I really don't know what to do here, sorry.  Are you saying a specific
commit has broken this?  If so, did you test if you made a change it
fixed the issue?

Yes, commit 366f6c955d4d1a5125ffcd6875ead26a3c7a2a1c broke the one to one
correspondence
between programmed and actual baudrate; reverting it (and
9c5c8aaed50bf3478073ab51b8b1f3f5327d3cfa
that builds on that patch) restores the expected functionality (i.e. you get
the baudrate you ask for)
on 5.19.8.

  I have implemented the calculation using parameters from original OxSemi
datasheets and verified this code across three architectures available to
me (POWER9, RISC-V, 32-bit x86) and a couple of cards made by different
manufacturers connected to a non-OxSemi serial device each at the other
end.  I have checked the usual baud rates of up to 460800bps.  Higher baud
rates work too, though I could only try them between OxSemi devices, so
actual rates were not verified for correctness.

  And offhand I can say it works just fine at 230400bps with 6.0.0-rc2 as
at commit 10d4879f9ef0 and my RISC-V machine (using an EXSYS EX-44171
1S+1P port PCIe option card, built around the OXPCIe952 too) talking to a
remote console server in my lab.  I don't have an oscilloscope available
to check actual waveforms produced.

What do you suggest happen here?
Either there is a bug in the code, or the chipset on my card (a Delock 2xRS232
card) is not a true oxford
chipset (the package and PCI id's says that they are).

  A bug can never be ruled out.  I doubt that Delock would use a fake chip
or indeed that anyone would choose to clone an OxSemi part, which seems
fairly complex to me for a serial port.

Since the chip seems to be discontinued since 2014 (see
https://www.mouser.com/PCN/PLX_Technology_2013_8.pdf),
I think a revert would not be uncalled for.

  The problem is the original calculation is inaccurate enough for the
serial interface not to communicate correctly at higher baud rates.  I
found setting two stop bits while talking to a remote end that has one
stop bit set a possible workaround for some cases, but why not do the
calculation correctly in the first place?

  If you're willing to debug it, then I'll be more than happy to supply you
with diagnostic patches, some of which I made in the development of the
fix.  Also what processor architecture do you use the interface with?

   Maciej

--
Anders Blomdell                  Email: anders.blomdell@xxxxxxxxxxxxxx
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118
SE-221 00 Lund, Sweden



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux