Re: Low Latency Tolerance preventing Intel Package from entering deep sleep states

[Adrian Hunter <adrian.hunter@intel.com>]

+ Ben Chuang <ben.chuang@genesyslogic.com.tw>

It does not look like that driver allows runtime pm.


On 22/05/20 7:16 pm, larsh@apache.org wrote:
> Relevant logs:
> 
> May 21 23:05:31 host kernel: sdhci-pci 0000:53:00.0: SDHCI controller found [17a0:9755] (rev 0)
> May 21 23:05:31 host kernel: sdhci-pci 0000:53:00.0: enabling device (0000 -> 0002)
> May 21 23:05:31 host kernel: mmc0: SDHCI controller on PCI [0000:53:00.0] using ADMA 64-bit
> 
> 
> 
> On Friday, May 22, 2020, 1:59:08 AM PDT, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: 
> 
> 
> 
> 
> 
> +Cc: Adrian
> 
> On Fri, May 22, 2020 at 9:15 AM larsh@apache.org <larsh@apache.org> wrote:
>>
>> 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
> 
>>
> 
>