All of lore.kernel.org
 help / color / mirror / Atom feed
* Question on States monitoring
@ 2018-05-14 15:46 Andres Oportus
  2018-05-14 23:16 ` Andrew Jeffery
  0 siblings, 1 reply; 8+ messages in thread
From: Andres Oportus @ 2018-05-14 15:46 UTC (permalink / raw)
  To: openbmc

Are there any ongoing efforts on expanding States (say provided by GPIOs)
monitoring/management?  I see that phosphor-state-manager has
Chassis/Host/BMC states that are placed onto DBUS but not a more generic
mechanism.  On the GPIO specific side, I see that phosphor-gpio-monitor
allows for interrupt driven GPIO monitoring (seemly only used under a
gpio-keys driver with /dev/input for Power's checkstop monitoring?), but no
generic GPIO setting/getting for those not allowing interrupt type
monitoring (say output GPIOs).

Thanks,
Andres

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Question on States monitoring
  2018-05-14 15:46 Question on States monitoring Andres Oportus
@ 2018-05-14 23:16 ` Andrew Jeffery
  2018-05-14 23:26   ` Andres Oportus
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Jeffery @ 2018-05-14 23:16 UTC (permalink / raw)
  To: Andres Oportus, openbmc

Hi Andres,

On Tue, 15 May 2018, at 01:16, Andres Oportus wrote:
> Are there any ongoing efforts on expanding States (say provided by GPIOs)
> monitoring/management?  I see that phosphor-state-manager has
> Chassis/Host/BMC states that are placed onto DBUS but not a more generic
> mechanism.  On the GPIO specific side, I see that phosphor-gpio-monitor
> allows for interrupt driven GPIO monitoring (seemly only used under a
> gpio-keys driver with /dev/input for Power's checkstop monitoring?), but no
> generic GPIO setting/getting for those not allowing interrupt type
> monitoring (say output GPIOs).

It's not clear to me what you're looking for here. Are you hoping for something to expose the GPIOs on DBus? I don't think we have anything like that, which is more of a design philosophy thing (we should probably provide a higher-level capability on DBus, not just directly expose GPIOs).

Alternatively if you're looking to handle GPIOs from your application, I would recommend libgpiod: 

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/

Cheers,

Andrew

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Question on States monitoring
  2018-05-14 23:16 ` Andrew Jeffery
@ 2018-05-14 23:26   ` Andres Oportus
  2018-05-15  1:49     ` Lei YU
  0 siblings, 1 reply; 8+ messages in thread
From: Andres Oportus @ 2018-05-14 23:26 UTC (permalink / raw)
  To: andrew; +Cc: openbmc

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

Thanks Andrew, yeah I see the design philosophy of not exposing low level
stuff like GPIOs unless they mean something more high level (hence the
"State" reference) that could be exposed/monitored/changed/etc.  I'm just
checking to see if we have anything already being thought of or implemented
as to not come up with a custom solution.  The problem is managing "States"
at least initially backed by GPIOs, and it does not have to be on the DBUS
although from what I've seen for instance on IPMI we use DBUS extensively
for things that get exported.

On Mon, May 14, 2018 at 4:16 PM Andrew Jeffery <andrew@aj.id.au> wrote:

> Hi Andres,
>
> On Tue, 15 May 2018, at 01:16, Andres Oportus wrote:
> > Are there any ongoing efforts on expanding States (say provided by GPIOs)
> > monitoring/management?  I see that phosphor-state-manager has
> > Chassis/Host/BMC states that are placed onto DBUS but not a more generic
> > mechanism.  On the GPIO specific side, I see that phosphor-gpio-monitor
> > allows for interrupt driven GPIO monitoring (seemly only used under a
> > gpio-keys driver with /dev/input for Power's checkstop monitoring?), but
> no
> > generic GPIO setting/getting for those not allowing interrupt type
> > monitoring (say output GPIOs).
>
> It's not clear to me what you're looking for here. Are you hoping for
> something to expose the GPIOs on DBus? I don't think we have anything like
> that, which is more of a design philosophy thing (we should probably
> provide a higher-level capability on DBus, not just directly expose GPIOs).
>
> Alternatively if you're looking to handle GPIOs from your application, I
> would recommend libgpiod:
>
> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
>
> Cheers,
>
> Andrew
>

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Question on States monitoring
  2018-05-14 23:26   ` Andres Oportus
@ 2018-05-15  1:49     ` Lei YU
  2018-05-15  1:53       ` Andrew Jeffery
  0 siblings, 1 reply; 8+ messages in thread
From: Lei YU @ 2018-05-15  1:49 UTC (permalink / raw)
  To: Andres Oportus; +Cc: Andrew Jeffery, OpenBMC Maillist

Hi Andres,

The existing [phosphor-gpio-monitor][1] contains two services, one is for
monitor gpio interrupts, the other is "phosphor-gpio-presence" that checks a
gpio output and let it be some state on DBus.

I guess the "presence" service is what you are looking for, that maps a
gpio output to a Dbus object.

The existing use case is:
1. Witherspoon checks if power supply is connected and create dbus object
   /inventory/system/chassis/motherboard/powersupplyX, it also is able to
   bind the kernel driver when it is attached.
2. Zaius checks if a PCIE card is connected on E2B and create dbus object
   /inventory/system/chassis/pcie_card_e2b

You can see a little detailed explanation at
https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence

[1]: https://github.com/openbmc/phosphor-gpio-monitor

On Tue, May 15, 2018 at 7:26 AM, Andres Oportus
<andresoportus@google.com> wrote:
> Thanks Andrew, yeah I see the design philosophy of not exposing low level
> stuff like GPIOs unless they mean something more high level (hence the
> "State" reference) that could be exposed/monitored/changed/etc.  I'm just
> checking to see if we have anything already being thought of or implemented
> as to not come up with a custom solution.  The problem is managing "States"
> at least initially backed by GPIOs, and it does not have to be on the DBUS
> although from what I've seen for instance on IPMI we use DBUS extensively
> for things that get exported.
>
> On Mon, May 14, 2018 at 4:16 PM Andrew Jeffery <andrew@aj.id.au> wrote:
>>
>> Hi Andres,
>>
>> On Tue, 15 May 2018, at 01:16, Andres Oportus wrote:
>> > Are there any ongoing efforts on expanding States (say provided by
>> > GPIOs)
>> > monitoring/management?  I see that phosphor-state-manager has
>> > Chassis/Host/BMC states that are placed onto DBUS but not a more generic
>> > mechanism.  On the GPIO specific side, I see that phosphor-gpio-monitor
>> > allows for interrupt driven GPIO monitoring (seemly only used under a
>> > gpio-keys driver with /dev/input for Power's checkstop monitoring?), but
>> > no
>> > generic GPIO setting/getting for those not allowing interrupt type
>> > monitoring (say output GPIOs).
>>
>> It's not clear to me what you're looking for here. Are you hoping for
>> something to expose the GPIOs on DBus? I don't think we have anything like
>> that, which is more of a design philosophy thing (we should probably provide
>> a higher-level capability on DBus, not just directly expose GPIOs).
>>
>> Alternatively if you're looking to handle GPIOs from your application, I
>> would recommend libgpiod:
>>
>> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
>>
>> Cheers,
>>
>> Andrew

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Question on States monitoring
  2018-05-15  1:49     ` Lei YU
@ 2018-05-15  1:53       ` Andrew Jeffery
  2018-05-15  1:57         ` Lei YU
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Jeffery @ 2018-05-15  1:53 UTC (permalink / raw)
  To: Lei YU, Andres Oportus; +Cc: OpenBMC Maillist

Hi Lei,

On Tue, 15 May 2018, at 11:19, Lei YU wrote:
> Hi Andres,
> 
> The existing [phosphor-gpio-monitor][1] contains two services, one is for
> monitor gpio interrupts, the other is "phosphor-gpio-presence" that checks a
> gpio output and let it be some state on DBus.
> 
> I guess the "presence" service is what you are looking for, that maps a
> gpio output to a Dbus object.
> 
> The existing use case is:
> 1. Witherspoon checks if power supply is connected and create dbus object
>    /inventory/system/chassis/motherboard/powersupplyX, it also is able to
>    bind the kernel driver when it is attached.
> 2. Zaius checks if a PCIE card is connected on E2B and create dbus object
>    /inventory/system/chassis/pcie_card_e2b
> 
> You can see a little detailed explanation at
> https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence

That porting guide looks like it has some interesting info, and I feel like we should probably make it part of the docs repository. Did you have any plans on integrating it?

Cheers,

Andrew

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Question on States monitoring
  2018-05-15  1:53       ` Andrew Jeffery
@ 2018-05-15  1:57         ` Lei YU
  2018-05-15  5:05           ` Andres Oportus
  0 siblings, 1 reply; 8+ messages in thread
From: Lei YU @ 2018-05-15  1:57 UTC (permalink / raw)
  To: Andrew Jeffery; +Cc: Andres Oportus, OpenBMC Maillist

On Tue, May 15, 2018 at 9:53 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Hi Lei,
>
> On Tue, 15 May 2018, at 11:19, Lei YU wrote:
>> Hi Andres,
>>
>> The existing [phosphor-gpio-monitor][1] contains two services, one is for
>> monitor gpio interrupts, the other is "phosphor-gpio-presence" that checks a
>> gpio output and let it be some state on DBus.
>>
>> I guess the "presence" service is what you are looking for, that maps a
>> gpio output to a Dbus object.
>>
>> The existing use case is:
>> 1. Witherspoon checks if power supply is connected and create dbus object
>>    /inventory/system/chassis/motherboard/powersupplyX, it also is able to
>>    bind the kernel driver when it is attached.
>> 2. Zaius checks if a PCIE card is connected on E2B and create dbus object
>>    /inventory/system/chassis/pcie_card_e2b
>>
>> You can see a little detailed explanation at
>> https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence
>
> That porting guide looks like it has some interesting info, and I feel like we should probably make it part of the docs repository. Did you have any plans on integrating it?

Yup, I will submit to openbmc/doc (when it's somehow ready).

This doc is my attempt to help system vendors to know OpenBMC and get it
ported on their machine.
And for now I have sent this to 2 or 3 vendors and ask for feedback.

It's not completed yet as I need to add one more page for some development
tips, e.g. how to quickly modify a code and get it tested.

>
> Cheers,
>
> Andrew

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Question on States monitoring
  2018-05-15  1:57         ` Lei YU
@ 2018-05-15  5:05           ` Andres Oportus
  2018-05-15 12:32             ` Lei YU
  0 siblings, 1 reply; 8+ messages in thread
From: Andres Oportus @ 2018-05-15  5:05 UTC (permalink / raw)
  To: mine260309; +Cc: andrew, openbmc

On Mon, May 14, 2018 at 6:57 PM Lei YU <mine260309@gmail.com> wrote:

> On Tue, May 15, 2018 at 9:53 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> > Hi Lei,
> >
> > On Tue, 15 May 2018, at 11:19, Lei YU wrote:
> >> Hi Andres,
> >>
> >> The existing [phosphor-gpio-monitor][1] contains two services, one is
for
> >> monitor gpio interrupts, the other is "phosphor-gpio-presence" that
checks a
> >> gpio output and let it be some state on DBus.
> >>
> >> I guess the "presence" service is what you are looking for, that maps a
> >> gpio output to a Dbus object.
> >>
> >> The existing use case is:
> >> 1. Witherspoon checks if power supply is connected and create dbus
object
> >>    /inventory/system/chassis/motherboard/powersupplyX, it also is able
to
> >>    bind the kernel driver when it is attached.
> >> 2. Zaius checks if a PCIE card is connected on E2B and create dbus
object
> >>    /inventory/system/chassis/pcie_card_e2b
> >>
> >> You can see a little detailed explanation at
> >>
https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence
> >
Thanks for info.  It seems that since both monitor and presence are
subclasses from Evdev they, at least in their current form, need GPIOs to
be setup as input (in the examples use /dev/input devices) with a driver
like gpio-keys, is this the case?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Question on States monitoring
  2018-05-15  5:05           ` Andres Oportus
@ 2018-05-15 12:32             ` Lei YU
  0 siblings, 0 replies; 8+ messages in thread
From: Lei YU @ 2018-05-15 12:32 UTC (permalink / raw)
  To: Andres Oportus; +Cc: Andrew Jeffery, OpenBMC Maillist

> Thanks for info.  It seems that since both monitor and presence are
> subclasses from Evdev they, at least in their current form, need GPIOs to
> be setup as input (in the examples use /dev/input devices) with a driver
> like gpio-keys, is this the case?

Yup, at this level they are the same, using the same driver.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-05-15 12:32 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-14 15:46 Question on States monitoring Andres Oportus
2018-05-14 23:16 ` Andrew Jeffery
2018-05-14 23:26   ` Andres Oportus
2018-05-15  1:49     ` Lei YU
2018-05-15  1:53       ` Andrew Jeffery
2018-05-15  1:57         ` Lei YU
2018-05-15  5:05           ` Andres Oportus
2018-05-15 12:32             ` Lei YU

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.