Message ID | 50E45483.2040106@canonical.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst <maarten.lankhorst@canonical.com> wrote: > 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. 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 > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > --- > > 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. > > diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c > index 5515921..8816958 100644 > --- a/drivers/gpu/drm/radeon/radeon_device.c > +++ b/drivers/gpu/drm/radeon/radeon_device.c > @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum vga_switchero > struct 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: > On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst > <maarten.lankhorst@canonical.com> wrote: >> 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. > 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. > 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. >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> >> >> --- >> >> 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. >> >> diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c >> index 5515921..8816958 100644 >> --- a/drivers/gpu/drm/radeon/radeon_device.c >> +++ b/drivers/gpu/drm/radeon/radeon_device.c >> @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum vga_switchero >> struct 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 { >>
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 5515921..8816958 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -910,10 +910,19 @@ static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum vga_switchero struct 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 {
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. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> --- 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.