From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: [RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron Date: Fri, 04 Jan 2013 17:26:27 +0100 Message-ID: <50E702B3.4070709@canonical.com> References: <50E45483.2040106@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by gabe.freedesktop.org (Postfix) with ESMTP id 06849E5F69 for ; Fri, 4 Jan 2013 08:26:31 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alex Deucher Cc: Seth Forshee , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org Op 04-01-13 16:34, Alex Deucher schreef: > On Wed, Jan 2, 2013 at 10:38 AM, Maarten Lankhorst > 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 >> >> --- >> >> 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 { >>