Discussion on GPIO monitoring and design thoughts.

[vishwa]

Hi Andrew,

Thanks for the feedback. I have responded inline.

On 04/07/2017 05:44 AM, Andrew Jeffery wrote:
> Hi Vishwa,
>
> I have some queries below. Apologies if they appear curt, but I'm
> trying to cut to the point in each case.
>
> On Wed, 2017-04-05 at 13:56 +0530, vishwa wrote:
>> We had a technical discussion on HOWTO and what is the right thing to do
>> handling the GPIO assertion and here is the gist.
>>
>> 1) Use gpio-keys and utilize libevdev wrappers (
>> https://www.freedesktop.org/software/libevdev/doc/latest/ ) to watch for
>> data in /dev/input/event.
> Okay, I'd like you to step back and detail what problem you're actually
> trying to solve here. Going from wanting to handle GPIO interrupts to
> using gpio-keys everywhere needs some explanation. We have at least two
> other interfaces that would appear to be sufficient: GPIO chardev and
> sysfs.

Sure. I realize I should have put the use-case here than at the end.

Problem: When the host check-stops, we need a way to detect that.
The existing mechanism will assert a configured GPIO when that happens.
Firmware code needs a way of knowing that it has happened and that is 
why this application.

I was told that /sysfs is being deprecated and that we use the chardev. 
We had 2 options then.

1/. Use the gpio-keys
2/. Use libgpio ( the support is not in yet in 4.7 per the discussion )

Brad Bishop recommended that gpio-keys be used over libgpio due to the 
debouncing support built into gpio-keys implementation.
Since I am not an expert in this area, I suggest you please talk to Brad 
if you see there are better ideas.
> What you've described reads to me like a case of the X-Y problem. This
> link is rather blunt, but it illustrates the issue:
>
> http://mywiki.wooledge.org/XyProblem

This link is really hilarious ( yeah ), Thanks for this :)

>> 2) Define a target with set of services that would be called into by the
>> GPIO monitor application when the GPIO state changes to what is expected.
>>
>>    - 2.1) Another option was to just broadcast a signal that interested
>> parties could catch and act
> I assume this is on D-Bus?

Correct.

>
>>   but then it was not chosen because there
>> would be no guarantee that the signal would ever be delivered / caught
>> by needed parties.
> Isn't this what systemd is for?

It was Patrick's concern on using signals. But I tend to agree with him 
too. Although I understand systemd is already doing a good job here with 
signals.
>
> Isn't this what you gain by decoupling the monitoring from the
> handling? For instance if we're talking in abstract terms, the current
> system policy might be to not care about the state change.

Yeah. This is a valid one. We shall talk about it.

>>    - 2.2 ) Also going the signal way demands a service that just needs to
>> watch for that.
> Is that the case? Can't we have one service handling multiple signals?
> Whether that's a good idea is another question.
>

I don't like the idea of one jumbo application monitoring all signals. 
Whoever that has a need, let them wait.

>> *) The services that are part of the target will then own complete
>> handling of the condition instead of the application that monitored the
>> GPIO.
> Why are we decoupling the handler services from the GPIO? What is the
> advantage?
>
> The disadvantage is the behaviour of the system is much harder to
> understand. If we go this route, what tooling will be in place to debug
> failures of interactions between components?
>
> I would argue that this is already a significant hurdle in
> understanding integration failures on the BMC, and I would prefer not
> to add to the problems.
>

I am not following the argument here. Why is the behavior harder to 
understand when you have defined systemd targets doing what they are
required to do. Its the job of applications that get into that target to 
do the right thing of collecting what is necessary to understand
one specific problem.
>> ---------
>>
>> Here is an example of application that handles the GPIO assertion that
>> happens when host does a checkstop.
>>
>> 1) Application's arguments need /dev/input/event<$number> and the
>> expected GPIO state as indicated by linux,code in :
>>
>> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/gpio-keys.txt
> There is a downside in that you will be creating a kernel ABI by
> mapping GPIO events to a keycode. This choice appears to me to be
> arbitrary, and from the kernel's perspective we don't know how
> userspace is going to treat the value so we lose the flexibility to
> change it if it's not. This isn't a show-stopper, but it sure feels
> like a wart that doesn't need to exist.
>

Is it not expected that the binding always pass the input_event struct 
?. What kind of changes are you thinking ?

Are you saying for instance you will change these values and 
applications may go crazy ?

|#define KEY_UP 103 ||#define KEY_DOWN 108 |


>> 2) Call this app after reaching `Host-Running` state thus avoiding any
>> checks to see current state.
>>
>> 2) App will then use libevdev wrappers to watch for the state
> It bothers me that we'd be invoking libevdev to catch an interrupt on a
> GPIO. It seems unnecessarily complex in general.

I need Brad Bishop help here.

>
>> 3) On seeing the expected state change, app calls into the configured
>> target.
>>
>> 4) Configured target right now has 2 services.
>>
>>     - 4.1 ) Service that Creates an errorlog indicating the checkstop
>>     - 4.2 ) Service that will start the Quiesce target
>>
>> --------
>>
>> This design direction helps decouple applications that monitor and
>> analyze the conditions.
> Sure. But you need to describe the advantage of decoupling these
> concepts. Why do we need the abstraction? I need something more than
> "decoupling is good", because as described above it can lead to a lot
> of overhead trying to track down bugs. Sometimes it's a balancing act,
> and we need to understand what we're trading off.

Sure. The advantage of decoupling is that you can use this gpio monitor 
in any implementation and offloading handling the errors to 
implementation specific targets than consuming implementation specific 
complexity into this code and thus making it specific to some platforms.

> Cheers,
>
> Andrew

Hope I answered. Thank you.

!! Vishwa !!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170407/6ec52d67/attachment.html>