Re: [Qemu-devel] [PATCH v4 5/5] i8259: fix dynamically masking slave IRQs with IMR register

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-09-04 20:27, Maciej W. Rozycki wrote:
> On Tue, 4 Sep 2012, Jan Kiszka wrote:
> 
>>>> What I'm trying to understand and translate from the description is
>>>> rather "note that for inputs a high-to-low transition cancels the
>>>> interrupt as in the level-triggered mode." This is surely not what we do
>>>> right now. OTOH, I'm afraid that switching to this mode in the PIC can
>>>> cause problems elsewhere, with devices that actually inject short
>>>> low-high-low signals. Still wrapping my head around it...
>>>
>>>  That won't work reliably with true 8259A hardware -- for an 
>>
>> Ok, then we have to scan our code base for such device models that won't
>> survive with real 8259A hardware. That can only be devices attached to
>> edge-only inputs of the PIC, namely the PIT, the keyboard controller,
>> the RTC and FPU emulation. They basically need to generate high-low-high
>> transitions on new events, instead of low-high-low (via qemu_irq_pulse
>> e.g.). I'm I on the right track?
> 
>  They shouldn't be the problem unless we've got an implementation problem:
> 
>  * The 8254 PIT is normally configured in mode 2 or 3 in the PC/AT 
>    architecture.  In the former its output is high (active) all the time 
>    except from one (last) clock cycle.  In the latter a wave that has a 
>    duty cycle close or equal to 0.5 (depending on whether the divider is 
>    odd or even) is produced, so no short pulses either.  I don't remember 
>    the other four modes -- have a look at the datasheet if interested, but 
>    I reckon they're not really compatible with the wiring anyway, e.g. the 
>    gate is hardwired enabled.
> 
>  * The 8042 keyboard controller requires an interrupt acknowledge (by 
>    reading its data port, normally at the address 0x60 in the PC/AT port 
>    I/O space) to clear its output, so no concern here either (this is BTW 
>    how many years ago I actually learnt the hard way how the 
>    edge-triggered mode works in the 8259A -- reading the KBC's data port 
>    in the main program a tight loop with the keyboard interrupt enabled 
>    will lead to a spurious interrupt each time data is supplied).  I 
>    believe it's otherwise edge-triggered though (I don't have an 8042 
>    datasheet handy, I would have to dig for a hardcopy that I left 
>    abroad).
> 
>  * The MC146818 RTC interrupt is level triggered and has to be 
>    acknowledged by reading Register C.
> 
>  * The i287/i387 FPU interrupt (in the PC/AT compatibility mode) is 
>    latched and requires the location at the address 0xf0 in the PC/AT port 
>    I/O space to be poked at to acknowledge.  It can therefore be 
>    considered level-triggered (overall the design is busted and you have 
>    to be very careful not to freeze the system when handling the FPU error 
>    this way rather than via the FPU exception).
> 
>  Did I miss anything?

Nope, and it looks like I was too pessimistic. I've checked PIT, 8042,
and RTC, and they all set their output levels properly. So it should be
safe to start clearing an IRQ on falling edges at a PIC input.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux