openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Andrew Jeffery" <andrew@aj.id.au>
To: "Chris Chen (TPI)" <Chris.Chen3@flex.com>,
	"Bills, Jason M" <jason.m.bills@linux.intel.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: [x86-power-control]: press the power button for a long time that can't force turn off system power
Date: Tue, 17 Aug 2021 11:27:31 +0930	[thread overview]
Message-ID: <aef11e4c-0b18-47a3-8116-36db990b998c@www.fastmail.com> (raw)
In-Reply-To: <DM6PR08MB551444C4EAB80473CB576740DCFD9@DM6PR08MB5514.namprd08.prod.outlook.com>

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

  reply	other threads:[~2021-08-17  1:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 10:28 [x86-power-control]: press the power button for a long time that can't force turn off system power Chris Chen (TPI)
2021-07-23 20:36 ` Bills, Jason M
2021-07-24  3:04   ` 回覆: " Chris Chen (TPI)
2021-07-26 16:46     ` Bills, Jason M
2021-08-16  3:52       ` Chris Chen (TPI)
2021-08-16  6:30         ` Andrew Jeffery
2021-08-16 10:45           ` 回覆: " Chris Chen (TPI)
2021-08-17  1:57             ` Andrew Jeffery [this message]
2021-08-17 11:17               ` Chris Chen (TPI)
2021-08-17 11:30                 ` Andrew Jeffery
2021-08-17 19:04                   ` Bills, Jason M
2021-08-18 11:07                     ` 回覆: " Chris Chen (TPI)

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=aef11e4c-0b18-47a3-8116-36db990b998c@www.fastmail.com \
    --to=andrew@aj.id.au \
    --cc=Chris.Chen3@flex.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).