[parisc-linux] serial baud_base, high baud rates and divisors

Enrik Berkhan Enrik.Berkhan@planb.de
Thu, 7 Feb 2002 13:08:52 +0100


when using a 720 (running linux, of course ;-) as serial console
for a 715(old) I've noticed that the terminal (720) produces garbage
when the 715 comes to the firmware prompt (both running at 115200).
This is not a flow control or something problem. Investigating on
that I've found some oddities concerning setserial, baud_base and
the divisor calculation in the serial driver ...

- by default all parisc serial devices' baud_base is set to 454545
  (derived from the LASI UART crystal's frequency). The actual divisor
  is calculated in change_speed() of serial.c to be

  quot = baud_base / baud;

  with all integers. Thus, 454545 / 115200 = 3. The resulting baud
  rate should be something like 454545 / 3 = 151515. That's somewhat
  far away from 115200, explaining the garbage.

- I've made a simple measurement of the actual baud rate using a DMM
  with builtin frequency counter: set the port to 8N1 and outputting
  0x55 continously should produce a square wave of half the baud rate
  frequency at the transmit pin. So I've verified that at least the
  720 seems to have a real baud_base of 460800 (the measured frequency
  was 57.6kHz for a divisor of 4).

- trying to change the baud_base using setserial to 460800 failed with
  EADDRINUSE. I've found the reason to be a loop in set_serial_info():

        /* Make sure address is not already in use */
        if (new_serial.type) {
                for (i = 0 ; i < NR_PORTS; i++)
                        if ((state != &rs_table[i]) &&
                            (rs_table[i].port == new_port) &&
                                return -EADDRINUSE;

  Memory mapped parisc ports all have port == 0, so this has to fail.
  Temporary workaround: `setserial /dev/ttyS1 port 0x10000 ...' once
  will prevent the above loop from finding conflicts.

So, the following things have to be fixed:

- get/set_serial_info have to be enhanced for memory mapped ports
- setserial should be enhanced accordingly
- divisor calculation should be changed at least to round to nearest,
  not round towards zero, or LASI ports might still suffer from the first
  problem _if_ they really have baud_base 454545
- baud_base should be initialized correctly for other gsc based ports.

If someone can confirm my analysis and tell me the direction of how to
fix these things I would be willing to work on it (shouldn't be hard,
maybe boring ;-).

Enrik Berkhan                                         plan b. GmbH
                                                      Rüppurrer Straße 4
+49-721-388582 (voice)                                76137 Karlsruhe
+49-721-388581 (fax)                                  Germany