On 2017-08-01 21:07, Dmitry Torokhov wrote:
On Tue, Aug 01, 2017 at 08:51:40PM +0200, danilokrummrich@xxxxxxxxxxxxx
wrote:
On 2017-08-01 19:32, Dmitry Torokhov wrote:
>On Tue, Aug 01, 2017 at 06:26:14AM +0200, Danilo Krummrich wrote:
>>+ irq = gpio_to_irq(drvdata->gpio_clk);
>>+ if (!irq) {
>>+ dev_err(dev, "cannot get irq from gpio %u\n",
>>+ drvdata->gpio_clk);
>>+ error = -ENXIO;
>>+ goto err_free_serio;
>>+ }
>
>
>IRQ line does not have to be the same as GPIO pin. Describe it
>separately in device properties and just do:
>
> irq = platform_get_irq(pdev, 0);
>
>and use it in the request below.
>
In which constellation can they be different?
IIRC there are controllers that may not let you re-configure GPIO that
is reserved for interrupt, for output. So you could have a bit of
hardware logic that splits and isolates GPIO and interrupt line.
Also have the trigger come from the interrupt description as well in
case you happen to have inverter logic there.
Thanks for clarification, didn't knew that. So,I will take this in
advance.
>>+
>>+ error = devm_request_irq(dev, irq, ps2_gpio_irq, IRQF_NO_THREAD |
>>+ IRQF_TRIGGER_FALLING, DRIVER_NAME, drvdata);
>
>This will not work if GPIO is behind I2C or other slow bus. Is it
>essential that there is no scheduling delay here?
>
Yes it is. You are right, this wouldn't work. Was this the scenario
you had in mind while
writing the comment above?
No, that was just a general comment about GPIO on slow busses. You
might
need to check gpiod_can_sleep() and abort driver load if gpio is
sleeping.
Yes, I will do so.
Thanks.
--
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
