drm/radeon: increase d3 delay to 20 ms during switcheroo poweron
Subsystems (2)
RFC PATCH 1/1 drm/radeon: increase d3 delay to 20 ms during switcheroo poweron
vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI configuration space is not restored correctly, resulting in MSI not working after switch.
Only useful item in dmesg is:
[ 33.922807] radeon 0000:01:00.0: Refused to change power state, currently in D3
I did some testing, dumping the difference in ms between first succesful switch from D3 to D0, and it seems that there is slightly more than 20 ms difference when the device is re-enabled through vga-switcheroo.
So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not working on my system after switcheroo-ing.
---
This is a RFC patch since I feel what I'm doing is done in a hackish way, but it seems only the D3->D0 transition during switcheroo enable is affected, other transitions like suspend/resume and switcheroo poweroff seem unaffected.
drivers/gpu/drm/radeon/radeon_device.c +9 -0
@@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum vga_switcherostruct drm_device *dev =pci_get_drvdata (pdev);pm_message_t pmm = { .event =PM_EVENT_SUSPEND };if (state ==VGA_SWITCHEROO_ON ) { +unsigned d3_delay = dev->pdev->d3_delay; +printk (KERN_INFO "radeon: switched on\n" );/* don't suspend or resume card normally */ dev->switch_power_state =DRM_SWITCH_POWER_CHANGING ; + +if (dev->pdev->d3_delay <20 ) + dev->pdev->d3_delay =20 ; +radeon_resume_kms (dev); + + dev->pdev->d3_delay = d3_delay; + dev->switch_power_state =DRM_SWITCH_POWER_ON ;drm_kms_helper_poll_enable (dev); }else {
Quoted 5 lines · Maarten Lankhorst
vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI configuration space is not restored correctly, resulting in MSI not working after switch.
Only useful item in dmesg is:
Quoted 8 lines
[ 33.922807] radeon 0000:01:00.0: Refused to change power state, currently in D3I did some testing, dumping the difference in ms between first succesful switch from D3 to D0, and it seems that there is slightly more than 20 ms difference when the device is re-enabled through vga-switcheroo.
So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not working on my system after switcheroo-ing.
I guess if it fixes it... Has anyone seen similar problems on non-mac systems? What is the delay normally set to? It seems pretty innocuous other than potentially adding a little extra latency. Do you think it makes sense to make it more like a quirk and only apply it to problematic systems or just apply across the board?
Alex
Quoted 34 lines
Signed-off-by Maarten Lankhorst <[email protected]>---
This is a RFC patch since I feel what I'm doing is done in a hackish way, but it seems only the
D3->D0transition during switcheroo enable is affected, other transitions like suspend/resume and switcheroo poweroff seem unaffected.drivers/gpu/drm/radeon/radeon_device.c +9
-0@@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum vga_switcherostruct drm_device *dev =pci_get_drvdata (pdev);pm_message_t pmm = { .event =PM_EVENT_SUSPEND };if (state ==VGA_SWITCHEROO_ON ) { +unsigned d3_delay = dev->pdev->d3_delay; +printk (KERN_INFO "radeon: switched on\n" );/* don't suspend or resume card normally */ dev->switch_power_state =DRM_SWITCH_POWER_CHANGING ; + +if (dev->pdev->d3_delay <20 ) + dev->pdev->d3_delay =20 ; +radeon_resume_kms (dev); + + dev->pdev->d3_delay = d3_delay; + dev->switch_power_state =DRM_SWITCH_POWER_ON ;drm_kms_helper_poll_enable (dev); }else {
Op 04-01-13 16:34, Alex Deucher schreef:
Quoted 9 lines
Quoted 7 lines · Maarten Lankhorst
vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI configuration space is not restored correctly, resulting in MSI not working after switch.
Only useful item in dmesg is:
[ 33.922807] radeon 0000:01:00.0: Refused to change power state, currently in D3
Quoted 8 lines
Quoted 6 lines
I did some testing, dumping the difference in ms between first succesful switch from D3 to D0, and it seems that there is slightly more than 20 ms difference when the device is re-enabled through vga-switcheroo.
So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not working on my system after switcheroo-ing.
I guess if it fixes it... Has anyone seen similar problems on non-mac systems? What is the delay normally set to? It seems pretty
It's normally set to PCI_PM_D3_WAIT, 10 ms.
Quoted 3 lines
innocuous other than potentially adding a little extra latency. Do you think it makes sense to make it more like a quirk and only apply it to problematic systems or just apply across the board?
Quirking would be fine. Since there is a message in dmesg it would be easy to identify when others hit the same issue, in which case we could enable it all the time.
Quoted 33 lines
Quoted 33 lines
Signed-off-by Maarten Lankhorst <[email protected]>---
This is a RFC patch since I feel what I'm doing is done in a hackish way, but it seems only the
D3->D0transition during switcheroo enable is affected, other transitions like suspend/resume and switcheroo poweroff seem unaffected.drivers/gpu/drm/radeon/radeon_device.c +9
-0@@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum vga_switcherostruct drm_device *dev =pci_get_drvdata (pdev);pm_message_t pmm = { .event =PM_EVENT_SUSPEND };if (state ==VGA_SWITCHEROO_ON ) { +unsigned d3_delay = dev->pdev->d3_delay; +printk (KERN_INFO "radeon: switched on\n" );/* don't suspend or resume card normally */ dev->switch_power_state =DRM_SWITCH_POWER_CHANGING ; + +if (dev->pdev->d3_delay <20 ) + dev->pdev->d3_delay =20 ; +radeon_resume_kms (dev); + + dev->pdev->d3_delay = d3_delay; + dev->switch_power_state =DRM_SWITCH_POWER_ON ;drm_kms_helper_poll_enable (dev); }else {