On Tue, Aug 01, 2017 at 08:51:40PM +0200, danilokrummrich@xxxxxxxxxxxxx wrote:Thanks for clarification, didn't knew that. So,I will take this in advance.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.
Yes, I will do so.>>+
>>+ 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.
Thanks.