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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 448FCC433F5 for ; Sat, 8 Jan 2022 11:08:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231420AbiAHLGq (ORCPT ); Sat, 8 Jan 2022 06:06:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229973AbiAHLGp (ORCPT ); Sat, 8 Jan 2022 06:06:45 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A87EC061574 for ; Sat, 8 Jan 2022 03:06:45 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EB49A60BA7 for ; Sat, 8 Jan 2022 11:06:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 520C5C36AE9; Sat, 8 Jan 2022 11:06:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641640004; bh=sEt4CvB8HyzL5Rmhx9mM8CFEOx1uQyVT5iaBusXeEtw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tpbAGqHpLzdEPdYW3lEOJg0u6mOJ6cC2ulHe+R2Kd5jVaRkOHRE0rgbXZtBhdeU5M w66RBGwwjG4HfgmOafHd5X7eaIbbum2kR0eBIqIe0GCDzmOHM2AqthoE2lV/rwmJsB 7zEqqHG1bKFyg7DOlR0GT5I3s2NuvMc67IkB9ysCwal5f7IeFi8cjLshyjAMjeEk6v 8gjZOTf3LRgOWumM+INpo34GskD7fhzeZR1/H2qVtVd9oHx6Y7O8Hzo7Bs1v5HT+sD sGkUvGF1oRh+jPnvWe7L7lqKkJUMMGOy/gnSPRuV6xjFc9+XyZCK2oFV8yo2jtD6u8 WSm3hruUZVbiA== 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 1n69YY-00GkEE-Cc; Sat, 08 Jan 2022 11:06:42 +0000 Date: Sat, 08 Jan 2022 11:06:42 +0000 Message-ID: <87r19itrjx.wl-maz@kernel.org> From: Marc Zyngier To: Qianggui Song Cc: Thomas Gleixner , Kevin Hilman , Neil Armstrong , Jerome Brunet , Martin Blumenstingl , , , Subject: Re: [PATCH 4/4] irqchip/meson-gpio: Add support for meson s4 SoCs In-Reply-To: <20220108084218.31877-5-qianggui.song@amlogic.com> References: <20220108084218.31877-1-qianggui.song@amlogic.com> <20220108084218.31877-5-qianggui.song@amlogic.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: qianggui.song@amlogic.com, tglx@linutronix.de, khilman@baylibre.com, narmstrong@baylibre.com, jbrunet@baylibre.com, martin.blumenstingl@googlemail.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org 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: linux-kernel@vger.kernel.org On Sat, 08 Jan 2022 08:42:18 +0000, Qianggui Song wrote: > > The meson s4 SoCs support 12 gpio irq lines compared with previous > serial chips and have something different, details are as below. > > IRQ Number: > - 80:68 13 pins on bank Z > - 67:48 20 pins on bank X > - 47:36 12 pins on bank H > - 35:24 12 pins on bank D > - 23:22 2 pins on bank E > - 21:14 8 pins on bank C > - 13:0 13 pins on bank B > > - PADCTRL_GPIO_IRQ_CTRL0 > bit[31]: enable/disable the whole irq lines s/the whole/all the/ > bit[12-23]: single edge trigger > bit[0-11]: poll trigger > > - PADCTRL_GPIO_IRQ_CTRL[X] > - bit[0-16]: 7 bits to chooge gpio source for irq line 2*[X] - 2 choose? > - bit[16-22]:7 bits to chooge gpio source for irq line 2*[X] - 1 > where X = 1-6 > > - PADCTRL_GPIO_IRQ_CTRL[7] > bit[0-11]: both edge trigger This information would fit better in the code than in the commit message. > > Signed-off-by: Qianggui Song > --- > drivers/irqchip/irq-meson-gpio.c | 51 ++++++++++++++++++++++++++++++++ > 1 file changed, 51 insertions(+) > > diff --git a/drivers/irqchip/irq-meson-gpio.c b/drivers/irqchip/irq-meson-gpio.c > index 98419428fcbd..c5d20a866c37 100644 > --- a/drivers/irqchip/irq-meson-gpio.c > +++ b/drivers/irqchip/irq-meson-gpio.c > @@ -42,6 +42,11 @@ > #define REG_PIN_SEL_SHIFT(x) (((x) % 4) * 8) > #define REG_FILTER_SEL_SHIFT(x) ((x) * 4) > > +/* use for s4 chips */ s/use/Used/ > +#define REG_EDGE_POL_S4 0x1c > +#define REG_EDGE_POL_MASK_S4(x) \ > + ({typeof(x) _x = (x); BIT(_x) | BIT(12 + (_x)); }) Why on Earth should this macro handle multiple types? > + > struct meson_gpio_irq_controller; > static void meson8_gpio_irq_sel_pin(struct meson_gpio_irq_controller *ctl, > unsigned int channel, unsigned long hwirq); > @@ -50,6 +55,9 @@ static void meson_a1_gpio_irq_sel_pin(struct meson_gpio_irq_controller *ctl, > unsigned int channel, > unsigned long hwirq); > static void meson_a1_gpio_irq_init(struct meson_gpio_irq_controller *ctl); > +static unsigned int > +meson_s4_gpio_irq_sel_type(struct meson_gpio_irq_controller *ctl, > + unsigned int idx, u32 val); > > struct irq_ctl_ops { > void (*gpio_irq_sel_pin)(struct meson_gpio_irq_controller *ctl, > @@ -96,6 +104,17 @@ struct meson_gpio_irq_params { > .pin_sel_mask = 0x7f, \ > .channel_num = 8, \ > > +#define INIT_MESON_S4_COMMON_DATA(irqs) \ > + INIT_MESON_COMMON(irqs, meson_a1_gpio_irq_init, \ > + meson_a1_gpio_irq_sel_pin, \ > + meson_s4_gpio_irq_sel_type) \ > + .support_edge_both = true, \ > + .edge_both_offset = 0, \ > + .edge_single_offset = 12, \ > + .pol_low_offset = 0, \ > + .pin_sel_mask = 0xff, \ > + .channel_num = 12, \ > + > static const struct meson_gpio_irq_params meson8_params = { > INIT_MESON8_COMMON_DATA(134) > }; > @@ -126,6 +145,10 @@ static const struct meson_gpio_irq_params a1_params = { > INIT_MESON_A1_COMMON_DATA(62) > }; > > +static const struct meson_gpio_irq_params s4_params = { > + INIT_MESON_S4_COMMON_DATA(82) > +}; > + > static const struct of_device_id meson_irq_gpio_matches[] = { > { .compatible = "amlogic,meson8-gpio-intc", .data = &meson8_params }, > { .compatible = "amlogic,meson8b-gpio-intc", .data = &meson8b_params }, > @@ -135,6 +158,7 @@ static const struct of_device_id meson_irq_gpio_matches[] = { > { .compatible = "amlogic,meson-g12a-gpio-intc", .data = &axg_params }, > { .compatible = "amlogic,meson-sm1-gpio-intc", .data = &sm1_params }, > { .compatible = "amlogic,meson-a1-gpio-intc", .data = &a1_params }, > + { .compatible = "amlogic,meson-s4-gpio-intc", .data = &s4_params }, > { } > }; > > @@ -202,6 +226,33 @@ static void meson_a1_gpio_irq_init(struct meson_gpio_irq_controller *ctl) > meson_gpio_irq_update_bits(ctl, REG_EDGE_POL, BIT(31), BIT(31)); > } > > +static unsigned int > +meson_s4_gpio_irq_sel_type(struct meson_gpio_irq_controller *ctl, > + unsigned int idx, unsigned int type) An 'unsigned int' return type, directly returned by a caller that has 'int' as its return type. What could possibly go wrong? > +{ > + unsigned int val = 0; > + > + meson_gpio_irq_update_bits(ctl, REG_EDGE_POL_S4, BIT(0 + (idx)), 0); Drop the 0 + as well as the useless bracketing all over this function. > + > + if (type == IRQ_TYPE_EDGE_BOTH) { > + val |= BIT(ctl->params->edge_both_offset + (idx)); > + meson_gpio_irq_update_bits(ctl, REG_EDGE_POL_S4, > + BIT(ctl->params->edge_both_offset + (idx)), val); > + return 0; > + } > + > + if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING)) > + val |= BIT(ctl->params->pol_low_offset + (idx)); > + > + if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING)) > + val |= BIT(ctl->params->edge_single_offset + (idx)); > + > + meson_gpio_irq_update_bits(ctl, REG_EDGE_POL, > + REG_EDGE_POL_MASK_S4(idx), val); > + > + return 0; > +}; > + > static int > meson_gpio_irq_request_channel(struct meson_gpio_irq_controller *ctl, > unsigned long hwirq, M. -- Without deviation from the norm, progress is not possible.