From: atish.patra@wdc.com (Atish Patra) To: linux-riscv@lists.infradead.org Subject: [RFC 4/4] gpio: sifive: Add GPIO driver for SiFive SoCs Date: Tue, 16 Oct 2018 18:01:13 -0700 [thread overview] Message-ID: <d8fe9a17-283c-e2ad-9e01-2754b35699b4@wdc.com> (raw) In-Reply-To: <CACRpkdaoBwqQ4V5Hm9f_G5_jrdkvjT5anhBK1_HoFTj6=cba-Q@mail.gmail.com> On 10/10/18 5:35 AM, Linus Walleij wrote: > Hi Atish, > > thanks for your patch! > > On Tue, Oct 9, 2018 at 8:51 PM Atish Patra <atish.patra@wdc.com> wrote: > >> From: "Wesley W. Terpstra" <wesley@sifive.com> >> >> Adds the GPIO driver for SiFive RISC-V SoCs. >> >> Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> >> [Atish: Various fixes and code cleanup] >> Signed-off-by: Atish Patra <atish.patra@wdc.com> > > (...) > >> +config GPIO_SIFIVE >> + bool "SiFive GPIO support" >> + depends on OF_GPIO >> + select GPIOLIB_IRQCHIP > > I suggest to add > select GPIO_GENERIC as per below. > > Maybe select REGMAP_MMIO as well. ok. > >> + help >> + Say yes here to support the GPIO device on SiFive SoCs. >> + > >> +#include <linux/of_irq.h> >> +#include <linux/irqchip/chained_irq.h> > > Do you need these two? I think <linux/gpio/driver.h> > will bring them in for you. > driver.h only brings chained_irq.h. of_irq.h is still required. Right ? >> +#include <linux/pinctrl/consumer.h> > > Are you using this? My bad. Left over from the old code. I will remove it. > >> +struct sifive_gpio { >> + raw_spinlock_t lock; >> + void __iomem *base; >> + struct gpio_chip gc; >> + unsigned long enabled; > > Since max GPIO is 32 why not use an u32 for this? > Sure. >> + unsigned int trigger[MAX_GPIO]; >> + unsigned int irq_parent[MAX_GPIO]; >> + struct sifive_gpio *self_ptr[MAX_GPIO]; >> +}; >> + >> +static void sifive_assign_bit(void __iomem *ptr, unsigned int offset, int value) >> +{ >> + /* >> + * It's frustrating that we are not allowed to use the device atomics >> + * which are GUARANTEED to be supported by this device on RISC-V >> + */ >> + u32 bit = BIT(offset), old = ioread32(ptr); >> + >> + if (value) >> + iowrite32(old | bit, ptr); >> + else >> + iowrite32(old & ~bit, ptr); >> +} > > This looks like a mask and set implementation, you are > essentially reinventing regmap MMIO and the > regmap_update_bits() call. Could you look into > just using regmap MMIO in that case? > > If you need examples, look at gpio-mvebu.c that calls > devm_regmap_init_mmio() for example. > That's really cool. Sorry, for not checking that earlier. I am pretty new to this. >> +static int sifive_direction_input(struct gpio_chip *gc, unsigned int offset) >> +static int sifive_direction_output(struct gpio_chip *gc, unsigned int offset, >> +static int sifive_get_direction(struct gpio_chip *gc, unsigned int offset) >> +static int sifive_get_value(struct gpio_chip *gc, unsigned int offset) >> +static void sifive_set_value(struct gpio_chip *gc, unsigned int offset, > > These functions look like a typical hardware that can use > > GPIOLIB_GENERIC and bgpio_init() to set up the accessors. > > See gpio-ftgpio010.c for an example. > > As a bonus you will get .get/.set_multiple implemented by > the generic GPIO. > Great. This will reduce the driver a code by a big factor. Thanks for the pointer. >> +static void sifive_irq_enable(struct irq_data *d) >> +static void sifive_irq_disable(struct irq_data *d) > (...) >> +static struct irq_chip sifive_irqchip = { >> + .name = "sifive-gpio", >> + .irq_set_type = sifive_irq_set_type, >> + .irq_mask = sifive_irq_mask, >> + .irq_unmask = sifive_irq_unmask, >> + .irq_enable = sifive_irq_enable, >> + .irq_disable = sifive_irq_disable, > > The handling of .irq_enable and .irq_disable has > changed upstream. Please align with the new codebase > as changed by Hans Verkuil: > > commit 461c1a7d4733d1dfd5c47b040cf32a5e7eefbc6c > "gpiolib: override irq_enable/disable" > commit 4e9439ddacea06f35acce4d374bf6bd0acf99bc8 > "gpiolib: add flag to indicate if the irq is disabled" > > You will need to rebase your work on the v4.20-rc1 once it is > out. Right now the changes are on linux-next or my devel > branch. Will do. > >> + ngpio = of_irq_count(node); >> + if (ngpio >= MAX_GPIO) { >> + dev_err(dev, "Too many GPIO interrupts (max=%d)\n", MAX_GPIO); >> + return -ENXIO; >> + } > (...) >> + for (gpio = 0; gpio < ngpio; ++gpio) { >> + irq = platform_get_irq(pdev, gpio); >> + if (irq < 0) { >> + dev_err(dev, "invalid IRQ\n"); >> + gpiochip_remove(&chip->gc); >> + return -ENODEV; >> + } > > This is an hierarchical IRQ so it should use an hierarchical > irqdomain. > > I am discussing with Thierry to make more generic irq domains > for hierarchical IRQ GPIOs, until then you have to look at > gpio-thunderx.c, gpio-uniphier.c or gpio-xgene-sb.c that all > use hierarchical IRQs. > Thanks. I will convert them to hierarchical IRQ. Regards, Atish > Yours, > Linus Walleij >
WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <atish.patra@wdc.com> To: Linus Walleij <linus.walleij@linaro.org>, "thierry.reding@gmail.com" <thierry.reding@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>, Palmer Dabbelt <palmer@sifive.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@infradead.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org> Subject: Re: [RFC 4/4] gpio: sifive: Add GPIO driver for SiFive SoCs Date: Tue, 16 Oct 2018 18:01:13 -0700 [thread overview] Message-ID: <d8fe9a17-283c-e2ad-9e01-2754b35699b4@wdc.com> (raw) Message-ID: <20181017010113.izXDCOPJ3ps0qKRqgNt5OaOZf6ghv-_e1nquGaG8TsE@z> (raw) In-Reply-To: <CACRpkdaoBwqQ4V5Hm9f_G5_jrdkvjT5anhBK1_HoFTj6=cba-Q@mail.gmail.com> On 10/10/18 5:35 AM, Linus Walleij wrote: > Hi Atish, > > thanks for your patch! > > On Tue, Oct 9, 2018 at 8:51 PM Atish Patra <atish.patra@wdc.com> wrote: > >> From: "Wesley W. Terpstra" <wesley@sifive.com> >> >> Adds the GPIO driver for SiFive RISC-V SoCs. >> >> Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> >> [Atish: Various fixes and code cleanup] >> Signed-off-by: Atish Patra <atish.patra@wdc.com> > > (...) > >> +config GPIO_SIFIVE >> + bool "SiFive GPIO support" >> + depends on OF_GPIO >> + select GPIOLIB_IRQCHIP > > I suggest to add > select GPIO_GENERIC as per below. > > Maybe select REGMAP_MMIO as well. ok. > >> + help >> + Say yes here to support the GPIO device on SiFive SoCs. >> + > >> +#include <linux/of_irq.h> >> +#include <linux/irqchip/chained_irq.h> > > Do you need these two? I think <linux/gpio/driver.h> > will bring them in for you. > driver.h only brings chained_irq.h. of_irq.h is still required. Right ? >> +#include <linux/pinctrl/consumer.h> > > Are you using this? My bad. Left over from the old code. I will remove it. > >> +struct sifive_gpio { >> + raw_spinlock_t lock; >> + void __iomem *base; >> + struct gpio_chip gc; >> + unsigned long enabled; > > Since max GPIO is 32 why not use an u32 for this? > Sure. >> + unsigned int trigger[MAX_GPIO]; >> + unsigned int irq_parent[MAX_GPIO]; >> + struct sifive_gpio *self_ptr[MAX_GPIO]; >> +}; >> + >> +static void sifive_assign_bit(void __iomem *ptr, unsigned int offset, int value) >> +{ >> + /* >> + * It's frustrating that we are not allowed to use the device atomics >> + * which are GUARANTEED to be supported by this device on RISC-V >> + */ >> + u32 bit = BIT(offset), old = ioread32(ptr); >> + >> + if (value) >> + iowrite32(old | bit, ptr); >> + else >> + iowrite32(old & ~bit, ptr); >> +} > > This looks like a mask and set implementation, you are > essentially reinventing regmap MMIO and the > regmap_update_bits() call. Could you look into > just using regmap MMIO in that case? > > If you need examples, look at gpio-mvebu.c that calls > devm_regmap_init_mmio() for example. > That's really cool. Sorry, for not checking that earlier. I am pretty new to this. >> +static int sifive_direction_input(struct gpio_chip *gc, unsigned int offset) >> +static int sifive_direction_output(struct gpio_chip *gc, unsigned int offset, >> +static int sifive_get_direction(struct gpio_chip *gc, unsigned int offset) >> +static int sifive_get_value(struct gpio_chip *gc, unsigned int offset) >> +static void sifive_set_value(struct gpio_chip *gc, unsigned int offset, > > These functions look like a typical hardware that can use > > GPIOLIB_GENERIC and bgpio_init() to set up the accessors. > > See gpio-ftgpio010.c for an example. > > As a bonus you will get .get/.set_multiple implemented by > the generic GPIO. > Great. This will reduce the driver a code by a big factor. Thanks for the pointer. >> +static void sifive_irq_enable(struct irq_data *d) >> +static void sifive_irq_disable(struct irq_data *d) > (...) >> +static struct irq_chip sifive_irqchip = { >> + .name = "sifive-gpio", >> + .irq_set_type = sifive_irq_set_type, >> + .irq_mask = sifive_irq_mask, >> + .irq_unmask = sifive_irq_unmask, >> + .irq_enable = sifive_irq_enable, >> + .irq_disable = sifive_irq_disable, > > The handling of .irq_enable and .irq_disable has > changed upstream. Please align with the new codebase > as changed by Hans Verkuil: > > commit 461c1a7d4733d1dfd5c47b040cf32a5e7eefbc6c > "gpiolib: override irq_enable/disable" > commit 4e9439ddacea06f35acce4d374bf6bd0acf99bc8 > "gpiolib: add flag to indicate if the irq is disabled" > > You will need to rebase your work on the v4.20-rc1 once it is > out. Right now the changes are on linux-next or my devel > branch. Will do. > >> + ngpio = of_irq_count(node); >> + if (ngpio >= MAX_GPIO) { >> + dev_err(dev, "Too many GPIO interrupts (max=%d)\n", MAX_GPIO); >> + return -ENXIO; >> + } > (...) >> + for (gpio = 0; gpio < ngpio; ++gpio) { >> + irq = platform_get_irq(pdev, gpio); >> + if (irq < 0) { >> + dev_err(dev, "invalid IRQ\n"); >> + gpiochip_remove(&chip->gc); >> + return -ENODEV; >> + } > > This is an hierarchical IRQ so it should use an hierarchical > irqdomain. > > I am discussing with Thierry to make more generic irq domains > for hierarchical IRQ GPIOs, until then you have to look at > gpio-thunderx.c, gpio-uniphier.c or gpio-xgene-sb.c that all > use hierarchical IRQs. > Thanks. I will convert them to hierarchical IRQ. Regards, Atish > Yours, > Linus Walleij > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-10-17 1:01 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-09 18:51 [RFC 0/4] GPIO & PWM support for HiFive Unleashed Atish Patra 2018-10-09 18:51 ` Atish Patra 2018-10-09 18:51 ` [RFC 1/4] pwm: sifive: Add DT documentation for SiFive PWM Controller Atish Patra 2018-10-09 18:51 ` Atish Patra 2018-10-10 13:49 ` Thierry Reding 2018-10-10 13:49 ` Thierry Reding 2018-10-15 22:57 ` Atish Patra 2018-10-15 22:57 ` Atish Patra 2018-10-15 23:19 ` Wesley Terpstra 2018-10-15 23:19 ` Wesley Terpstra 2018-10-16 11:13 ` Thierry Reding 2018-10-16 11:13 ` Thierry Reding 2018-10-16 11:01 ` Thierry Reding 2018-10-16 11:01 ` Thierry Reding 2018-10-16 17:31 ` Paul Walmsley 2018-10-16 17:31 ` Paul Walmsley 2018-10-16 22:04 ` Thierry Reding 2018-10-16 22:04 ` Thierry Reding 2018-10-16 22:20 ` Atish Patra 2018-10-16 22:20 ` Atish Patra 2018-10-17 15:58 ` Rob Herring 2018-10-17 15:58 ` Rob Herring 2018-10-17 21:45 ` Atish Patra 2018-10-17 21:45 ` Atish Patra 2018-11-10 5:38 ` Paul Walmsley 2018-11-10 5:38 ` Paul Walmsley 2018-10-10 13:51 ` Thierry Reding 2018-10-10 13:51 ` Thierry Reding 2018-10-15 22:45 ` Atish Patra 2018-10-15 22:45 ` Atish Patra 2018-10-16 10:51 ` Thierry Reding 2018-10-16 10:51 ` Thierry Reding 2018-10-16 22:42 ` Atish Patra 2018-10-16 22:42 ` Atish Patra 2018-10-09 18:51 ` [RFC 2/4] pwm: sifive: Add a driver for SiFive SoC PWM Atish Patra 2018-10-09 18:51 ` Atish Patra 2018-10-10 13:11 ` Christoph Hellwig 2018-10-10 13:11 ` Christoph Hellwig 2018-10-10 13:44 ` Thierry Reding 2018-10-10 13:44 ` Thierry Reding 2018-10-16 6:28 ` Atish Patra 2018-10-16 6:28 ` Atish Patra 2018-10-10 14:13 ` Thierry Reding 2018-10-10 14:13 ` Thierry Reding 2018-10-16 6:24 ` Atish Patra 2018-10-16 6:24 ` Atish Patra 2018-10-09 18:51 ` [RFC 3/4] gpio: sifive: Add DT documentation for SiFive GPIO Atish Patra 2018-10-09 18:51 ` Atish Patra 2018-10-09 18:51 ` [RFC 4/4] gpio: sifive: Add GPIO driver for SiFive SoCs Atish Patra 2018-10-09 18:51 ` Atish Patra 2018-10-10 12:35 ` Linus Walleij 2018-10-10 12:35 ` Linus Walleij 2018-10-17 1:01 ` Atish Patra [this message] 2018-10-17 1:01 ` Atish Patra 2019-09-18 7:32 ` Bin Meng 2018-10-10 13:01 ` Andreas Schwab 2018-10-10 13:01 ` Andreas Schwab 2018-10-10 13:12 ` Christoph Hellwig 2018-10-10 13:12 ` Christoph Hellwig 2018-10-10 13:28 ` Andreas Schwab 2018-10-10 13:28 ` Andreas Schwab
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d8fe9a17-283c-e2ad-9e01-2754b35699b4@wdc.com \ --to=atish.patra@wdc.com \ --cc=linux-riscv@lists.infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).