diff mbox

[RFC] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron

Message ID 50E45483.2040106@canonical.com (mailing list archive)
State New, archived
Headers show

Commit Message

Maarten Lankhorst Jan. 2, 2013, 3:38 p.m. UTC
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.

Comments

Alex Deucher Jan. 4, 2013, 3:34 p.m. UTC | #1
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 {
>
Maarten Lankhorst Jan. 4, 2013, 4:26 p.m. UTC | #2
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 mbox

Patch

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 {