lkml.org 
[lkml]   [2015]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] IIO: Adds ACPI support for ST gyroscopes
    On Thu, Mar 26, 2015 at 04:37:39PM +0200, Octavian Purdila wrote:
    > On Thu, Mar 26, 2015 at 4:04 PM, Mika Westerberg
    > <mika.westerberg@linux.intel.com> wrote:
    > > On Thu, Mar 26, 2015 at 02:04:35PM +0200, Octavian Purdila wrote:
    > >> On Thu, Mar 26, 2015 at 12:16 PM, Mika Westerberg
    > >> <mika.westerberg@linux.intel.com> wrote:
    > >> > On Wed, Mar 25, 2015 at 11:12:16PM +0200, Octavian Purdila wrote:
    > >> >> On Wed, Mar 25, 2015 at 3:21 PM, Mika Westerberg
    > >> >> <mika.westerberg@linux.intel.com> wrote:
    > >> >> > On Wed, Mar 25, 2015 at 02:25:05PM +0200, Mika Westerberg wrote:
    > >> >> >> I think we can do the same for ACPI GpioInts so that we introduce
    > >> >> >> acpi_gpio_irq_get() that translates from GpioInt to Linux IRQ
    > >> >> >> numberspace. Then we can do something like below in I2C core:
    > >> >> >>
    > >> >> >> if (client->irq <= 0) {
    > >> >> >> int irq = -ENOENT;
    > >> >> >>
    > >> >> >> if (dev->of_node)
    > >> >> >> irq = of_irq_get(dev->of_node, 0);
    > >> >> >> else if (ACPI_COMPANION(dev))
    > >> >> >> irq = acpi_gpio_irq_get(ACPI_COMPANION(dev), 0);
    > >> >> >>
    > >> >> >> if (irq == -EPROBE_DEFER)
    > >> >> >> return irq;
    > >> >> >> if (irq < 0)
    > >> >> >> irq = 0;
    > >> >> >>
    > >> >> >> client->irq = irq;
    > >> >> >> }
    > >> >> >>
    > >> >> >> Now it has the drawback that the first GpioInt will not be available to
    > >> >> >> the driver anymore (as a GPIO since it is locked) but if DT already does
    > >> >> >> the same we should be fine.
    > >> >> >
    > >> >> > Below patch should take care of this.
    > >> >> >
    > >> >>
    > >> >> One issue we noticed is that now the gpio request and set input
    > >> >> directions operations are not called anymore. Some gpio controller
    > >> >> drivers (dln2, adnp, lynx_point from quickly browsing the code) do not
    > >> >> explicitly enable the GPIO pin nor set direction to input when the
    > >> >> interrupt is enabled. Depending on hardware this may be an issue - it
    > >> >> is on dln2 for example.
    > >> >>
    > >> >> Should the gpio controllers enable and set to input in irq_enable,
    > >> >> irq_bus_sync_unlock, etc.? Or should this be done in gpiolib?
    > >> >
    > >> > Good question.
    > >> >
    > >> > In general I think that it is assumed that the boot firmware configures
    > >> > the pin upfront. However, we have seen too many times that it actually
    > >> > doesn't happen or it is configured wrong.
    > >> >
    > >> > Perhaps we could do this in GPIO core, for example in
    > >> > gpiochip_irq_reqres/gpiochip_irq_map or so.
    > >> >
    > >>
    > >> That sounds good to me. We tested your patch with the patch below and
    > >> we can now directly use client->irq:
    > >>
    > >> 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.

    > One case I missed was if the user wants to read the GPIO while using
    > it as an interrupt which seems to be possible...

    While the GPIO is locked as IRQ it cannot be done as far as I can tell
    but you can work it around by calling free_irq() first.

    >
    > >> +
    > >> + ret = gpiod_direction_input(&chip->desc[d->hwirq]);
    > >> + if (ret) {
    > >> + chip_err(chip, "unable to set HW IRQ %lu as input\n", d->hwirq);
    > >> + return ret;
    > >> + }
    > >>
    > >> if (gpiochip_lock_as_irq(chip, d->hwirq)) {
    > >> chip_err(chip,


    \
     
     \ /
      Last update: 2015-03-26 16:01    [W:5.090 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site