<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 16, 2017 at 3:12 PM, Brad Bishop <span dir="ltr"><<a href="mailto:bradleyb@fuzziesquirrel.com" target="_blank">bradleyb@fuzziesquirrel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Patrick<br>
<span class=""><br>
On Thu, 2017-09-14 at 15:02 -0700, Patrick Venture wrote:<br>
> I apologize if this already exists or is in the works.<br>
><br>
> I propose we create a daemon that centralizes userspace GPIO access.<br>
><br>
> From a high level, the daemon will implement interfaces to export or<br>
> unexport GPIOs.  Each GPIO exported will exist on the dbus:<br>
><br>
> /xyz/openbmc_project/gpio/53 and implement an interface with the<br>
> following properties:<br>
> value, direction, active_low, etc.<br>
<br>
</span>Just thinking out loud...are we sure a gpio is a useful abstraction?<br>
If applications all just use the chardev API what is the benefit of<br>
having a dbus object, at the cost of API complexity.<br></blockquote><div><br></div><div>As an alternative, perhaps a library would suffice.  My goal is to avoid multiple in-application implementations.  However, I felt it might be helpful to have some centralized daemon serving this information -- a simple dbus property access may be simpler than either implementing the ioctl in each application.  However, a library may also provide the necessary abstraction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> Some doubts, should the gpio name on the dbus be the relative name<br>
> (53), should it be the system specific name (G5) or the absolute<br>
> name?  I'm thinking the relative name and let the daemon handle<br>
> internalizing the adjustment from relative to absolute.<br>
><br>
> I'm working on adding GPIO support within phosphor-hwmon so that I<br>
> can access a voltage sensor that's gated by a GPIO, and I know there<br>
<br>
</span>Can you elaborate on what gated means?  Is it you have to wiggle a GPIO<br>
before the hwmon driver for this voltage sensor can actually access the<br>
sensor hardware?<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>There is a GPIO that controls whether the battery sensor on the quanta board (and I've heard of similar configurations on others) that needs to be set high for the sensor to work.  I implemented a bit of a hack in phosphor-hwmon to allow one to specify a GPIO that needs to be flipped in this type of configuration.  I'd consider submitting the patch, however it uses the sysfs interface -- as this saved a little implementation time.</div><div><br></div><div>I'd be willing to fix it up to use the proper interface and submit it upstream if that's something helpful -- or seek out a good library for us to use -- I'm also open to suggestions on this.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
> have been conversations and implementations of this for IPMI OEM --<br>
> and I think it could easily be centralized.<br>
><br>
> Thoughts?<br>
><br>
> Patrick<br>
</div></div></blockquote></div><br></div></div>