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

[Tom Rini]

On Wed, Apr 06, 2022 at 03:30:11PM +0200, Pali Rohár wrote:

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

I keep meaning to reply to this.  I think this is the right direction,
I'd just like to see it implemented for some other UARTs as well, and
this hasn't re-appeared at the top of my CONFIG migrate list yet.

> 
> 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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220406/1d925384/attachment.sig>