* x86-power-control
@ 2019-10-17 1:13 Vijay Khemka
2019-10-17 9:56 ` x86-power-control Michael Richardson
2019-10-17 16:01 ` x86-power-control Bills, Jason M
0 siblings, 2 replies; 27+ messages in thread
From: Vijay Khemka @ 2019-10-17 1:13 UTC (permalink / raw)
To: ed.tanous, James Feist, Amithash Prasad; +Cc: Sai Dasari, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]
Hi Ed,
I am trying to use x86-power-control and see there are lots of hard coded values which needs to be configurable as per platform.
1. Name of GPIO line, this should be configurable and should also support GPIO number if user doesn’t want to define line name in DTS.
2. All delay time as it varies for us per platform like powerPulseTimeMs is 1 sec instead of 200 ms and powerPulseTimeMs is 6 sec instead of 15 sec and these varies for different FB platforms.
3. GPIO lines to be monitored, not everyone needs SIO_S5 monitoring or NMI_OUT etc.
4. Enable/disable passthrough
Please suggest what is the best way to make these changes. I am ready to work on this to make required change. We can have these config option defined in entity manager or we can accept a new json file for this configuration.
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.
power_control::powerButtonIface->register_property(
"ButtonMasked", false, [](const bool requested, bool& current) {
if (requested)
{
if (power_control::powerButtonMask)
{
return 1;
}
if (!power_control::setGPIOOutput(
"POWER_OUT", 1, power_control::powerButtonMask))
{
throw std::runtime_error("Failed to request GPIO");
return 0;
}
std::cerr << "Power Button Masked.\n";
}
else
{
if (!power_control::powerButtonMask)
{
return 1;
}
std::cerr << "Power Button Un-masked\n";
power_control::powerButtonMask.reset();
}
Regards
-Vijay
[-- Attachment #2: Type: text/html, Size: 11453 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: x86-power-control 2019-10-17 1:13 x86-power-control Vijay Khemka @ 2019-10-17 9:56 ` Michael Richardson 2019-10-17 13:38 ` x86-power-control Oskar Senft 2019-10-17 22:08 ` x86-power-control Vijay Khemka 2019-10-17 16:01 ` x86-power-control Bills, Jason M 1 sibling, 2 replies; 27+ messages in thread From: Michael Richardson @ 2019-10-17 9:56 UTC (permalink / raw) To: OpenBMC Maillist [-- Attachment #1: Type: text/plain, Size: 1429 bytes --] Vijay Khemka <vijaykhemka@fb.com> wrote: > 1. Name of GPIO line, this should be configurable and should also > support GPIO number if user doesn’t want to define line name in DTS. Why in a target system wouldn't naming it in DTS be the most reliable and most easily accessible mechanism? I can see that in development being able to define things helps, but it is not like the production systems would have wire-wrap where the GPIO pin might change. > 2. All delay time as it varies for us per platform like > powerPulseTimeMs is 1 sec instead of 200 ms and powerPulseTimeMs is 6 > sec instead of 15 sec and these varies for different FB platforms. > 3. GPIO lines to be monitored, not everyone needs SIO_S5 monitoring or NMI_OUT etc. > 4. Enable/disable passthrough > Please suggest what is the best way to make these changes. I am ready > to work on this to make required change. We can have these config > option defined in entity manager or we can accept a new json file for > this configuration. I take it that this isn't a configuration that should be visible to operators, just to integrators. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 9:56 ` x86-power-control Michael Richardson @ 2019-10-17 13:38 ` Oskar Senft 2019-10-17 16:02 ` 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 1 sibling, 2 replies; 27+ messages in thread From: Oskar Senft @ 2019-10-17 13:38 UTC (permalink / raw) To: Michael Richardson; +Cc: OpenBMC Maillist [-- Attachment #1: Type: text/plain, Size: 854 bytes --] Hi Michael Why in a target system wouldn't naming it in DTS be the most reliable and > most easily accessible mechanism? I can see that in development being > able to define > things helps, but it is not like the production systems would have > wire-wrap > where the GPIO pin might change. > I totally agree. I was actually experimenting on our platform (TYAN S7106) to name GPIO pins in the DTS, but I couldn't figure out how to read those names from userspace. Here's what I tried in the DTS: &gpio { pin_gpio_d2 { gpios = <ASPEED_GPIO(D, 2) GPIO_ACTIVE_HIGH>; input; line-name = "SYS_PWROK_BUF"; }; ... However, from what I can tell line-name is actually only relevant when used together with "gpiohog", which is not what we want. Did you manage to make this work? Thanks Oskar. [-- Attachment #2: Type: text/html, Size: 1670 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 13:38 ` x86-power-control Oskar Senft @ 2019-10-17 16:02 ` Bills, Jason M 2019-10-17 17:21 ` x86-power-control Oskar Senft 2019-10-17 22:13 ` x86-power-control Vijay Khemka 1 sibling, 1 reply; 27+ messages in thread From: Bills, Jason M @ 2019-10-17 16:02 UTC (permalink / raw) To: Oskar Senft, Michael Richardson; +Cc: OpenBMC Maillist On 10/17/2019 6:38 AM, Oskar Senft wrote: > Hi Michael > > Why in a target system wouldn't naming it in DTS be the most > reliable and > most easily accessible mechanism? I can see that in development > being able to define > things helps, but it is not like the production systems would have > wire-wrap > where the GPIO pin might change. > > > I totally agree. I was actually experimenting on our platform (TYAN > S7106) to name GPIO pins in the DTS, but I couldn't figure out how to > read those names from userspace. > > Here's what I tried in the DTS: > > &gpio { > pin_gpio_d2 { > gpios = <ASPEED_GPIO(D, 2) GPIO_ACTIVE_HIGH>; > input; > line-name = "SYS_PWROK_BUF"; > }; > ... > > However, from what I can tell line-name is actually only relevant when > used together with "gpiohog", which is not what we want. > > Did you manage to make this work? In our DTS we use gpio-line-names to name all of the GPIOs in one block: &gpio { status = "okay"; gpio-line-names = /*A0-A7*/ "","","","","","","","", /*B0-B7*/ "","","","","","","","", /*C0-C7*/ "","","","","","","","", /*D0-D7*/ "","","","","","","","", /*E0-E7*/ "RESET_BUTTON","RESET_OUT","POWER_BUTTON","POWER_OUT","","","","", /*F0-F7*/ "NMI_OUT","","","","CPU_ERR0","CPU_ERR1","","", /*G0-G7*/ "CPU_ERR2","CPU_CATERR","PCH_BMC_THERMTRIP","","","","","", /*H0-H7*/ "","","","","","","","", /*I0-I7*/ "","","","","","","","", /*J0-J7*/ "","","","","","","","", /*K0-K7*/ "","","","","","","","", /*L0-L7*/ "","","","","","","","", /*M0-M7*/ "","","","","","","","", /*N0-N7*/ "","","","","","","","", /*O0-O7*/ "","","","","","","","", /*P0-P7*/ "","","","","","","","", /*Q0-Q7*/ "","","","","","","","", /*R0-R7*/ "","","","","","","","", /*S0-S7*/ "","","","","","","","", /*T0-T7*/ "","","","","","","","", /*U0-U7*/ "","","","","","","","", /*V0-V7*/ "","","","","","","","", /*W0-W7*/ "","","","","","","","", /*X0-X7*/ "","","","","","","","", /*Y0-Y7*/ "SIO_S3","SIO_S5","","SIO_ONCONTROL","","","","", /*Z0-Z7*/ "","SIO_POWER_GOOD","","","","","","", /*AA0-AA7*/ "P3VBAT_BRIDGE_EN","","","","","","SMI","POST_COMPLETE", /*AB0-AB7*/ "","NMI_BUTTON","ID_BUTTON","PS_PWROK","","","","", /*AC0-AC7*/ "","","","","","","",""; }; https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-ast2500/recipes-kernel/linux/linux-aspeed/0001-arm-dts-add-DTS-for-Intel-platforms.patch#L144 Then, in user space, libgpiod has a gpiod::find_line() function that takes the GPIO name and returns a gpiod::line object that can request various functions from the GPIO. Here is an example of requesting GPIO edge events in x86-power-control: https://github.com/openbmc/x86-power-control/blob/master/power-control-x86/src/power_control.cpp#L805 > > Thanks > Oskar. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 16:02 ` x86-power-control Bills, Jason M @ 2019-10-17 17:21 ` Oskar Senft 2019-10-17 19:05 ` x86-power-control Bills, Jason M 0 siblings, 1 reply; 27+ messages in thread From: Oskar Senft @ 2019-10-17 17:21 UTC (permalink / raw) To: Bills, Jason M; +Cc: Michael Richardson, OpenBMC Maillist [-- Attachment #1: Type: text/plain, Size: 714 bytes --] Hi Jason > In our DTS we use gpio-line-names to name all of the GPIOs in one block: > > &gpio { > status = "okay"; > gpio-line-names = > [...] > /*D0-D7*/ "","","","","","","","", > /*E0-E7*/ > "RESET_BUTTON","RESET_OUT","POWER_BUTTON","POWER_OUT","","","","", > /*F0-F7*/ "NMI_OUT","","","","CPU_ERR0","CPU_ERR1","","", > /*G0-G7*/ > "CPU_ERR2","CPU_CATERR","PCH_BMC_THERMTRIP","","","","","", > Ugh, ok - that's a nice trick. But it's also a little messy :-/ Is that the "officially recommended" way? I guess, since the other option I tried doesn't work!. Is that purely used for naming lines, or does it have any semantic impact? Thanks Oskar. [-- Attachment #2: Type: text/html, Size: 1450 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 17:21 ` x86-power-control Oskar Senft @ 2019-10-17 19:05 ` Bills, Jason M 0 siblings, 0 replies; 27+ messages in thread From: Bills, Jason M @ 2019-10-17 19:05 UTC (permalink / raw) To: openbmc Hi Oskar, On 10/17/2019 10:21 AM, Oskar Senft wrote: > Hi Jason > > > In our DTS we use gpio-line-names to name all of the GPIOs in one block: > > &gpio { > status = "okay"; > gpio-line-names = > [...] > /*D0-D7*/ "","","","","","","","", > /*E0-E7*/ > "RESET_BUTTON","RESET_OUT","POWER_BUTTON","POWER_OUT","","","","", > /*F0-F7*/ "NMI_OUT","","","","CPU_ERR0","CPU_ERR1","","", > /*G0-G7*/ > "CPU_ERR2","CPU_CATERR","PCH_BMC_THERMTRIP","","","","","", > > > Ugh, ok - that's a nice trick. But it's also a little messy :-/ Is that > the "officially recommended" way? I guess, since the other option I > tried doesn't work!. I'm not completely sure. I remember seeing this approach as an example when studying up on libgpiod and a quick search showed this approach used for other DTS files such as for Raspberry Pi (https://github.com/raspberrypi/linux/blob/e33ef2c4cd5dc96aa05a7d328eff61c183c94748/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts#L37). So, if not "officially recommended" it's at least not unheard of. :) > > Is that purely used for naming lines, or does it have any semantic impact? As far as I know, this is purely used for naming lines for libpiod and associated tools such as 'gpioinfo'. You can still find and access GPIO lines by chip and line number. > > Thanks > Oskar. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 13:38 ` x86-power-control Oskar Senft 2019-10-17 16:02 ` x86-power-control Bills, Jason M @ 2019-10-17 22:13 ` Vijay Khemka 1 sibling, 0 replies; 27+ messages in thread From: Vijay Khemka @ 2019-10-17 22:13 UTC (permalink / raw) To: Oskar Senft, Michael Richardson; +Cc: OpenBMC Maillist [-- Attachment #1: Type: text/plain, Size: 1300 bytes --] From: openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> on behalf of Oskar Senft <osk@google.com> Date: Thursday, October 17, 2019 at 6:39 AM To: Michael Richardson <mcr@sandelman.ca> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org> Subject: Re: x86-power-control Hi Michael Why in a target system wouldn't naming it in DTS be the most reliable and most easily accessible mechanism? I can see that in development being able to define things helps, but it is not like the production systems would have wire-wrap where the GPIO pin might change. I totally agree. I was actually experimenting on our platform (TYAN S7106) to name GPIO pins in the DTS, but I couldn't figure out how to read those names from userspace. Here's what I tried in the DTS: &gpio { pin_gpio_d2 { gpios = <ASPEED_GPIO(D, 2) GPIO_ACTIVE_HIGH>; input; line-name = "SYS_PWROK_BUF"; }; ... Another thing here, I want to be able to map actual name defined in DTS to real name used in Power-control. However, from what I can tell line-name is actually only relevant when used together with "gpiohog", which is not what we want. It is mainly used via libgpiod. Did you manage to make this work? Thanks Oskar. [-- Attachment #2: Type: text/html, Size: 5161 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 9:56 ` x86-power-control Michael Richardson 2019-10-17 13:38 ` x86-power-control Oskar Senft @ 2019-10-17 22:08 ` Vijay Khemka 2019-10-18 6:43 ` x86-power-control Michael Richardson 1 sibling, 1 reply; 27+ messages in thread From: Vijay Khemka @ 2019-10-17 22:08 UTC (permalink / raw) To: Michael Richardson, OpenBMC Maillist On 10/17/19, 2:57 AM, "openbmc on behalf of Michael Richardson" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of mcr@sandelman.ca> wrote: Vijay Khemka <vijaykhemka@fb.com> wrote: > 1. Name of GPIO line, this should be configurable and should also > support GPIO number if user doesn’t want to define line name in DTS. Why in a target system wouldn't naming it in DTS be the most reliable and most easily accessible mechanism? I can see that in development being able to define things helps, but it is not like the production systems would have wire-wrap where the GPIO pin might change. I am not ruling out DTS definition but keeping that as optional. Many platform doesn't want to change kernel and want to keep dts minimal as well common across multiple platform. So providing this option will help developer. > 2. All delay time as it varies for us per platform like > powerPulseTimeMs is 1 sec instead of 200 ms and powerPulseTimeMs is 6 > sec instead of 15 sec and these varies for different FB platforms. > 3. GPIO lines to be monitored, not everyone needs SIO_S5 monitoring or NMI_OUT etc. > 4. Enable/disable passthrough > Please suggest what is the best way to make these changes. I am ready > to work on this to make required change. We can have these config > option defined in entity manager or we can accept a new json file for > this configuration. I take it that this isn't a configuration that should be visible to operators, just to integrators. Yes, you are right. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 22:08 ` x86-power-control Vijay Khemka @ 2019-10-18 6:43 ` Michael Richardson 0 siblings, 0 replies; 27+ messages in thread From: Michael Richardson @ 2019-10-18 6:43 UTC (permalink / raw) To: Vijay Khemka; +Cc: OpenBMC Maillist [-- Attachment #1: Type: text/plain, Size: 1230 bytes --] Vijay Khemka <vijaykhemka@fb.com> wrote: mcr> Why in a target system wouldn't naming it in DTS be the most mcr> reliable and most easily accessible mechanism? I can see that in mcr> development being able to define things helps, but it is not like the mcr> production systems would have wire-wrap where the GPIO pin might mcr> change. > I am not ruling out DTS definition but keeping that as optional. Many > platform doesn't want to change kernel and want to keep dts minimal as > well common across multiple platform. So providing this option will > help developer. My experience is that the DTS file is loaded separately from the kernel. I haven't had a chance to learn how things are booted in practice, since I haven't gotten real hardware yet. I would think that the DTS file may be the easiest thing for a VAR to update compared to editing a configuration file that is embedded in the file system image. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 1:13 x86-power-control Vijay Khemka 2019-10-17 9:56 ` x86-power-control Michael Richardson @ 2019-10-17 16:01 ` Bills, Jason M 2019-10-17 22:32 ` x86-power-control Vijay Khemka 1 sibling, 1 reply; 27+ messages in thread From: Bills, Jason M @ 2019-10-17 16:01 UTC (permalink / raw) To: openbmc 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. > > power_control::powerButtonIface->register_property( > > "ButtonMasked", false, [](constboolrequested, bool& current) { > > if(requested) > > { > > if(power_control::powerButtonMask) > > { This will return if powerButtonMask already references a GPIO. > > return1; > > } > > if(!power_control::setGPIOOutput( > > "POWER_OUT", 1, power_control::powerButtonMask)) Otherwise, this will request the "POWER_OUT" GPIO and assign it to powerButtonMask (which will make it return true). > > { > > throwstd::runtime_error("Failed to request GPIO"); > > return0; > > } > > std::cerr << "Power Button Masked.\n"; > > } > > else > > { > > if(!power_control::powerButtonMask) > > { This will return if powerButtonMask does not reference a GPIO line. > > return1; > > } > > std::cerr << "Power Button Un-masked\n"; > > power_control::powerButtonMask.reset(); Otherwise this will reset powerButtonMask to release the "POWER_OUT" GPIO (which will make it return false). > > } > > Regards > > -Vijay > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 16:01 ` x86-power-control Bills, Jason M @ 2019-10-17 22:32 ` Vijay Khemka 2019-10-17 23:25 ` x86-power-control Bills, Jason M 0 siblings, 1 reply; 27+ messages in thread From: Vijay Khemka @ 2019-10-17 22:32 UTC (permalink / raw) To: Bills, Jason M, openbmc 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. > > power_control::powerButtonIface->register_property( > > "ButtonMasked", false, [](constboolrequested, bool& current) { > > if(requested) > > { > > if(power_control::powerButtonMask) > > { This will return if powerButtonMask already references a GPIO. > > return1; > > } > > if(!power_control::setGPIOOutput( > > "POWER_OUT", 1, power_control::powerButtonMask)) Otherwise, this will request the "POWER_OUT" GPIO and assign it to powerButtonMask (which will make it return true). > > { > > throwstd::runtime_error("Failed to request GPIO"); > > return0; > > } > > std::cerr << "Power Button Masked.\n"; > > } > > else > > { > > if(!power_control::powerButtonMask) > > { This will return if powerButtonMask does not reference a GPIO line. > > return1; > > } > > std::cerr << "Power Button Un-masked\n"; > > power_control::powerButtonMask.reset(); Otherwise this will reset powerButtonMask to release the "POWER_OUT" GPIO (which will make it return false). > > } > > Regards > > -Vijay > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 22:32 ` x86-power-control Vijay Khemka @ 2019-10-17 23:25 ` Bills, Jason M 2019-10-17 23:52 ` x86-power-control Vijay Khemka 0 siblings, 1 reply; 27+ messages in thread From: Bills, Jason M @ 2019-10-17 23:25 UTC (permalink / raw) To: openbmc 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. 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); https://github.com/openbmc/x86-power-control/blob/master/power-control-x86/src/power_control.cpp#L946 > > > > > power_control::powerButtonIface->register_property( > > > > "ButtonMasked", false, [](constboolrequested, bool& current) { > > > > if(requested) > > > > { > > > > if(power_control::powerButtonMask) > > > > { > This will return if powerButtonMask already references a GPIO. > > > > > return1; > > > > } > > > > if(!power_control::setGPIOOutput( > > > > "POWER_OUT", 1, power_control::powerButtonMask)) > Otherwise, this will request the "POWER_OUT" GPIO and assign it to > powerButtonMask (which will make it return true). > > > > > { > > > > throwstd::runtime_error("Failed to request GPIO"); > > > > return0; > > > > } > > > > std::cerr << "Power Button Masked.\n"; > > > > } > > > > else > > > > { > > > > if(!power_control::powerButtonMask) > > > > { > This will return if powerButtonMask does not reference a GPIO line. > > > > > return1; > > > > } > > > > std::cerr << "Power Button Un-masked\n"; > > > > power_control::powerButtonMask.reset(); > Otherwise this will reset powerButtonMask to release the "POWER_OUT" > GPIO (which will make it return false). > > > > > } > > > > Regards > > > > -Vijay > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 23:25 ` x86-power-control Bills, Jason M @ 2019-10-17 23:52 ` Vijay Khemka 2019-10-18 18:00 ` x86-power-control Bills, Jason M 0 siblings, 1 reply; 27+ messages in thread From: Vijay Khemka @ 2019-10-17 23:52 UTC (permalink / raw) To: Bills, Jason M, openbmc 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. 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. https://github.com/openbmc/x86-power-control/blob/master/power-control-x86/src/power_control.cpp#L946 > > > > > power_control::powerButtonIface->register_property( > > > > "ButtonMasked", false, [](constboolrequested, bool& current) { > > > > if(requested) > > > > { > > > > if(power_control::powerButtonMask) > > > > { > This will return if powerButtonMask already references a GPIO. > > > > > return1; > > > > } > > > > if(!power_control::setGPIOOutput( > > > > "POWER_OUT", 1, power_control::powerButtonMask)) > Otherwise, this will request the "POWER_OUT" GPIO and assign it to > powerButtonMask (which will make it return true). > > > > > { > > > > throwstd::runtime_error("Failed to request GPIO"); > > > > return0; > > > > } > > > > std::cerr << "Power Button Masked.\n"; > > > > } > > > > else > > > > { > > > > if(!power_control::powerButtonMask) > > > > { > This will return if powerButtonMask does not reference a GPIO line. > > > > > return1; > > > > } > > > > std::cerr << "Power Button Un-masked\n"; > > > > power_control::powerButtonMask.reset(); > Otherwise this will reset powerButtonMask to release the "POWER_OUT" > GPIO (which will make it return false). > > > > > } > > > > Regards > > > > -Vijay > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-17 23:52 ` x86-power-control Vijay Khemka @ 2019-10-18 18:00 ` Bills, Jason M 2019-10-18 23:04 ` x86-power-control Vijay Khemka 0 siblings, 1 reply; 27+ messages in thread From: Bills, Jason M @ 2019-10-18 18:00 UTC (permalink / raw) To: openbmc 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-18 18:00 ` x86-power-control Bills, Jason M @ 2019-10-18 23:04 ` Vijay Khemka 2019-10-21 23:03 ` x86-power-control Bills, Jason M 0 siblings, 1 reply; 27+ messages in thread From: Vijay Khemka @ 2019-10-18 23:04 UTC (permalink / raw) To: Bills, Jason M, openbmc 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-18 23:04 ` x86-power-control Vijay Khemka @ 2019-10-21 23:03 ` Bills, Jason M 2019-10-22 1:15 ` x86-power-control Vijay Khemka 0 siblings, 1 reply; 27+ messages in thread From: Bills, Jason M @ 2019-10-21 23:03 UTC (permalink / raw) To: Vijay Khemka, openbmc 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 > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-21 23:03 ` x86-power-control Bills, Jason M @ 2019-10-22 1:15 ` Vijay Khemka 2019-10-22 17:14 ` x86-power-control Bills, Jason M 0 siblings, 1 reply; 27+ messages in thread From: Vijay Khemka @ 2019-10-22 1:15 UTC (permalink / raw) To: Bills, Jason M, openbmc 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. > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-22 1:15 ` x86-power-control Vijay Khemka @ 2019-10-22 17:14 ` Bills, Jason M 2019-10-22 17:46 ` x86-power-control Vijay Khemka 0 siblings, 1 reply; 27+ messages in thread From: Bills, Jason M @ 2019-10-22 17:14 UTC (permalink / raw) To: openbmc On 10/21/2019 6:15 PM, Vijay Khemka wrote: > > > 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. Another option that may be simpler is to move the values that you want to configure out to a header file and then override the header in a bbappend. Then you don't need to read or parse any additional configuration information at run time. > > > > > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-22 17:14 ` x86-power-control Bills, Jason M @ 2019-10-22 17:46 ` Vijay Khemka 2019-10-22 17:56 ` x86-power-control James Feist 0 siblings, 1 reply; 27+ messages in thread From: Vijay Khemka @ 2019-10-22 17:46 UTC (permalink / raw) To: Bills, Jason M, openbmc On 10/22/19, 10:16 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/21/2019 6:15 PM, Vijay Khemka wrote: > > > 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. Another option that may be simpler is to move the values that you want to configure out to a header file and then override the header in a bbappend. Then you don't need to read or parse any additional configuration information at run time. I can do that but bbappend for patch is not accepted in any repository. > > > > > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-22 17:46 ` x86-power-control Vijay Khemka @ 2019-10-22 17:56 ` James Feist 2019-10-22 18:04 ` x86-power-control Johnathan Mantey 0 siblings, 1 reply; 27+ messages in thread From: James Feist @ 2019-10-22 17:56 UTC (permalink / raw) To: Vijay Khemka, Bills, Jason M, openbmc On 10/22/19 10:46 AM, Vijay Khemka wrote: > > > On 10/22/19, 10:16 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/21/2019 6:15 PM, Vijay Khemka wrote: > > > > > > 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. > Another option that may be simpler is to move the values that you want > to configure out to a header file and then override the header in a > bbappend. Then you don't need to read or parse any additional > configuration information at run time. > > I can do that but bbappend for patch is not accepted in any repository. Don't patch, simply copy over your new header into the correct directory in a do_configure_prepend (I think that's the right yocto step to overwrite, but I might be off). > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-22 17:56 ` x86-power-control James Feist @ 2019-10-22 18:04 ` Johnathan Mantey 2019-10-22 19:06 ` x86-power-control Johnathan Mantey 2019-10-23 16:35 ` x86-power-control Vijay Khemka 0 siblings, 2 replies; 27+ messages in thread From: Johnathan Mantey @ 2019-10-22 18:04 UTC (permalink / raw) To: James Feist, Vijay Khemka, Bills, Jason M, openbmc [-- Attachment #1.1.1: Type: text/plain, Size: 597 bytes --] You may want to delay the copy until the compile step. For example: PROJECT_SRC_DIR := "${THISDIR}/${PN}" do_compile_prepend(){ cp -f ${PROJECT_SRC_DIR}/your-header.hpp ${S} } > Don't patch, simply copy over your new header into the correct > directory in a do_configure_prepend (I think that's the right yocto > step to overwrite, but I might be off). -- Johnathan Mantey Senior Software Engineer *azad te**chnology partners* Contributing to Technology Innovation since 1992 Phone: (503) 712-6764 Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com> [-- Attachment #1.1.2: Type: text/html, Size: 1560 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-22 18:04 ` x86-power-control Johnathan Mantey @ 2019-10-22 19:06 ` Johnathan Mantey 2019-10-22 19:12 ` x86-power-control James Feist 2019-10-23 16:35 ` x86-power-control Vijay Khemka 1 sibling, 1 reply; 27+ messages in thread From: Johnathan Mantey @ 2019-10-22 19:06 UTC (permalink / raw) To: James Feist, Vijay Khemka, Bills, Jason M, openbmc [-- Attachment #1.1.1: Type: text/plain, Size: 1527 bytes --] One observation about this method. It may not work for the way CI unit tests are presently behaving. For phosphorr-networkd, I think, the unit tests insist that everything being tested be Git committed. The copy of the source file will not be. This will prevent the unit test from running. I found this requirement by the unit tests to be an irritant. I would clang-format my source, and commit. The unit tests would do an automated reformat, causing my commit to be useless. I'd have to recommit the source one more time to proceed. It would be nice to eliminate/modify this requirement in the unit tests. On 10/22/19 11:04 AM, Johnathan Mantey wrote: > You may want to delay the copy until the compile step. For example: > > PROJECT_SRC_DIR := "${THISDIR}/${PN}" > do_compile_prepend(){ > cp -f ${PROJECT_SRC_DIR}/your-header.hpp ${S} > } >> Don't patch, simply copy over your new header into the correct >> directory in a do_configure_prepend (I think that's the right yocto >> step to overwrite, but I might be off). -- > Johnathan Mantey > Senior Software Engineer > *azad te**chnology partners* > Contributing to Technology Innovation since 1992 > Phone: (503) 712-6764 > Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com> > -- Johnathan Mantey Senior Software Engineer *azad te**chnology partners* Contributing to Technology Innovation since 1992 Phone: (503) 712-6764 Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com> [-- Attachment #1.1.2: Type: text/html, Size: 3510 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-22 19:06 ` x86-power-control Johnathan Mantey @ 2019-10-22 19:12 ` James Feist 0 siblings, 0 replies; 27+ messages in thread From: James Feist @ 2019-10-22 19:12 UTC (permalink / raw) To: Johnathan Mantey, Vijay Khemka, Bills, Jason M, openbmc On 10/22/19 12:06 PM, Johnathan Mantey wrote: > One observation about this method. > It may not work for the way CI unit tests are presently behaving. > > For phosphorr-networkd, I think, the unit tests insist that everything > being tested be Git committed. The copy of the source file will not be. > This will prevent the unit test from running. I found this requirement > by the unit tests to be an irritant. I would clang-format my source, and > commit. The unit tests would do an automated reformat, causing my > commit to be useless. I'd have to recommit the source one more time to > proceed. It would be nice to eliminate/modify this requirement in the > unit tests. It should be fine in this case because CI would only be running against the "default" header file, the modified one would not get introduced in the CI path. > > On 10/22/19 11:04 AM, Johnathan Mantey wrote: >> You may want to delay the copy until the compile step. For example: >> >> PROJECT_SRC_DIR := "${THISDIR}/${PN}" >> do_compile_prepend(){ >> cp -f ${PROJECT_SRC_DIR}/your-header.hpp ${S} >> } >>> Don't patch, simply copy over your new header into the correct >>> directory in a do_configure_prepend (I think that's the right yocto >>> step to overwrite, but I might be off). -- >> Johnathan Mantey >> Senior Software Engineer >> *azad te**chnology partners* >> Contributing to Technology Innovation since 1992 >> Phone: (503) 712-6764 >> Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com> >> > > -- > Johnathan Mantey > Senior Software Engineer > *azad te**chnology partners* > Contributing to Technology Innovation since 1992 > Phone: (503) 712-6764 > Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-10-22 18:04 ` x86-power-control Johnathan Mantey 2019-10-22 19:06 ` x86-power-control Johnathan Mantey @ 2019-10-23 16:35 ` Vijay Khemka 1 sibling, 0 replies; 27+ messages in thread From: Vijay Khemka @ 2019-10-23 16:35 UTC (permalink / raw) To: Johnathan Mantey, James Feist, Bills, Jason M, openbmc [-- Attachment #1: Type: text/plain, Size: 932 bytes --] Thanks James, Bill and John. From: Johnathan Mantey <johnathanx.mantey@intel.com> Date: Tuesday, October 22, 2019 at 11:05 AM To: James Feist <james.feist@linux.intel.com>, Vijay Khemka <vijaykhemka@fb.com>, "Bills, Jason M" <jason.m.bills@linux.intel.com>, "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org> Subject: Re: x86-power-control You may want to delay the copy until the compile step. For example: PROJECT_SRC_DIR := "${THISDIR}/${PN}" do_compile_prepend(){ cp -f ${PROJECT_SRC_DIR}/your-header.hpp ${S} } Don't patch, simply copy over your new header into the correct directory in a do_configure_prepend (I think that's the right yocto step to overwrite, but I might be off). -- Johnathan Mantey Senior Software Engineer azad technology partners Contributing to Technology Innovation since 1992 Phone: (503) 712-6764 Email: johnathanx.mantey@intel.com<mailto:johnathanx.mantey@intel.com> [-- Attachment #2: Type: text/html, Size: 4181 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* x86-power-control @ 2019-11-02 0:33 Vijay Khemka 2019-11-04 19:52 ` x86-power-control Bills, Jason M 0 siblings, 1 reply; 27+ messages in thread From: Vijay Khemka @ 2019-11-02 0:33 UTC (permalink / raw) To: jason.m.bills, james.feist; +Cc: openbmc Hi Jason/James, I see some limitation in current x86-power-control as we don’t have NMI_OUT, NMI_BUTTON and ID_BUTTON usage. And I am not sure why these are being used. So if I don’t define these in DTS then this program fails. So Please how to disable these. These should be optional. I have following options to disable these. 1. No returning -1 if we don't find line name, simply move on. I have to see impact on rest of code. 2. Make it compile time flag and should be included through bbappend like -DNMI_OUT etc. 3. Have config Jason file and enable or disable gpio line to be used. Please let us know your thought and how should we approach. I am fine with changing this code and submit patch. Regards -Vijay ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-11-02 0:33 x86-power-control Vijay Khemka @ 2019-11-04 19:52 ` Bills, Jason M 2019-11-05 0:33 ` x86-power-control Vijay Khemka 0 siblings, 1 reply; 27+ messages in thread From: Bills, Jason M @ 2019-11-04 19:52 UTC (permalink / raw) To: openbmc Hi Vijay, On 11/1/2019 5:33 PM, Vijay Khemka wrote: > Hi Jason/James, > I see some limitation in current x86-power-control as we don’t have NMI_OUT, NMI_BUTTON and ID_BUTTON usage. And I am not sure why these are being used. So if I don’t define these in DTS then this program fails. So Please how to disable these. These should be optional. I have following options to disable these. > > 1. No returning -1 if we don't find line name, simply move on. I have to see impact on rest of code. > 2. Make it compile time flag and should be included through bbappend like -DNMI_OUT etc. I chatted with James and I think we like this option the best. If you set a build flag that is enabled by default, it will let you disable the features you don't need in a .bbappend. This will let you remove the pins you don't use and still allow for easier detection when an expected pin isn't working. Thanks, -Jason > 3. Have config Jason file and enable or disable gpio line to be used. > > > Please let us know your thought and how should we approach. I am fine with changing this code and submit patch. > > Regards > -Vijay > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: x86-power-control 2019-11-04 19:52 ` x86-power-control Bills, Jason M @ 2019-11-05 0:33 ` Vijay Khemka 0 siblings, 0 replies; 27+ messages in thread From: Vijay Khemka @ 2019-11-05 0:33 UTC (permalink / raw) To: Bills, Jason M, openbmc On 11/4/19, 11:53 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 11/1/2019 5:33 PM, Vijay Khemka wrote: > Hi Jason/James, > I see some limitation in current x86-power-control as we don’t have NMI_OUT, NMI_BUTTON and ID_BUTTON usage. And I am not sure why these are being used. So if I don’t define these in DTS then this program fails. So Please how to disable these. These should be optional. I have following options to disable these. > > 1. No returning -1 if we don't find line name, simply move on. I have to see impact on rest of code. > 2. Make it compile time flag and should be included through bbappend like -DNMI_OUT etc. I chatted with James and I think we like this option the best. If you set a build flag that is enabled by default, it will let you disable the features you don't need in a .bbappend. This will let you remove the pins you don't use and still allow for easier detection when an expected pin isn't working. Thanks Jason, I will work on patch and send it for review. Thanks, -Jason > 3. Have config Jason file and enable or disable gpio line to be used. > > > Please let us know your thought and how should we approach. I am fine with changing this code and submit patch. > > Regards > -Vijay > ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2019-11-05 0:33 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 ` x86-power-control Vijay Khemka 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
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.