How to handle GPIO differences between P8 and P9

[Yi TZ Li]

I committed a patch: https://gerrit.openbmc-project.xyz/#/c/1019/
to add a getSystemName() dbus method in org.obmc.managers.System interface.
There are several places in skeleton requires fix for a specific system.

Other way be add a compile flag in yocto when building Skeleton.

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

For a temp fix, the simplest way is not to define IDBTN in Romulus.py.
This will cause an error message reported - but does not hurt.

Thanks,
-Yi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161107/d8819f10/attachment.html>