On 11-06-21, 10:22, Geert Uytterhoeven wrote:> The same reasoning can apply to your backend daemon, so when using > the GPIO aggregator, you can just control a full gpiochip, without > having to implement access control on individual GPIO lines.I tried to look at it and it surely looks very temping and may fit well and reduce size of my backend :) I am now wondering how interrupts can be made to work here. Do you have anything in mind for that ? GPIO sysfs already supports interrupts, just that you need to register irq for the specific GPIO pins inside the aggregator ? -- viresh
Hi Viresh, On Tue, Jun 15, 2021 at 1:15 PM Viresh Kumar <viresh.kumar at linaro.org> wrote:> On 11-06-21, 10:22, Geert Uytterhoeven wrote: > > The same reasoning can apply to your backend daemon, so when using > > the GPIO aggregator, you can just control a full gpiochip, without > > having to implement access control on individual GPIO lines. > > I tried to look at it and it surely looks very temping and may fit > well and reduce size of my backend :) > > I am now wondering how interrupts can be made to work here. Do you > have anything in mind for that ? > > GPIO sysfs already supports interrupts, just that you need to register > irq for the specific GPIO pins inside the aggregator ?So far I hadn't considered interrupts. Will think about it... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Jun 15, 2021 at 1:15 PM Viresh Kumar <viresh.kumar at linaro.org> wrote:> I am now wondering how interrupts can be made to work here. Do you > have anything in mind for that ?The aggregator does not aggregate interrupts only lines for now.> GPIO sysfs already supports interrupts, (...)I hope that doesn't make you tempted to use sysfs to get interrupts, those are awful, they use sysfs_notify_dirent() which means that if two IRQs happen in fast succession you will miss one of them and think it was only one. The GPIO character device supports low latency events forwarding interrupts to userspace including QEMU & similar, timestamps the events as close in time as possible to when they actually happen (which is necessary for any kind of industrial control) and will never miss an event if the hardware can register it. See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio/gpio-event-mon.c Yours, Linus Walleij