From owner-freebsd-hackers Thu Aug 28 17:21:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28844 for hackers-outgoing; Thu, 28 Aug 1997 17:21:22 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA28831; Thu, 28 Aug 1997 17:21:02 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA18886; Thu, 28 Aug 1997 17:13:26 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd018880; Fri Aug 29 00:13:24 1997 Date: Thu, 28 Aug 1997 17:13:11 -0700 (PDT) From: Julian Elischer To: Bruce Evans cc: bde@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: sio.c "turbo mode" additions. In-Reply-To: <199708281549.BAA26250@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 29 Aug 1997, Bruce Evans wrote: > >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). Why should we limit our baud rates to thise used by linux? if we use a standard baud rate (e.g. 9600) they will still be able to do it right? I don't see this as much of an argument. certainly it might be possible to "mask" the baud rates to those that are expected, but I don't see how removing the table has any bad effects as the only things looking at that table were in sio.c There are times when I'd have liked to be able to run at 1500 baud. I've seen it in some non standard radio gear. and the console driver allows aby speed to be set without too much problem.. (sc on my 2.1.laptop anyhow) I presume that these probrams you mention will only have problems if I set the baud rate to 1700 or similar. I'd like to set the xtal rate, or the max baudrate, as you said, but I wanted to describe the change in the flags with the 4 bits I could perloin. > > >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). no, I want to be able to use this regardless of how available the com structure values are.. the siocn-xxx() functions don't have a pointer to the appropriate devconf or softc structures, so they need a global to use. I admit that it could easily be initialised from teh devconf struct at the time that it is probed for the 'CAN BE CONSOLE' bit but in our case here, we have a file that contains code that hits soem special registers to double the baud rate. this same code doubles the multiplier at the same time, so that the console code always works at the right speed, both before and after the hardware has been nobbled. > > > /* 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); > >! } A flag f 0 gives a multiple of 1. a value of 0 indicates an unexpected code path that leaves ot uninitialised.. this should be in "DIAGNOSTIC" and should be removed when I'm a bit more confident that I didn'r have such a path left in the code. > > 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)). yes, that's not a bad idea.. I still don't understand your need for the table. if you use an unexpected baudrate, then some things are unable to correctly interrogate the speed. This doesn't seem like a problem to me as it's almost always going to be set to a standard speed. can you explain this a bit better, and in general do you think that the ability to handle 'turbo' sio ports (becoming more common these days) is bad or worth while? I would like to re-do the interaction between siocn_xx() and the normal driver a bit better. but I didn't want to change everything as I want a HOPE of puting this in 2.2.3 (where I actually need it) julian > > Bruce >