Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp3398997ybe; Sun, 15 Sep 2019 14:40:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqwFNs93kqpo4z6MTHh1QIKoaai+M+gYof0lc39hrA3zXMj5wjlwB7QDH87bcL/kO6HmEXsu X-Received: by 2002:a17:906:1e45:: with SMTP id i5mr33130794ejj.135.1568583627598; Sun, 15 Sep 2019 14:40:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568583627; cv=none; d=google.com; s=arc-20160816; b=KSA/P6H/jmbR2wwmFlIRneUxQ63/TvQsHZRPlF1A/p1avqWYcdXMu44UjErZv2K6v+ GOGYrf7pZoe4HN3VTtGkx+k72UzfW9rucKZsh3/rsS8PN7vB/2RUNF+v87+PaR7Bu8pq 3WEj13vnVE5pmRGBnZwrF+qPXOEL0TDs5JMcFCAlRyL3b1CEy82qCkjQNcDBGL+dsWoY axI2w7FbOENiMuRoLhLj5d+0yuFr75iTPwg0uA8ZDMlyMvn5a9k1KIv3jQwOj/rLcMf6 PyqCx/WU3ycSJ002LXHBou9VKvIUJdKDLMiCsziAo+4cotvMQZdTHO4hoxv2ZTaGpfhy IzTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=2xxPC7ZD05WWV4QDlHy87hf3Z9xzJBCphOv0uQisj18=; b=WKuHLwYAb45EbX9lIKClKzW43L3i+celdpcMv24Hiw68W/wrEq/6McJlRe3CjDfd6J t24zs0IEzbLGs2k8Et98ssQyjVN8BAq8/K2SH4w0E25GqoimP/rn2cxgQHGF4f1G/Wp9 ctMF9CTdnWv5G+nLR5uCXfv9zdWnohT2RPO9LGZXD7qa7MCZQr1xAHtro4Md+9rSotPW yeEEYD2QoJ9lpDuWJ/hxQWI/q0aIEfxcxuMxXGwN9x/g7i49kZxXpeKhpExVVZE1TeIU r4Tlk1m/XEZZsUeNmANFTOtnZRWgZ9eR7fvezvxZoZPue1DpnM+TBvJwOeBMU7xFpQY7 Re2g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si16597322ejl.162.2019.09.15.14.39.50; Sun, 15 Sep 2019 14:40:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726169AbfIOSUu (ORCPT + 99 others); Sun, 15 Sep 2019 14:20:50 -0400 Received: from foss.arm.com ([217.140.110.172]:37196 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbfIOSUu (ORCPT ); Sun, 15 Sep 2019 14:20:50 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 73095337; Sun, 15 Sep 2019 11:20:49 -0700 (PDT) Received: from big-swifty.misterjones.org (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C624D3F67D; Sun, 15 Sep 2019 11:20:46 -0700 (PDT) Date: Sun, 15 Sep 2019 19:20:40 +0100 Message-ID: <861rwhs9on.wl-maz@kernel.org> From: Marc Zyngier To: Palmer Dabbelt Cc: Paul Walmsley , David Johnson , Darius Rad , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, jason@lakedaemon.net Subject: Re: [PATCH] irqchip/sifive-plic: add irq_mask and irq_unmask In-Reply-To: References: <8636gxskmj.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 15 Sep 2019 18:31:33 +0100, Palmer Dabbelt wrote: Hi Palmer, > > On Sun, 15 Sep 2019 07:24:20 PDT (-0700), maz@kernel.org wrote: > > On Thu, 12 Sep 2019 22:40:34 +0100, > > Darius Rad wrote: > > > > Hi Darius, > > > >> > >> As per the existing comment, irq_mask and irq_unmask do not need > >> to do anything for the PLIC. However, the functions must exist > >> (the pointers cannot be NULL) as they are not optional, based on > >> the documentation (Documentation/core-api/genericirq.rst) as well > >> as existing usage (e.g., include/linux/irqchip/chained_irq.h). > >> > >> Signed-off-by: Darius Rad > >> --- > >> drivers/irqchip/irq-sifive-plic.c | 13 +++++++++---- > >> 1 file changed, 9 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c > >> index cf755964f2f8..52d5169f924f 100644 > >> --- a/drivers/irqchip/irq-sifive-plic.c > >> +++ b/drivers/irqchip/irq-sifive-plic.c > >> @@ -111,6 +111,13 @@ static void plic_irq_disable(struct irq_data *d) > >> plic_irq_toggle(cpu_possible_mask, d->hwirq, 0); > >> } > >> +/* > >> + * There is no need to mask/unmask PLIC interrupts. They are "masked" > >> + * by reading claim and "unmasked" when writing it back. > >> + */ > >> +static void plic_irq_mask(struct irq_data *d) { } > >> +static void plic_irq_unmask(struct irq_data *d) { } > > > > This outlines a bigger issue. If your irqchip doesn't require > > mask/unmask, you're probably not using the right interrupt > > flow. Looking at the code, I see you're using handle_simple_irq, which > > is almost universally wrong. > > > > As per the description above, these interrupts should be using the > > fasteoi flow, which is designed for this exact behaviour (the > > interrupt controller knows which interrupt is in flight and doesn't > > require SW to do anything bar signalling the EOI). > > > > Another thing is that mask/unmask tends to be a requirement, while > > enable/disable tends to be optional. There is no hard line here, but > > the expectations are that: > > > > (a) A disabled line can drop interrupts > > (b) A masked line cannot drop interrupts > > > > Depending what the PLIC architecture mandates, you'll need to > > implement one and/or the other. Having just (a) is indicative of a HW > > bug, and I'm not assuming that this is the case. (b) only is pretty > > common, and (a)+(b) has a few adepts. My bet is that it requires (b) > > only. > > > >> + > >> #ifdef CONFIG_SMP > >> static int plic_set_affinity(struct irq_data *d, > >> const struct cpumask *mask_val, bool force) > >> @@ -138,12 +145,10 @@ static int plic_set_affinity(struct irq_data *d, > >> static struct irq_chip plic_chip = { > >> .name = "SiFive PLIC", > >> - /* > >> - * There is no need to mask/unmask PLIC interrupts. They are "masked" > >> - * by reading claim and "unmasked" when writing it back. > >> - */ > >> .irq_enable = plic_irq_enable, > >> .irq_disable = plic_irq_disable, > >> + .irq_mask = plic_irq_mask, > >> + .irq_unmask = plic_irq_unmask, > >> #ifdef CONFIG_SMP > >> .irq_set_affinity = plic_set_affinity, > >> #endif > > > > Can you give the following patch a go? It brings the irq flow in line > > with what the HW can do. It is of course fully untested (not even > > compile tested...). > > > > Thanks, > > > > M. > > > > From c0ce33a992ec18f5d3bac7f70de62b1ba2b42090 Mon Sep 17 00:00:00 2001 > > From: Marc Zyngier > > Date: Sun, 15 Sep 2019 15:17:45 +0100 > > Subject: [PATCH] irqchip/sifive-plic: Switch to fasteoi flow > > > > The SiFive PLIC interrupt controller seems to have all the HW > > features to support the fasteoi flow, but the driver seems to be > > stuck in a distant past. Bring it into the 21st century. > > Thanks. We'd gotten these comments during the review process but > nobody had gotten the time to actually fix the issues. No worries. The IRQ subsystem is an acquired taste... ;-) > > > > Signed-off-by: Marc Zyngier > > --- > > drivers/irqchip/irq-sifive-plic.c | 29 +++++++++++++++-------------- > > 1 file changed, 15 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c > > index cf755964f2f8..8fea384d392b 100644 > > --- a/drivers/irqchip/irq-sifive-plic.c > > +++ b/drivers/irqchip/irq-sifive-plic.c > > @@ -97,7 +97,7 @@ static inline void plic_irq_toggle(const struct cpumask *mask, > > } > > } > > -static void plic_irq_enable(struct irq_data *d) > > +static void plic_irq_mask(struct irq_data *d) Of course, this is wrong. The perks of trying to do something at the last minute while boarding an airplane. Don't do that. This should of course read "plic_irq_unmask"... > > { > > unsigned int cpu = cpumask_any_and(irq_data_get_affinity_mask(d), > > cpu_online_mask); > > @@ -106,7 +106,7 @@ static void plic_irq_enable(struct irq_data *d) > > plic_irq_toggle(cpumask_of(cpu), d->hwirq, 1); > > } > > -static void plic_irq_disable(struct irq_data *d) > > +static void plic_irq_unmask(struct irq_data *d) ... and this should be "plic_irq_mask". [...] > Reviewed-by: Palmer Dabbelt > Tested-by: Palmer Dabbelt (QEMU Boot) Huhuh... It may be that QEMU doesn't implement the full-fat PLIC, as the above bug should have kept the IRQ lines masked. > We should test them on the hardware, but I don't have any with me > right now. David's probably in the best spot to do this, as he's got > a setup that does all the weird interrupt sources (ie, PCIe). > > David: do you mind testing this? I've put the patch here: > > ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git > -b plic-fasteoi I've pushed out a branch with the fixed patch: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/plic-fasteoi Thanks, M. -- Jazz is not dead, it just smells funny.