Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: "larsh@apache.org" <larsh@apache.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	"David E. Box" <david.e.box@linux.intel.com>
Cc: "ibm-acpi-devel@lists.sourceforge.net" 
	<ibm-acpi-devel@lists.sourceforge.net>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: Low Latency Tolerance preventing Intel Package from entering deep sleep states
Date: Fri, 22 May 2020 06:14:59 +0000 (UTC)
Message-ID: <193598853.2172716.1590128099214@mail.yahoo.com> (raw)
In-Reply-To: <d0022af356cf9bd5b544187d9a396734d85a76b3.camel@linux.intel.com>

Thanks David!

With this I tracked down the SD Card Reader (Genesys Logic, Inc Device 9755) as the culprit.
These are standard in many ThinkPads.
The curious part is that resume from suspend (S3 or S0iX) also fixes the problem.
Looks like the driver is not initializing correctly at boot time.

Transcript:

$ cat /sys/kernel/debug/pmc_core/ltr_show | grep SOUTHPORT
SOUTHPORT_A                             LTR: RAW: 0x88018c01            Non-Snoop(ns): 1024             Snoop(ns): 32768           
SOUTHPORT_B                             LTR: RAW: 0x0                   Non-Snoop(ns): 0                Snoop(ns): 0               
SOUTHPORT_C                             LTR: RAW: 0x9f409f4             Non-Snoop(ns): 0                Snoop(ns): 0               
SOUTHPORT_D                             LTR: RAW: 0x88aa88aa            Non-Snoop(ns): 174080           Snoop(ns): 174080          
SOUTHPORT_E                             LTR: RAW: 0x0                   Non-Snoop(ns): 0                Snoop(ns): 0               

$ lspci -t
-[0000:00]-+-00.0
           +-01.0-[01]--+-00.0
           |            \-00.1
           +-02.0
           +-04.0
           +-08.0
           +-12.0
           +-14.0
           +-14.2
           +-15.0
           +-16.0
           +-1c.0-[53]----00.0
           +-1d.0-[02]----00.0
           +-1d.6-[52]----00.0
           +-1e.0
           +-1f.0
           +-1f.3
           +-1f.4
           +-1f.5
           \-1f.6

$ lspci | grep 53
53:00.0 SD Host controller: Genesys Logic, Inc Device 9755

$ cat /sys/bus/pci/devices/0000\:53\:00.0/power/control
auto

$ echo 1 > /sys/bus/pci/devices/0000\:53\:00.0/remove
1

$ cat /sys/kernel/debug/pmc_core/ltr_show | grep SOUTHPORT
SOUTHPORT_A                             LTR: RAW: 0x8010c01             Non-Snoop(ns): 0                Snoop(ns): 0               
SOUTHPORT_B                             LTR: RAW: 0x0                   Non-Snoop(ns): 0                Snoop(ns): 0               
SOUTHPORT_C                             LTR: RAW: 0x9f409f4             Non-Snoop(ns): 0                Snoop(ns): 0               
SOUTHPORT_D                             LTR: RAW: 0x8c548c54            Non-Snoop(ns): 2752512          Snoop(ns): 2752512         
SOUTHPORT_E                             LTR: RAW: 0x0                   Non-Snoop(ns): 0                Snoop(ns): 0               

Cheers.

-- Lars








On Tuesday, May 19, 2020, 9:03:53 AM PDT, David E. Box <david.e.box@linux.intel.com> wrote: 





> > > Does anybody know what's going on or how to debug this further?
> > > As stated above, I was able to work around this problem by
> > > ignoring SOUTHPORT_A via /sys/kernel/debug/pmc_core/ltr_ignore.
> > > There has to be a better way, and I'm sure I'm not the only one
> > > running into this.

ltr_show shows the PMC's (Power Management Controller) view of SoC
devices and busses. The SOUTHPORTs are the PCIe root ports on your
system. When you run lspci they are the PCI bridges. Generally, the
bridges are enumerated in the same order as the SOUTHPORTs, so
SOUTHPORT_A is your first bridge and the device attached to it (shown
in lspci -t) is the device that was blocking deeper PC states according
to your debug.

Determine what this device is on your system. If the ltr was low it's
because that is what the device requested. You should first check that
runtime pm is enabled for the device. To do this, check the control
file in /sys/bus/pci/devices/<SSSS:BB:DD.F>/power, where SSSS:BB:DD.F
is the enumeration of your device as shown in lspci. If it is 'on' then
runtime pm is disabled. To enable it echo 'auto' into the file with
root privileges. Enabling runtime pm should allow the driver to reduce
functionality of the device when idle. This should lead to a larger
latency request on the PCI bus which should be reflected in ltr_show.
You can see if the device is actually runtime suspended and how much
time it's been suspended (or active) by reading the associated files in
the power folder.

If this doesn't work, then it's possible that your device doesn't
support runtime pm. This may be purposely for reliability reasons or
the driver may just lack support. Check forums discussing issues with
the device and look for possible options in the driver to force pm
support (generally this will be centered around enabling ASPM).

You can also download powertop to see the package c-state residencies
more clearly as percentages of time. powertop also has a tunables tab
that will show the status of runtime pm on all devices on the system
and allow you to enable them individually.


David


  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1505028180.591737.1589564161284.ref@mail.yahoo.com>
     [not found] ` <1505028180.591737.1589564161284@mail.yahoo.com>
2020-05-15 21:41   ` Andy Shevchenko
2020-05-18 10:26     ` Rafael J. Wysocki
2020-05-19 16:03       ` David E. Box
2020-05-22  6:14         ` larsh [this message]
2020-05-22  8:58           ` Andy Shevchenko
2020-05-22 16:16             ` larsh
2020-05-25  5:37               ` Adrian Hunter

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=193598853.2172716.1590128099214@mail.yahoo.com \
    --to=larsh@apache.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=david.e.box@linux.intel.com \
    --cc=ibm-acpi-devel@lists.sourceforge.net \
    --cc=linux-acpi@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /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

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git