Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
On Mon, May 25, 2020 at 02:59:36PM +0200, Linus Walleij wrote: > On Mon, May 25, 2020 at 12:20 PM Michael Walle wrote: > > > If you like I could submit this patch on its own. But then there > > wouldn't be a user for it. > > I'm pretty much fine with that, we do merge code that has no > users if we anticipate they will be around the corner. I remember we discussed with Pierre to use it for his ASoC work. Pierre, does it sound useful for you? -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
On Mon, May 25, 2020 at 12:20 PM Michael Walle wrote: > If you like I could submit this patch on its own. But then there > wouldn't be a user for it. I'm pretty much fine with that, we do merge code that has no users if we anticipate they will be around the corner. Yours, Linus Walleij
Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
Am 2020-05-25 11:05, schrieb Bartosz Golaszewski:
wt., 12 maj 2020 o 16:41 Michael Walle napisał(a):
>> +
>> +MODULE_AUTHOR("Michael Walle ");
>> +MODULE_DESCRIPTION("GPIO generic regmap driver core");
>> +MODULE_LICENSE("GPL");
>> diff --git a/include/linux/gpio-regmap.h b/include/linux/gpio-regmap.h
>> new file mode 100644
>> index ..a868cbcde6e9
>> --- /dev/null
>> +++ b/include/linux/gpio-regmap.h
>> @@ -0,0 +1,69 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#ifndef _LINUX_GPIO_REGMAP_H
>> +#define _LINUX_GPIO_REGMAP_H
>> +
>> +struct gpio_regmap;
>> +
>> +#define GPIO_REGMAP_ADDR_ZERO ((unsigned long)(-1))
>> +#define GPIO_REGMAP_ADDR(addr) ((addr) ? : GPIO_REGMAP_ADDR_ZERO)
>> +
>
> What if the addr is actually 0?
Then the driver has to set GPIO_REGMAP_ADDR_ZERO or use the
convenience
macro GPIO_REGMAP_ADDR.
So you can have
struct gpio_regmap_config config = { 0 };
config.reg_dat_base = 0x10;
config.reg_dir_out_base = 0x20;
or
config.reg_dat_base = GPIO_REGMAP_ADDR_ZERO;
or if you can't be sure if the RHS value might be zero:
config.reg_dat_base = GPIO_REGMAP_ADDR(reg);
> Maybe drop GPIO_REGMAP_ADDR and require users to set unused registers
> to GPIO_REGMAP_ADDR_ZERO?
Thats bad because:
* you'd have to set plenty of unused base registers for a simple
driver
* if there will be additional properties in the future, you have to
touch
all other drivers, because they are initialized as 0 (ie. valid
reg
0).
>> +/**
>> + * struct gpio_regmap_config - Description of a generic regmap
>> gpio_chip.
>> + *
>> + * @parent:The parent device
>> + * @regmap:The regmap used to access the registers
>> + * given, the name of the device is used
>> + * @label: (Optional) Descriptive name for GPIO
>> controller.
>> + * If not given, the name of the device is used.
>> + * @ngpio: Number of GPIOs
>> + * @reg_dat_base: (Optional) (in) register base address
>> + * @reg_set_base: (Optional) set register base address
>> + * @reg_clr_base: (Optional) clear register base address
>> + * @reg_dir_in_base: (Optional) out setting register base address
>> + * @reg_dir_out_base: (Optional) in setting register base address
>
> The two above are inverted I think?
good catch.
> Also: why the limitation of only supporting one at a time?
they should be exclusive, either you have a register where you set the
output bits to one, or the input bits. Maybe this need a bit more
context
above. in gpio-mmio.c you can set both and both are used in
set_direction(), but only one is read in get_direction().
That being said, I have no strong opinion wether they should be
exclusive
or not, besides the symmetry of set_/get_direction().
-michael
Sorry for the late response, your comments make sense to me. Are you
going to submit a v4 before the v5.8 merge window?
I'm currently stuck with how to handle the MFD part. Ie. Rob doesn't
seem to like the logicial device numbering - or at least there wasn't
an answer to that one anymore, see patch 5/16.
If you like I could submit this patch on its own. But then there
wouldn't be a user for it.
-michael
Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
wt., 12 maj 2020 o 16:41 Michael Walle napisał(a):
>
> >> +
> >> +MODULE_AUTHOR("Michael Walle ");
> >> +MODULE_DESCRIPTION("GPIO generic regmap driver core");
> >> +MODULE_LICENSE("GPL");
> >> diff --git a/include/linux/gpio-regmap.h b/include/linux/gpio-regmap.h
> >> new file mode 100644
> >> index ..a868cbcde6e9
> >> --- /dev/null
> >> +++ b/include/linux/gpio-regmap.h
> >> @@ -0,0 +1,69 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +
> >> +#ifndef _LINUX_GPIO_REGMAP_H
> >> +#define _LINUX_GPIO_REGMAP_H
> >> +
> >> +struct gpio_regmap;
> >> +
> >> +#define GPIO_REGMAP_ADDR_ZERO ((unsigned long)(-1))
> >> +#define GPIO_REGMAP_ADDR(addr) ((addr) ? : GPIO_REGMAP_ADDR_ZERO)
> >> +
> >
> > What if the addr is actually 0?
>
> Then the driver has to set GPIO_REGMAP_ADDR_ZERO or use the convenience
> macro GPIO_REGMAP_ADDR.
>
> So you can have
>
>struct gpio_regmap_config config = { 0 };
>config.reg_dat_base = 0x10;
>config.reg_dir_out_base = 0x20;
>
> or
>
>config.reg_dat_base = GPIO_REGMAP_ADDR_ZERO;
>
> or if you can't be sure if the RHS value might be zero:
>
>config.reg_dat_base = GPIO_REGMAP_ADDR(reg);
>
>
> > Maybe drop GPIO_REGMAP_ADDR and require users to set unused registers
> > to GPIO_REGMAP_ADDR_ZERO?
>
> Thats bad because:
> * you'd have to set plenty of unused base registers for a simple driver
> * if there will be additional properties in the future, you have to
> touch
> all other drivers, because they are initialized as 0 (ie. valid reg
> 0).
>
> >> +/**
> >> + * struct gpio_regmap_config - Description of a generic regmap
> >> gpio_chip.
> >> + *
> >> + * @parent:The parent device
> >> + * @regmap:The regmap used to access the registers
> >> + * given, the name of the device is used
> >> + * @label: (Optional) Descriptive name for GPIO
> >> controller.
> >> + * If not given, the name of the device is used.
> >> + * @ngpio: Number of GPIOs
> >> + * @reg_dat_base: (Optional) (in) register base address
> >> + * @reg_set_base: (Optional) set register base address
> >> + * @reg_clr_base: (Optional) clear register base address
> >> + * @reg_dir_in_base: (Optional) out setting register base address
> >> + * @reg_dir_out_base: (Optional) in setting register base address
> >
> > The two above are inverted I think?
> good catch.
>
> > Also: why the limitation of only supporting one at a time?
>
> they should be exclusive, either you have a register where you set the
> output bits to one, or the input bits. Maybe this need a bit more
> context
> above. in gpio-mmio.c you can set both and both are used in
> set_direction(), but only one is read in get_direction().
>
> That being said, I have no strong opinion wether they should be
> exclusive
> or not, besides the symmetry of set_/get_direction().
>
> -michael
>
Sorry for the late response, your comments make sense to me. Are you
going to submit a v4 before the v5.8 merge window?
Bart
Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
Am 2020-05-12 14:48, schrieb Bartosz Golaszewski:
czw., 23 kwi 2020 o 19:46 Michael Walle napisał(a):
There are quite a lot simple GPIO controller which are using regmap to
access the hardware. This driver tries to be a base to unify existing
code into one place. This won't cover everything but it should be a
good
starting point.
It does not implement its own irq_chip because there is already a
generic one for regmap based devices. Instead, the irq_chip will be
instantiated in the parent driver and its irq domain will be associate
to this driver.
For now it consists of the usual registers, like set (and an optional
clear) data register, an input register and direction registers.
Out-of-the-box, it supports consecutive register mappings and mappings
where the registers have gaps between them with a linear mapping
between
GPIO offset and bit position. For weirder mappings the user can
register
its own .xlate().
Signed-off-by: Michael Walle
---
This looks good to me. Please see some nits below.
drivers/gpio/Kconfig| 4 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-regmap.c | 343
include/linux/gpio-regmap.h | 69
4 files changed, 417 insertions(+)
create mode 100644 drivers/gpio/gpio-regmap.c
create mode 100644 include/linux/gpio-regmap.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8ef2179fb999..ae3a49a2e970 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -73,6 +73,10 @@ config GPIO_GENERIC
depends on HAS_IOMEM # Only for IOMEM drivers
tristate
+config GPIO_REGMAP
+ depends on REGMAP
+ tristate
+
# put drivers in the right section, in alphabetical order
# This symbol is selected by both I2C and SPI expanders
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index b2cfc21a97f3..93e139fdfa57 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o
obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
# Device drivers. Generally keep list sorted alphabetically
+obj-$(CONFIG_GPIO_REGMAP) += gpio-regmap.o
obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
# directly supported by gpio-generic
diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
new file mode 100644
index ..04939c0a22f9
--- /dev/null
+++ b/drivers/gpio/gpio-regmap.c
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * regmap based generic GPIO driver
+ *
+ * Copyright 2019 Michael Walle
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct gpio_regmap {
+ struct device *parent;
+ struct regmap *regmap;
+ struct gpio_chip gpio_chip;
+
+ int reg_stride;
+ int ngpio_per_reg;
+ unsigned int reg_dat_base;
+ unsigned int reg_set_base;
+ unsigned int reg_clr_base;
+ unsigned int reg_dir_in_base;
+ unsigned int reg_dir_out_base;
+
+ int (*reg_mask_xlate)(struct gpio_regmap *gpio, unsigned int
base,
+ unsigned int offset, unsigned int *reg,
+ unsigned int *mask);
+
+ void *driver_data;
+};
+
+static unsigned int gpio_regmap_addr(unsigned int addr)
+{
+ return (addr == GPIO_REGMAP_ADDR_ZERO) ? 0 : addr;
+}
+
+/**
+ * gpio_regmap_simple_xlate() - translate base/offset to reg/mask
+ *
+ * Use a simple linear mapping to translate the offset to the
bitmask.
+ */
+static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
+ unsigned int base, unsigned int
offset,
+ unsigned int *reg, unsigned int
*mask)
+{
+ unsigned int line = offset % gpio->ngpio_per_reg;
+ unsigned int stride = offset / gpio->ngpio_per_reg;
+
+ *reg = base + stride * gpio->reg_stride;
+ *mask = BIT(line);
+
+ return 0;
+}
+
+static int gpio_regmap_get(struct gpio_chip *chip, unsigned int
offset)
+{
+ struct gpio_regmap *gpio = gpiochip_get_data(chip);
+ unsigned int base, val, reg, mask;
+ int ret;
+
+ /* we might not have an output register if we are input only
*/
+ if (gpio->reg_dat_base)
+ base = gpio_regmap_addr(gpio->reg_dat_base);
+ else
+ base = gpio_regmap_addr(gpio->reg_set_base);
+
+ ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(gpio->regmap, reg, &val);
+ if (ret)
+ return ret;
+
+ return (val & mask) ? 1 : 0;
+}
+
+static void gpio_regmap_set(struct gpio_chip *chip, unsigned int
offset,
+ int val)
+{
+ struct gpio_regmap *gpio = gpiochip_get_data(chip);
+ unsigned int base = gpio_regmap_addr(gpio->reg_set_base);
+ unsigned int reg, mask;
+
+ gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
+ if
Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
czw., 23 kwi 2020 o 19:46 Michael Walle napisał(a):
>
> There are quite a lot simple GPIO controller which are using regmap to
> access the hardware. This driver tries to be a base to unify existing
> code into one place. This won't cover everything but it should be a good
> starting point.
>
> It does not implement its own irq_chip because there is already a
> generic one for regmap based devices. Instead, the irq_chip will be
> instantiated in the parent driver and its irq domain will be associate
> to this driver.
>
> For now it consists of the usual registers, like set (and an optional
> clear) data register, an input register and direction registers.
> Out-of-the-box, it supports consecutive register mappings and mappings
> where the registers have gaps between them with a linear mapping between
> GPIO offset and bit position. For weirder mappings the user can register
> its own .xlate().
>
> Signed-off-by: Michael Walle
> ---
This looks good to me. Please see some nits below.
> drivers/gpio/Kconfig| 4 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-regmap.c | 343
> include/linux/gpio-regmap.h | 69
> 4 files changed, 417 insertions(+)
> create mode 100644 drivers/gpio/gpio-regmap.c
> create mode 100644 include/linux/gpio-regmap.h
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 8ef2179fb999..ae3a49a2e970 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -73,6 +73,10 @@ config GPIO_GENERIC
> depends on HAS_IOMEM # Only for IOMEM drivers
> tristate
>
> +config GPIO_REGMAP
> + depends on REGMAP
> + tristate
> +
> # put drivers in the right section, in alphabetical order
>
> # This symbol is selected by both I2C and SPI expanders
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index b2cfc21a97f3..93e139fdfa57 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o
> obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
>
> # Device drivers. Generally keep list sorted alphabetically
> +obj-$(CONFIG_GPIO_REGMAP) += gpio-regmap.o
> obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
>
> # directly supported by gpio-generic
> diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
> new file mode 100644
> index ..04939c0a22f9
> --- /dev/null
> +++ b/drivers/gpio/gpio-regmap.c
> @@ -0,0 +1,343 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * regmap based generic GPIO driver
> + *
> + * Copyright 2019 Michael Walle
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct gpio_regmap {
> + struct device *parent;
> + struct regmap *regmap;
> + struct gpio_chip gpio_chip;
> +
> + int reg_stride;
> + int ngpio_per_reg;
> + unsigned int reg_dat_base;
> + unsigned int reg_set_base;
> + unsigned int reg_clr_base;
> + unsigned int reg_dir_in_base;
> + unsigned int reg_dir_out_base;
> +
> + int (*reg_mask_xlate)(struct gpio_regmap *gpio, unsigned int base,
> + unsigned int offset, unsigned int *reg,
> + unsigned int *mask);
> +
> + void *driver_data;
> +};
> +
> +static unsigned int gpio_regmap_addr(unsigned int addr)
> +{
> + return (addr == GPIO_REGMAP_ADDR_ZERO) ? 0 : addr;
> +}
> +
> +/**
> + * gpio_regmap_simple_xlate() - translate base/offset to reg/mask
> + *
> + * Use a simple linear mapping to translate the offset to the bitmask.
> + */
> +static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
> + unsigned int base, unsigned int offset,
> + unsigned int *reg, unsigned int *mask)
> +{
> + unsigned int line = offset % gpio->ngpio_per_reg;
> + unsigned int stride = offset / gpio->ngpio_per_reg;
> +
> + *reg = base + stride * gpio->reg_stride;
> + *mask = BIT(line);
> +
> + return 0;
> +}
> +
> +static int gpio_regmap_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct gpio_regmap *gpio = gpiochip_get_data(chip);
> + unsigned int base, val, reg, mask;
> + int ret;
> +
> + /* we might not have an output register if we are input only */
> + if (gpio->reg_dat_base)
> + base = gpio_regmap_addr(gpio->reg_dat_base);
> + else
> + base = gpio_regmap_addr(gpio->reg_set_base);
> +
> + ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> +
> + ret = regmap_read(gpio->regmap, reg, &val);
> + if (ret)
> + return ret;
> +
> + return (val & mask) ? 1 : 0;
> +}
> +
> +static void gpio_regmap_set(struct gpio_chip *chip, unsigned int offset,
> + int val)
> +{
> + struct gpio_regmap
