Re: Using gpio_keys with regmapped gpio?

[Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>]

On Tue, Mar 31, 2015 at 2:06 PM, Thor Thayer
<tthayer@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
>
> On 03/31/2015 03:17 PM, Dmitry Torokhov wrote:
>>
>> On Tue, Mar 31, 2015 at 02:57:35PM -0500, Thor Thayer wrote:
>>>
>>> Hi,
>>>
>>> I have a SPI gpio expander chip that is using the regmap framework.
>>> There are some pushbuttons that I'd like to use the gpio_keys
>>> framework for but only the first button press creates an input
>>> event.
>>>
>>> It seems like my problem occurs because I'm only getting events on a
>>> button press.  The input_get_disposition() function toggles a local
>>> copy of the button state [__change_bit(code, dev->key);] in the
>>> input.c file. I think this function also needs to be called when the
>>> button is released to toggle the dev->key state and re-arm for the
>>> next button press.
>>
>>
>> Yes.
>>
>>>
>>> I tried enabling autorepeat but that causes an infinite loop in the
>>> input_repeat_key() function.
>>>
>>> In both cases, it seems like the button press condition must be
>>> cleared when the button is released. This seems like it should be
>>> common for all GPIOs so I'm probably missing something.
>>
>>
>> It sounds like your expander does not generate interrupt when the button
>> is released and so gpio-keys driver is not aware of it.
>>
>> Thanks.
>>
>
> Thanks for the quick reply. Is giving an interrupt on both press and release
> a requirement for gpio-keys? or is there another setup that I'm not aware
> of?
>

Yes.

> How does the gpio-key framework work with register mapped GPIOs that are
> rising-edge or falling-edge triggered? I tend to think of these IRQ states
> as the general case for GPIO.

I am not sure why it matters if it is register mapped gpio or not. The
driver needs to know when the key is pressed and released, so it
expects to get an interrupt when gpio changes state.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html