From: Patrick Williams <patrick@stwcx.xyz>
To: Mine <mine260309@gmail.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: How to handle GPIO differences between P8 and P9
Date: Sun, 6 Nov 2016 22:06:44 -0600 [thread overview]
Message-ID: <20161107040643.GE15757@heinlein.lan> (raw)
In-Reply-To: <CAARXrtmemiSFPH7RGxFLcddt1Ld4pGTwsDX-rPtAmf2coS8VDg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]
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?
--
Patrick Williams
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2016-11-07 4:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 16:45 How to handle GPIO differences between P8 and P9 Mine
2016-11-07 4:06 ` Patrick Williams [this message]
2016-11-07 9:10 ` Yi TZ Li
2016-11-07 16:19 ` Patrick Williams
2016-11-07 17:01 ` Mine
2016-11-07 21:53 ` Xo Wang
2016-11-08 21:13 ` Mine
2016-11-08 23:38 ` Xo Wang
2016-11-09 1:34 ` Andrew Jeffery
-- strict thread matches above, loose matches on Subject: below --
2016-11-04 16:38 Lei KM 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=20161107040643.GE15757@heinlein.lan \
--to=patrick@stwcx.xyz \
--cc=mine260309@gmail.com \
--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.