| Message ID | 6c53b9ccfd4a56fc1b00e243bb9e7cae9e124932.1518155780.git.baolin.wang@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Input: gpio_keys: Add level trigger support for GPIO keys | expand |
On Thu, Feb 8, 2018 at 10:08 PM, Baolin Wang <baolin.wang@linaro.org> wrote: > On some platforms (such as Spreadtrum platform), the GPIO keys can only > be triggered by level type. How do you stop the interrupt from re-triggering as long as the key stays pressed? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9 February 2018 at 14:39, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Thu, Feb 8, 2018 at 10:08 PM, Baolin Wang <baolin.wang@linaro.org> wrote: >> On some platforms (such as Spreadtrum platform), the GPIO keys can only >> be triggered by level type. > > How do you stop the interrupt from re-triggering as long as the key > stays pressed? We will set the level type irq handler as handle_level_irq(), in this function, it will mask and ack the irq firstly. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 9, 2018 at 11:23 AM, Baolin Wang <baolin.wang@linaro.org> wrote: > On 9 February 2018 at 14:39, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: >> On Thu, Feb 8, 2018 at 10:08 PM, Baolin Wang <baolin.wang@linaro.org> wrote: >>> On some platforms (such as Spreadtrum platform), the GPIO keys can only >>> be triggered by level type. >> >> How do you stop the interrupt from re-triggering as long as the key >> stays pressed? > > We will set the level type irq handler as handle_level_irq(), in this > function, it will mask and ack the irq firstly. Wouldn't be ambiguous? 1. User presses the key -> a) we got edge followed by level signaling; b) IRQ core masks line, calls handler, ACKs, unmasks; c) somewhere here Press Event is sent; d) we still have level... We get IRQ fired again? But see 1. It obviously not the case. 2. User releases the key -> ... So, the main question if I understood Dmitry correctly is the period in time where IRQ line should be masked on one hand, and on the other it will guarantee that user didn't release-press cylcle. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9 February 2018 at 23:03, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Fri, Feb 9, 2018 at 11:23 AM, Baolin Wang <baolin.wang@linaro.org> wrote: >> On 9 February 2018 at 14:39, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: >>> On Thu, Feb 8, 2018 at 10:08 PM, Baolin Wang <baolin.wang@linaro.org> wrote: >>>> On some platforms (such as Spreadtrum platform), the GPIO keys can only >>>> be triggered by level type. >>> >>> How do you stop the interrupt from re-triggering as long as the key >>> stays pressed? >> >> We will set the level type irq handler as handle_level_irq(), in this >> function, it will mask and ack the irq firstly. > > Wouldn't be ambiguous? > > 1. User presses the key -> > a) we got edge followed by level signaling; > b) IRQ core masks line, calls handler, ACKs, unmasks; > c) somewhere here Press Event is sent; > d) we still have level... We get IRQ fired again? But see 1. It > obviously not the case. > 2. User releases the key -> > ... > > So, the main question if I understood Dmitry correctly is the period > in time where IRQ line should be masked on one hand, and on the other > it will guarantee that user didn't release-press cylcle. Yes, you and Dmitry are right. I realized my problem. When I tested on Spreadtrum platform, we use Spreadtrum-special EIC (external interrupt controller) to trigger button events, if we acked the EIC irq, it will drop the interrupt line and never trigger events until we set irq type again. But this can not work for general GPIOs like you said. So I think I need disable the irq until reversing the level type. Thanks. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt b/Documentation/devicetree/bindings/input/gpio-keys.txt index a949404..e3104bd 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.txt +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt @@ -29,6 +29,8 @@ Optional subnode-properties: - linux,can-disable: Boolean, indicates that button is connected to dedicated (not shared) interrupt which can be disabled to suppress events from the button. + - gpio-key,level-trigger: Boolean, indicates that button's interrupt + type is level trigger. Otherwise it is edge trigger as default. Example nodes: diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c index 87e613d..d3b4bb6 100644 --- a/drivers/input/keyboard/gpio_keys.c +++ b/drivers/input/keyboard/gpio_keys.c @@ -385,6 +385,19 @@ static void gpio_keys_gpio_work_func(struct work_struct *work) struct gpio_button_data *bdata = container_of(work, struct gpio_button_data, work.work); + if (bdata->button->level_trigger) { + unsigned int trigger = + irq_get_trigger_type(bdata->irq) & ~IRQF_TRIGGER_MASK; + int state = gpiod_get_raw_value_cansleep(bdata->gpiod); + + if (state) + trigger |= IRQF_TRIGGER_LOW; + else + trigger |= IRQF_TRIGGER_HIGH; + + irq_set_irq_type(bdata->irq, trigger); + } + gpio_keys_gpio_report_event(bdata); if (bdata->button->wakeup) @@ -566,7 +579,11 @@ static int gpio_keys_setup_key(struct platform_device *pdev, INIT_DELAYED_WORK(&bdata->work, gpio_keys_gpio_work_func); isr = gpio_keys_gpio_isr; - irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING; + if (button->level_trigger) + irqflags = gpiod_is_active_low(bdata->gpiod) ? + IRQF_TRIGGER_LOW : IRQF_TRIGGER_HIGH; + else + irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING; } else { if (!button->irq) { @@ -721,6 +738,9 @@ static void gpio_keys_close(struct input_dev *input) button->can_disable = fwnode_property_read_bool(child, "linux,can-disable"); + button->level_trigger = + fwnode_property_read_bool(child, "gpio-key,level-trigger"); + if (fwnode_property_read_u32(child, "debounce-interval", &button->debounce_interval)) button->debounce_interval = 5; diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h index d06bf77..5095645 100644 --- a/include/linux/gpio_keys.h +++ b/include/linux/gpio_keys.h @@ -28,6 +28,7 @@ struct gpio_keys_button { int wakeup; int debounce_interval; bool can_disable; + bool level_trigger; int value; unsigned int irq; };
On some platforms (such as Spreadtrum platform), the GPIO keys can only be triggered by level type. So this patch introduces one property to indicate if the GPIO trigger type is level trigger or edge trigger. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> --- .../devicetree/bindings/input/gpio-keys.txt | 2 ++ drivers/input/keyboard/gpio_keys.c | 22 +++++++++++++++++++- include/linux/gpio_keys.h | 1 + 3 files changed, 24 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html