On 26/02/15 13:45, Peter Hurley wrote: > Hi James, > > On 02/26/2015 06:25 AM, James Hogan wrote: >> Hi Sebastian, >> >> On 26/02/15 08:51, Sebastian Andrzej Siewior wrote: >>> On 02/26/2015 01:21 AM, James Hogan wrote: >>>> When the UART clock is set slightly under 1.8432MHz, the 8250 driver >>>> core doesn't permit the 115200 baud rate since it calculates the maximum >>>> frequency to pass to uart_get_baud_rate by simply dividing the uart >>>> clock by 16 which yields a value slightly under 115200, even though the >>>> frequency is close enough for the UART to operate reliably. >>>> >>>> Therefore add some tolerance in the calculation of the maximum baud >>>> rate, specifically +1/128th (~0.8%), to allow the 115200 baud rate to >>>> be closen for a UART clock as low as 1.8149MHz. For an external divider >>>> set as close as possible to 1.8432MHz, this should cover every possible >>>> input frequency above 118.9MHz. >>>> >>>> Signed-off-by: James Hogan <james.hogan@xxxxxxxxxx> >>>> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> >>>> Cc: Jiri Slaby <jslaby@xxxxxxx> >>>> Cc: Anton Vorontsov <avorontsov@xxxxxxxxxxxxx> >>>> Cc: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> >>>> Cc: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> >>>> Cc: linux-serial@xxxxxxxxxxxxxxx >>>> --- >>>> As far as I can tell from reading the link below, this tolerance should >>>> be okay, and it definitely covers the range of input frequencies I >>>> expect for my particular hardware. I'm open to better ways of handling >>>> it though. >>> >>> What is your hardware? >> >> SoC is TZ1090 (metag based). UART clock is best derived from system >> clock which would normally be somewhere between 180MHz and 240MHz, using >> an integer divider. >> >>> (1814900 + 1814900 / 128) / 16 >>> 114317 >>> It is not 115200 but close enough to get you the 115200 baud rate. It >>> might make sense to increase the tolerance rather than increasing the >>> the clock but it is up to Peter / Alan to decide. >> >> One random example configuration I have here is: >> >> # cat /sys/kernel/debug/clk/clk_summary >> clock enable_cnt prepare_cnt rate >> -------------------------------------------------------------------- >> xtal1 2 2 24576000 >> sys_sw 1 1 24576000 >> sys_pll 1 1 719965090 >> sys_div 1 1 719965090 >> sys_x2_undeleted 1 1 719965090 >> sys_undeleted 2 2 179991273 >> uart_sw 1 1 179991273 >> uart_en 1 1 179991273 >> uart 1 1 1836646 >> >> sys_undeleted divide uart baud error >> 179991273 97 1855580 115973 774 = 0.67% >> 179991273 98 1836646 114790 -410 = -0.36% (chosen) >> >> At this sys_undeleted frequency, the difference between two consecutive >> divider values is about 1183 Hz. >> For round to closest, the max error is about 591.5 Hz = 0.513%. >> For round up (i.e. increasing the clock), the max error is about 1183 Hz >> = 1.03%. >> >> So my reasoning is that rounding to closest and fixing 8250 driver to >> accept it and getting as accurate a baud rate as possible is better than >> having a less accurate baud rate and having to add a new rounding mode >> to common clock muxes and dividers. >> >> Note that AFAICT for faster input clocks the 8250 driver would accept a >> 115200 baud rate regardless of how inaccurate the resulting baud rate >> would be after division, so arguably the tolerance could be much higher. >> >> The serial core also calculates the divider with DIV_ROUND_CLOSEST, so >> there is precedent for using that rounding mode right up through the >> clock tree. > > Why clock the uart so low? I tried forcing uart = sys_undeleted / 1 a couple of years ago when switching to common clock & DT, relying instead on the divider internal to the UART, but it didn't work for everybody. It was presumed at the time that the UART input was effectively being overclocked between the divider and the uart so wasn't reliable at higher frequencies. The hardware manual lists Fmax/ideal as 25MHz, but I didn't want to set it to a specific value such as 25MHz as the combination of the 2 dividers (the one in the uart block and the external one in the SoC) will reduce the precision that can be attained. So that really only leaves the option of aiming for the right uart frequency with the external divider and using an internal divide by 1. Cheers James
Attachment:
signature.asc
Description: OpenPGP digital signature
