[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bochs-dev
Subject:    Re: [Bochs-developers] Pic Priorities, polled and autoeoi
From:       Dave Poirier <eks () void-core ! 2y ! net>
Date:       2001-11-25 4:20:52
[Download RAW message or body]

On Sun, Nov 25, 2001 at 11:28:51AM +0800, Jonathan Hunt wrote:
> I'm afraid I don't understand quite what you mean. A specific eoi clears the 
> isr and irr bits for that interrupt regardless of whether or not the 
> interrupt is enabled (at least that's what I think it does). Here is what I 
> think happens:
> 
> 1 - irr bit is set and service_*_pic is called.
> 2 - since bit is masked nothing happens
> 3 - specific eoi command is sent irr bit is cleared and service_*_pic is 
> called again. Nothing happens again.
> 4 - bit is unmasked and interrupt is now enabled but since irr bit is cleared 
> nothing happens until it is set again (by another interrupt request).
> 
> Are you saying that it goes ahead and raises an interrupt when it shouldn't 
> in step 4? Or am I totally off about what you mean? I'd be happy to do it 
> once I figure out what you mean (last day of exams are tomorrow so more time 
> then).
> 
> Jonathan Hunt 

I actually checked the code on cvs + patch after I replied to the email
(bad thing to do .. I know ehehe), the issue I actually raised was one I
fixed some time ago and I wasn't sure if it ever made it into the main
bochs sources.

originally the irr bit wasn't cleared, which caused an int to be fired
for the requested irq specifically acknowledged while masked.

There is still one thing that isn't fully implemented but would most
likely require alot of work in all the various devices, it is edge/level
detection.

The only 2 functions I see as available to a device are:

- trigger_irq()
- untrigger_irq()

To have a complete PIC model, there should be:

- raise_irq_line()
- lower_irq_line()
- unraise_irq_line()

The idea is the following, if a timer for example, raises a irq line for
X microseconds:

________------_______________________

Here's what happen with IRR on a edge triggered mode:

________----------------------------- (until int is triggered)

And here's what happen with IRR on a level triggered mode:

________------_______________________

When the irq_line is set back to low, even if the interrupt wasn't
fired, the IRR is sent back to low.  Which will cause the interrupt to
never be fired in this particular case.

The reason for having a two functions, lower_irq_line() and
unraise_irq_line() is the following:

unraise_irq() line could be used by the devices in case an interrupt
request was wrongly sent, I guess it could be used wherever the current
untrigger_irq() function was.

lower_irq_line() could be used by the device to lower the irq request,
which depending on the detection mode could lower the IRR back to 0 or
leave it to 1.

Also, in level detection mode, an int could be fired many time, in fact,
as long as the irq line is held high.  So upon completion of an
interrupt, if the irq line is still held high, the IRR bit is kept high,
not cleared.

Like I said, implementing level triggered irq would require also
modifying many devices; the floppy device for example only makes calls
to trigger_irq(), never to untrigger_irq().

Hope I am not too confusing ;)
EKS - Dave Poirier

_______________________________________________
bochs-developers mailing list
bochs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bochs-developers

[prev in list] [next in list] [prev in thread] [next in thread]