Skeleton power control machine configuration
xow at google.com
Sat Sep 24 13:31:56 AEST 2016
On Thu, Sep 22, 2016 at 10:26 PM, Joel Stanley <joel at jms.id.au> wrote:
> Hey Xo,
> On Fri, Sep 23, 2016 at 10:28 AM, Xo Wang <xow at google.com> wrote:
>> Hi folks,
>> I was adding power sequencing and buttons for our P9 machine and I
>> noticed that Firestone, Garrison, and Witherspoon had patches to
>> op-pwrctl that replaced the net names on the power pins, added more
>> reset complexes, etc.
>> I didn't want to do the same for our machine. I propose moving machine
>> specific options to the Python configuration so we can eliminate the
>> skeleton patches.
> Great! This was an area of concern for me as well.
> I'm not sure what the future plans are for this part of the codebase.
> I think that fixing it to remove the out of tree patches and enable
> new machines is great for the time being. We should check with Patrick
> and Brad as to their plans for the future, so we don't waste time on
> code that will be reworked.
This looked like the shortest path to per-machine power config until
we designed something new, so I just went and implemented it. I
thought Patrick did mention rewriting but you're right, we need this
part to work pretty soon.
>> I mailed my prototype to the Gerrit that adds a dbus call to
>> system_manager, C bindings, and power control logic to handle the
>> abstraction. Please take a look.
>> I'm planning to also extend the GPIO/net name abstraction to reset and
>> power buttons, since they're also using net names directly in their
> I had a brief look at the patches and they look good to me. I left
> some minor comments in gerrit.
> In the future we want to ensure that all of the GPIOs are configured
> correctly to a known state at BMC boot.
To add to that, we might want to experiment with reset tolerance
registers to protect systems against blips from unexpected BMC warm
More information about the openbmc