Date: Fri, 29 Aug 1997 01:49:52 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@freebsd.org, julian@whistle.com Cc: hackers@freebsd.org Subject: Re: sio.c "turbo mode" additions. Message-ID: <199708281549.BAA26250@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Here are a set of diffs that allow the sio driver in 2.2.2 to take
>into account that the hardware has had it's clock doubled (or more),
>and to use any baud rate that it can reach within 4%. (the usual
>standard).
>...
>Other than style (you always don't like my style so I take
>that for granted) What objections/problems do you see in this?
Nonstandard speeds break the speed tables in kern/tty_compat.c,
i386/ibcs2/ibcs2_ioctl.c, i386/linux/linux_ioctl.c, rlogin and
window (speeds set using termios get corrupted when a program
saves and "restores" them using sgttyb). You have to extend these
tables. The BSD tables are limited to 127 entries. The ibcs2
table is limited to 16 entries and can't even support speeds 57600
and 115200. The linux table is limited to 32 entries. Because of
this braindamage, I think it is a bug to support approximations
to standard speeds at the software level (standard speeds may
need to be approximated at the hardware level, e.g., 134.5 in sio).
>I run use this to get 230400 baud (and it shows up as 230400
>in the stty status information. It allows the kernel hacker
>to specify in his config line that a particular tty line is
>overclocked, from 1 to 16 times. 16 would give 1843200 baud.
I'd prefer to configure the fundamental divisor (115200 etc), but
this will have to wait until config provides more bits.
>+ int siocn_baud_multiple = 1; /* set from vendor startup code */
I think this variable is unnecessary - you can use the configured
value for everything (just be careful about converting the default
of 0 to 1 everywhere).
> /* check requested parameters */
>! if(com->baud_multiple == 0) { /* catch 0 as well */
>! com->baud_multiple = 1;
>! printf("sio%d: warning, baud multiple was 0\n", unit);
>! }
Flags of 0 are the default and shouldn't be warned about. The
multiple should be converted from 0 to 1 earlier (the new struct
member should actually be for (115200 * (the multiple)).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708281549.BAA26250>