On Fri, 1 Oct 2004, Daniel Carosone wrote:

> On Fri, Oct 01, 2004 at 10:17:37AM +1000, Daniel Carosone wrote:
>> On Thu, Sep 30, 2004 at 02:32:35PM -0500, Frederick Bruckman wrote:
>>>
>>> Try building a current kernel with options COM_16650 (COM16650 on 2.0).
>>
>> Well, this is interesting.  I saw that option in the sources, but my
>> eyes misled me to read it as 16550 and I just assumed it was on.
>>
>> However, cu still doesn't accept -s >115200, nor does stty.
>> EINVAL from tcsetattr.
>
> And on further reading, I can't really see how it makes a difference
> for speed; the #ifdef'd code is only at probe time, and results in a
> sc->sc_fifolen = 32, but nothing that I can see affects the speed or
> the frequency (like is done for the HAYESP).
>
> Likewise, comspeed() takes a type argument that goes unused, even if
> sc_type were set differently for 16650, which it isn't.
>
> Is the 16650 support incomplete?

Oh, yes. I have fashioned some patches against netbsd-1-6 to set the 
multiplier, vary the trigger level dynamically, and a couple of other 
things.  The multiplier is actually a small part of it, and I'd 
forgotten about that.

Here's the patch I've been running on my ISDN-TA-connected mail server 
for five months now:

   ftp://ftp.netbsd.org/pub/NetBSD/misc/fredb/com-netbsd-1-6.diff

Unfortunately, intervening changes make a pull-down to current 
non-trivial. I'm also not happy with the design. As it is, you must 
recompile to turn features such as the dynamic trigger level and 
AUTO_RTS off and on. I think it would be better to let a utility 
handle that at run-time, through sysctls.  Also, the "burst" thing 
doesn't work at all.


Frederick