Discussion on GPIO monitoring and design thoughts.

[vishwa]

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.

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 but then it was not chosen because there 
would be no guarantee that the signal would ever be delivered / caught 
by needed parties.

  - 2.2 ) Also going the signal way demands a service that just needs to 
watch for that.

*) The services that are part of the target will then own complete 
handling of the condition instead of the application that monitored the 
GPIO.

---------

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

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

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.

Please let me know your thoughts on this.

Thanks.

!! Vishwa !!