[Top] [All Lists]

Re: zs driver problems ...

To: Harald Koerfgen <>
Subject: Re: zs driver problems ...
From: "Vladimir A. Roganov" <>
Date: Fri, 11 Jun 1999 21:50:19 +0400
Cc: Michael Engel <>,
Organization: NIISI
References: <>
Harald Koerfgen wrote:
> On 10-Jun-99 Michael Engel wrote:
> > can anyone please tell me what exactly I have to do in zs.c in order to
> > - correctly enable interrupts from port A
> These will be enabled in startup() when you open the corresponding ttySx.
> > - determine which zs chip the IRQ came from
> Look at struct dec_serial *info = (struct dec_serial *) dev_id;
> > - correctly initialize a port to a different baud rate
> Normally you'd do this with an ioctrl().
> > I tried to hack my way through zs.c but am somehow lost ... I get
> > IRQ's from the keyboard or mouse, but it seems as if the status bit for
> > the wrong channel is being set. Funny ...
> Well, I'd call it funny hardware. The interrupt pending bits (RR3) are
> only valid when read from Port A but show the interrupts pending for both
> channels.
> Yes, Michael, I know that zs.c isn't ready for Keyboard/Mouse handling and
> is in badly need of an overhaul. Maybe you should have a look at
> drivers/sbus/zs.c.
> Hope this helps.
> ---
> Regards,
> Harald

Hello All hacking drivers/tc/zs.c !

It looks it becames popular to hack this driver.  We spend last month 
periodically fixing code in this file to make it able to provide 
robust console on our MIPS BE Baget-202 computer (like some DECstations, 
it has two Zilog chips). The result we have now is very closed to original zs.c,
and at least we know some problems, looking linked with reported in this 
conference last time (for instance, Gleb Raiko has idea, that permanent 
problems with 'login' on DECstations can be linked with some 'zs.c' features:
hacking our computer we detected same effect at login stage).

First of all, why we are sure that channel with lowest address is channel A ?
Is it true that chip should select channel by address bit 0x8 ?
Our friend who deeply know about electronic side of our computer, said that 
Zilog decodes channel just by this bit.
So, if our Baget has another internal mapping of Zilog registers by modulo 8,
we have (we detected it in practice first :-) another order of channels.
But interrupts are handled by channel A only, so it leads to 'nothing works'.

Second, we detected that we have problems with interrupts until we add following
string to the end of interrupt handler:

        // FIXME: is it really needed (and why) ?
        write_zsreg(info->zs_channel, 0, RES_H_IUS);

This command explicitly marks end of interrupt. Without it Zilog think IRQ is 
handled by software. 
It is strange, because the driver should set mode which forces automatic IACK...

Third, we found the routines linked with blocked operation are waiting infinite
time in procedure:

 * rs_wait_until_sent() --- wait until the transmitter is empty
static void rs_wait_until_sent(struct tty_struct *tty, int timeout)
        struct dec_serial *info = (struct dec_serial *) tty->driver_data;
        unsigned long orig_jiffies, char_time;

        if (serial_paranoia_check(info, tty->device, "rs_wait_until_sent"))

        orig_jiffies = jiffies;
         * Set the check interval to be 1/5 of the estimated time to
         * send a single character, and make it at least 1.  The check
         * interval should also be less than the timeout.
        char_time = (info->timeout - HZ/50) / info->xmit_fifo_size;
        char_time = char_time / 5;
        // FIXME: added line
        char_time = 1;
        if (char_time == 0)
                char_time = 1;
        if (timeout)
                char_time = MIN(char_time, timeout);
        while (0/*FIXME*/ && (read_zsreg(info->zs_channel, 1) & ALL_SNT) == 0) {
          //     printk("scc: wait_until_send in loop, char_time=%d, timeout=%d,
 orig_jiffies=%d, jiffies = %d\n",
          //        char_time, timeout, orig_jiffies, jiffies);
                current->state = TASK_INTERRUPTIBLE;
                current->counter = 0;   /* make us low-priority */
                if (signal_pending(current))
                if (timeout && ((orig_jiffies + timeout) < jiffies))
        current->state = TASK_RUNNING;

See how we were forced to place hacks nead FIXME words.
Really, this function need some attention: we found it can wait a HUGE time 
negative 'char_time' !

More interesting: our chip may forget to said ALL_SNT in some cases (!)

It is not all, but most important things.

If somebody found our fixes useful, please inform us.

Yet another activity:

We need nearest time to add support for serial keyboard (that is, keyboard 
which looks
like a normal keyboard, but is connected via serial port).
It looks relatively easy to add support for it in zs.c, like in Sparc Zilog 
like Harald already suggested.
If anybody already doing it, please mail about results.

Happy Ziloging,

Best wishes,

<Prev in Thread] Current Thread [Next in Thread>