All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vijay Khemka <vijaykhemka@fb.com>
To: "Bills, Jason M" <jason.m.bills@linux.intel.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: x86-power-control
Date: Tue, 22 Oct 2019 01:15:22 +0000	[thread overview]
Message-ID: <6DA89556-AD25-4BEE-AF40-9D7A129B7CB9@fb.com> (raw)
In-Reply-To: <54c375be-e45e-fc2a-dd31-6c9d61158169@linux.intel.com>



On 10/21/19, 4:04 PM, "Bills, Jason M" <jason.m.bills@linux.intel.com> wrote:

    
    
    On 10/18/2019 4:04 PM, Vijay Khemka wrote:
    > 
    > 
    > On 10/18/19, 11:02 AM, "openbmc on behalf of Bills, Jason M" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of jason.m.bills@linux.intel.com> wrote:
    > 
    >      
    >      
    >      On 10/17/2019 4:52 PM, Vijay Khemka wrote:
    >      >
    >      >
    >      > On 10/17/19, 4:27 PM, "openbmc on behalf of Bills, Jason M" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of jason.m.bills@linux.intel.com> wrote:
    >      >
    >      >
    >      >
    >      >      On 10/17/2019 3:32 PM, Vijay Khemka wrote:
    >      >      >
    >      >      > On 10/17/19, 9:03 AM, "openbmc on behalf of Bills, Jason M" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of jason.m.bills@linux.intel.com> wrote:
    >      >      >
    >      >      >      Hi Vijay
    >      >      >
    >      >      >      On 10/16/2019 6:13 PM, Vijay Khemka wrote:
    >      >      >      > One more question on code, I see following code requires powerButtonMask
    >      >      >      > to be set before aquiring GPIO line. Please let me know who sets this
    >      >      >      > powerButtonMask to true. I know this is related to GPIO passthrough but
    >      >      >      > still couldn’t understand where in code it gets set until someone call
    >      >      >      > set-property of dbus.
    >      >      >
    >      >      >      powerButtonMask is a gpiod::line object that returns true if it
    >      >      >      references a GPIO line and false otherwise.
    >      >      >
    >      >      > I understood code but my point here is there will not be any
    >      >      > gpiod::line object if powerButtonMask is defined as false. And
    >      >      > initially it is defined as false means tehre will not be any line
    >      >      > object created until someone sets it to true. And I don't see it
    >      >      > any way to set it true other than set-property through dbus.
    >      >
    >      >      That's correct.  Masking the power button is something that is done by
    >      >      some component outside of power-control.
    >      >
    >      >      For example, we currently use it with the Set Front Panel Button Enables
    >      >      IPMI command to enable/disable the power button.  So, it is only masked
    >      >      when requested.
    >      > So to use x-86-power-control, either we need to have IPMI command to enable
    >      > this or some other daemon has to set this property. Can we have this feature
    >      > optional. I guess this is a prt og GPIO passthrough.
    >      
    >      Yes, this is part of GPIO passthrough.  When the GPIO is requested,
    >      passthrough is disabled in the pinctrl driver.  So, to mask the power
    >      button (disable passthrough), power-control requests and holds the
    >      "POWER_OUT" GPIO line.
    >      
    >      It should behave normally without this property ever getting set.
    >      
    >      >
    >      >      The actual "POWER_OUT" line for power-control is not permanently
    >      >      created, but is asserted using temporary calls like this one:
    >      >      setGPIOOutputForMs("POWER_OUT", 0, powerPulseTimeMs);
    >      >
    >      > This function will not run power on/off sequence until button mask is set. It
    >      > Will only set GPIO value which is not enough for powering on/off.
    >      
    >      Something else is going on, here.  The powerButtonMask is a separate
    >      feature from driving the "POWER_OUT" pin.  If powerButtonMask is not
    >      set, then the power on/off should function normally.  There is a special
    >      case in the setGPIOOutputForMs() code to handle when "POWER_OUT" is
    >      driven while powerButtonMask is true:
    >      
    >           // If the requested GPIO is masked, use the mask line to set the output
    >           if (powerButtonMask && name == "POWER_OUT")
    >           {
    >               return setMaskedGPIOOutputForMs(powerButtonMask, name, value,
    >                                               durationMs);
    >           }
    >           ...
    >           // No mask set, so request and set the GPIO normally
    >      
    >      So, "POWER_OUT" should work either way, but the default behavior is to
    >      function without powerButtonMask set.  Are you seeing failures on your
    >      platform when powerButtonMask is false?
    > 
    > No, It is not working because it simplpy sets power_out to '0'. But to power on
    > it should got down as 0 and come back to 1 after a delay. Which happens only
    > in case of powerButtonMask set to true. I guess we may need to fix this.
    
    Ahh, okay.  I think I see the issue now.
    
    The issue is that because releasing the GPIO on a system with 
    pass-through, sets the power button back to the hardware default 
    automatically, the software setting doesn't matter, so it is left at 0.
    
    If you don't need to keep holding the GPIO line for POWER_OUT, I think 
    you can just add the code to revert the POWER_OUT value when the timer 
    expires.
    
    Take this line:
                 // Set the masked GPIO line back to the opposite value
                 maskedGPIOLine.set_value(!value);
     From here: 
    https://github.com/openbmc/x86-power-control/blob/master/power-control-x86/src/power_control.cpp#L891
    
    And add it here: 
    https://github.com/openbmc/x86-power-control/blob/master/power-control-x86/src/power_control.cpp#L932

I already did that as a work around, testing different scenario. Will send patch once I see it working.

I also want to make these timeout values as configurable, either I can add these as a property in dbus interface or 
Entity-manager or have a separate config json file. What would you prefer.

    
    >      
    > 
    


  reply	other threads:[~2019-10-22  1:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17  1:13 x86-power-control Vijay Khemka
2019-10-17  9:56 ` x86-power-control Michael Richardson
2019-10-17 13:38   ` x86-power-control Oskar Senft
2019-10-17 16:02     ` x86-power-control Bills, Jason M
2019-10-17 17:21       ` x86-power-control Oskar Senft
2019-10-17 19:05         ` x86-power-control Bills, Jason M
2019-10-17 22:13     ` x86-power-control Vijay Khemka
2019-10-17 22:08   ` x86-power-control Vijay Khemka
2019-10-18  6:43     ` x86-power-control Michael Richardson
2019-10-17 16:01 ` x86-power-control Bills, Jason M
2019-10-17 22:32   ` x86-power-control Vijay Khemka
2019-10-17 23:25     ` x86-power-control Bills, Jason M
2019-10-17 23:52       ` x86-power-control Vijay Khemka
2019-10-18 18:00         ` x86-power-control Bills, Jason M
2019-10-18 23:04           ` x86-power-control Vijay Khemka
2019-10-21 23:03             ` x86-power-control Bills, Jason M
2019-10-22  1:15               ` Vijay Khemka [this message]
2019-10-22 17:14                 ` x86-power-control Bills, Jason M
2019-10-22 17:46                   ` x86-power-control Vijay Khemka
2019-10-22 17:56                     ` x86-power-control James Feist
2019-10-22 18:04                       ` x86-power-control Johnathan Mantey
2019-10-22 19:06                         ` x86-power-control Johnathan Mantey
2019-10-22 19:12                           ` x86-power-control James Feist
2019-10-23 16:35                         ` x86-power-control Vijay Khemka
2019-11-02  0:33 x86-power-control Vijay Khemka
2019-11-04 19:52 ` x86-power-control Bills, Jason M
2019-11-05  0:33   ` x86-power-control Vijay Khemka

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=6DA89556-AD25-4BEE-AF40-9D7A129B7CB9@fb.com \
    --to=vijaykhemka@fb.com \
    --cc=jason.m.bills@linux.intel.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.