On Thu, Mar 26, 2015 at 06:28:19PM +0200, Octavian Purdila wrote:
> >>> >> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> >>> >> index 568aa2b..9865627 100644
> >>> >> --- a/drivers/gpio/gpiolib.c
> >>> >> +++ b/drivers/gpio/gpiolib.c
> >>> >> @@ -511,6 +511,19 @@ static const struct irq_domain_ops gpiochip_domain_ops = {
> >>> >> static int gpiochip_irq_reqres(struct irq_data *d)
> >>> >> {
> >>> >> struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
> >>> >> + int ret;
> >>> >> +
> >>> >> + ret = gpiod_request(&chip->desc[d->hwirq], "IRQ");
> >>> >> + if (ret) {
> >>> >> + chip_err(chip, "unable to request %lu for IRQ\n", d->hwirq);
> >>> >> + return ret;
> >>> >> + }
> >>> >
> >>> > What if the driver has already requested the GPIO?
> >>> >
> >>>
> >>> Initially I implemented the above to take that into account, e.g. if
> >>> (test_and_set_bit(FLAG_REQUESTED, &desc->flags) ...
> >>>
> >>> But than I thought that we can't mess up with the GPIO anyway while
> >>> the interrupt is in use.
> >>
> >> That's right but then the above will fail also normal cases. For example
> >> if the driver gets the irq like:
> >>
> >> desc = devm_gpiod_get(dev, ..);
> >> gpiod_direction_input(desc);
> >> irq = gpiod_to_irq(desc);
> >>
> >> ret = request_irq(irq, ...)
> >>
> >> at this point we end up calling gpiochip_irq_reqres() which cannot
> >> request the GPIO again and fails.
> >>
> >
> > Good point, let me add back that check then :)
> >
>
> I just realized that there is another issue: gpiochip_irq_reqres() is
> called under a spinlock, so we can call gpiod_request() only if the
> gpio controller does not sleep.
Good point.
> For the sleep case I think the GPIO controller needs to do the pin
> enable and set input direction operation in it's irq_bus_sync_unlock.
I wonder how DT handles all this? Is it the boot firmware that sets up
the pins accordingly or is there something we are missing?
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
