[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZG6Oz1XTCGim2offVpRxw-X17omAVe7zqR5m9TwwPobw@mail.gmail.com>
Date: Thu, 11 Oct 2012 18:26:44 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Drasko DRASKOVIC <drasko.draskovic@...il.com>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
Grant Likely <grant.likely@...retlab.ca>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH][GPIO] Add IRQ edge setter to gpiolib
On Tue, Oct 9, 2012 at 4:22 PM, Drasko DRASKOVIC
<drasko.draskovic@...il.com> wrote:
> [Me]
>> So can you explain exactly why userspace want to configure
>> GPIO pins in interrupt mode, when there is no way whatsoever
>> for userspace to handle these IRQs?
>
> Maybe I understand something wrong, but explicit configuration of GPIO
> interrupt trigger type visible in sysfs is possible __only__ from the
> userspace today, and that is exactly limitation I am addressing.
So this is the real problem is it not?
So if we consider this:
static irqreturn_t my_callback(int irq, void *dev_id)
{
return IRQ_HANDLED;
}
int my_gpio, my_irq, ret;
my_gpio = 17; /* For some reason I like this pin */
ret = gpio_request(my_gpio);
ret = gpio_direction_input(my_gpio);
my_irq = gpio_to_irq(my_gpio);
ret = request_any_context_irq(my_irq,
my_callback,
IRQF_TRIGGER_FALLING,
"my gpio thing");
(some error handling removed, based on drivers/mmc/host/mmci.c)
What is wrong with this picture? Do you mean that the problem is
that the trigger type I just set up for the IRQ connected to the pin
is not reflected in GPIO sysfs?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists