Subject: Re: problems with interrupts
To: None <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
From: Brad Walker <bwalker@musings.com>
List: port-sparc
Date: 09/22/1995 00:06:03
> From owner-port-sparc@NetBSD.ORG Thu Sep 21 21:05 PDT 1995
> To: Brad Walker <bwalker@musings.com>
> Cc: port-sparc@netbsd.org
> X-Copyright: Copyright 1995, Christopher G. Demetriou.  All rights reserved.
> X-Notice: Duplication and redistribution prohibited without consent of
> 	  the author.
> Subject: Re: problems with interrupts 
> Date: Thu, 21 Sep 1995 21:56:18 -0400
> From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
> 
> > I've been working on the zs driver. And I've made some extensive
> > changes. But, the problem that I'm running into that the interrupt
> > framework is severely broken. The whole framework is not general
> > enough. And there are several places where things happen but the
> > system crashes because the kernel isn't properly protecting itself.
> 
> what are "things"?  how is it "not general enough"?
> 
> 

Okay, first let me say that I'm not trying to bash NetBSD. I only
want to see it get better. And of course because I've worked extensively
with SunOS and later Solaris and IRIX, that I'm going to be a little
biased. So now that I've laid my cards on the table..

Okay for the general part, I would have prefered something that takes
more advantage of the hardware. Why not make things a little more
opaque like SunOS did. I'm not suggesting that we be like SunOS. But,
rather why not try to think of things in a little more general terms.
One of the things that I like about the way sun did things is that
one gets an opaque pointer passed in the attach routine. And then
one calls a generic function to put this on the interrupt chain.
Maybe I'm just a purist.

As for changes to the zs driver I've done the following:

1) in zsxint
#ifdef OLD      
        cs->cs_tbc = i - 1;
        zc->zc_data = *cs->cs_tba++;
        ZS_DELAY();     
        zc->zc_csr = ZSWR0_CLR_INTR;
        ZS_DELAY();             
#else                   
        do {            
                zc->zc_data = *cs->cs_tba++;
                ZS_DELAY();
                i = i - 1;
                c = zc->zc_csr;
                ZS_DELAY();
        } while ((i > 0) && (c & ZSRR0_TX_READY));
        
        cs->cs_tbc = i;
        
        zc->zc_csr = ZSWR0_CLR_INTR;
        ZS_DELAY();
        return (0);
#endif

this makes things a little more general. There are some pin compatible
Zilog chips that I've been using that have FIFOs. This works beautifully
with them. Also, one has to consider that there are usually an extra
character in the transmit holding register. This allows you to get
2 chars out each interrupt instead of just one

2) the zshard() routine could use some work. I could better take advantage
of the vectoring that the chip gives you. This is what provoked my
question as I was working on this.

Finally, when I put a printf in the zshard routine the system starting
to panic. Maybe I should file a send-pr on this.

Okay, so there is my start. Please enlighten me as I could be totally
off base from what the consensus is. So let me know what you think..

-brad w.