Re: [RFC 4/4] gpio: sifive: Add GPIO driver for SiFive SoCs
From: Linus Walleij <hidden>
Date: 2018-10-10 12:35:34
Also in:
linux-devicetree, linux-pwm, linux-riscv, lkml
Hi Atish, thanks for your patch! On Tue, Oct 9, 2018 at 8:51 PM Atish Patra [off-list ref] wrote:
From: "Wesley W. Terpstra" <redacted> Adds the GPIO driver for SiFive RISC-V SoCs. Signed-off-by: Wesley W. Terpstra <redacted> [Atish: Various fixes and code cleanup] Signed-off-by: Atish Patra <redacted>
(...)
+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.
+ 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.
+#include <linux/pinctrl/consumer.h>
Are you using this?
+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?
+ 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.
+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.
+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.
+ 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. Yours, Linus Walleij