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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B40AEC433EF for ; Wed, 20 Jul 2022 14:52:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=puobAy9q9JMJheJo9EfavsunIQ+YaMoxwPh/8PrlKjM=; b=VB9SaR7qzgz8+O n6SP/arjJopuiieaMtUyvREUAZxGg2YWdBjy8+Ma3Hx5osC5B0EWJpXALJcwzVi5VdKsTPndKSBBo mdkVywjgtvZq5eksBQDewE6bI8mp0ivMJ1QbqXF1QebeJ0wXraQofWlUkeunf9LQrKo5Tx3JkePBa mrdS4+02Hh+vPYa4O1dRWNJFXquVTYMXLFFQ/QfiEz1CKL6o6dbSzs2QFp/RXCq4AcwAPrlccL9g0 M+dBElPm5YnG9LZuDGskBhh/ENKBIcOlTqtqFOwE31M0rT3BBMu3wUrqEbMxHPrrqD6Pbx3RqtWbU gAd9NSnkOxYDCD/jo8GA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEB47-0078P8-C4; Wed, 20 Jul 2022 14:52:43 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEB2m-00772O-E8 for linux-riscv@lists.infradead.org; Wed, 20 Jul 2022 14:51:22 +0000 Received: by mail-lj1-x230.google.com with SMTP id q7so21359677lji.12 for ; Wed, 20 Jul 2022 07:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVRQbOhE6XB1EW7hHnsX9K0NKGA6RXSKLaL5jZqCe6c=; b=LbEYyiLe5ZqK1UMM3OLzwYJoPn/rHr+mgeH9ZyHITD3tdAefU3ECQu5EqF9Iyn8dmM wn5PZzxbvAWsrQzVWfL56X28iiHLLQMxqeh6ApYBhYYqtwI3TR3A2zLFRPlce0t5B7SA NhJZ5UgOIiNSFGEFj318aAHJTo4rK95QnyM+St8WoDYo72w6vIX3tm5KYUnK7R4UiIJc wthvpx1VYdfB1aAFqJJ31Iwh/sTYoCivCyxl523lJQRRhdhlOZ6MRJfhzFo8JUIrt7bs T1/AIlQmPaGycdY8zVKRJ6Z2V4Aq4fbwOad2j9CAMWbB9XTg3hDXMWw58nVgEbGgt7m4 Qv3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVRQbOhE6XB1EW7hHnsX9K0NKGA6RXSKLaL5jZqCe6c=; b=B/fUrwCVjoT1sOq8f0HWUiKdAaIIUtKgI+QShdNx8GiSfibOCicB9a66ypZmeJyuDF F7/p2RT+DaHsbuthVI8ZMl0ayfs0VKlvdfEaVgNst4PyFqfH3Vroh+JwldOiM4nRI8Kx JtbBJKM4lF5278gRnd7VATElk7YZ41JEatW+dBPLiyuVyrk/JAjy/hhHUBW+MY5OIXLL QJM/Ya9i5CLo02D3bf05N+CIf1hfXu1Y55K0acbB+VRvjGdW3x8d9O57qdohg7DfOgsY 8tTK0kA84Z/jYG0gFQXz+nGBz8tdtTI8fUqPygfOCOLPKLdOlJisRoNzuPW5QjecTzpd mADQ== X-Gm-Message-State: AJIora/9Mo0SHo2LjsQtO4W0OeHNo4UC4jLgEVWjOgqD7A/fcFjRauWp RXQ0FleHxna7xBBnPMx5SzkyHS680YXr/usD1Pyd6w== X-Google-Smtp-Source: AGRyM1vs0Jfc47H+moDSMVJNt400EsA6vj7j7OirOjA9rlu8ilu6vA+M2DUhNMX6xR7pFEtKZ+uqzOdtuaBXz3IgUp8= X-Received: by 2002:a05:651c:1616:b0:25d:6f3f:44a7 with SMTP id f22-20020a05651c161600b0025d6f3f44a7mr16569237ljq.466.1658328674730; Wed, 20 Jul 2022 07:51:14 -0700 (PDT) MIME-Version: 1.0 References: <20220418105305.1196665-1-apatel@ventanamicro.com> <20220418105305.1196665-4-apatel@ventanamicro.com> <87bktlyszw.wl-maz@kernel.org> In-Reply-To: <87bktlyszw.wl-maz@kernel.org> From: Anup Patel Date: Wed, 20 Jul 2022 20:20:09 +0530 Message-ID: Subject: Re: [PATCH v6 3/7] genirq: Add mechanism to multiplex a single HW IPI To: Marc Zyngier Cc: Palmer Dabbelt , Paul Walmsley , Thomas Gleixner , Daniel Lezcano , Atish Patra , Alistair Francis , Anup Patel , linux-riscv , "linux-kernel@vger.kernel.org List" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220720_075120_550282_6C3DF639 X-CRM114-Status: GOOD ( 49.46 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Jul 19, 2022 at 9:50 PM Marc Zyngier wrote: > > On Mon, 18 Apr 2022 11:53:01 +0100, > Anup Patel wrote: > > > > All RISC-V platforms have a single HW IPI provided by the INTC local > > interrupt controller. The HW method to trigger INTC IPI can be through > > external irqchip (e.g. RISC-V AIA), through platform specific device > > (e.g. SiFive CLINT timer), or through firmware (e.g. SBI IPI call). > > > > To support multiple IPIs on RISC-V, we add a generic IPI multiplexing > > mechanism which help us create multiple virtual IPIs using a single > > HW IPI. This generic IPI multiplexing is shared among various RISC-V > > irqchip drivers. > > > > Signed-off-by: Anup Patel > > --- > > include/linux/irq.h | 11 +++ > > kernel/irq/Kconfig | 4 + > > kernel/irq/Makefile | 1 + > > kernel/irq/ipi-mux.c | 197 +++++++++++++++++++++++++++++++++++++++++++ > > 4 files changed, 213 insertions(+) > > create mode 100644 kernel/irq/ipi-mux.c > > > > diff --git a/include/linux/irq.h b/include/linux/irq.h > > index f92788ccdba2..5bb4e2db63d7 100644 > > --- a/include/linux/irq.h > > +++ b/include/linux/irq.h > > @@ -1247,6 +1247,17 @@ int __ipi_send_mask(struct irq_desc *desc, const struct cpumask *dest); > > int ipi_send_single(unsigned int virq, unsigned int cpu); > > int ipi_send_mask(unsigned int virq, const struct cpumask *dest); > > > > +#define IPI_MUX_NR_IRQS BITS_PER_LONG > > + > > +struct ipi_mux_ops { > > + void (*ipi_mux_clear)(unsigned int parent_virq); > > + void (*ipi_mux_send)(unsigned int parent_virq, > > + const struct cpumask *mask); > > You really cannot just dump this like this. This requires > documentation so that architecture maintainers can move over to this. > I appreciate that this area is pretty poorly documented, but we need > to start somewhere. Okay, I will add documentation. > > > +}; > > + > > +void ipi_mux_process(void); > > +int ipi_mux_create(unsigned int parent_virq, const struct ipi_mux_ops *ops); > > + > > #ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER > > /* > > * Registers a generic IRQ handling function as the top-level IRQ handler in > > diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig > > index 10929eda9825..2388e7d40ed3 100644 > > --- a/kernel/irq/Kconfig > > +++ b/kernel/irq/Kconfig > > @@ -84,6 +84,10 @@ config GENERIC_IRQ_IPI > > bool > > select IRQ_DOMAIN_HIERARCHY > > > > +# Generic IRQ IPI Mux support > > +config GENERIC_IRQ_IPI_MUX > > + bool > > + > > # Generic MSI interrupt support > > config GENERIC_MSI_IRQ > > bool > > diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile > > index b4f53717d143..f19d3080bf11 100644 > > --- a/kernel/irq/Makefile > > +++ b/kernel/irq/Makefile > > @@ -15,6 +15,7 @@ obj-$(CONFIG_GENERIC_IRQ_MIGRATION) += cpuhotplug.o > > obj-$(CONFIG_PM_SLEEP) += pm.o > > obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o > > obj-$(CONFIG_GENERIC_IRQ_IPI) += ipi.o > > +obj-$(CONFIG_GENERIC_IRQ_IPI_MUX) += ipi-mux.o > > obj-$(CONFIG_SMP) += affinity.o > > obj-$(CONFIG_GENERIC_IRQ_DEBUGFS) += debugfs.o > > obj-$(CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR) += matrix.o > > diff --git a/kernel/irq/ipi-mux.c b/kernel/irq/ipi-mux.c > > new file mode 100644 > > index 000000000000..1a1fcfe3ac54 > > --- /dev/null > > +++ b/kernel/irq/ipi-mux.c > > @@ -0,0 +1,197 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Multiplex several virtual IPIs over a single HW IPI. > > + * > > + * Copyright (c) 2022 Ventana Micro Systems Inc. > > + */ > > + > > +#define pr_fmt(fmt) "ipi-mux: " fmt > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +static unsigned int ipi_mux_parent_virq; > > +static struct irq_domain *ipi_mux_domain; > > +static const struct ipi_mux_ops *ipi_mux_ops; > > +static DEFINE_PER_CPU(unsigned long, ipi_mux_bits); > > + > > +static void ipi_mux_dummy(struct irq_data *d) > > +{ > > +} > > + > > +static void ipi_mux_send_mask(struct irq_data *d, const struct cpumask *mask) > > +{ > > + int cpu; > > + > > + /* Barrier before doing atomic bit update to IPI bits */ > > + smp_mb__before_atomic(); > > + > > + for_each_cpu(cpu, mask) > > + set_bit(d->hwirq, per_cpu_ptr(&ipi_mux_bits, cpu)); > > + > > + /* Barrier after doing atomic bit update to IPI bits */ > > + smp_mb__after_atomic(); > > + > > + /* Trigger the parent IPI */ > > + ipi_mux_ops->ipi_mux_send(ipi_mux_parent_virq, mask); > > +} > > + > > +static struct irq_chip ipi_mux_chip = { > > const, please. Okay, I will add const here. > > > + .name = "IPI Mux", > > + .irq_mask = ipi_mux_dummy, > > + .irq_unmask = ipi_mux_dummy, > > Maybe we should consider a flow that does not require this dummy > callbacks. These dummy irq_mask()/irq_unmask() were added to allow irq_percpu_enable()/disable() for the muxed IPIs. We are using handle_percpu_devid_irq() flow so we really don't need these dummy irq_mask()/irq_unmask(). I will drop these dummy calls in the next patch revision. > > > + .ipi_send_mask = ipi_mux_send_mask, > > +}; > > + > > +static int ipi_mux_domain_map(struct irq_domain *d, unsigned int irq, > > + irq_hw_number_t hwirq) > > +{ > > + irq_set_percpu_devid(irq); > > + irq_domain_set_info(d, irq, hwirq, &ipi_mux_chip, d->host_data, > > + handle_percpu_devid_irq, NULL, NULL); > > + > > + return 0; > > +} > > + > > +static int ipi_mux_domain_alloc(struct irq_domain *d, unsigned int virq, > > + unsigned int nr_irqs, void *arg) > > +{ > > + unsigned int type = IRQ_TYPE_NONE; > > Really, this should be EDGE. Actually, the "type" initialization is redundant because the irq_domain_translate_onecell() function will set it anyway. I will drop the "type" initialization here. > > > + struct irq_fwspec *fwspec = arg; > > + irq_hw_number_t hwirq; > > + int i, ret; > > + > > + ret = irq_domain_translate_onecell(d, fwspec, &hwirq, &type); > > + if (ret) > > + return ret; > > + > > + for (i = 0; i < nr_irqs; i++) { > > + ret = ipi_mux_domain_map(d, virq + i, hwirq + i); > > + if (ret) > > + return ret; > > + } > > + > > + return 0; > > +} > > + > > +static const struct irq_domain_ops ipi_mux_domain_ops = { > > + .translate = irq_domain_translate_onecell, > > What is the purpose of this callback? Firmware shouldn't be involved > in IPIs at all, and since you only have one cell, you can use the > default path. This is also a dependency on CONFIG_IRQ_DOMAIN_HIERARCHY. It's not needed. I will drop it. > > > + .alloc = ipi_mux_domain_alloc, > > + .free = irq_domain_free_irqs_top, > > +}; > > + > > +/** > > + * ipi_mux_process - Process multiplexed virtual IPIs > > + */ > > +void ipi_mux_process(void) > > +{ > > + unsigned long irqs, *bits = this_cpu_ptr(&ipi_mux_bits); > > + irq_hw_number_t hwirq; > > + int err; > > + > > + /* Clear the parent IPI */ > > + if (ipi_mux_ops->ipi_mux_clear) > > + ipi_mux_ops->ipi_mux_clear(ipi_mux_parent_virq); > > + > > + /* > > + * Barrier for IPI bits paired with smp_mb__xyz_atomic() > > xyz??? Okay, I will update this comment. > > > + * in ipi_mux_send_mask() > > + */ > > + smp_mb(); > > + > > + irqs = xchg(bits, 0); > > + if (!irqs) > > + return; > > + > > + for_each_set_bit(hwirq, &irqs, IPI_MUX_NR_IRQS) { > > + err = generic_handle_domain_irq(ipi_mux_domain, > > + hwirq); > > + if (unlikely(err)) > > + pr_warn_ratelimited( > > + "can't find mapping for hwirq %lu\n", > > + hwirq); > > + } > > +} > > + > > +static void ipi_mux_handler(struct irq_desc *desc) > > +{ > > + struct irq_chip *chip = irq_desc_get_chip(desc); > > + > > + chained_irq_enter(chip, desc); > > + ipi_mux_process(); > > + chained_irq_exit(chip, desc); > > +} > > + > > +static int ipi_mux_dying_cpu(unsigned int cpu) > > +{ > > + disable_percpu_irq(ipi_mux_parent_virq); > > + return 0; > > +} > > + > > +static int ipi_mux_starting_cpu(unsigned int cpu) > > +{ > > + enable_percpu_irq(ipi_mux_parent_virq, > > + irq_get_trigger_type(ipi_mux_parent_virq)); > > + return 0; > > +} > > + > > +/** > > + * ipi_mux_create - Create virtual IPIs (total IPI_MUX_NR_IRQS) multiplexed > > + * on top of a single parent IPI. > > + * @parent_virq: virq of the parent IPI > > + * @ops: multiplexing operations for the parent IPI > > + * > > + * If the parent IPI > 0 then ipi_mux_process() will be automatically > > + * called via chained handler. > > + * > > + * If the parent IPI <= 0 then it is responsiblity of irqchip drivers > > + * to explicitly call ipi_mux_process() for processing muxed IPIs. > > + * > > + * Returns first virq of the newly created virutal IPIs upon success > > + * or <=0 upon failure > > + */ > > +int ipi_mux_create(unsigned int parent_virq, const struct ipi_mux_ops *ops) > > +{ > > Why should be parent_virq be unique? I also see nothing that checks > that this is a per-CPU interrupt. If anything, this needs documenting. Okay, I will add checks on parent_virq to ensure it is a percpu irq. > > > + struct irq_domain *domain; > > + struct irq_fwspec ipi; > > + int virq; > > + > > + if (ipi_mux_domain || !ops || !ops->ipi_mux_send) > > + return 0; > > + > > + domain = irq_domain_add_linear(NULL, IPI_MUX_NR_IRQS, > > Urgh. For a start, please use the irq_domain_create_* version, as this > shouldn't be DT specific. Then, don't use a NULL fwnode, as this > results in a "default domain", which nobody sane should ever use > anymore. Also, defaulting to BITS_PER_LONG is a lot of interrupts for > not much (most archs use only a handful). You may want to consider > this being a parameter, and cap it at BITS_PER_LONG. Okay, I will use irq_domain_create_simple() here and also add a parameter to ipi_mux_create() for the number of IPIs which will be capped at BITS_PER_LONG. > > > + &ipi_mux_domain_ops, NULL); > > + if (!domain) { > > + pr_err("unable to add IPI Mux domain\n"); > > + return 0; > > + } > > + > > + ipi.fwnode = domain->fwnode; > > Which is NULL (see above). > > > + ipi.param_count = 1; > > + ipi.param[0] = 0; > > + virq = __irq_domain_alloc_irqs(domain, -1, IPI_MUX_NR_IRQS, > > + NUMA_NO_NODE, &ipi, false, NULL); > > + if (virq <= 0) { > > + pr_err("unable to alloc IRQs from IPI Mux domain\n"); > > + irq_domain_remove(domain); > > + return virq; > > + } > > + > > + ipi_mux_domain = domain; > > + ipi_mux_parent_virq = parent_virq; > > + ipi_mux_ops = ops; > > + > > + if (parent_virq > 0) { > > + irq_set_chained_handler(parent_virq, ipi_mux_handler); > > + > > + cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, > > + "irqchip/ipi-mux:starting", > > + ipi_mux_starting_cpu, ipi_mux_dying_cpu); > > + } > > + > > + return virq; > > +} > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible. Thanks Marc, I will send v7 patches soon. Regards, Anup _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv