From patchwork Tue Jan 2 11:13:06 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jean-Christophe Dubois X-Patchwork-Id: 10140311 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2D5DF6034B for ; Tue, 2 Jan 2018 11:13:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2107328A7C for ; Tue, 2 Jan 2018 11:13:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 14D0528AB9; Tue, 2 Jan 2018 11:13:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 58E2428A7C for ; Tue, 2 Jan 2018 11:13:57 +0000 (UTC) Received: from localhost ([::1]:38978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eWKW4-0000OQ-J1 for patchwork-qemu-devel@patchwork.kernel.org; Tue, 02 Jan 2018 06:13:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eWKVP-0008UA-NB for qemu-devel@nongnu.org; Tue, 02 Jan 2018 06:13:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eWKVK-0002xO-Ot for qemu-devel@nongnu.org; Tue, 02 Jan 2018 06:13:15 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:50261) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eWKVK-0002vq-IT for qemu-devel@nongnu.org; Tue, 02 Jan 2018 06:13:10 -0500 Received: from [IPv6:2a01:e34:eebf:9c0:90b8:2011:7ddd:90b9] (unknown [IPv6:2a01:e34:eebf:9c0:90b8:2011:7ddd:90b9]) (Authenticated sender: jcd@tribudubois.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id E20D1C5A70; Tue, 2 Jan 2018 12:13:06 +0100 (CET) To: Mark Cave-Ayland , Artyom Tarasenko From: Jean-Christophe DUBOIS Message-ID: <4b0a136a-7017-0890-6dd9-33bd8ddf3e3d@tribudubois.net> Date: Tue, 2 Jan 2018 12:13:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.70.183.194 Subject: [Qemu-devel] [SPARC] question on LEON IRQMP interrupt controller. X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "qemu-devel@nongnu.org Developers" , Jean-Christophe Dubois Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Hi Mark, Artyom, I am wondering if the IRQMP code in hw/intc/grlib_irqmp.c is correct when it comes to acknowledging interrupts. With the actual code an interrupt can be lowered/acked only by an "ack" from the processor which means that the trap handler related to this external interrupt needs to be run for the ack to happen. In particular this means that the interrupt cannot be acked only by software. Even if the software clears the "pending" interrupts (by writing to the CLEAR_OFFSET register before the interrupt handler is run) this does not clear the interrupt to the processor (which is kept asserted until the handler is run and the interrupt acked by the processor). Do you know if this is indeed the intended behavior (I understand that for most operating system the interrupt handler will be run at last and this does not make a difference)? I would expect that clearing interrupt through software (by writing to the CLEAR_OFFSET register) would have the same effect as the processor acknowledgment (and could avoid to run the interrupt handler if things have already been taken care of by software). Unfortunately the documentation I got (on the web) on the IRQMP is not very clear on the topic. Anyway you can find below the patch I'd like to provide for IRQMP. Thanks JC diff --git a/hw/intc/grlib_irqmp.c b/hw/intc/grlib_irqmp.c index 94659ee256..d6f9cb3692 100644 --- a/hw/intc/grlib_irqmp.c +++ b/hw/intc/grlib_irqmp.c @@ -106,6 +106,15 @@ static void grlib_irqmp_check_irqs(IRQMPState *state)      }  } +static void grlib_irqmp_ack_mask(IRQMPState *state, uint32_t mask) +{ +    /* Clear registers */ +    state->pending  &= ~mask; +    state->force[0] &= ~mask; /* Only CPU 0 (No SMP support) */ + +    grlib_irqmp_check_irqs(state); +} +  void grlib_irqmp_ack(DeviceState *dev, int intno)  {      IRQMP        *irqmp = GRLIB_IRQMP(dev); @@ -120,11 +129,7 @@ void grlib_irqmp_ack(DeviceState *dev, int intno)      trace_grlib_irqmp_ack(intno); -    /* Clear registers */ -    state->pending  &= ~mask; -    state->force[0] &= ~mask; /* Only CPU 0 (No SMP support) */ - -    grlib_irqmp_check_irqs(state); +    grlib_irqmp_ack_mask(state, mask);  }  void grlib_irqmp_set_irq(void *opaque, int irq, int level) @@ -251,7 +256,7 @@ static void grlib_irqmp_write(void *opaque, hwaddr addr,      case CLEAR_OFFSET:          value &= ~1; /* clean up the value */ -        state->pending &= ~value; +        grlib_irqmp_ack_mask(state, value);          return;      case MP_STATUS_OFFSET: