All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lei YU <mine260309@gmail.com>
To: Andres Oportus <andresoportus@google.com>
Cc: Andrew Jeffery <andrew@aj.id.au>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Question on States monitoring
Date: Tue, 15 May 2018 09:49:31 +0800	[thread overview]
Message-ID: <CAARXrt=Pkddt03EVfwjZN9Qpp8No5LA5X6dqJ+MfU6_K+k-00Q@mail.gmail.com> (raw)
In-Reply-To: <CAD5O4R3f1u9Ptk0_rz12teQgmqNkucGpOWmU9EKNBmxdSYAMrg@mail.gmail.com>

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

  reply	other threads:[~2018-05-15  1:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAARXrt=Pkddt03EVfwjZN9Qpp8No5LA5X6dqJ+MfU6_K+k-00Q@mail.gmail.com' \
    --to=mine260309@gmail.com \
    --cc=andresoportus@google.com \
    --cc=andrew@aj.id.au \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.