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 <[email protected]> > > > > 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
