From e511a52691ddb2290f5d3c9ca6e9f0fc3b320289 Mon Sep 17 00:00:00 2001 From: Theo de Raadt Date: Sun, 11 Aug 1996 05:35:37 +0000 Subject: netbsd port, now we merge our changes back in --- sys/arch/sparc/dev/zsvar.h | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) (limited to 'sys/arch/sparc/dev/zsvar.h') diff --git a/sys/arch/sparc/dev/zsvar.h b/sys/arch/sparc/dev/zsvar.h index 3fef4d3981e..3234fbc7537 100644 --- a/sys/arch/sparc/dev/zsvar.h +++ b/sys/arch/sparc/dev/zsvar.h @@ -1,4 +1,4 @@ -/* $NetBSD: zsvar.h,v 1.6 1996/01/24 19:52:57 gwr Exp $ */ +/* $NetBSD: zsvar.h,v 1.8 1996/03/31 22:39:08 pk Exp $ */ /* * Copyright (c) 1992, 1993 @@ -91,8 +91,7 @@ struct zsdevice { #define ZRING_MAKE(t, v) ((t) | (v) << 8) struct zs_chanstate { - struct zs_chanstate *cs_next; /* linked list for zshard() */ - struct zs_softc *cs_sc; /* points to my softc */ + struct zs_chanstate *cs_next; /* linked list for zshard() */ volatile struct zschan *cs_zc; /* points to hardware regs */ int cs_unit; /* unit number */ struct tty *cs_ttyp; /* ### */ @@ -163,17 +162,22 @@ struct zs_chanstate { * On the SparcStation the 1.6 microsecond recovery time is * handled in hardware. On the older Sun4 machine it isn't, and * software must deal with the problem. + * + * However, it *is* a problem on some Sun4m's (i.e. the SS20) (XXX: why?). + * Thus we leave in the delay. + * + * XXX: (ABB) Think about this more. */ -#ifdef SUN4 +#if defined(SUN4) + #define ZS_READ(c, r) zs_read(c, r) #define ZS_WRITE(c, r, v) zs_write(c, r, v) -#if defined(SUN4C) || defined(SUN4M) -#define ZS_DELAY() (cputyp == CPU_SUN4 ? delay(2) : 0) -#else -#define ZS_DELAY() delay(2) -#endif -#else +#define ZS_DELAY() (CPU_ISSUN4C ? (0) : delay(1)) + +#else /* SUN4 */ + #define ZS_READ(c, r) ((c)->zc_csr = (r), (c)->zc_csr) #define ZS_WRITE(c, r, v) ((c)->zc_csr = (r), (c)->zc_csr = (v)) -#define ZS_DELAY() -#endif +#define ZS_DELAY() (CPU_ISSUN4M ? delay(1) : 0) + +#endif /* SUN4 */ -- cgit v1.2.3