[x86-power-control]: press the power button for a long time that can't force turn off system power

[Chris Chen (TPI)]

Hi Andrew,

That means I'm able to choose one of following 2 options to achieve pass-through behavior when I using x86-power-control package, is my understanding correct?

1. Add code to re-enable GPIOP0 and GPIOP1 into a pass-through function after they are requested as a GPIO function in the x86-power-control package. (Or maybe to create a script with "devmem > 0x1e6e24BC 32 0x0F000000" command that will be run automatically after system up to change register directly.)

2. Modify pinctrl in Kernel that will not disable GPIOP0 and GPIOP1's pass-through function if they already are configured as a pass-through when they are requesting as a GPIO function.


Regards,
Chris Chen

-----Original Message-----
From: Andrew Jeffery <andrew at aj.id.au> 
Sent: Tuesday, August 17, 2021 9:58 AM
To: Chris Chen (TPI) <Chris.Chen3 at flex.com>; Bills, Jason M <jason.m.bills at linux.intel.com>; openbmc at lists.ozlabs.org
Subject: Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

On Mon, 16 Aug 2021, at 20:15, Chris Chen (TPI) wrote:
>  Hi Andrew,
> 
> Thanks for your hint (CONFIG_DEBUG_PINCTRL=y) that let me see where 
> the passthrough setting was disabled.
> ======
> [   11.631044] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: request pin 
> 120 (AB22) for 1e780000.gpio:120 
> [   11.631064] Muxing pin 120 for GPIO
> [   11.631071] Disabling signal PWM8 for PWM8
> [   11.631087] Want SCU41C[0x01000000]=0x1, got 0x0 from 0x000000C0
> [   11.631094] Disabling signal THRUIN0 for THRU0
> [   11.631102] Want SCU4BC[0x01000000]=0x1, got 0x1 from 0x0F000000
> [   11.631118] Want SCU4BC[0x01000000]=0x0, got 0x0 from 0x0E000000
> [   11.631124] Enabling signal GPIOP0 for GPIOP0
> ======
> 
> But something strange is the logs seems from "x86-power-control" 
> package because it would not appear after I commented out partial code 
> as below in the package.
> Could you or others tell me why, please? I mean did I miss any 
> configurations or code changes or anything when using the 
> "x86-power-control" package?
> 
> #if 0 //Added by Chris for testing 
>     // Request POWER_BUTTON GPIO events
>     if (!powerButtonName.empty())
>     {
>         if (!requestGPIOEvents(powerButtonName, powerButtonHandler,
>                                powerButtonLine, powerButtonEvent))
>         {
>             return -1;
>         }
>     }
>     else
>     {
>         phosphor::logging::log<phosphor::logging::level::ERR>(
>             "powerButton name should be configured from json config file");
>         return -1;
>     }
> #endif //Added by Chris for testing

Requesting the pin as GPIO removes the pass-through mux configuration.

If you want the pass-through behaviour when you obtain the pin as a GPIO then you need to also do that in software by requesting the GPIOP1 pin and setting it to the state of the GPIOP0 pin when GPIOP0 changes.

This is a limitation of the kernel, though I'm open to ideas on how to avoid it.

Separately, I encourage you to encourage the author of the kernel patch that added pass-through support to send their changes upstream.

> 
> Another, last time I forgot to say that I have tried to use "devmem 
> 0x1e6e24BC 32 0x0F000000" to set passthrough back manually and the 
> power button works fine. This is why I think the passthrough was gone 
> after the system booting up.

I think it's possible to sense the input pin state even in the pass-through configuration, but at the point where you request the GPIO via pinctrl we've lost the intent of the request and the mux configuration mustn't assume any particular mode of use. As such it disables the pass-through mode and puts GPIOP0 in regular GPIO mode.

> Legal Disclaimer :
> The information contained in this message may be privileged and 
> confidential.
> It is intended to be read only by the individual or entity to whom it 
> is addressed or by their designee. If the reader of this message is 
> not the intended recipient, you are on notice that any distribution of 
> this message, in any form, is strictly prohibited. If you have 
> received this message in error, please immediately notify the sender 
> and delete or destroy any copy of this message!

On a separate note, please don't include these disclaimers on mail sent to the mailing list.

Andrew