Cyril Novikov answered Stargazer:
removed comp.arch.embedded (can't access it from here)
>> ; Acknowledge interupt with PIC(s).
>> ; After calling callbacks, to enable nesting of interrupt handlers
>> according to priorities
>> ; TODO: check rotation priorities of 8259 and other options
>> mov al, CMD_EOI
>> out PIC_MASTER, al
>> cmp ebx, 8
>> jb fin
>> out PIC_SLAVE, al
> These 2 OUT's are what takes 2000+ cycles.
> The reason you see it elsewhere is most likely a bug in
> your measurement code.
I cannot confirm this, except if I/O-permission is heavy detouring.
Else it would mean a very slow chipset connected to a high speed BUS.
Last time I checked I got ~40nS for legacy ****t access on PCI-bridges.
So it should be not more than additional 8 cycles on a 200 MHz bus.
to Stargazer:
what device causes the IRQ ?
an EOI only sent to the PIC will not reset the IRQ-pin on the device.
If the PIT-channel is set to level sense, you may invoke more IRQs
with EOI for the whole duration of an IRQ-pulse ... may be endless
on other devices than timer, rtcl or retrace.
__
wolfgang
|
