support for gpio as ipmb sensor

support for gpio as ipmb sensor

[naveen moses]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

Hi All,

we have a couple of gpios ( input ) accessed via ipmb commands in our platform.
which cannot be directly monitored using gpio monitor.

our idea is to expose them as ipmb sensors which has gpio state as property which is updated based
on the current state of the gpio.

at present there is no compatible interface under xyz/openbmc_project/sensors for gpio as sensor.

So is this acceptable to create a new interface for gpio state under xyz/openbmc_project/sensors :
interface name : gpioState
which has a property named value whose possible values are boolean (true or false).

any alternate implementation suggestions or corrections are welcome.

Thanks,
Naveen.


[-- Attachment #2: Type: text/html, Size: 3053 bytes --]

Re: support for gpio as ipmb sensor

[Andrew Jeffery]

Hi Naveen,

On Tue, 5 Oct 2021, at 23:46, naveen moses wrote:
> Hi All,
>
> we have a couple of gpios ( input ) accessed via ipmb commands in our platform.
> which cannot be directly monitored using gpio monitor.

What do you mean when you say "cannot be directly monitored using gpio 
monitor"?

>
> our idea is to expose them as ipmb sensors which has gpio state as 
> property which is updated based
> on the current state of the gpio.
>
> at present there is no compatible interface under 
> xyz/openbmc_project/sensors for gpio as sensor.
>
> So is this acceptable to create a new interface for gpio state under 
> xyz/openbmc_project/sensors :
> interface name : gpioState
> which has a property named value whose possible values are boolean 
> (true or false).

What about modelling the behaviour the GPIO state represents rather 
than just providing a DBus interface to the GPIO values?

Andrew

Re: support for gpio as ipmb sensor

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Wed, Oct 06, 2021 at 10:46:40AM +1030, Andrew Jeffery wrote:
> On Tue, 5 Oct 2021, at 23:46, naveen moses wrote:

> > So is this acceptable to create a new interface for gpio state under 
> > xyz/openbmc_project/sensors :
> > interface name : gpioState
> > which has a property named value whose possible values are boolean 
> > (true or false).
> 
> What about modelling the behaviour the GPIO state represents rather 
> than just providing a DBus interface to the GPIO values?

Agreed.  In general we've tried to refrain from exposing raw GPIOs on the dbus
and instead tried to model some behavior out of those GPIOs.  Your use case
(wanting to use gpio-monitor) doesn't really seem strong enough to me to warrant
a change of this direction.  You'd have to add support in `gpio-monitor` to
watch dbus signals, in addition to gpio-lines, and create a new program that
exposes those gpio objects.  And, at the same time you're introducing a poorly
documented API between two dbus providers because you're expecting very specific
name matching.  Why not just have the original program do whatever you intended
gpio-monitor to do?

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: support for gpio as ipmb sensor

[naveen moses]

[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]

Hi Andrew,

Thanks for the suggestions. please find my comments below:

What do you mean when you say "cannot be directly monitored using gpio
monitor"?

Naveen : The gpio is connected via ipmb bridge interface so to read its state it should be done via ipmb call.
so, it cannot be specified as direct gpio config to be read by gpio-monitor process.

What about modelling the behaviour the GPIO state represents rather
than just providing a DBus interface to the GPIO values?

Naveen : The gpio behavior is done in separate process and there is a separate process which is depends on the gpio state.
Here the implementation is not for a specific gpio. there are 10 to 30 similiar gpios
which can be only accessed via ipmb bridge interface.  The ipmb gpio sensor we are proposing
could be for multiple number ipmb based gpios. The states of the individual ipmb gpios are monitored if they are configured in entity manager as gpio sensors.
their state is updated as sensor state property which can be read by other dependent properties.

Thanks,
Naveen
________________________________
From: Andrew Jeffery <andrew@aj.id.au>
Sent: Wednesday, October 6, 2021 5:46 AM
To: naveen moses <naveen.moses@hotmail.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
Cc: Zhikui Ren <zhikui.ren@intel.com>; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; Ed Tanous <ed@tanous.net>; naveen moses <naveen.moses@outlook.com>
Subject: Re: support for gpio as ipmb sensor

Hi Naveen,

On Tue, 5 Oct 2021, at 23:46, naveen moses wrote:
> Hi All,
>
> we have a couple of gpios ( input ) accessed via ipmb commands in our platform.
> which cannot be directly monitored using gpio monitor.

What do you mean when you say "cannot be directly monitored using gpio
monitor"?

>
> our idea is to expose them as ipmb sensors which has gpio state as
> property which is updated based
> on the current state of the gpio.
>
> at present there is no compatible interface under
> xyz/openbmc_project/sensors for gpio as sensor.
>
> So is this acceptable to create a new interface for gpio state under
> xyz/openbmc_project/sensors :
> interface name : gpioState
> which has a property named value whose possible values are boolean
> (true or false).

What about modelling the behaviour the GPIO state represents rather
than just providing a DBus interface to the GPIO values?

Andrew

[-- Attachment #2: Type: text/html, Size: 9378 bytes --]

Re: support for gpio as ipmb sensor

[naveen moses]

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]


________________________________
From: naveen moses <naveen.moses@hotmail.com>
Sent: Thursday, October 7, 2021 11:42 AM
To: Andrew Jeffery <andrew@aj.id.au>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
Cc: Zhikui Ren <zhikui.ren@intel.com>; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; Ed Tanous <ed@tanous.net>; naveen moses <naveen.moses@outlook.com>
Subject: Re: support for gpio as ipmb sensor

Hi Andrew,

Thanks for the suggestions. please find my comments below:

What do you mean when you say "cannot be directly monitored using gpio
monitor"?

Naveen : The gpio is connected via ipmb bridge interface so to read its state it should be done via ipmb call.
so, it cannot be specified as direct gpio config to be read by gpio-monitor process.

What about modelling the behaviour the GPIO state represents rather
than just providing a DBus interface to the GPIO values?

Naveen : The gpio behavior is done in separate process and there is a separate process which is depends on the gpio state.
Here the implementation is not for a specific gpio. there are 10 to 30 similiar gpios
which can be only accessed via ipmb bridge interface.  The ipmb gpio sensor we are proposing
could be for multiple number ipmb based gpios. The states of the individual ipmb gpios are monitored if they are configured in entity manager as gpio sensors.
their state is updated as sensor state property which can be read by other dependent properties.

Thanks,
Naveen
________________________________
From: Andrew Jeffery <andrew@aj.id.au>
Sent: Wednesday, October 6, 2021 5:46 AM
To: naveen moses <naveen.moses@hotmail.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
Cc: Zhikui Ren <zhikui.ren@intel.com>; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; Ed Tanous <ed@tanous.net>; naveen moses <naveen.moses@outlook.com>
Subject: Re: support for gpio as ipmb sensor

Hi Naveen,

On Tue, 5 Oct 2021, at 23:46, naveen moses wrote:
> Hi All,
>
> we have a couple of gpios ( input ) accessed via ipmb commands in our platform.
> which cannot be directly monitored using gpio monitor.

What do you mean when you say "cannot be directly monitored using gpio
monitor"?

>
> our idea is to expose them as ipmb sensors which has gpio state as
> property which is updated based
> on the current state of the gpio.
>
> at present there is no compatible interface under
> xyz/openbmc_project/sensors for gpio as sensor.
>
> So is this acceptable to create a new interface for gpio state under
> xyz/openbmc_project/sensors :
> interface name : gpioState
> which has a property named value whose possible values are boolean
> (true or false).

What about modelling the behaviour the GPIO state represents rather
than just providing a DBus interface to the GPIO values?

Andrew

[-- Attachment #2: Type: text/html, Size: 7745 bytes --]

Re: support for gpio as ipmb sensor

[Andrei Kartashev]

Hi Naveen,

What are the consumers of this 30 GPIO lines? How are you going to
integrate this signal to software?

If this is really "sensors", which should be exposed to end user (e.g.
with ipmi discrete sensors), I propose to add some generic discrete
sensor mechanism, which can be configured from EM.
Probably we should extend xyz.openbmc_project.Sensor interfaces set to
handle discrete sensors.

If this is some internal mechanism, required only for other daemons, I
prefer you to not use "sensors" term - this something other )

On Thu, 2021-10-07 at 07:45 +0000, naveen moses wrote:
> 
> From: naveen moses <naveen.moses@hotmail.com>
> Sent: Thursday, October 7, 2021 11:42 AM
> To: Andrew Jeffery <andrew@aj.id.au>; openbmc@lists.ozlabs.org
> <openbmc@lists.ozlabs.org>
> Cc: Zhikui Ren <zhikui.ren@intel.com>; Jae Hyun Yoo
> <jae.hyun.yoo@linux.intel.com>; Vernon Mauery
> <vernon.mauery@linux.intel.com>; Ed Tanous <ed@tanous.net>; naveen
> moses <naveen.moses@outlook.com>
> Subject: Re: support for gpio as ipmb sensor  
> Hi Andrew,
> 
> Thanks for the suggestions. please find my comments below:
> 
> What do you mean when you say "cannot be directly monitored using
> gpio
> monitor"?
>  
> Naveen : The gpio is connected via ipmb bridge interface so to read
> its state it should be done via ipmb call.
> so, it cannot be specified as direct gpio config to be read by gpio-
> monitor process.
> 
> What about modelling the behaviour the GPIO state represents rather
> than just providing a DBus interface to the GPIO values?
> 
> Naveen : The gpio behavior is done in separate process and there is a
> separate process which is depends on the gpio state.
> Here the implementation is not for a specific gpio. there are 10 to
> 30 similiar gpios
> which can be only accessed via ipmb bridge interface.  The ipmb gpio
> sensor we are proposing
> could be for multiple number ipmb based gpios. The states of the
> individual ipmb gpios are monitored if they are configured in entity
> manager as gpio sensors.
> their state is updated as sensor state property which can be read by
> other dependent properties.
>   
> Thanks,Naveen
> From: Andrew Jeffery <andrew@aj.id.au>
> Sent: Wednesday, October 6, 2021 5:46 AM
> To: naveen moses <naveen.moses@hotmail.com>; openbmc@lists.ozlabs.org
> <openbmc@lists.ozlabs.org>
> Cc: Zhikui Ren <zhikui.ren@intel.com>; Jae Hyun Yoo
> <jae.hyun.yoo@linux.intel.com>; Vernon Mauery
> <vernon.mauery@linux.intel.com>; Ed Tanous <ed@tanous.net>; naveen
> moses <naveen.moses@outlook.com>
> Subject: Re: support for gpio as ipmb sensor  
> Hi Naveen,
> 
> On Tue, 5 Oct 2021, at 23:46, naveen moses wrote:
> > Hi All,
> > 
> > we have a couple of gpios ( input ) accessed via ipmb commands in
> > our platform.
> > which cannot be directly monitored using gpio monitor.
> 
> What do you mean when you say "cannot be directly monitored using
> gpio 
> monitor"?
> 
> > 
> > our idea is to expose them as ipmb sensors which has gpio state as 
> > property which is updated based
> > on the current state of the gpio.
> > 
> > at present there is no compatible interface under 
> > xyz/openbmc_project/sensors for gpio as sensor.
> > 
> > So is this acceptable to create a new interface for gpio state
> > under 
> > xyz/openbmc_project/sensors :
> > interface name : gpioState
> > which has a property named value whose possible values are boolean 
> > (true or false).
> 
> What about modelling the behaviour the GPIO state represents rather 
> than just providing a DBus interface to the GPIO values?
> 
> Andrew

-- 
Best regards,
Andrei Kartashev