All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brad Bishop <bradleyb@fuzziesquirrel.com>
To: Patrick Venture <venture@google.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: GPIO Centralized Control Daemon
Date: Sat, 16 Sep 2017 18:12:40 -0400	[thread overview]
Message-ID: <1505599960.32310.1.camel@fuzziesquirrel.com> (raw)
In-Reply-To: <CAO=notyfYfT51+q_-8a7S5VrhJtuVbXaSav78mbCmGe6OnvjLA@mail.gmail.com>

Hi Patrick

On Thu, 2017-09-14 at 15:02 -0700, Patrick Venture wrote:
> I apologize if this already exists or is in the works.
> 
> I propose we create a daemon that centralizes userspace GPIO access.
> 
> From a high level, the daemon will implement interfaces to export or
> unexport GPIOs.  Each GPIO exported will exist on the dbus:
> 
> /xyz/openbmc_project/gpio/53 and implement an interface with the
> following properties:
> value, direction, active_low, etc.

Just thinking out loud...are we sure a gpio is a useful abstraction? 
If applications all just use the chardev API what is the benefit of
having a dbus object, at the cost of API complexity.

> 
> Some doubts, should the gpio name on the dbus be the relative name
> (53), should it be the system specific name (G5) or the absolute
> name?  I'm thinking the relative name and let the daemon handle
> internalizing the adjustment from relative to absolute.
> 
> I'm working on adding GPIO support within phosphor-hwmon so that I
> can access a voltage sensor that's gated by a GPIO, and I know there 

Can you elaborate on what gated means?  Is it you have to wiggle a GPIO
before the hwmon driver for this voltage sensor can actually access the
sensor hardware?


> have been conversations and implementations of this for IPMI OEM --
> and I think it could easily be centralized.
> 
> Thoughts?
> 
> Patrick

  parent reply	other threads:[~2017-09-16 22:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14 22:02 GPIO Centralized Control Daemon Patrick Venture
2017-09-14 22:29 ` Rick Altherr
2017-09-14 22:55   ` Patrick Venture
2017-09-16 22:12 ` Brad Bishop [this message]
2017-09-17  4:22   ` Patrick Venture
2017-09-17 16:26     ` Brad Bishop
2017-09-17 16:39       ` Patrick Venture
2017-09-17 17:33         ` Brad Bishop
2017-09-17 21:04           ` Patrick Venture
2017-09-17 21:38             ` Brad Bishop
2017-09-17 21:49               ` Patrick Venture
2017-09-17 22:10                 ` Brad Bishop
2017-09-18  7:32                 ` Andrew Jeffery
2017-09-18 14:52                   ` Patrick Venture
2017-09-18  7:07     ` Andrew Jeffery

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=1505599960.32310.1.camel@fuzziesquirrel.com \
    --to=bradleyb@fuzziesquirrel.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=venture@google.com \
    /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.