From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7385C43461 for ; Sat, 5 Sep 2020 13:09:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5016E2072D for ; Sat, 5 Sep 2020 13:09:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OqVdozfv"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="j3tHfPFH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5016E2072D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xEboi3VREjHQqksputogwixFaj7UFP0Q17a92g6k64A=; b=OqVdozfvLxdhB5/uW+CF4AQOJ V68n/bidrwomSXiMctTNppn2m7gIpa3epuTA5JON8Vfz1gNEVbxtBASdcblLu/xTAIq6aOc5LqABU C6k8/VTy+4AsbNRe9a++BzcONxJAM6+QuHEMhsotr+8iFT7BBcjdzU3L2v/2DcYyj6qhQTvsCYzxW 61tU8GMawaFABuG8uk+XvSaZt2u2QR+lSGi4ZlzbrQ/Q0A8wdsH3P/dWmP7c8jz2Y3n/bfODITIN8 NK8/r/QReWx8hqCgVoJcoDEUYExagXaJmpK14ifSXhglU8AP2c17W/KeAuTseo6DhXaKQGDj4XhbC RJ2IF+8RQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kEXvt-0004CQ-9Q; Sat, 05 Sep 2020 13:08:41 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kEXvq-0004BY-8n for linux-arm-kernel@lists.infradead.org; Sat, 05 Sep 2020 13:08:39 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EB7A22072D; Sat, 5 Sep 2020 13:08:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599311317; bh=HvvGqGKI8323SdXHg2jD/FClfb8tuoa5gcu2Ns7uKzs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=j3tHfPFHFgihb72CmyYKwhWYW38bynuxH9HsrZUFAcBe/eX7rspBYKJUX0dRBMn7p 02BIem5kvA8/gXIvB7535fA7xIssKj61fSmD2fLMKqnzYMOeJXy2Dd3Xq6rtzAQgs+ 7P2A/ChqfpGDMUkoXttayRIbWLzJOGQXyZaimkbo= Received: from [185.104.136.29] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kEXvm-009MzR-Nj; Sat, 05 Sep 2020 14:08:34 +0100 Date: Sat, 05 Sep 2020 14:08:20 +0100 Message-ID: <875z8smkvv.wl-maz@kernel.org> From: Marc Zyngier To: Jonathan Cameron Subject: Re: [PATCH 04/23] irqchip/rvid: Add PCI MSI support In-Reply-To: <20200904151538.00003cff@Huawei.com> References: <20200903152610.1078827-1-maz@kernel.org> <20200903152610.1078827-5-maz@kernel.org> <20200904151538.00003cff@Huawei.com> 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.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: Jonathan.Cameron@Huawei.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com, suzuki.poulose@arm.com, Christoffer.Dall@arm.com, james.morse@arm.com, kernel-team@android.com, julien.thierry.kdev@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200905_090838_526648_0A48C4D5 X-CRM114-Status: GOOD ( 37.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Lorenzo Pieralisi , kvm@vger.kernel.org, Suzuki K Poulose , Christoffer Dall , James Morse , Julien Thierry , kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jonathan, On Fri, 04 Sep 2020 15:15:38 +0100, Jonathan Cameron wrote: > > On Thu, 3 Sep 2020 16:25:51 +0100 > Marc Zyngier wrote: > > > Signed-off-by: Marc Zyngier > Few minor comments inline. > > Thanks, > > Jonathan > > > --- > > drivers/irqchip/irq-rvid.c | 182 +++++++++++++++++++++++++++++++++++++ > > 1 file changed, 182 insertions(+) > > > > diff --git a/drivers/irqchip/irq-rvid.c b/drivers/irqchip/irq-rvid.c > > index 953f654e58d4..250f95ad1a09 100644 > > --- a/drivers/irqchip/irq-rvid.c > > +++ b/drivers/irqchip/irq-rvid.c > > @@ -12,12 +12,19 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > struct rvid_data { > > struct fwnode_handle *fwnode; > > struct irq_domain *domain; > > + struct irq_domain *msi_domain; > > + struct irq_domain *pci_domain; > > + unsigned long *msi_map; > > + struct mutex msi_lock; > > + u32 msi_base; > > + u32 msi_nr; > > }; > > > > static struct rvid_data rvid; > > @@ -209,6 +216,177 @@ static const struct irq_domain_ops rvid_irq_domain_ops = { > > .deactivate = rvid_irq_domain_deactivate, > > }; > > > > +#ifdef CONFIG_PCI_MSI > > +/* > > + * The MSI irqchip is completely transparent. The only purpose of the > > + * corresponding irq domain is to provide the MSI allocator, and feed > > + * the allocated inputs to the main rVID irq domain for mapping at the > > + * rVIC level. > > + */ > > +static struct irq_chip rvid_msi_chip = { > > + .name = "rvid-MSI", > > + .irq_mask = irq_chip_mask_parent, > > + .irq_unmask = irq_chip_unmask_parent, > > + .irq_eoi = irq_chip_eoi_parent, > > + .irq_get_irqchip_state = irq_chip_get_parent_state, > > + .irq_set_irqchip_state = irq_chip_set_parent_state, > > + .irq_retrigger = irq_chip_retrigger_hierarchy, > > + .irq_set_type = irq_chip_set_type_parent, > > + .irq_set_affinity = irq_chip_set_affinity_parent, > > +}; > > + > > +static int rvid_msi_domain_alloc(struct irq_domain *domain, unsigned int virq, > > + unsigned int nr_irqs, void *arg) > > +{ > > + int ret, hwirq, i; > > + > > + mutex_lock(&rvid.msi_lock); > > + hwirq = bitmap_find_free_region(rvid.msi_map, rvid.msi_nr, > > + get_count_order(nr_irqs)); > > + mutex_unlock(&rvid.msi_lock); > > + > > + if (hwirq < 0) > > + return -ENOSPC; > > + > > + for (i = 0; i < nr_irqs; i++) { > > + /* Use the rVID domain to map the input to something */ > > + struct irq_fwspec fwspec = (struct irq_fwspec) { > > + .fwnode = domain->parent->fwnode, > > + .param_count = 1, > > + .param[0] = rvid.msi_base + hwirq + i, > > + }; > > + > > + ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, &fwspec); > > + if (WARN_ON(ret)) > > + goto out; > > + > > + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i, > > + &rvid_msi_chip, &rvid); > > + } > > + > > + return 0; > > + > > +out: > > I missed this on previous patch, but doesn't the error path need to undo the > irq_domain_alloc_irqs_parent part? irq_domain_free_irqs_parent() Yes, this indeed needs some rework. [...] > > +static void __init rvid_msi_setup(struct device_node *np) > > +{ > > + if (!of_property_read_bool(np, "msi-controller")) > > + return; > > + > > + if (of_property_read_u32_index(np, "msi-range", 0, &rvid.msi_base) || > > + of_property_read_u32_index(np, "msi-range", 1, &rvid.msi_nr)) { > > Looks like msi-range isn't defined in any existing bindings, or my grep > fu is broken today. As hinted at in the cover letter, there is no binding whatsoever for now, and all the properties are totally made up. As for the use of "msi-range", most bindings are using some ad-hoc descriptions of their *outputs* to the downstream irqchip. What I am describing here is the range of *inputs* into the rVID that can be used for MSIs. It we wanted to use an abstraction similar to what exists in the physical world, then the MSI widget would be a separate component upstream of the rVID itself. In a way the driver works like that already (there is a separate MSI domain sitting atop the rVID domain), and it wouldn't be a big deal to switch to that. We'd need a property describing the output range of the widget, similar in essence to what is required for the GICv3 MBI ranges. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel