* [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller @ 2018-07-25 12:26 Quentin Schulz 2018-07-25 12:26 ` [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller Quentin Schulz ` (3 more replies) 0 siblings, 4 replies; 10+ messages in thread From: Quentin Schulz @ 2018-07-25 12:26 UTC (permalink / raw) To: alexandre.belloni, robh+dt, mark.rutland, linus.walleij Cc: ralf, paul.burton, jhogan, linux-gpio, linux-mips, devicetree, linux-kernel, thomas.petazzoni, Quentin Schulz The GPIO controller also serves as an interrupt controller for events on the GPIO it handles. An interrupt occurs whenever a GPIO line has changed. Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> --- arch/mips/boot/dts/mscc/ocelot.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi b/arch/mips/boot/dts/mscc/ocelot.dtsi index d7f0e3551500..afe8fc9011ea 100644 --- a/arch/mips/boot/dts/mscc/ocelot.dtsi +++ b/arch/mips/boot/dts/mscc/ocelot.dtsi @@ -168,6 +168,9 @@ gpio-controller; #gpio-cells = <2>; gpio-ranges = <&gpio 0 0 22>; + interrupt-controller; + interrupts = <13>; + #interrupt-cells = <2>; uart_pins: uart-pins { pins = "GPIO_6", "GPIO_7"; -- 2.14.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller 2018-07-25 12:26 [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Quentin Schulz @ 2018-07-25 12:26 ` Quentin Schulz 2018-08-06 11:06 ` Linus Walleij 2018-07-27 10:36 ` [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Alexandre Belloni ` (2 subsequent siblings) 3 siblings, 1 reply; 10+ messages in thread From: Quentin Schulz @ 2018-07-25 12:26 UTC (permalink / raw) To: alexandre.belloni, robh+dt, mark.rutland, linus.walleij Cc: ralf, paul.burton, jhogan, linux-gpio, linux-mips, devicetree, linux-kernel, thomas.petazzoni, Quentin Schulz This GPIO controller can serve as an interrupt controller as well on the GPIOs it handles. An interrupt is generated whenever a GPIO line changes and the interrupt for this GPIO line is enabled. This means that both the changes from low to high and high to low generate an interrupt. For some use cases, it makes sense to ignore the high to low change and not generate an interrupt. Such a use case is a line that is hold in a level high/low manner until the event holding the line gets acked. This can be achieved by making sure the interrupt on the GPIO controller side gets acked and masked only after the line gets hold in its default state, this is what's done with the fasteoi functions. Only IRQ_TYPE_EDGE_BOTH and IRQ_TYPE_LEVEL_HIGH are supported for now. Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> --- drivers/pinctrl/Kconfig | 1 + drivers/pinctrl/pinctrl-ocelot.c | 102 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 101 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index dd50371225bc..891d80ef038a 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -332,6 +332,7 @@ config PINCTRL_OCELOT depends on OF depends on MSCC_OCELOT || COMPILE_TEST select GPIOLIB + select GPIOLIB_IRQCHIP select GENERIC_PINCONF select GENERIC_PINCTRL_GROUPS select GENERIC_PINMUX_FUNCTIONS diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c index 15bb1cb8729b..d80b32413b09 100644 --- a/drivers/pinctrl/pinctrl-ocelot.c +++ b/drivers/pinctrl/pinctrl-ocelot.c @@ -11,6 +11,7 @@ #include <linux/interrupt.h> #include <linux/io.h> #include <linux/of_device.h> +#include <linux/of_irq.h> #include <linux/of_platform.h> #include <linux/pinctrl/pinctrl.h> #include <linux/pinctrl/pinmux.h> @@ -427,11 +428,98 @@ static const struct gpio_chip ocelot_gpiolib_chip = { .owner = THIS_MODULE, }; +static void ocelot_irq_mask(struct irq_data *data) +{ + struct gpio_chip *chip = irq_data_get_irq_chip_data(data); + struct ocelot_pinctrl *info = gpiochip_get_data(chip); + unsigned int gpio = irqd_to_hwirq(data); + + regmap_update_bits(info->map, OCELOT_GPIO_INTR_ENA, BIT(gpio), 0); +} + +static void ocelot_irq_unmask(struct irq_data *data) +{ + struct gpio_chip *chip = irq_data_get_irq_chip_data(data); + struct ocelot_pinctrl *info = gpiochip_get_data(chip); + unsigned int gpio = irqd_to_hwirq(data); + + regmap_update_bits(info->map, OCELOT_GPIO_INTR_ENA, BIT(gpio), + BIT(gpio)); +} + +static void ocelot_irq_ack(struct irq_data *data) +{ + struct gpio_chip *chip = irq_data_get_irq_chip_data(data); + struct ocelot_pinctrl *info = gpiochip_get_data(chip); + unsigned int gpio = irqd_to_hwirq(data); + + regmap_write_bits(info->map, OCELOT_GPIO_INTR, BIT(gpio), BIT(gpio)); +} + +static int ocelot_irq_set_type(struct irq_data *data, unsigned int type); + +static struct irq_chip ocelot_eoi_irqchip = { + .name = "gpio", + .irq_mask = ocelot_irq_mask, + .irq_eoi = ocelot_irq_ack, + .irq_unmask = ocelot_irq_unmask, + .flags = IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED, + .irq_set_type = ocelot_irq_set_type, +}; + +static struct irq_chip ocelot_irqchip = { + .name = "gpio", + .irq_mask = ocelot_irq_mask, + .irq_ack = ocelot_irq_ack, + .irq_unmask = ocelot_irq_unmask, + .irq_set_type = ocelot_irq_set_type, +}; + +static int ocelot_irq_set_type(struct irq_data *data, unsigned int type) +{ + type &= IRQ_TYPE_SENSE_MASK; + + if (!(type & (IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_HIGH))) + return -EINVAL; + + if (type & IRQ_TYPE_LEVEL_HIGH) + irq_set_chip_handler_name_locked(data, &ocelot_eoi_irqchip, + handle_fasteoi_irq, NULL); + if (type & IRQ_TYPE_EDGE_BOTH) + irq_set_chip_handler_name_locked(data, &ocelot_irqchip, + handle_edge_irq, NULL); + + return 0; +} + +static void ocelot_irq_handler(struct irq_desc *desc) +{ + struct irq_chip *parent_chip = irq_desc_get_chip(desc); + struct gpio_chip *chip = irq_desc_get_handler_data(desc); + struct ocelot_pinctrl *info = gpiochip_get_data(chip); + unsigned int reg = 0, irq; + unsigned long irqs; + + regmap_read(info->map, OCELOT_GPIO_INTR_IDENT, ®); + if (!reg) + return; + + chained_irq_enter(parent_chip, desc); + + irqs = reg; + + for_each_set_bit(irq, &irqs, OCELOT_PINS) { + generic_handle_irq(irq_linear_revmap(chip->irq.domain, irq)); + } + + chained_irq_exit(parent_chip, desc); +} + static int ocelot_gpiochip_register(struct platform_device *pdev, struct ocelot_pinctrl *info) { struct gpio_chip *gc; - int ret; + int ret, irq; info->gpio_chip = ocelot_gpiolib_chip; @@ -446,7 +534,17 @@ static int ocelot_gpiochip_register(struct platform_device *pdev, if (ret) return ret; - /* TODO: this can be used as an irqchip but no board is using that */ + irq = irq_of_parse_and_map(pdev->dev.of_node, 0); + if (irq <= 0) + return irq; + + ret = gpiochip_irqchip_add(gc, &ocelot_irqchip, 0, handle_edge_irq, + IRQ_TYPE_NONE); + if (ret) + return ret; + + gpiochip_set_chained_irqchip(gc, &ocelot_irqchip, irq, + ocelot_irq_handler); return 0; } -- 2.14.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller 2018-07-25 12:26 ` [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller Quentin Schulz @ 2018-08-06 11:06 ` Linus Walleij 0 siblings, 0 replies; 10+ messages in thread From: Linus Walleij @ 2018-08-06 11:06 UTC (permalink / raw) To: quentin.schulz Cc: Alexandre Belloni, Rob Herring, Mark Rutland, Ralf Baechle, paul.burton, James Hogan, open list:GPIO SUBSYSTEM, Linux MIPS, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, Thomas Petazzoni Hi Quentin, sorry for delays! On Wed, Jul 25, 2018 at 2:27 PM Quentin Schulz <quentin.schulz@bootlin.com> wrote: > This GPIO controller can serve as an interrupt controller as well on the > GPIOs it handles. > > An interrupt is generated whenever a GPIO line changes and the > interrupt for this GPIO line is enabled. This means that both the > changes from low to high and high to low generate an interrupt. > > For some use cases, it makes sense to ignore the high to low change and > not generate an interrupt. Such a use case is a line that is hold in a > level high/low manner until the event holding the line gets acked. > This can be achieved by making sure the interrupt on the GPIO controller > side gets acked and masked only after the line gets hold in its default > state, this is what's done with the fasteoi functions. > > Only IRQ_TYPE_EDGE_BOTH and IRQ_TYPE_LEVEL_HIGH are supported for now. > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Patch applied, it's such a pretty and straight-forward patch. Also IRQ is probably very nice to have, so let's get this in and supported. Please consider addressing the following in follow-up patch(es): > +static int ocelot_irq_set_type(struct irq_data *data, unsigned int type); Can't you just move the function above so you don't have to forward-declare this? > +static struct irq_chip ocelot_eoi_irqchip = { > + .name = "gpio", > + .irq_mask = ocelot_irq_mask, > + .irq_eoi = ocelot_irq_ack, > + .irq_unmask = ocelot_irq_unmask, > + .flags = IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED, As you see the latter part of the define is "IF_HANDLED". > + .irq_set_type = ocelot_irq_set_type, > +}; > + > +static struct irq_chip ocelot_irqchip = { > + .name = "gpio", > + .irq_mask = ocelot_irq_mask, > + .irq_ack = ocelot_irq_ack, > + .irq_unmask = ocelot_irq_unmask, > + .irq_set_type = ocelot_irq_set_type, > +}; Is it really neccessary to have two irqchips? Is this to separate ACK and EOI because the EOI version doesn't survive an ACK? Yours, Linus Walleij ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller @ 2018-08-06 11:06 ` Linus Walleij 0 siblings, 0 replies; 10+ messages in thread From: Linus Walleij @ 2018-08-06 11:06 UTC (permalink / raw) To: quentin.schulz Cc: Alexandre Belloni, Rob Herring, Mark Rutland, Ralf Baechle, paul.burton, James Hogan, open list:GPIO SUBSYSTEM, Linux MIPS, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, Thomas Petazzoni Hi Quentin, sorry for delays! On Wed, Jul 25, 2018 at 2:27 PM Quentin Schulz <quentin.schulz@bootlin.com> wrote: > This GPIO controller can serve as an interrupt controller as well on the > GPIOs it handles. > > An interrupt is generated whenever a GPIO line changes and the > interrupt for this GPIO line is enabled. This means that both the > changes from low to high and high to low generate an interrupt. > > For some use cases, it makes sense to ignore the high to low change and > not generate an interrupt. Such a use case is a line that is hold in a > level high/low manner until the event holding the line gets acked. > This can be achieved by making sure the interrupt on the GPIO controller > side gets acked and masked only after the line gets hold in its default > state, this is what's done with the fasteoi functions. > > Only IRQ_TYPE_EDGE_BOTH and IRQ_TYPE_LEVEL_HIGH are supported for now. > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Patch applied, it's such a pretty and straight-forward patch. Also IRQ is probably very nice to have, so let's get this in and supported. Please consider addressing the following in follow-up patch(es): > +static int ocelot_irq_set_type(struct irq_data *data, unsigned int type); Can't you just move the function above so you don't have to forward-declare this? > +static struct irq_chip ocelot_eoi_irqchip = { > + .name = "gpio", > + .irq_mask = ocelot_irq_mask, > + .irq_eoi = ocelot_irq_ack, > + .irq_unmask = ocelot_irq_unmask, > + .flags = IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED, As you see the latter part of the define is "IF_HANDLED". > + .irq_set_type = ocelot_irq_set_type, > +}; > + > +static struct irq_chip ocelot_irqchip = { > + .name = "gpio", > + .irq_mask = ocelot_irq_mask, > + .irq_ack = ocelot_irq_ack, > + .irq_unmask = ocelot_irq_unmask, > + .irq_set_type = ocelot_irq_set_type, > +}; Is it really neccessary to have two irqchips? Is this to separate ACK and EOI because the EOI version doesn't survive an ACK? Yours, Linus Walleij ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller 2018-08-06 11:06 ` Linus Walleij @ 2018-08-06 12:10 ` Quentin Schulz -1 siblings, 0 replies; 10+ messages in thread From: Quentin Schulz @ 2018-08-06 12:10 UTC (permalink / raw) To: Linus Walleij Cc: Alexandre Belloni, Rob Herring, Mark Rutland, Ralf Baechle, paul.burton, James Hogan, open list:GPIO SUBSYSTEM, Linux MIPS, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, Thomas Petazzoni [-- Attachment #1: Type: text/plain, Size: 4241 bytes --] Hi Linus, On Mon, Aug 06, 2018 at 01:06:23PM +0200, Linus Walleij wrote: > Hi Quentin, sorry for delays! > No worries :) > On Wed, Jul 25, 2018 at 2:27 PM Quentin Schulz > <quentin.schulz@bootlin.com> wrote: > > > This GPIO controller can serve as an interrupt controller as well on the > > GPIOs it handles. > > > > An interrupt is generated whenever a GPIO line changes and the > > interrupt for this GPIO line is enabled. This means that both the > > changes from low to high and high to low generate an interrupt. > > > > For some use cases, it makes sense to ignore the high to low change and > > not generate an interrupt. Such a use case is a line that is hold in a > > level high/low manner until the event holding the line gets acked. > > This can be achieved by making sure the interrupt on the GPIO controller > > side gets acked and masked only after the line gets hold in its default > > state, this is what's done with the fasteoi functions. > > > > Only IRQ_TYPE_EDGE_BOTH and IRQ_TYPE_LEVEL_HIGH are supported for now. > > > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> > > Patch applied, it's such a pretty and straight-forward patch. > Also IRQ is probably very nice to have, so let's get this in and > supported. > > Please consider addressing the following in follow-up patch(es): > > > +static int ocelot_irq_set_type(struct irq_data *data, unsigned int type); > > Can't you just move the function above so you don't have to forward-declare > this? > No I can't, not in the current implementation at least. In this function, I set the irq chip handler which needs one of the below irq_chip. As you can see, the set_type function is also defined in those two structures. > > +static struct irq_chip ocelot_eoi_irqchip = { > > + .name = "gpio", > > + .irq_mask = ocelot_irq_mask, > > + .irq_eoi = ocelot_irq_ack, > > + .irq_unmask = ocelot_irq_unmask, > > + .flags = IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED, > > As you see the latter part of the define is "IF_HANDLED". > > > + .irq_set_type = ocelot_irq_set_type, > > +}; > > + > > +static struct irq_chip ocelot_irqchip = { > > + .name = "gpio", > > + .irq_mask = ocelot_irq_mask, > > + .irq_ack = ocelot_irq_ack, > > + .irq_unmask = ocelot_irq_unmask, > > + .irq_set_type = ocelot_irq_set_type, > > +}; > > Is it really neccessary to have two irqchips? > > Is this to separate ACK and EOI because the EOI version > doesn't survive an ACK? > Let me give you a real world use case, the reason why I used EOI. I've a PHY interrupt line that connects to a GPIO of this controller. The PHY holds the line until the PHY acknowledges the reason for generating an interrupt. So we can say that it's a LEVEL_HIGH "interrupt". The GPIO interrupt controller generates an interruption whenever the GPIO line has changed (0->1 or 1->0). In a "normal" use case, I'd have the PHY holding high the line, the GPIO controller generating an interrupt because the line has changed. We acknowledge the interrupt in the GPIO controller. Later, we acknowledge in the PHY the reason why we had to generate an "interrupt" on the PHY side, resulting in the line being now held low. This generates another interrupt on the GPIO controller side. However, only one actual interrupt should have been generated by the GPIO controller as there's only one event that resulted in an "interrupt" generation from the PHY. So, we need EOI so that the GPIO controller interrupt gets acked only when the PHY event is acked so that we don't receive an unexpected interrupt. However, we also need the common irq handler behaviour as we might want to have the interrupt generated for 0->1 AND 1->0 transition depending on the IP connected to the GPIO. I could make my use case work with EOI but I find it very specific to my use case and thus added the support for a more commonly found (IMHO) use case. I'd say that, yes, the two irqchips are needed but I may be missing another way to handle all that. Thanks, Quentin [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller @ 2018-08-06 12:10 ` Quentin Schulz 0 siblings, 0 replies; 10+ messages in thread From: Quentin Schulz @ 2018-08-06 12:10 UTC (permalink / raw) To: Linus Walleij Cc: Alexandre Belloni, Rob Herring, Mark Rutland, Ralf Baechle, paul.burton, James Hogan, open list:GPIO SUBSYSTEM, Linux MIPS, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, Thomas Petazzoni [-- Attachment #1: Type: text/plain, Size: 4241 bytes --] Hi Linus, On Mon, Aug 06, 2018 at 01:06:23PM +0200, Linus Walleij wrote: > Hi Quentin, sorry for delays! > No worries :) > On Wed, Jul 25, 2018 at 2:27 PM Quentin Schulz > <quentin.schulz@bootlin.com> wrote: > > > This GPIO controller can serve as an interrupt controller as well on the > > GPIOs it handles. > > > > An interrupt is generated whenever a GPIO line changes and the > > interrupt for this GPIO line is enabled. This means that both the > > changes from low to high and high to low generate an interrupt. > > > > For some use cases, it makes sense to ignore the high to low change and > > not generate an interrupt. Such a use case is a line that is hold in a > > level high/low manner until the event holding the line gets acked. > > This can be achieved by making sure the interrupt on the GPIO controller > > side gets acked and masked only after the line gets hold in its default > > state, this is what's done with the fasteoi functions. > > > > Only IRQ_TYPE_EDGE_BOTH and IRQ_TYPE_LEVEL_HIGH are supported for now. > > > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> > > Patch applied, it's such a pretty and straight-forward patch. > Also IRQ is probably very nice to have, so let's get this in and > supported. > > Please consider addressing the following in follow-up patch(es): > > > +static int ocelot_irq_set_type(struct irq_data *data, unsigned int type); > > Can't you just move the function above so you don't have to forward-declare > this? > No I can't, not in the current implementation at least. In this function, I set the irq chip handler which needs one of the below irq_chip. As you can see, the set_type function is also defined in those two structures. > > +static struct irq_chip ocelot_eoi_irqchip = { > > + .name = "gpio", > > + .irq_mask = ocelot_irq_mask, > > + .irq_eoi = ocelot_irq_ack, > > + .irq_unmask = ocelot_irq_unmask, > > + .flags = IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED, > > As you see the latter part of the define is "IF_HANDLED". > > > + .irq_set_type = ocelot_irq_set_type, > > +}; > > + > > +static struct irq_chip ocelot_irqchip = { > > + .name = "gpio", > > + .irq_mask = ocelot_irq_mask, > > + .irq_ack = ocelot_irq_ack, > > + .irq_unmask = ocelot_irq_unmask, > > + .irq_set_type = ocelot_irq_set_type, > > +}; > > Is it really neccessary to have two irqchips? > > Is this to separate ACK and EOI because the EOI version > doesn't survive an ACK? > Let me give you a real world use case, the reason why I used EOI. I've a PHY interrupt line that connects to a GPIO of this controller. The PHY holds the line until the PHY acknowledges the reason for generating an interrupt. So we can say that it's a LEVEL_HIGH "interrupt". The GPIO interrupt controller generates an interruption whenever the GPIO line has changed (0->1 or 1->0). In a "normal" use case, I'd have the PHY holding high the line, the GPIO controller generating an interrupt because the line has changed. We acknowledge the interrupt in the GPIO controller. Later, we acknowledge in the PHY the reason why we had to generate an "interrupt" on the PHY side, resulting in the line being now held low. This generates another interrupt on the GPIO controller side. However, only one actual interrupt should have been generated by the GPIO controller as there's only one event that resulted in an "interrupt" generation from the PHY. So, we need EOI so that the GPIO controller interrupt gets acked only when the PHY event is acked so that we don't receive an unexpected interrupt. However, we also need the common irq handler behaviour as we might want to have the interrupt generated for 0->1 AND 1->0 transition depending on the IP connected to the GPIO. I could make my use case work with EOI but I find it very specific to my use case and thus added the support for a more commonly found (IMHO) use case. I'd say that, yes, the two irqchips are needed but I may be missing another way to handle all that. Thanks, Quentin [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller 2018-07-25 12:26 [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Quentin Schulz 2018-07-25 12:26 ` [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller Quentin Schulz @ 2018-07-27 10:36 ` Alexandre Belloni 2018-07-29 21:25 ` Linus Walleij 2018-07-30 17:35 ` Paul Burton 3 siblings, 0 replies; 10+ messages in thread From: Alexandre Belloni @ 2018-07-27 10:36 UTC (permalink / raw) To: Quentin Schulz Cc: robh+dt, mark.rutland, linus.walleij, ralf, paul.burton, jhogan, linux-gpio, linux-mips, devicetree, linux-kernel, thomas.petazzoni On 25/07/2018 14:26:20+0200, Quentin Schulz wrote: > The GPIO controller also serves as an interrupt controller for events > on the GPIO it handles. > > An interrupt occurs whenever a GPIO line has changed. > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > --- > arch/mips/boot/dts/mscc/ocelot.dtsi | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi b/arch/mips/boot/dts/mscc/ocelot.dtsi > index d7f0e3551500..afe8fc9011ea 100644 > --- a/arch/mips/boot/dts/mscc/ocelot.dtsi > +++ b/arch/mips/boot/dts/mscc/ocelot.dtsi > @@ -168,6 +168,9 @@ > gpio-controller; > #gpio-cells = <2>; > gpio-ranges = <&gpio 0 0 22>; > + interrupt-controller; > + interrupts = <13>; > + #interrupt-cells = <2>; > > uart_pins: uart-pins { > pins = "GPIO_6", "GPIO_7"; > -- > 2.14.1 > -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller 2018-07-25 12:26 [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Quentin Schulz @ 2018-07-29 21:25 ` Linus Walleij 2018-07-27 10:36 ` [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Alexandre Belloni ` (2 subsequent siblings) 3 siblings, 0 replies; 10+ messages in thread From: Linus Walleij @ 2018-07-29 21:25 UTC (permalink / raw) To: quentin.schulz Cc: Alexandre Belloni, Rob Herring, Mark Rutland, Ralf Baechle, paul.burton, James Hogan, open list:GPIO SUBSYSTEM, Linux MIPS, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, Thomas Petazzoni On Wed, Jul 25, 2018 at 2:27 PM Quentin Schulz <quentin.schulz@bootlin.com> wrote: > The GPIO controller also serves as an interrupt controller for events > on the GPIO it handles. > > An interrupt occurs whenever a GPIO line has changed. > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller @ 2018-07-29 21:25 ` Linus Walleij 0 siblings, 0 replies; 10+ messages in thread From: Linus Walleij @ 2018-07-29 21:25 UTC (permalink / raw) To: quentin.schulz Cc: Alexandre Belloni, Rob Herring, Mark Rutland, Ralf Baechle, paul.burton, James Hogan, open list:GPIO SUBSYSTEM, Linux MIPS, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, Thomas Petazzoni On Wed, Jul 25, 2018 at 2:27 PM Quentin Schulz <quentin.schulz@bootlin.com> wrote: > The GPIO controller also serves as an interrupt controller for events > on the GPIO it handles. > > An interrupt occurs whenever a GPIO line has changed. > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller 2018-07-25 12:26 [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Quentin Schulz ` (2 preceding siblings ...) 2018-07-29 21:25 ` Linus Walleij @ 2018-07-30 17:35 ` Paul Burton 3 siblings, 0 replies; 10+ messages in thread From: Paul Burton @ 2018-07-30 17:35 UTC (permalink / raw) To: Quentin Schulz Cc: alexandre.belloni, robh+dt, mark.rutland, linus.walleij, ralf, jhogan, linux-gpio, linux-mips, devicetree, linux-kernel, thomas.petazzoni Hi Quentin, On Wed, Jul 25, 2018 at 02:26:20PM +0200, Quentin Schulz wrote: > The GPIO controller also serves as an interrupt controller for events > on the GPIO it handles. > > An interrupt occurs whenever a GPIO line has changed. > > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> > --- > arch/mips/boot/dts/mscc/ocelot.dtsi | 3 +++ > 1 file changed, 3 insertions(+) Thanks - applied to mips-next for 4.19. Paul ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-08-06 12:11 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-25 12:26 [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Quentin Schulz 2018-07-25 12:26 ` [PATCH 2/2] pinctrl: ocelot: add support for interrupt controller Quentin Schulz 2018-08-06 11:06 ` Linus Walleij 2018-08-06 11:06 ` Linus Walleij 2018-08-06 12:10 ` Quentin Schulz 2018-08-06 12:10 ` Quentin Schulz 2018-07-27 10:36 ` [PATCH 1/2] MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller Alexandre Belloni 2018-07-29 21:25 ` Linus Walleij 2018-07-29 21:25 ` Linus Walleij 2018-07-30 17:35 ` Paul Burton
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.