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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 6BC2DC433EF for ; Mon, 20 Sep 2021 09:45:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A36260F9B for ; Mon, 20 Sep 2021 09:45:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230239AbhITJqr (ORCPT ); Mon, 20 Sep 2021 05:46:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:35376 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229565AbhITJqr (ORCPT ); Mon, 20 Sep 2021 05:46:47 -0400 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 6A7C560F6C; Mon, 20 Sep 2021 09:45:20 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mSFrS-00BjKG-Bg; Mon, 20 Sep 2021 10:45:18 +0100 Date: Mon, 20 Sep 2021 10:45:18 +0100 Message-ID: <87zgs7vavl.wl-maz@kernel.org> From: Marc Zyngier To: Daniel Palmer Cc: devicetree@vger.kernel.org, robh+dt@kernel.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, romain.perier@gmail.com Subject: Re: [PATCH 2/3] irqchip: SigmaStar SSD20xD gpi In-Reply-To: <20210914100415.1549208-3-daniel@0x0f.com> References: <20210914100415.1549208-1-daniel@0x0f.com> <20210914100415.1549208-3-daniel@0x0f.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-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 X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: daniel@0x0f.com, devicetree@vger.kernel.org, robh+dt@kernel.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, romain.perier@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, 14 Sep 2021 11:04:14 +0100, Daniel Palmer wrote: > > Add support for the SigmaStar GPIO interrupt controller, gpi, > that is present in SSD201 and SSD202D SoCs. > > This routes interrupts from many interrupts into a single > interrupt that is connected to the peripheral interrupt > controller. > > Signed-off-by: Daniel Palmer > --- > MAINTAINERS | 1 + > drivers/irqchip/Kconfig | 11 ++ > drivers/irqchip/Makefile | 2 + > drivers/irqchip/irq-ssd20xd-gpi.c | 211 ++++++++++++++++++++++++++++++ > 4 files changed, 225 insertions(+) > create mode 100644 drivers/irqchip/irq-ssd20xd-gpi.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3004c0f735b6..487d5e62c287 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2248,6 +2248,7 @@ F: arch/arm/boot/dts/mstar-* > F: arch/arm/mach-mstar/ > F: drivers/clk/mstar/ > F: drivers/gpio/gpio-msc313.c > +F: drivers/irqchip/irq-ssd20xd-gpi.c > F: drivers/watchdog/msc313e_wdt.c > F: include/dt-bindings/clock/mstar-* > F: include/dt-bindings/gpio/msc313-gpio.h > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig > index 4d5924e9f766..8786aed7f776 100644 > --- a/drivers/irqchip/Kconfig > +++ b/drivers/irqchip/Kconfig > @@ -582,6 +582,17 @@ config MST_IRQ > help > Support MStar Interrupt Controller. > > +config SSD20XD_GPI > + bool "SigmaStar SSD20xD GPIO Interrupt Controller" > + depends on ARCH_MSTARV7 || COMPILE_TEST > + default ARCH_MSTARV7 > + select IRQ_DOMAIN > + select IRQ_DOMAIN_HIERARCHY > + select REGMAP > + help > + Support for the SigmaStar GPIO interrupt controller > + found in SSD201, SSD202D and others. > + > config WPCM450_AIC > bool "Nuvoton WPCM450 Advanced Interrupt Controller" > depends on ARCH_WPCM450 > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > index f88cbf36a9d2..1a6c3dbd67a8 100644 > --- a/drivers/irqchip/Makefile > +++ b/drivers/irqchip/Makefile > @@ -116,3 +116,5 @@ obj-$(CONFIG_MACH_REALTEK_RTL) += irq-realtek-rtl.o > obj-$(CONFIG_WPCM450_AIC) += irq-wpcm450-aic.o > obj-$(CONFIG_IRQ_IDT3243X) += irq-idt3243x.o > obj-$(CONFIG_APPLE_AIC) += irq-apple-aic.o > +obj-$(CONFIG_SSD20XD_GPI) += irq-ssd20xd-gpi.o > + > diff --git a/drivers/irqchip/irq-ssd20xd-gpi.c b/drivers/irqchip/irq-ssd20xd-gpi.c > new file mode 100644 > index 000000000000..c34f41380717 > --- /dev/null > +++ b/drivers/irqchip/irq-ssd20xd-gpi.c > @@ -0,0 +1,211 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2021 Daniel Palmer > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define NUM_IRQ 76 > +#define IRQS_PER_REG 16 > +#define STRIDE 4 > + > +#define REG_MASK 0x0 > +#define REG_ACK 0x28 > +#define REG_TYPE 0x40 > +#define REG_STATUS 0xc0 > + > +struct ssd20xd_gpi { > + struct regmap *regmap; > + struct irq_domain *domain; > +}; > + > +#define REG_OFFSET(_hwirq) ((hwirq >> 4) * STRIDE) > +#define BIT_OFFSET(_hwirq) (1 << (hwirq & 0xf)) > + > +static void ssd20xd_gpi_mask_irq(struct irq_data *data) > +{ > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + regmap_update_bits(gpi->regmap, REG_MASK + offset_reg, offset_bit, offset_bit); > +} > + > +static void ssd20xd_gpi_unmask_irq(struct irq_data *data) > +{ > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + regmap_update_bits(gpi->regmap, REG_MASK + offset_reg, offset_bit, 0); Is this regmap call atomic? When running this, you are holding a raw_spinlock already. From what I can see, this is unlikely to work correctly with the current state of regmap. > +} > + > +static void ssd20xd_gpi_irq_eoi(struct irq_data *data) > +{ > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + regmap_update_bits_base(gpi->regmap, REG_ACK + offset_reg, > + offset_bit, offset_bit, NULL, false, true); > +} > + > +static int ssd20xd_gpi_set_type_irq(struct irq_data *data, unsigned int flow_type) > +{ > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + switch (flow_type) { > + case IRQ_TYPE_EDGE_FALLING: > + regmap_update_bits(gpi->regmap, REG_TYPE + offset_reg, offset_bit, offset_bit); > + break; > + case IRQ_TYPE_EDGE_RISING: > + regmap_update_bits(gpi->regmap, REG_TYPE + offset_reg, offset_bit, 0); > + break; > + default: > + return -EINVAL; > + } > + > + return 0; > +} > + > +static struct irq_chip ssd20xd_gpi_chip = { > + .name = "GPI", > + .irq_mask = ssd20xd_gpi_mask_irq, > + .irq_unmask = ssd20xd_gpi_unmask_irq, > + .irq_eoi = ssd20xd_gpi_irq_eoi, > + .irq_set_type = ssd20xd_gpi_set_type_irq, > +}; > + > +static int ssd20xd_gpi_domain_alloc(struct irq_domain *domain, unsigned int virq, > + unsigned int nr_irqs, void *arg) > +{ > + struct ssd20xd_gpi *intc = domain->host_data; > + struct irq_fwspec *fwspec = arg; > + int i; > + > + for (i = 0; i < nr_irqs; i++) > + irq_domain_set_info(domain, virq + i, fwspec->param[0] + i, > + &ssd20xd_gpi_chip, intc, handle_fasteoi_irq, NULL, NULL); > + > + return 0; > +} > + > +static void ssd20xd_gpi_domain_free(struct irq_domain *domain, unsigned int virq, > + unsigned int nr_irqs) > +{ > + int i; > + > + for (i = 0; i < nr_irqs; i++) { > + struct irq_data *d = irq_domain_get_irq_data(domain, virq + i); > + > + irq_set_handler(virq + i, NULL); > + irq_domain_reset_irq_data(d); > + } > +} > + > +static const struct irq_domain_ops ssd20xd_gpi_domain_ops = { > + .alloc = ssd20xd_gpi_domain_alloc, > + .free = ssd20xd_gpi_domain_free, > +}; > + > +static const struct regmap_config ssd20xd_gpi_regmap_config = { > + .reg_bits = 16, > + .val_bits = 16, > + .reg_stride = 4, > +}; > + > +static void ssd20x_gpi_chainedhandler(struct irq_desc *desc) > +{ > + struct ssd20xd_gpi *intc = irq_desc_get_handler_data(desc); > + struct irq_chip *chip = irq_desc_get_chip(desc); > + unsigned int irqbit, hwirq, virq, status; > + int i; > + > + chained_irq_enter(chip, desc); > + > + for (i = 0; i < NUM_IRQ / IRQS_PER_REG; i++) { > + int offset_reg = STRIDE * i; > + int offset_irq = IRQS_PER_REG * i; > + > + regmap_read(intc->regmap, REG_STATUS + offset_reg, &status); Does this act as an ACK in the HW? > + > + while (status) { > + irqbit = __ffs(status); > + hwirq = offset_irq + irqbit; > + virq = irq_find_mapping(intc->domain, hwirq); > + if (virq) > + generic_handle_irq(virq); Please replace this with generic_handle_domain_irq(). > + status &= ~BIT(irqbit); > + } > + } > + > + chained_irq_exit(chip, desc); > +} > + > +static int __init ssd20xd_gpi_of_init(struct device_node *node, > + struct device_node *parent) > +{ > + struct ssd20xd_gpi *intc; > + void __iomem *base; > + int irq, ret; > + > + intc = kzalloc(sizeof(*intc), GFP_KERNEL); > + if (!intc) > + return -ENOMEM; > + > + base = of_iomap(node, 0); > + if (!base) { > + ret = -ENODEV; > + goto out_free; > + } > + > + intc->regmap = regmap_init_mmio(NULL, base, &ssd20xd_gpi_regmap_config); > + if (IS_ERR(intc->regmap)) { > + ret = PTR_ERR(intc->regmap); > + goto out_unmap; > + } > + > + intc->domain = irq_domain_add_linear(node, NUM_IRQ, &ssd20xd_gpi_domain_ops, intc); > + if (!intc->domain) { > + ret = -ENOMEM; > + goto out_free_regmap; > + } > + > + irq = of_irq_get(node, 0); > + if (irq <= 0) { > + ret = irq; > + goto out_free_domain; > + } > + > + irq_set_chained_handler_and_data(irq, ssd20x_gpi_chainedhandler, > + intc); > + > + return 0; > + > +out_free_domain: > + irq_domain_remove(intc->domain); > +out_free_regmap: > + regmap_exit(intc->regmap); > +out_unmap: > + iounmap(base); > +out_free: > + kfree(intc); > + return ret; > +} > + > +IRQCHIP_DECLARE(ssd20xd_gpi, "sstar,ssd20xd-gpi", ssd20xd_gpi_of_init); Is there any reason why this isn't a standard platform device? In general, irqchips that are not part of the root hierarchy shouldn't need this anymore. M. -- Without deviation from the norm, progress is not possible. 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=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 04331C433EF for ; Mon, 20 Sep 2021 09:47:10 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C041F60F6C for ; Mon, 20 Sep 2021 09:47:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C041F60F6C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:MIME-Version:References:In-Reply-To: Subject:Cc: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=0dqHm1T73C1aEiz9dq8mz4Ty3szkCKlSE4uzibjJCQw=; b=hAp/OaYAtqL6Pt ggKJ16MXvrvVePHpfICrAY+DM3n2UBQU5+J5KLCojYFGe9xe8DS+BxoHHKZj5qdhdb1zXPYYOGxuE m+sfZqfEjXjDqMmBO6wBu0mXWYWAicozFCpMtvc6rKQLZrkMk4sWaKLArjuhMwyNIvfaEEW9UmtlM DjSr0al5ph/4JskVY+7JMcGQjf3nbs/g571P7nlrby5D3yNq1B5SNEQw0iDKdrhLxndkRPe8X9vN3 wPAfZqFCACGHI3LwR3ULZlfhKqDCKKq72TYUTB+UGqUl6qtpK7yTIAgr1ASyJVi6NwLEEFMnTJaGC fzJyL7WUNpzhFaxj1GEw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSFrZ-0019u1-T5; Mon, 20 Sep 2021 09:45:26 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSFrU-0019sz-Tp for linux-arm-kernel@lists.infradead.org; Mon, 20 Sep 2021 09:45:22 +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 6A7C560F6C; Mon, 20 Sep 2021 09:45:20 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mSFrS-00BjKG-Bg; Mon, 20 Sep 2021 10:45:18 +0100 Date: Mon, 20 Sep 2021 10:45:18 +0100 Message-ID: <87zgs7vavl.wl-maz@kernel.org> From: Marc Zyngier To: Daniel Palmer Cc: devicetree@vger.kernel.org, robh+dt@kernel.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, romain.perier@gmail.com Subject: Re: [PATCH 2/3] irqchip: SigmaStar SSD20xD gpi In-Reply-To: <20210914100415.1549208-3-daniel@0x0f.com> References: <20210914100415.1549208-1-daniel@0x0f.com> <20210914100415.1549208-3-daniel@0x0f.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (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.219.108.64 X-SA-Exim-Rcpt-To: daniel@0x0f.com, devicetree@vger.kernel.org, robh+dt@kernel.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, romain.perier@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-20210920_024521_028970_3F27CA30 X-CRM114-Status: GOOD ( 38.68 ) X-BeenThere: linux-arm-kernel@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-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 14 Sep 2021 11:04:14 +0100, Daniel Palmer wrote: > > Add support for the SigmaStar GPIO interrupt controller, gpi, > that is present in SSD201 and SSD202D SoCs. > > This routes interrupts from many interrupts into a single > interrupt that is connected to the peripheral interrupt > controller. > > Signed-off-by: Daniel Palmer > --- > MAINTAINERS | 1 + > drivers/irqchip/Kconfig | 11 ++ > drivers/irqchip/Makefile | 2 + > drivers/irqchip/irq-ssd20xd-gpi.c | 211 ++++++++++++++++++++++++++++++ > 4 files changed, 225 insertions(+) > create mode 100644 drivers/irqchip/irq-ssd20xd-gpi.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3004c0f735b6..487d5e62c287 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2248,6 +2248,7 @@ F: arch/arm/boot/dts/mstar-* > F: arch/arm/mach-mstar/ > F: drivers/clk/mstar/ > F: drivers/gpio/gpio-msc313.c > +F: drivers/irqchip/irq-ssd20xd-gpi.c > F: drivers/watchdog/msc313e_wdt.c > F: include/dt-bindings/clock/mstar-* > F: include/dt-bindings/gpio/msc313-gpio.h > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig > index 4d5924e9f766..8786aed7f776 100644 > --- a/drivers/irqchip/Kconfig > +++ b/drivers/irqchip/Kconfig > @@ -582,6 +582,17 @@ config MST_IRQ > help > Support MStar Interrupt Controller. > > +config SSD20XD_GPI > + bool "SigmaStar SSD20xD GPIO Interrupt Controller" > + depends on ARCH_MSTARV7 || COMPILE_TEST > + default ARCH_MSTARV7 > + select IRQ_DOMAIN > + select IRQ_DOMAIN_HIERARCHY > + select REGMAP > + help > + Support for the SigmaStar GPIO interrupt controller > + found in SSD201, SSD202D and others. > + > config WPCM450_AIC > bool "Nuvoton WPCM450 Advanced Interrupt Controller" > depends on ARCH_WPCM450 > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > index f88cbf36a9d2..1a6c3dbd67a8 100644 > --- a/drivers/irqchip/Makefile > +++ b/drivers/irqchip/Makefile > @@ -116,3 +116,5 @@ obj-$(CONFIG_MACH_REALTEK_RTL) += irq-realtek-rtl.o > obj-$(CONFIG_WPCM450_AIC) += irq-wpcm450-aic.o > obj-$(CONFIG_IRQ_IDT3243X) += irq-idt3243x.o > obj-$(CONFIG_APPLE_AIC) += irq-apple-aic.o > +obj-$(CONFIG_SSD20XD_GPI) += irq-ssd20xd-gpi.o > + > diff --git a/drivers/irqchip/irq-ssd20xd-gpi.c b/drivers/irqchip/irq-ssd20xd-gpi.c > new file mode 100644 > index 000000000000..c34f41380717 > --- /dev/null > +++ b/drivers/irqchip/irq-ssd20xd-gpi.c > @@ -0,0 +1,211 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2021 Daniel Palmer > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define NUM_IRQ 76 > +#define IRQS_PER_REG 16 > +#define STRIDE 4 > + > +#define REG_MASK 0x0 > +#define REG_ACK 0x28 > +#define REG_TYPE 0x40 > +#define REG_STATUS 0xc0 > + > +struct ssd20xd_gpi { > + struct regmap *regmap; > + struct irq_domain *domain; > +}; > + > +#define REG_OFFSET(_hwirq) ((hwirq >> 4) * STRIDE) > +#define BIT_OFFSET(_hwirq) (1 << (hwirq & 0xf)) > + > +static void ssd20xd_gpi_mask_irq(struct irq_data *data) > +{ > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + regmap_update_bits(gpi->regmap, REG_MASK + offset_reg, offset_bit, offset_bit); > +} > + > +static void ssd20xd_gpi_unmask_irq(struct irq_data *data) > +{ > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + regmap_update_bits(gpi->regmap, REG_MASK + offset_reg, offset_bit, 0); Is this regmap call atomic? When running this, you are holding a raw_spinlock already. From what I can see, this is unlikely to work correctly with the current state of regmap. > +} > + > +static void ssd20xd_gpi_irq_eoi(struct irq_data *data) > +{ > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + regmap_update_bits_base(gpi->regmap, REG_ACK + offset_reg, > + offset_bit, offset_bit, NULL, false, true); > +} > + > +static int ssd20xd_gpi_set_type_irq(struct irq_data *data, unsigned int flow_type) > +{ > + irq_hw_number_t hwirq = irqd_to_hwirq(data); > + struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data); > + int offset_reg = REG_OFFSET(hwirq); > + int offset_bit = BIT_OFFSET(hwirq); > + > + switch (flow_type) { > + case IRQ_TYPE_EDGE_FALLING: > + regmap_update_bits(gpi->regmap, REG_TYPE + offset_reg, offset_bit, offset_bit); > + break; > + case IRQ_TYPE_EDGE_RISING: > + regmap_update_bits(gpi->regmap, REG_TYPE + offset_reg, offset_bit, 0); > + break; > + default: > + return -EINVAL; > + } > + > + return 0; > +} > + > +static struct irq_chip ssd20xd_gpi_chip = { > + .name = "GPI", > + .irq_mask = ssd20xd_gpi_mask_irq, > + .irq_unmask = ssd20xd_gpi_unmask_irq, > + .irq_eoi = ssd20xd_gpi_irq_eoi, > + .irq_set_type = ssd20xd_gpi_set_type_irq, > +}; > + > +static int ssd20xd_gpi_domain_alloc(struct irq_domain *domain, unsigned int virq, > + unsigned int nr_irqs, void *arg) > +{ > + struct ssd20xd_gpi *intc = domain->host_data; > + struct irq_fwspec *fwspec = arg; > + int i; > + > + for (i = 0; i < nr_irqs; i++) > + irq_domain_set_info(domain, virq + i, fwspec->param[0] + i, > + &ssd20xd_gpi_chip, intc, handle_fasteoi_irq, NULL, NULL); > + > + return 0; > +} > + > +static void ssd20xd_gpi_domain_free(struct irq_domain *domain, unsigned int virq, > + unsigned int nr_irqs) > +{ > + int i; > + > + for (i = 0; i < nr_irqs; i++) { > + struct irq_data *d = irq_domain_get_irq_data(domain, virq + i); > + > + irq_set_handler(virq + i, NULL); > + irq_domain_reset_irq_data(d); > + } > +} > + > +static const struct irq_domain_ops ssd20xd_gpi_domain_ops = { > + .alloc = ssd20xd_gpi_domain_alloc, > + .free = ssd20xd_gpi_domain_free, > +}; > + > +static const struct regmap_config ssd20xd_gpi_regmap_config = { > + .reg_bits = 16, > + .val_bits = 16, > + .reg_stride = 4, > +}; > + > +static void ssd20x_gpi_chainedhandler(struct irq_desc *desc) > +{ > + struct ssd20xd_gpi *intc = irq_desc_get_handler_data(desc); > + struct irq_chip *chip = irq_desc_get_chip(desc); > + unsigned int irqbit, hwirq, virq, status; > + int i; > + > + chained_irq_enter(chip, desc); > + > + for (i = 0; i < NUM_IRQ / IRQS_PER_REG; i++) { > + int offset_reg = STRIDE * i; > + int offset_irq = IRQS_PER_REG * i; > + > + regmap_read(intc->regmap, REG_STATUS + offset_reg, &status); Does this act as an ACK in the HW? > + > + while (status) { > + irqbit = __ffs(status); > + hwirq = offset_irq + irqbit; > + virq = irq_find_mapping(intc->domain, hwirq); > + if (virq) > + generic_handle_irq(virq); Please replace this with generic_handle_domain_irq(). > + status &= ~BIT(irqbit); > + } > + } > + > + chained_irq_exit(chip, desc); > +} > + > +static int __init ssd20xd_gpi_of_init(struct device_node *node, > + struct device_node *parent) > +{ > + struct ssd20xd_gpi *intc; > + void __iomem *base; > + int irq, ret; > + > + intc = kzalloc(sizeof(*intc), GFP_KERNEL); > + if (!intc) > + return -ENOMEM; > + > + base = of_iomap(node, 0); > + if (!base) { > + ret = -ENODEV; > + goto out_free; > + } > + > + intc->regmap = regmap_init_mmio(NULL, base, &ssd20xd_gpi_regmap_config); > + if (IS_ERR(intc->regmap)) { > + ret = PTR_ERR(intc->regmap); > + goto out_unmap; > + } > + > + intc->domain = irq_domain_add_linear(node, NUM_IRQ, &ssd20xd_gpi_domain_ops, intc); > + if (!intc->domain) { > + ret = -ENOMEM; > + goto out_free_regmap; > + } > + > + irq = of_irq_get(node, 0); > + if (irq <= 0) { > + ret = irq; > + goto out_free_domain; > + } > + > + irq_set_chained_handler_and_data(irq, ssd20x_gpi_chainedhandler, > + intc); > + > + return 0; > + > +out_free_domain: > + irq_domain_remove(intc->domain); > +out_free_regmap: > + regmap_exit(intc->regmap); > +out_unmap: > + iounmap(base); > +out_free: > + kfree(intc); > + return ret; > +} > + > +IRQCHIP_DECLARE(ssd20xd_gpi, "sstar,ssd20xd-gpi", ssd20xd_gpi_of_init); Is there any reason why this isn't a standard platform device? In general, irqchips that are not part of the root hierarchy shouldn't need this anymore. 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