<html><body><p><tt>I committed a patch: </tt><a href="https://gerrit.openbmc-project.xyz/#/c/1019/"><tt>https://gerrit.openbmc-project.xyz/#/c/1019/</tt></a><br><tt>to add a getSystemName() dbus method in org.obmc.managers.System interface.</tt><br><tt>There are several places in skeleton requires fix for a specific system.</tt><br><br><tt>Other way be add a compile flag in yocto when building Skeleton.</tt><br><tt><br>> From: Patrick Williams <patrick@stwcx.xyz></tt><br><tt>> To: Mine <mine260309@gmail.com></tt><br><tt>> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org></tt><br><tt>> Date: 11/07/2016 12:07 PM</tt><br><tt>> Subject: Re: How to handle GPIO differences between P8 and P9</tt><br><tt>> Sent by: "openbmc" <openbmc-bounces+shliyi=cn.ibm.com@lists.ozlabs.org></tt><br><tt>> <br>> On Fri, Nov 04, 2016 at 11:45:02AM -0500, Mine wrote:<br>> > Hi All,<br>> > <br>> > This mail is to discuss how to handle GPIO differences (e.g.<br>> > functionality, IN/OUT) between different HWs.<br>> > <br>> > I went into a case the P8 uses two GPIOs, but P9 does not use them: in<br>> > skeleton/op-hostctl/control_host_obj.c:<br>> > <br>> > GPIO Throttle = (GPIO){ "BMC_THROTTLE" };<br>> > GPIO idbtn = (GPIO){ "IDBTN" };<br>> > ...<br>> > rc |= gpio_write(&Throttle,1);<br>> > rc |= gpio_write(&idbtn,0);<br>> > <br>> > In P9, BMC_THROTTLE is renamed to N_MODE_N, and changed to an IN GPIO;<br>> > IDBTN is changed to IN GPIO as well.<br>> > If we keep the above code and overriding the GPIOs, writing<br>> > BMC_THROTTLE takes no effect, but writing to IDBTN may break the<br>> > function of its related front panel button.<br>> > <br>> > So I think we need to distinguish such cases to avoid issues.<br>> > <br>> > The question is, how to change the code to support different HWs that<br>> > have unique GPIOs?<br>> <br>> The current GPIO names are "Barreleye-Centric" in that they are named<br>> based on names that were on the Barreleye board. We need to move the<br>> GPIO structure to be "Function-Centric" instead so that it is more<br>> generally applicable.<br>> <br>> That is something that will probably happen over the next few months.<br>> Joel is working on a proposal and we'll schedule some of the refactoring<br>> work afterwards in the userspace code.<br>> <br>> We might go the route of having dbus objects for GPIOs instead of having<br>> direct access, similar to what I believe the current proposal is for<br>> LEDs. We'll have to see what Joel proposes first and then discuss it.<br>> <br>> I would suggest for now we simply do the minimum we need to to "make P9<br>> work". If this means using GPIO names that continue to match Barreleye<br>> naming schemes, rather than Witherspoon / Romulus, I think that makes<br>> sense. You can always keep a comment in the System.py file that names<br>> the "real board" name.<br>> <br>> In cases where they have different functionality, doesn't using a<br>> different name solve that? Having a different name means the lookup to<br>> "BMC_THROTTLE" or "IDBTN" will fail on Witherspoon and thus this code<br>> will no longer function, right?</tt><br><br><tt>For a temp fix, the simplest way is not to define IDBTN in Romulus.py.</tt><br><tt>This will cause an error message reported - but does not hurt.</tt><br><tt><br>Thanks,</tt><br><tt>-Yi</tt><BR>
</body></html>