All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: linux-mips@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/5] serial, Malta: Fixes to magic multipliers for SMSC Super I/O UARTs
Date: Thu, 10 Jun 2021 20:38:22 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2105181800170.3032@angie.orcam.me.uk> (raw)

Hi,

 I've noticed our Malta platform serial driver does not take advantage of 
support for the special UART divisor values for the bit rates of 230400 
and 460800 bits per second its SMSC FDC37M817 Super I/O hardware provides.  

 Our 8250 core provides for these divisors via the UPF_MAGIC_MULTIPLIER 
flag, so I thought it would be a straightforward platform change, but it 
has turned out that the flag has AFAICT never worked (I wonder how people 
test those things).  The only platform currently in our tree that sets the 
flag uses it for a different purpose.

 I've fixed UPF_MAGIC_MULTIPLIER handling then in our 8250 core, added 
reporting so that people have a chance to know the rates are supported and 
then added the flag to Malta platform initialisers for Super I/O UARTs.  
I have examined YAMON sources to verify that we don't have to enable the 
special UART divisor values ourselves.  See individual change descriptions 
for further details.

 Verified with a WTI CPM-800 site manager device which supports bit rates 
of up to 230400bps.  Also verified at 230400bps and 460800bps with an 
EXSYS EX-44072 option card under Linux, based on the Oxford Semiconductor 
OXPCIe952 device in its native mode; our clock settings are however off 
enough for OxSemi PCIe devices for the former data rate only just working 
and the latter making transmission go out of sync with data corruption 
resulting.  Another patch series to fix OxSemi handling bugs follows then.

 Verification of the OxSemi patch series actually revealed an interesting 
peculiarity of the SMSC Super I/O IC that contradicts SMSC documentation.  
I have added a clarification as 1/5 of this patch series, originally meant 
to contain four patches only.  This has been confirmed both with the Malta 
board concerned here and my old x86 server, which also has a similar SMSC 
Super I/O part, although with high-speed operation not enabled by the 
BIOS.

 NB occasional input overruns were observed at 460800bps (with a MIPS 5Kc 
@160MHz running this Malta), which could be eliminated by lowering the 
`rx_trig_bytes' parameter to 4 from the default of 8 (the UART core in the 
FDC37M817 has a 16-byte FIFO), via sysfs.  Perhaps it would make sense to 
change the default, at least for the higher-speed ports?

 Please apply.

  Maciej

             reply	other threads:[~2021-06-10 18:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 18:38 Maciej W. Rozycki [this message]
2021-06-10 18:38 ` [PATCH 1/5] serial: 8250: Document SMSC Super I/O UART peculiarities Maciej W. Rozycki
2021-06-10 18:38 ` [PATCH 2/5] serial: 8250: Actually allow UPF_MAGIC_MULTIPLIER baud rates Maciej W. Rozycki
2021-06-10 18:38 ` [PATCH 3/5] serial: 8250: Handle custom baud rates in UPF_MAGIC_MULTIPLIER range Maciej W. Rozycki
2021-06-10 18:38 ` [PATCH 4/5] serial: core, 8250: Add a hook for extra port property reporting Maciej W. Rozycki
2021-06-15 13:19   ` Greg Kroah-Hartman
2021-06-26  4:12     ` Maciej W. Rozycki
2021-06-10 18:38 ` [PATCH 5/5] MIPS: Malta: Enable magic multipliers for Super I/O UARTs Maciej W. Rozycki

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=alpine.DEB.2.21.2105181800170.3032@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=tsbogend@alpha.franken.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.