On 09/12/2020 12:23, Enrico Weigelt, metux IT consult wrote:
On 08.12.20 17:18, Grygorii Strashko wrote:
Having all GPIO drivers doing their IRQ management entirely through the
GPIO subsystem (eg. never calling generic_handle_irq() and using the
builtin
IRQ handling) would also allow a more direct (eg. callback-based)
pin change
notification for GPIO consumers, that doesn't involve registering
them as
generic IRQ handlers.
Above part makes me worry - why?
Why so ?
Little clarification, in case i've been a bit confusion - there're two
separate topics:
a) consolidating repeated patterns (eg. calling the actual irq handling)
into gpiolib, (and later possibly use more fields already existing in
struct gpio_chip for irq handling)
Even if there is some pattern It doesn't mean consolidation is always reasonable.
one of the things to think about is compiler optimization and will/will not this change
add additional
b) a direct consumer callback for change, where the consumer doesn't
have to care about IRQs at all (some drivers could even do polling,
when hw doesn't have IRQs). This is for consumers that don't use
GPIOs as interrupt source, but more more like a very raw serial port,
eg. bitbanging of other interfaces (maybe an gpio bus type ? ;-))
in his case they do polling, so what's the issue with this?
or you want gpio-controller to do polling for you?
Actually there are few types of consumers:
- gpio users, no irq
- irq users, no gpio
- gpio users and irq users
- and finally (only few) use the same gpio as gpio and as an irq,
including dynamic direction change.
The above paragraph just outlines that b) might be much easier to
implement, once the suggested refactoring is done and no driver would
call irq handlers directly anymore. But this hasn't much to do with
the proposal itself, just an idea for future use.
--mtx
--
Best regards,
grygorii
