| Message ID | 1401090486-4414-2-git-send-email-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Mon, May 26, 2014 at 09:47:56AM +0200, Hans de Goede wrote: > From: Chen-Yu Tsai <wens@csie.org> > > The irq/pin mapping is used to lookup the pin to mux to the irq > function when the irq is enabled. It is created when gpio_to_irq > is called. Creating the mapping during init allows us to map the > interrupts directly from the device tree. Can you be a bit more precise on this? What is the issue that this patch fix? Maxime
On Tue, May 27, 2014 at 4:02 PM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > Hi, > > On Mon, May 26, 2014 at 09:47:56AM +0200, Hans de Goede wrote: >> From: Chen-Yu Tsai <wens@csie.org> >> >> The irq/pin mapping is used to lookup the pin to mux to the irq >> function when the irq is enabled. It is created when gpio_to_irq >> is called. Creating the mapping during init allows us to map the >> interrupts directly from the device tree. > > Can you be a bit more precise on this? > > What is the issue that this patch fix? IIRC, originally the IRQ to pin mapping was created when gpio_to_irq was called with a GPIO handle. The mapping in turn is used to mux the pin into EINT mode. If the mapping is created during gpio_to_irq, we can't use the interrupts directly, i.e. through the DT with "interrupts = <&pio A 4>". Instead we'd have to use "gpios = <&pio A B>", then pass the gpio through to gpio_to_irq. ChenYu -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 26, 2014 at 9:47 AM, Hans de Goede <hdegoede@redhat.com> wrote: > From: Chen-Yu Tsai <wens@csie.org> > > The irq/pin mapping is used to lookup the pin to mux to the irq > function when the irq is enabled. It is created when gpio_to_irq > is called. Creating the mapping during init allows us to map the > interrupts directly from the device tree. > > Signed-off-by: Chen-Yu Tsai <wens@csie.org> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> This is exactly correct. Patch applied. I tried to hack the sunxi driver to even use the gpiolib irqchip helpers but exactly this complex map thing in ->irq_array[] git me stuck. If any of you guys could be so nice to take a stab at this (compare to other commits converting drivers to use gpiolibs irqchip helpers) then I'd be very happy. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 27, 2014 at 10:11 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, May 26, 2014 at 9:47 AM, Hans de Goede <hdegoede@redhat.com> wrote: > >> From: Chen-Yu Tsai <wens@csie.org> >> >> The irq/pin mapping is used to lookup the pin to mux to the irq >> function when the irq is enabled. It is created when gpio_to_irq >> is called. Creating the mapping during init allows us to map the >> interrupts directly from the device tree. >> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > This is exactly correct. Patch applied. Thanks. > I tried to hack the sunxi driver to even use the gpiolib > irqchip helpers but exactly this complex map thing in > ->irq_array[] git me stuck. If any of you guys could be so > nice to take a stab at this (compare to other commits > converting drivers to use gpiolibs irqchip helpers) then > I'd be very happy. We still need to rework the whole irqchip stuff for sun6i/sun8i, which have 1 parent interrupt per EINT capable pin bank. Earlier discussions with Maxime (on IRC IIRC) suggested moving this over to gpiolib irqchip helpers might be more work than using our own irqchip implementation, requiring 1 gpiochip per pin group? (not sure) ChenYu -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 27, 2014 at 4:21 PM, Chen-Yu Tsai <wens@csie.org> wrote: > On Tue, May 27, 2014 at 10:11 PM, Linus Walleij >> I tried to hack the sunxi driver to even use the gpiolib >> irqchip helpers but exactly this complex map thing in >> ->irq_array[] git me stuck. If any of you guys could be so >> nice to take a stab at this (compare to other commits >> converting drivers to use gpiolibs irqchip helpers) then >> I'd be very happy. > > We still need to rework the whole irqchip stuff for sun6i/sun8i, > which have 1 parent interrupt per EINT capable pin bank. > > Earlier discussions with Maxime (on IRC IIRC) suggested moving this > over to gpiolib irqchip helpers might be more work than using our own > irqchip implementation, requiring 1 gpiochip per pin group? (not sure) OK then keep your current code. I do not intend to cover all cases in the world with these helpers, just the simple cases. Complex hardware merits complex code. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index f6522b5..db9ccd6 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -529,8 +529,6 @@ static int sunxi_pinctrl_gpio_to_irq(struct gpio_chip *chip, unsigned offset) if (!desc) return -EINVAL; - pctl->irq_array[desc->irqnum] = offset; - dev_dbg(chip->dev, "%s: request IRQ for GPIO %d, return %d\n", chip->label, offset + chip->base, desc->irqnum); @@ -731,6 +729,9 @@ static int sunxi_pinctrl_build_state(struct platform_device *pdev) struct sunxi_desc_function *func = pin->functions; while (func->name) { + /* Create interrupt mapping while we're at it */ + if (!strcmp(func->name, "irq")) + pctl->irq_array[func->irqnum] = pin->pin.number; sunxi_pinctrl_add_function(pctl, func->name); func++; }