Re: gpio_get_value in atomic context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Brownell <david-b@xxxxxxxxxxx> writes:

> On Wednesday 14 October 2009, Arve Hjønnevåg wrote:
>
>>> Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> writes:
>>>
>>>> On Mon, Oct 12, 2009 at 07:09:50PM +0200, Ferenc Wagner wrote:
>>>>
>>>>>     The gpio_get_value function may sleep, so it should not be
>>>>>     called in a timer function.
>>>>>
>>>>> So is drivers/staging/dream/gpio_input.c in error, too?
>>>>
>>>> I guess so. Initially gpio method did not sleep but that has
>>>> changed.
>> 
>> If gpio_get_value may sleep, then what is gpio_get_value_cansleep for?
>
> To tell if this is one of the GPIOs for which it may sleep.

Isn't that gpio_cansleep()?

> Whether the GPIO is atomic vs cansleep is an attribute of the
> GPIO itself, not the routine it's called with.

My reading of Documentation/gpio.txt implies that actually it is,
because gpio_get_value() is ignored for GPIOs which can sleep:

    Other than the fact that these (gpio_[sg]et_value_cansleep) calls
    might sleep, and will not be ignored for GPIOs that can't be
    accessed from IRQ handlers, these calls act the same as the
    spinlock-safe calls.

>> The gpio documentation claims gpio_get_value and gpio_set_value are
>> safe to use from interrupt context, but a call to gpio_cansleep is
>> probably needed in probe.
>
> They're safe to use there ... if that GPIO is safe.  Yes, make sure
> you know the answer before you call gpio_get_value() instead of
> the always-safe gpio_get_value_cansleep().

Always-safe, meaning never ignored?  They surely aren't safe to use in
atomic context...

>> The matrix driver also need to change the direction of the gpio from
>> the timer, so it would be useful to have a standard way to check if
>> this is allowed as well.
>
> If gpio_{set,get}_value() can sleep, so can gpio_direction_*().

As above, in my reading gpio_[sg]et_value() cannot sleep, but are
ignored for the sleepy GPIOs.  Also, from the documentation:

    Also, using these calls for GPIOs that can't safely be accessed
    without sleeping is an error.

I'd deeply appreciate some further clarification of the above, and
possibly on the problems outlined in the thread
http://thread.gmane.org/gmane.linux.kernel.input/8775/focus=9153.  Is it
possible to use level triggered shared IRQs for GPIOs which can sleep?
If yes, how?

Using a nested handler would be a possibility, if I could assume that
the irqchips belonging to sleepy GPIOs are always sleepy as well
(ie. their dispatchers run in a separate thread with the IRQ disabled).
Is that the case by any chance?
-- 
Thanks,
Feri.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux