Hi folks,
this became an interesting thread and Manivannan made some nice
changes to MRAA as a result.
It appears the Raspberry Pi has become a victim of its own success
and went from hobbyist toy system to a foundation for random industrial
control hacks. I'm a bit scared about that for electron
On 26.04.19 18:03, Jan Kiszka wrote:
> Leaving that blunt hack aside:
>
> import mraa
>
> pin = mraa.Gpio(13)
> pin.dir(mraa.DIR_OUT)
> pin.write(1)
>
> And the same goes for nodejs, java and c++.
Such trivial wrappers are easy write in the coffe break.
For those usecases the good old sysfs in
On Fri, Apr 26, 2019 at 8:52 PM Manivannan Sadhasivam
wrote:
> On Fri, Apr 26, 2019 at 08:44:36PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2019 at 8:33 PM Manivannan Sadhasivam
> > wrote:
> > > On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Apr 26, 2019
On Fri, Apr 26, 2019 at 07:52:48PM +0200, Jan Kiszka wrote:
> On 26.04.19 19:46, Manivannan Sadhasivam wrote:
> > On Fri, Apr 26, 2019 at 07:39:56PM +0200, Jan Kiszka wrote:
> > > On 26.04.19 19:33, Manivannan Sadhasivam wrote:
> > > > On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote
On 26.04.19 19:46, Manivannan Sadhasivam wrote:
On Fri, Apr 26, 2019 at 07:39:56PM +0200, Jan Kiszka wrote:
On 26.04.19 19:33, Manivannan Sadhasivam wrote:
On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote:
On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
On 26.04.19 16:42, E
On Fri, Apr 26, 2019 at 08:44:36PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 26, 2019 at 8:33 PM Manivannan Sadhasivam
> wrote:
> > On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote:
> > > On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
> > > > On 26.04.19 16:42, Enrico Weigelt,
On Fri, Apr 26, 2019 at 07:39:56PM +0200, Jan Kiszka wrote:
> On 26.04.19 19:33, Manivannan Sadhasivam wrote:
> > On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote:
> > > On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
> > > >
> > > > On 26.04.19 16:42, Enrico Weigelt, metux IT co
On Fri, Apr 26, 2019 at 8:33 PM Manivannan Sadhasivam
wrote:
> On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
> > > On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote:
> > > > On 26.04.19 15:36, Jan Kiszka wrote:
> >
On 26.04.19 19:33, Manivannan Sadhasivam wrote:
On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote:
On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote:
On 26.04.19 15:36, Jan Kiszka wrote:
At the same time, there are no
On 26.04.19 19:20, Andy Shevchenko wrote:
On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote:
On 26.04.19 15:36, Jan Kiszka wrote:
At the same time, there are no real alternatives - to my> knowledge - for the
value it brings (various
On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
> >
> > On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote:
> > > On 26.04.19 15:36, Jan Kiszka wrote:
> > >
> > >> At the same time, there are no real alternatives - to my>
On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka wrote:
>
> On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote:
> > On 26.04.19 15:36, Jan Kiszka wrote:
> >
> >> At the same time, there are no real alternatives - to my> knowledge - for
> >> the value it brings (various bindings) to simply
> > sw
On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote:
On 26.04.19 15:36, Jan Kiszka wrote:
At the same time, there are no real alternatives - to my> knowledge - for the
value it brings (various bindings) to simply
switch> the engine.
Which value exactly does that collection of crude wrap
On 26.04.19 16:41, Linus Walleij wrote:
On Fri, Apr 26, 2019 at 3:06 PM Andy Shevchenko
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, w
On Fri, Apr 26, 2019 at 04:42:35PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 26.04.19 15:36, Jan Kiszka wrote:
>
> > At the same time, there are no real alternatives - to my> knowledge - for
> > the value it brings (various bindings) to simply
> switch> the engine.
> Which value exactl
On 26.04.19 15:36, Jan Kiszka wrote:
> At the same time, there are no real alternatives - to my> knowledge - for the
> value it brings (various bindings) to simply
switch> the engine.
Which value exactly does that collection of crude wrappers and broken
attempts to buypass the kernel (driving gpi
On Fri, Apr 26, 2019 at 3:06 PM Andy Shevchenko
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 squ
On 26.04.19 15:06, Andy Shevchenko 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 witho
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
On Wed, Apr 24, 2019 at 04:24:16PM +0200, Jan Kiszka wrote:
> > I'm trying to say that for the sysfs access (well or char dev) you
> > should not need the sch_sci_handler() thing that is in your current
> > patch.
>
> Then I'm still missing the black magic where - in my case - CGTS or RGTS are
> r
On 24.04.19 15:13, Mika Westerberg wrote:
On Wed, Apr 24, 2019 at 02:41:02PM +0200, Jan Kiszka wrote:
On 24.04.19 12:46, Mika Westerberg 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 K
On Wed, Apr 24, 2019 at 02:41:02PM +0200, Jan Kiszka wrote:
> On 24.04.19 12:46, Mika Westerberg 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:
> > > > > > I t
On 24.04.19 12:46, Mika Westerberg 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:
I think what you want is "GPIO signaled ACPI event". It works so that
you declare _AEI met
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:
> > > > I think what you want is "GPIO signaled ACPI event". It works so that
> > > > you declare _AEI method below the GPIO contro
On 24.04.19 12:33, Mika Westerberg wrote:
On Wed, Apr 24, 2019 at 12:19:02PM +0200, Jan Kiszka wrote:
I think what you want is "GPIO signaled ACPI event". It works so that
you declare _AEI method below the GPIO controller listing the GPIOs you
want to trigger events for and then either _Lxx, _Ex
On Wed, Apr 24, 2019 at 12:19:02PM +0200, Jan Kiszka wrote:
> > I think what you want is "GPIO signaled ACPI event". It works so that
> > you declare _AEI method below the GPIO controller listing the GPIOs you
> > want to trigger events for and then either _Lxx, _Exx or _EVT method for
> > each of
On 24.04.19 12:01, Mika Westerberg wrote:
On Wed, Apr 24, 2019 at 11:48:09AM +0200, Jan Kiszka wrote:
On 24.04.19 11:45, Mika Westerberg wrote:
On Wed, Apr 24, 2019 at 11:36:58AM +0200, Jan Kiszka wrote:
OK, there is that table, but what is it supposed to tell me about the
event and where to h
On Wed, Apr 24, 2019 at 11:48:09AM +0200, Jan Kiszka wrote:
> On 24.04.19 11:45, Mika Westerberg wrote:
> > On Wed, Apr 24, 2019 at 11:36:58AM +0200, Jan Kiszka wrote:
> > > OK, there is that table, but what is it supposed to tell me about the
> > > event and where to hook into it better?
> > ...
>
On 24.04.19 11:45, Mika Westerberg wrote:
On Wed, Apr 24, 2019 at 11:36:58AM +0200, Jan Kiszka wrote:
OK, there is that table, but what is it supposed to tell me about the
event and where to hook into it better?
...
[02Eh 0046 2]SCI Interrupt : 0009
This is the SCI interrup
On Wed, Apr 24, 2019 at 11:36:58AM +0200, Jan Kiszka wrote:
> OK, there is that table, but what is it supposed to tell me about the
> event and where to hook into it better?
...
> [02Eh 0046 2]SCI Interrupt : 0009
This is the SCI interrupt GSI number. IIRC it maps 1:1 to Linux
in
On 24.04.19 10:42, Mika Westerberg wrote:
> On Wed, Apr 24, 2019 at 10:25:40AM +0200, Jan Kiszka wrote:
>> On 24.04.19 10:18, Mika Westerberg wrote:
>>> On Wed, Apr 24, 2019 at 10:12:42AM +0200, Jan Kiszka wrote:
On 24.04.19 09:58, Mika Westerberg wrote:
> +Rafael and linux-acpi.
>
>>>
On Wed, Apr 24, 2019 at 10:25:40AM +0200, Jan Kiszka wrote:
> On 24.04.19 10:18, Mika Westerberg wrote:
> > On Wed, Apr 24, 2019 at 10:12:42AM +0200, Jan Kiszka wrote:
> > > On 24.04.19 09:58, Mika Westerberg wrote:
> > > > +Rafael and linux-acpi.
> > > >
> > > > On Thu, Apr 18, 2019 at 11:23:49AM
On 24.04.19 10:18, Mika Westerberg wrote:
On Wed, Apr 24, 2019 at 10:12:42AM +0200, Jan Kiszka wrote:
On 24.04.19 09:58, Mika Westerberg wrote:
+Rafael and linux-acpi.
On Thu, Apr 18, 2019 at 11:23:49AM +0200, Jan Kiszka wrote:
From: Jan Kiszka
Validated on the Quark platform, this adds int
On Wed, Apr 24, 2019 at 10:12:42AM +0200, Jan Kiszka wrote:
> On 24.04.19 09:58, Mika Westerberg wrote:
> > +Rafael and linux-acpi.
> >
> > On Thu, Apr 18, 2019 at 11:23:49AM +0200, Jan Kiszka wrote:
> > > From: Jan Kiszka
> > >
> > > Validated on the Quark platform, this adds interrupt support
On 24.04.19 09:58, Mika Westerberg wrote:
+Rafael and linux-acpi.
On Thu, Apr 18, 2019 at 11:23:49AM +0200, Jan Kiszka wrote:
From: Jan Kiszka
Validated on the Quark platform, this adds interrupt support on rising
and/or falling edges.
The irqchip parts look good to me but but the ACPI SCI
+Rafael and linux-acpi.
On Thu, Apr 18, 2019 at 11:23:49AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Validated on the Quark platform, this adds interrupt support on rising
> and/or falling edges.
The irqchip parts look good to me but but the ACPI SCI handling seems
weird. This is typicall
On Thu, Apr 18, 2019 at 11:23 AM Jan Kiszka wrote:
> From: Jan Kiszka
>
> Validated on the Quark platform, this adds interrupt support on rising
> and/or falling edges.
>
> Signed-off-by: Jan Kiszka
Since this utilizes ACPI I'd like Andy and/or Mika to say something about
it before I merge it.
From: Jan Kiszka
Validated on the Quark platform, this adds interrupt support on rising
and/or falling edges.
Signed-off-by: Jan Kiszka
---
drivers/gpio/gpio-sch.c | 142 +---
1 file changed, 135 insertions(+), 7 deletions(-)
diff --git a/drivers/gp
38 matches
Mail list logo
