linux-mips-fnet
[Top] [All Lists]

RE: DECStation zs driver continued...

To: Karel van Houten <K.H.C.vanHouten@research.kpn.com>
Subject: RE: DECStation zs driver continued...
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Date: Tue, 29 Jun 1999 21:48:25 +0200 (MEST)
Cc: linux-mips@fnet.fr
In-reply-to: <199906271515.RAA23379@sparta.research.kpn.com>
Organization: none
Reply-to: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Sender: harry@franz.no.dom
Hi,

On 27-Jun-99 Karel van Houten wrote:
> So I changed the loop in rs_wait_until_sent to:
> 
>       while ((read_zsreg(info->zs_channel, 0) & Tx_BUF_EMP) == 0) {
>                 udelay(100);
>         }
> or 
> 
>       while ((read_zsreg(info->zs_channel, 1) & ALL_SNT) == 0) {
>                 udelay(100);
>         }
> 
> Both versions result in a much faster init, and no problems with the
> console for now.
> 
> Any comments from the kernel-specialists?

As Gleb already pointed out, there seems to be a strange behaviour wrt
ALL-SNT.

Maybe I'm simple naive but do we really need rs_wait_until_sent? Neither
the sgi nor the sparc serial drivers have one and I'm wondering if 
tty_wait_until_sent(...) would do the trick.

Personally I'd prefer kicking zs.c in the bin and write a new one. zs.c
is and was never ment to be anything else but a bad hack.

IMHO we really should think about a more general approach. Maintaining
five or six different zs drivers simply is a pain in the *ss and a generic
zs driver and some hardware specific helper routines for different
machines _does_ make much more sense, doesn't it?

---
Regards,
Harald

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