On 26.04.19 16:41, Linus Walleij wrote:
On Fri, Apr 26, 2019 at 3:06 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
On Wed, Apr 24, 2019 at 12:39:35PM +0200, Jan Kiszka wrote:
On 24.04.19 12:33, Mika Westerberg wrote:
On Wed, Apr 24, 2019 at 12:19:02PM +0200, Jan Kiszka wrote:
And even if that were possible, we would be back to the square of existing
devices without those definitions. If this were a recent chipset, I would
say, "go, fix future firmware versions". But this one is legacy.
Is it fixing some real issue with these legacy platforms? I mean without
the patch some GPE event is not handled properly? It was not clear to me
from the commit message.
Without that patch, you are forced to poll for event changes in your
application, timer-driven. There are application that cannot process these
GPIOs because they lack such logic (mraa with node-red-node-intel-gpio is a
public example).
Just a side note: MRAA is a hack itself. It abuses almost all interfaces Linux
kernel provides.
I think it's pretty clean for GPIOs these days. My colleague Manivannan
was part of cleaning it up a while back and since then it is doing
what userspace should be doing if userspace absolutely cannot
abstain from using GPIOs directly (i.e. uses the character device).
https://github.com/intel-iot-devkit/mraa/blob/master/src/gpio/gpio_chardev.c
I don't know about other resources than GPIOs though.
That's valuable progress!
OTOH, there still seem to be the broken pattern to address pins via hard-coded
GPIO numbers. This broke our neck, e.g., when trying to replace the hacky BSP
kernel with upstream. I started to create better infrastructure but never fished
that.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
