[RFC PATCH] RFC: Replace CONFIG_SYS_BAUDRATE_TABLE by board and UART driver rounding functions

[Pali Rohár]

On Saturday 25 September 2021 09:51:08 Tom Rini wrote:
> On Sat, Sep 25, 2021 at 02:19:58PM +0200, Pali Rohár wrote:
> 
> > Add new functions which returns the nearest baudrate and use them instead
> > of hardcoded and incomplete CONFIG_SYS_BAUDRATE_TABLE compile time option.
> > 
> > Add implementation of rounding function for serial_mvebu_a3700 driver and
> > also for A3720 Espressobin board which has integrated pl2303 USB<->UART
> > converter, which basically limits baudrates which can user set.
> > 
> > Completely remove CONFIG_SYS_BAUDRATE_TABLE defines from all A3720 boards
> > as now with rounding functions it is not used anymore.
> > 
> > NOTE: This is just an example how to kill CONFIG_SYS_BAUDRATE_TABLE compile
> > time definitions. I tested it that it works on A3720 Turris Mox board. I
> > have not tested A3720 Espressobin board yet.
> > 
> > More discussion on this approach is required, so take this just as RFC
> > change.
> > 
> > Signed-off-by: Pali Rohár <pali at kernel.org>
> 
> Thanks for doing this.  My first question is, is this really per-board?

There is per UART chipset rounding / limitation and this should be
implemented in UART driver (like I did it in serial_mvebu_a3700.c).

Then there can be per SoC limitation, e.g. SoC has unstable clock source
for high baudrates. Meaning that UART chipset can support higher
baudrates (as exposed by UART driver) but for some reasons they are not
possible on SoC.

And then there can be really per-board limitations, like it is for
Espressobin board. In most cases SoC has UART pins which people can
connect to other UART device (e.g. to other SoC with UART or to some
universal USB<->UART cables for "computers"). But Espressobin board
has integrated pl2303 chip which is soldered directly to A3720 SoC UART
pins. This pl2303 chip is USB<->UART converter and board itself has just
micro-USB port (which is soldered to this pl2303). So at the end you can
on this board use UART only via that integrated micro-USB port, which
talks with standard USB protocol.

Therefore on this board you have two limitations for UART baudrates.
First one is exposed by UART SoC chip (serial_mvebu_a3700.c) and second
one is exposed by what that pl2303 supports. And this second limitation
is board specific -- not A3720 SoC. Other boards with A3720 SoC, e.g.
Turris Mox has exposed directly UART pins and you are free to connect
any USB<->UART cable to these pins as you want.

And this design with soldered USB<->UART chip on the board is not rare.
So U-Boot should have better support for it.

Note that lot of times clock source for these USB<->UART chips and SoC
UART chip is different (because these USB based chips have its own
clock source). So there are less common supported baudrates which can be
used on the boards. And when talking about high speed baudrates (above
115200 bauds) then lot of times these "common supported baudrates" are
just non-standard baudrate numbers (e.g. 3 125 000 bauds). Because you
have to choose divisors both both chips to produce baudrate with only
about 2-3% difference.

> Or per SoC / UART chipset.  I would hope for example that for plain old
> ns16550s this would be a generic function, perhaps with an optional
> board call-out for board design limitations.  This does feel like a
> reasonable amount of code for platforms like this that were supporting
> what was the maximal rate table before.
> 
> -- 
> Tom