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? Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
