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

[Pali Rohár]

PING. Any progress in this direction? Any comments or objections in this approach?

On Saturday 25 September 2021 16:23:13 Pali Rohár wrote:
> 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