Xref: utzoo comp.unix.internals:3024 comp.unix.xenix.sco:2803
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uwm.edu!linac!att!ucbvax!van-bc!cynic!curt
From: curt@cynic.wimsey.bc.ca (Curt Sampson)
Newsgroups: comp.unix.internals,comp.unix.xenix.sco
Subject: DTR and the FAS serial driver
Message-ID: <1991Jun11.044804.7690@cynic.wimsey.bc.ca>
Date: 11 Jun 91 04:48:04 GMT
Sender: curt@cynic.wimsey.bc.ca (Curt Sampson)
Organization: Mad Artists' Technological Hangout
Lines: 118

I've just installed the FAS serial driver on my SCO Xenix 2.3.2
(286) system.  It's version 2.08, which is the latest, I believe.

Now, the driver works fine for the most part, including enabling
the FIFO on my 16550A UART.  (No most lost characters at 38.4 Kbps.
Yea!  :-))

However, it seems that the driver just ignores DTR completely.  It
doesn't raise it on open nor toggle it when given an B0 in an ioctl.
This, of course, is a pretty severe problem because most modems
won't pick up the phone if DTR is not present.

I've added a couple of lines to the driver in an attempt to fix
this problem.  Here's what the last bit of fas_open_device in fas.c
looks like (my the line I added is around line 2750, and is preceeded
by a "cjs" comment):

    setmcr:
	    /* set up modem and flow control lines */
	    fip->mcr &= ~(fip->modem.m.di
			    | fip->modem.m.ei
			    | fip->modem.m.eo
			    | fip->flow.m.ic
			    | fip->flow.m.hc);

	    fip->mcr |= (fip->o_state & OS_WAIT_OPEN)
			    ? fip->modem.m.ei
			    : fip->modem.m.eo;

	    if (fip->o_state & OS_HWI_HANDSHAKE)
		    fip->mcr |= fip->flow.m.ic;
	    else if (!(fip->o_state & OS_HDX_HANDSHAKE))
	    {
		    fip->flow_flags.s |= FF_HDX_STARTED;
		    fip->mcr |= fip->flow.m.hc;
	    }

	    /*
	     *  91.06.09 -- turn on DTR on open, too! -- cjs
	     */
	    fip->mcr |= MC_SET_DTR;

	    fas_outb (fip, MDM_CTL_PORT, fip->mcr);

	    fip->device_flags.s |= DF_DEVICE_OPEN | DF_MODEM_ENABLED;
    }

Basically what I did was add the fip->mcr |= MC_SET_DTR; line before
it outputs the final modem control register byte.  This works fine
so far, turning on the DTR when the port is opened.  Because the
MCR byte gets masked when the port is closed, DTR is dropped
correctly on the last close of the port.

So the system is partially working at the moment.  However, doing
an ioctl with B0 set still doesn't hang up the port.  Here is what
the relevant section of far_param looks like:


    /* hangup line if it is baud rate 0, else enable line */
    if ((cflag & CBAUD) == B0)
    {
	    fip->mcr &= (fip->o_state & OS_WAIT_OPEN)
			    ? ~fip->modem.m.ei
			    : ~fip->modem.m.eo;
	    /*
	     *  91.06.09 -- to hang up, turn of DTR, wait 1/2 second,
	     *  and turn it back on again.  Also send hangup signal
	     *  to all processes that have this tty open.  -- cjs
	    fip->mcr &= ~MC_SET_DTR;
	    fas_outb (fip, MDM_CTL_PORT, fip->mcr);
	    delay(HZ/2);
	    fip->mcr |= MC_SET_DTR;  /**/

	    fas_first_outb (fip, MDM_CTL_PORT, fip->mcr);
	    fip->device_flags.s &= ~DF_MODEM_ENABLED;

	    /* (void) signal (fip->tty->t_pgrp, SIGHUP);  /* -- cjs */
    }
    else
    {
	    if (!(fip->device_flags.i & DF_MODEM_ENABLED))
	    {
		    fip->mcr |= (fip->o_state & OS_WAIT_OPEN)
				    ? fip->modem.m.ei
				    : fip->modem.m.eo;
		    fas_first_outb (fip, MDM_CTL_PORT, fip->mcr);
		    fip->device_flags.s |= DF_MODEM_ENABLED;
	    }
    }

My modifications have been commented out, as they locked up the
system after an stty 0.  :-)  I added the four lines after the
comment and the one after the output that has a comment as well.

Without the signal() call an stty 0 would drop DTR and the line
would hang up.  Good so far.  However, the processes on this line
didn't receive a HUP signal (or at least, they didn't seem to) and
just sat there waiting for the device to send some more input.  So
I added the signal() call.  This caused my system to stop running
things, though the device drivers were still going (input still
echoed, and the like).

I'd appreciate any clues as to what's going on here.  Have I set
up FAS wrong in some way?  It seems very strange that it woudn't
assert DTR, but I couldn't find anything to make it do so in the
configuration files.  Is there something I can configure?  How
about a patch I can apply.  Failing that, I'd appreciate any help
on modifiying the device driver to work DTR correctly.

Thanks in advance.  This has certainly been a learning experience,
at any rate.  :-)

cjs
-- 
                        | "This sound system comes to you with fuel injection.
Curt Sampson            |  Toes tapping, the unthinking masses dance to a new
curt@cynic.uucp         |  tune. . . . Undress yourself to this bastard.  Suck
curt@cynic.wimsey.bc.ca |  on this plan of noise, bimbo!"       --Gary Clail