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