From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8xLX-0005Le-LC for qemu-devel@nongnu.org; Tue, 04 Sep 2012 13:55:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8xLW-0007hF-JB for qemu-devel@nongnu.org; Tue, 04 Sep 2012 13:55:31 -0400 Received: from david.siemens.de ([192.35.17.14]:21692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8xLW-0007h6-8x for qemu-devel@nongnu.org; Tue, 04 Sep 2012 13:55:30 -0400 Message-ID: <5046408D.1030105@siemens.com> Date: Tue, 04 Sep 2012 19:55:25 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1346640974-30974-1-git-send-email-mmogilvi_qemu@miniinfo.net> <1346640974-30974-6-git-send-email-mmogilvi_qemu@miniinfo.net> <50446F9A.4070809@web.de> <5046135B.2080200@redhat.com> <504625E5.7090903@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 5/5] i8259: fix dynamically masking slave IRQs with IMR register List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Maciej W. Rozycki" Cc: Paolo Bonzini , Matthew Ogilvie , "qemu-devel@nongnu.org" On 2012-09-04 19:41, 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? Thanks, Jan > edge-triggered interrupt to propagate up to the CPU first there must be a > low-to-high transition and then the high logic state must be maintained up > until the start of the second INTA cycle. If the interrupt request drops > before then (e.g. because CPU interrupts have been masked or a > higher-priority 8259A has been serviced), then the corresponding IRR bit > is cleared and either the interrupt is missed altogether or, if the CPU > has already accepted the interrupt and started the first INTA cycle, then > the spurious vector is supplied and no ISR bit is set. > > To put it in different words: the only actual difference between > edge-triggered and level-triggered interrupts in the 8259A is that the > formers require a leading edge to record another interrupt. For both > trigger modes the high level has to be maintained until the second INTA > cycle for the interrupt to be correctly delivered to the CPU and also in > both trigger modes a trailing edge cancels the interrupt. > > This is unlike the traditional edge-triggered mode where the level does > not have to be maintained once a leading edge has been correctly recorded > (there is usually spike filtering logic implemented on such IRQ inputs so > appropriate timings have to be met; because of its unusual interpretation > the 8259A obviously does not require such logic). > > The edge detector logic is also drawn in the 8259A datasheet (that for a > change used to be available from one of the Intel sites in the PDF form) > and I believe the functionality described can be inferred from that by the > curious enough. ;) > > Maciej > -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux