* [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases"
@ 2019-07-31 16:04 Kai-Heng Feng
2019-07-31 16:12 ` Mario.Limonciello
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Kai-Heng Feng @ 2019-07-31 16:04 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mika Westerberg, Mario Limonciello, Anthony Wong, Linux ACPI,
Linux PCI, Linux PM, LKML
Hi,
After commit "ACPI: PM: Allow transitions to D0 to occur in special cases”,
Thunderbolt on XPS 9380 spews the following when it runtime resumes:
[ 36.136554] pci_raw_set_power_state: 25 callbacks suppressed
[ 36.136558] pcieport 0000:03:00.0: Refused to change power state,
currently in D3
[ 36.143850] pcieport 0000:04:04.0: Refused to change power state,
currently in D3
[ 36.150796] pcieport 0000:04:00.0: Refused to change power state,
currently in D3
[ 36.157138] pcieport 0000:04:01.0: Refused to change power state,
currently in D3
[ 36.162635] pcieport 0000:04:02.0: Refused to change power state,
currently in D3
[ 36.166711] pcieport 0000:04:01.0: pciehp: pcie_do_write_cmd: no
response from device
[ 36.166818] pcieport 0000:04:01.0: pciehp: Slot(1): Card present
[ 36.166820] pcieport 0000:04:01.0: pciehp: Slot(1): Link Up
[ 36.167122] pcieport 0000:04:04.0: pciehp: pcie_do_write_cmd: no
response from device
[ 36.167179] pcieport 0000:04:04.0: pciehp: Slot(4): Card present
[ 36.167181] pcieport 0000:04:04.0: pciehp: Slot(4): Link Up
[ 36.196453] usb 1-6: new high-speed USB device number 4 using xhci_hcd
[ 36.436436] usb 1-6: New USB device found, idVendor=058f,
idProduct=6387, bcdDevice= 1.03
[ 36.436438] usb 1-6: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 36.436439] usb 1-6: Product: Mass Storage
[ 36.436441] usb 1-6: Manufacturer: Generic
[ 36.436442] usb 1-6: SerialNumber: 7632C867
[ 37.276751] thunderbolt 0000:05:00.0: Refused to change power state,
currently in D3
[ 37.343078] xhci_hcd 0000:39:00.0: Refused to change power state,
currently in D3
[ 37.407135] ------------[ cut here ]------------
[ 37.407136] thunderbolt 0000:05:00.0: interrupt for TX ring 0 is already
enabled
[ 37.407167] WARNING: CPU: 0 PID: 1830 at drivers/thunderbolt/nhi.c:104
ring_interrupt_active+0x1f6/0x240 [thunderbolt]
[ 37.407167] Modules linked in: rfcomm ccm cmac bnep nls_iso8859_1
snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic dell_laptop
ledtrig_audi
o sof_pci_dev dell_wmi snd_sof_intel_hda_common dell_smbios
snd_sof_intel_byt snd_sof_intel_ipc mei_hdcp snd_sof snd_sof_xtensa_dsp
snd_soc_skl wmi_bmof intel_wmi_thunderbolt dell_wmi_descriptor
snd_soc_hdac_hda snd_hda_ext_cor
e intel_rapl_msr crct10dif_pclmul snd_soc_skl_ipc snd_soc_sst_dsp
snd_soc_sst_ipc snd_soc_core snd_soc_acpi_intel_match snd_soc_acpi
crc32_pclmul ghash_clmulni_intel joydev snd_hda_intel snd_hda_codec
snd_hwdep snd_hda_core snd
_pcm aesni_intel aes_x86_64 glue_helper crypto_simd iwlmvm cryptd mac80211
dcdbas snd_seq i915 libarc4 intel_cstate intel_rapl_perf uvcvideo snd_timer
input_leds btusb snd_seq_device btrtl iwlwifi serio_raw btbcm btintel videob
uf2_vmalloc i2c_algo_bit videobuf2_memops snd bluetooth drm_kms_helper
videobuf2_v4l2
[ 37.407181] videobuf2_common videodev syscopyarea mc sysfillrect
soundcore sysimgblt cfg80211 fb_sys_fops drm rtsx_pci_ms memstick mei_me
ecdh_generic ecc mei hid_multitouch processor_thermal_device idma64
ucsi_acpi intel_p
ch_thermal typec_ucsi intel_soc_dts_iosf virt_dma intel_rapl_common typec
mac_hid wmi video int3403_thermal int3400_thermal int340x_thermal_zone
intel_hid acpi_pad acpi_thermal_rel sparse_keymap sch_fq_codel parport_pc
ppdev lp
parport ip_tables x_tables autofs4 hid_generic rtsx_pci_sdmmc nvme psmouse nvme_core thunderbolt i2c_i801 rtsx_pci intel_lpss_pci i2c_hid intel_lpss hid pinctrl_cannonlake pinctrl_intel
[ 37.407192] CPU: 0 PID: 1830 Comm: kworker/0:4 Not tainted 5.3.0-rc2+ #47
[ 37.407192] Hardware name: Dell Inc. XPS 13 9380/0SSY11, BIOS 1.5.0
06/03/2019
[ 37.407195] Workqueue: pm pm_runtime_work
[ 37.407198] RIP: 0010:ring_interrupt_active+0x1f6/0x240 [thunderbolt]
[ 37.407199] Code: 4c 89 4d c8 44 89 45 d4 e8 c7 cd 73 fd 4c 8b 4d c8 44
8b 45 d4 4c 89 e1 48 89 c6 4c 89 f2 48 c7 c7 20 11 1a c0 e8 35 f0 10 fd
<0f> 0b e9 17 ff ff ff 41 0f b6 47 78 d3 e0 09 c7 e9 d7 fe ff ff 44
[ 37.407199] RSP: 0018:ffffbf8701c1fc70 EFLAGS: 00010082
[ 37.407200] RAX: 0000000000000000 RBX: 00000000ffffffff RCX:
0000000000000006
[ 37.407200] RDX: 0000000000000007 RSI: 0000000000000092 RDI:
ffff9d5264417440
[ 37.407201] RBP: ffffbf8701c1fca8 R08: 000000000000047b R09:
0000000000000004
[ 37.407201] R10: 0000000000000000 R11: 0000000000000001 R12:
ffffffffc01a0641
[ 37.407202] R13: 0000000000038200 R14: ffff9d52620c3d60 R15:
ffff9d525faa1300
[ 37.407202] FS: 0000000000000000(0000) GS:ffff9d5264400000(0000)
knlGS:0000000000000000
[ 37.407203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.407203] CR2: 00007ffe0858de38 CR3: 000000013b20a001 CR4:
00000000003606f0
[ 37.407204] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 37.407204] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 37.407204] Call Trace:
[ 37.407208] tb_ring_start+0xd4/0x1c0 [thunderbolt]
[ 37.407210] tb_ctl_start+0x2d/0xa0 [thunderbolt]
[ 37.407213] tb_domain_runtime_resume+0x1a/0x40 [thunderbolt]
[ 37.407215] nhi_runtime_resume+0x28/0x30 [thunderbolt]
[ 37.407217] pci_pm_runtime_resume+0x75/0xd0
[ 37.407218] ? pci_restore_standard_config+0x50/0x50
[ 37.407218] __rpm_callback+0x8c/0x150
[ 37.407219] ? pci_restore_standard_config+0x50/0x50
[ 37.407220] rpm_callback+0x24/0x80
[ 37.407221] ? pci_restore_standard_config+0x50/0x50
[ 37.407222] rpm_resume+0x568/0x780
[ 37.407223] pm_runtime_work+0x7d/0xa0
[ 37.407225] process_one_work+0x1db/0x380
[ 37.407226] worker_thread+0x4d/0x400
[ 37.407227] kthread+0x104/0x140
[ 37.407228] ? process_one_work+0x380/0x380
[ 37.407229] ? kthread_park+0x80/0x80
[ 37.407231] ret_from_fork+0x1f/0x40
[ 37.407232] ---[ end trace 33a816af30ee403d ]---
[ 37.407251] ------------[ cut here ]------------
[ 37.407252] thunderbolt 0000:05:00.0: interrupt for RX ring 0 is already
enabled
[ 37.407262] WARNING: CPU: 0 PID: 1830 at drivers/thunderbolt/nhi.c:104
ring_interrupt_active+0x1f6/0x240 [thunderbolt]
[ 37.407262] Modules linked in: rfcomm ccm cmac bnep nls_iso8859_1
snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic dell_laptop
ledtrig_audio sof_pci_dev dell_wmi snd_sof_intel_hda_common dell_smbios
snd_sof_intel_byt snd_sof_intel_ipc mei_hdcp snd_sof snd_sof_xtensa_dsp
snd_soc_skl wmi_bmof intel_wmi_thunderbolt dell_wmi_descriptor
snd_soc_hdac_hda snd_hda_ext_core intel_rapl_msr crct10dif_pclmul
snd_soc_skl_ipc snd_soc_sst_dsp snd_soc_sst_ipc snd_soc_core
snd_soc_acpi_intel_match snd_soc_acpi crc32_pclmul ghash_clmulni_intel
joydev snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm
aesni_intel aes_x86_64 glue_helper crypto_simd iwlmvm cryptd mac80211
dcdbas snd_seq i915 libarc4 intel_cstate intel_rapl_perf uvcvideo snd_timer
input_leds btusb snd_seq_device btrtl iwlwifi serio_raw btbcm btintel
videobuf2_vmalloc i2c_algo_bit videobuf2_memops snd bluetooth
drm_kms_helper videobuf2_v4l2
[ 37.407270] videobuf2_common videodev syscopyarea mc sysfillrect
soundcore sysimgblt cfg80211 fb_sys_fops drm rtsx_pci_ms memstick mei_me
ecdh_generic ecc mei hid_multitouch processor_thermal_device idma64
ucsi_acpi intel_pch_thermal typec_ucsi intel_soc_dts_iosf virt_dma
intel_rapl_common typec mac_hid wmi video int3403_thermal int3400_thermal
int340x_thermal_zone intel_hid acpi_pad acpi_thermal_rel sparse_keymap
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4
hid_generic rtsx_pci_sdmmc nvme psmouse nvme_core thunderbolt i2c_i801
rtsx_pci intel_lpss_pci i2c_hid intel_lpss hid pinctrl_cannonlake
pinctrl_intel
[ 37.407277] CPU: 0 PID: 1830 Comm: kworker/0:4 Tainted: G
W 5.3.0-rc2+ #47
[ 37.407278] Hardware name: Dell Inc. XPS 13 9380/0SSY11, BIOS 1.5.0
06/03/2019
[ 37.407279] Workqueue: pm pm_runtime_work
[ 37.407281] RIP: 0010:ring_interrupt_active+0x1f6/0x240 [thunderbolt]
[ 37.407281] Code: 4c 89 4d c8 44 89 45 d4 e8 c7 cd 73 fd 4c 8b 4d c8 44
8b 45 d4 4c 89 e1 48 89 c6 4c 89 f2 48 c7 c7 20 11 1a c0 e8 35 f0 10 fd
<0f> 0b e9 17 ff ff ff 41 0f b6 47 78 d3 e0 09 c7 e9 d7 fe ff ff 44
[ 37.407282] RSP: 0018:ffffbf8701c1fc70 EFLAGS: 00010082
[ 37.407282] RAX: 0000000000000000 RBX: 00000000ffffffff RCX:
0000000000000006
[ 37.407283] RDX: 0000000000000007 RSI: 0000000000000092 RDI:
ffff9d5264417440
[ 37.407283] RBP: ffffbf8701c1fca8 R08: 00000000000004a4 R09:
0000000000000004
[ 37.407284] R10: 0000000000000000 R11: 0000000000000001 R12:
ffffffffc01a0649
[ 37.407284] R13: 0000000000038200 R14: ffff9d52620c3d60 R15:
ffff9d525faa1000
[ 37.407284] FS: 0000000000000000(0000) GS:ffff9d5264400000(0000)
knlGS:0000000000000000
[ 37.407285] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.407285] CR2: 00007ffe0858de38 CR3: 000000013b20a001 CR4:
00000000003606f0
[ 37.407286] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 37.407286] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 37.407286] Call Trace:
[ 37.407288] tb_ring_start+0xd4/0x1c0 [thunderbolt]
[ 37.407290] tb_ctl_start+0x36/0xa0 [thunderbolt]
[ 37.407293] tb_domain_runtime_resume+0x1a/0x40 [thunderbolt]
[ 37.407295] nhi_runtime_resume+0x28/0x30 [thunderbolt]
[ 37.407296] pci_pm_runtime_resume+0x75/0xd0
[ 37.407296] ? pci_restore_standard_config+0x50/0x50
[ 37.407297] __rpm_callback+0x8c/0x150
[ 37.407298] ? pci_restore_standard_config+0x50/0x50
[ 37.407299] rpm_callback+0x24/0x80
[ 37.407300] ? pci_restore_standard_config+0x50/0x50
[ 37.407300] rpm_resume+0x568/0x780
[ 37.407302] pm_runtime_work+0x7d/0xa0
[ 37.407303] process_one_work+0x1db/0x380
[ 37.407304] worker_thread+0x4d/0x400
[ 37.407305] kthread+0x104/0x140
[ 37.407305] ? process_one_work+0x380/0x380
[ 37.407306] ? kthread_park+0x80/0x80
[ 37.407307] ret_from_fork+0x1f/0x40
[ 37.407308] ---[ end trace 33a816af30ee403e ]---
[ 37.424608] xhci_hcd 0000:39:00.0: Refused to change power state,
currently in D3
[ 37.424702] xhci_hcd 0000:39:00.0: WARN: xHC restore state timeout
[ 37.424703] xhci_hcd 0000:39:00.0: PCI post-resume error -110!
[ 37.424705] xhci_hcd 0000:39:00.0: HC died; cleaning up
[ 37.704717] pcieport 0000:04:04.0: pciehp: link training error: status
0xffff
[ 37.704721] pcieport 0000:04:01.0: pciehp: link training error: status
0xffff
[ 37.704725] pcieport 0000:04:01.0: pciehp: Failed to check link status
[ 37.704731] pcieport 0000:04:04.0: pciehp: Failed to check link status
[ 37.704776] pcieport 0000:04:01.0: pciehp: pcie_do_write_cmd: no
response from device
[ 37.704778] pcieport 0000:04:04.0: pciehp: pcie_do_write_cmd: no
response from device
Kai-Heng
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases"
2019-07-31 16:04 [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases" Kai-Heng Feng
@ 2019-07-31 16:12 ` Mario.Limonciello
2019-07-31 21:30 ` Bjorn Helgaas
2019-07-31 22:20 ` Rafael J. Wysocki
2 siblings, 0 replies; 6+ messages in thread
From: Mario.Limonciello @ 2019-07-31 16:12 UTC (permalink / raw)
To: kai.heng.feng, rjw
Cc: mika.westerberg, anthony.wong, linux-acpi, linux-pci, linux-pm,
linux-kernel
I've actually been seeing worse behavior, in that I can't get Thunderbolt to work at all with 5.3rc1 or 5.3rc2 on the 9380 system I have on hand, similar messages related to link timeouts.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases"
2019-07-31 16:04 [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases" Kai-Heng Feng
2019-07-31 16:12 ` Mario.Limonciello
@ 2019-07-31 21:30 ` Bjorn Helgaas
2019-07-31 22:26 ` Rafael J. Wysocki
2019-07-31 22:20 ` Rafael J. Wysocki
2 siblings, 1 reply; 6+ messages in thread
From: Bjorn Helgaas @ 2019-07-31 21:30 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Rafael J. Wysocki, Mika Westerberg, Mario Limonciello,
Anthony Wong, Linux ACPI, Linux PCI, Linux PM, LKML,
Andreas Noever, Michael Jamet, Yehezkel Bernat
[+cc Thunderbolt folks, see
https://lore.kernel.org/r/578BD3F1-B185-471B-A3EB-FF71BA34B822@canonical.com
for beginning of thread]
On Thu, Aug 01, 2019 at 12:04:29AM +0800, Kai-Heng Feng wrote:
> Hi,
>
> After commit "ACPI: PM: Allow transitions to D0 to occur in special cases”,
This is f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in
special cases").
> Thunderbolt on XPS 9380 spews the following when it runtime resumes:
> [ 36.136554] pci_raw_set_power_state: 25 callbacks suppressed
> [ 36.136558] pcieport 0000:03:00.0: Refused to change power state,
> currently in D3
We really should be smarter about what we print here, maybe something
like the patch below?
pci_raw_set_power_state() prints "Refused to change power state" if
(in this case) the value of (PCI_PM_CTRL & PCI_PM_CTRL_STATE_MASK) is
0x3. Most likely we got 0xffff from PCI_PM_CTRL because the device is
in D3cold. If the device is in D3cold, pci_raw_set_power_state() has
no hope of doing anything because it only uses PCI PM config
registers, and they're inaccessible in D3cold.
Presumably there's some platform PM method that is supposed to take
the device out of D3cold, and maybe we're missing that somehow?
Based on an lspci I found at [1], I suspect 03:00.0 is a Thunderbolt
switch leading to [bus 04-6d]. From your log, it looks like these
devices don't work:
03:00.0 Thunderbolt Upstream Port
04:00.0 Thunderbolt Downstream Port
04:01.0 Thunderbolt Downstream Port (Slot 1)
04:02.0 Thunderbolt Downstream Port
04:04.0 Thunderbolt Downstream Port (Slot 4)
05:00.0 Thunderbolt NHI
39:00.0 XHCI USB
If 03:00.0 is stuck in D3cold, that would explain why none of these
things work.
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826125
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 29ed5ec1ac27..63ca963ebff9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -851,6 +852,11 @@ static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state)
return -EIO;
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
+ if (pmcsr == (u16) ~0) {
+ pci_err(dev, "device not responding; can't change to power state D%d\n",
+ state);
+ return -EIO;
+ }
/*
* If we're (effectively) in D3, force entire word to 0.
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases"
2019-07-31 21:30 ` Bjorn Helgaas
@ 2019-07-31 22:26 ` Rafael J. Wysocki
2019-08-02 22:36 ` Bjorn Helgaas
0 siblings, 1 reply; 6+ messages in thread
From: Rafael J. Wysocki @ 2019-07-31 22:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kai-Heng Feng, Mika Westerberg, Mario Limonciello, Anthony Wong,
Linux ACPI, Linux PCI, Linux PM, LKML, Andreas Noever,
Michael Jamet, Yehezkel Bernat
On Wednesday, July 31, 2019 11:30:01 PM CEST Bjorn Helgaas wrote:
> [+cc Thunderbolt folks, see
> https://lore.kernel.org/r/578BD3F1-B185-471B-A3EB-FF71BA34B822@canonical.com
> for beginning of thread]
>
> On Thu, Aug 01, 2019 at 12:04:29AM +0800, Kai-Heng Feng wrote:
> > Hi,
> >
> > After commit "ACPI: PM: Allow transitions to D0 to occur in special cases”,
>
> This is f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in
> special cases").
>
> > Thunderbolt on XPS 9380 spews the following when it runtime resumes:
> > [ 36.136554] pci_raw_set_power_state: 25 callbacks suppressed
> > [ 36.136558] pcieport 0000:03:00.0: Refused to change power state,
> > currently in D3
>
> We really should be smarter about what we print here, maybe something
> like the patch below?
>
> pci_raw_set_power_state() prints "Refused to change power state" if
> (in this case) the value of (PCI_PM_CTRL & PCI_PM_CTRL_STATE_MASK) is
> 0x3. Most likely we got 0xffff from PCI_PM_CTRL because the device is
> in D3cold. If the device is in D3cold, pci_raw_set_power_state() has
> no hope of doing anything because it only uses PCI PM config
> registers, and they're inaccessible in D3cold.
>
> Presumably there's some platform PM method that is supposed to take
> the device out of D3cold, and maybe we're missing that somehow?
Yes, there is.
> Based on an lspci I found at [1], I suspect 03:00.0 is a Thunderbolt
> switch leading to [bus 04-6d]. From your log, it looks like these
> devices don't work:
>
> 03:00.0 Thunderbolt Upstream Port
> 04:00.0 Thunderbolt Downstream Port
> 04:01.0 Thunderbolt Downstream Port (Slot 1)
> 04:02.0 Thunderbolt Downstream Port
> 04:04.0 Thunderbolt Downstream Port (Slot 4)
> 05:00.0 Thunderbolt NHI
> 39:00.0 XHCI USB
>
> If 03:00.0 is stuck in D3cold, that would explain why none of these
> things work.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826125
>
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 29ed5ec1ac27..63ca963ebff9 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -851,6 +852,11 @@ static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state)
> return -EIO;
>
> pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
> + if (pmcsr == (u16) ~0) {
Is the "device not accessible" the only case in which we can get all ones from this?
If so, the change will be fine by me.
> + pci_err(dev, "device not responding; can't change to power state D%d\n",
> + state);
But I wouldn't break this line.
> + return -EIO;
> + }
>
> /*
> * If we're (effectively) in D3, force entire word to 0.
>
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases"
2019-07-31 22:26 ` Rafael J. Wysocki
@ 2019-08-02 22:36 ` Bjorn Helgaas
0 siblings, 0 replies; 6+ messages in thread
From: Bjorn Helgaas @ 2019-08-02 22:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kai-Heng Feng, Mika Westerberg, Mario Limonciello, Anthony Wong,
Linux ACPI, Linux PCI, Linux PM, LKML, Andreas Noever,
Michael Jamet, Yehezkel Bernat
On Thu, Aug 01, 2019 at 12:26:51AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 31, 2019 11:30:01 PM CEST Bjorn Helgaas wrote:
> > [+cc Thunderbolt folks, see
> > https://lore.kernel.org/r/578BD3F1-B185-471B-A3EB-FF71BA34B822@canonical.com
> > for beginning of thread]
> >
> > On Thu, Aug 01, 2019 at 12:04:29AM +0800, Kai-Heng Feng wrote:
> > > Hi,
> > >
> > > After commit "ACPI: PM: Allow transitions to D0 to occur in special cases”,
> >
> > This is f850a48a0799 ("ACPI: PM: Allow transitions to D0 to occur in
> > special cases").
> >
> > > Thunderbolt on XPS 9380 spews the following when it runtime resumes:
> > > [ 36.136554] pci_raw_set_power_state: 25 callbacks suppressed
> > > [ 36.136558] pcieport 0000:03:00.0: Refused to change power state,
> > > currently in D3
> >
> > We really should be smarter about what we print here, maybe something
> > like the patch below?
> >
> > pci_raw_set_power_state() prints "Refused to change power state" if
> > (in this case) the value of (PCI_PM_CTRL & PCI_PM_CTRL_STATE_MASK) is
> > 0x3. Most likely we got 0xffff from PCI_PM_CTRL because the device is
> > in D3cold. If the device is in D3cold, pci_raw_set_power_state() has
> > no hope of doing anything because it only uses PCI PM config
> > registers, and they're inaccessible in D3cold.
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 29ed5ec1ac27..63ca963ebff9 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -851,6 +852,11 @@ static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state)
> > return -EIO;
> >
> > pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
> > + if (pmcsr == (u16) ~0) {
>
> Is the "device not accessible" the only case in which we can get all ones from this?
>
> If so, the change will be fine by me.
There are several RsvdP bits in that register, so it's not possible to
read all ones except in error cases. I'll finish up a patch for it.
Bjorn
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases"
2019-07-31 16:04 [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases" Kai-Heng Feng
2019-07-31 16:12 ` Mario.Limonciello
2019-07-31 21:30 ` Bjorn Helgaas
@ 2019-07-31 22:20 ` Rafael J. Wysocki
2 siblings, 0 replies; 6+ messages in thread
From: Rafael J. Wysocki @ 2019-07-31 22:20 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Mika Westerberg, Mario Limonciello, Anthony Wong, Linux ACPI,
Linux PCI, Linux PM, LKML
On Wednesday, July 31, 2019 6:04:29 PM CEST Kai-Heng Feng wrote:
> Hi,
>
> After commit "ACPI: PM: Allow transitions to D0 to occur in special cases”,
> Thunderbolt on XPS 9380 spews the following when it runtime resumes:
> [ 36.136554] pci_raw_set_power_state: 25 callbacks suppressed
> [ 36.136558] pcieport 0000:03:00.0: Refused to change power state,
> currently in D3
> [ 36.143850] pcieport 0000:04:04.0: Refused to change power state,
> currently in D3
> [ 36.150796] pcieport 0000:04:00.0: Refused to change power state,
> currently in D3
> [ 36.157138] pcieport 0000:04:01.0: Refused to change power state,
> currently in D3
> [ 36.162635] pcieport 0000:04:02.0: Refused to change power state,
> currently in D3
Thanks for identifying the offending commit and sorry for the breakage.
The patch below should fix it.
---
drivers/acpi/device_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/acpi/device_pm.c
===================================================================
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -236,13 +236,15 @@ int acpi_device_set_power(struct acpi_de
if (device->power.flags.power_resources)
result = acpi_power_transition(device, target_state);
} else {
+ int cur_state = device->power.state;
+
if (device->power.flags.power_resources) {
result = acpi_power_transition(device, ACPI_STATE_D0);
if (result)
goto end;
}
- if (device->power.state == ACPI_STATE_D0) {
+ if (cur_state == ACPI_STATE_D0) {
int psc;
/* Nothing to do here if _PSC is not present. */
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-08-02 22:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-31 16:04 [Regression] Commit "ACPI: PM: Allow transitions to D0 to occur in special cases" Kai-Heng Feng
2019-07-31 16:12 ` Mario.Limonciello
2019-07-31 21:30 ` Bjorn Helgaas
2019-07-31 22:26 ` Rafael J. Wysocki
2019-08-02 22:36 ` Bjorn Helgaas
2019-07-31 22:20 ` Rafael J. Wysocki
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).