Page MenuHomeFreeBSD

radeon_suspend_kms: don't mess with pci state that's managed by the bus
ClosedPublic

Authored by avg on Sep 3 2015, 8:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 12 2024, 12:29 PM
Unknown Object (File)
Oct 2 2024, 2:11 PM
Unknown Object (File)
Sep 18 2024, 1:23 AM
Unknown Object (File)
Sep 17 2024, 4:08 PM
Unknown Object (File)
Sep 17 2024, 8:09 AM
Unknown Object (File)
Sep 14 2024, 9:55 PM
Unknown Object (File)
Sep 14 2024, 9:54 PM
Unknown Object (File)
Sep 7 2024, 1:37 AM
Subscribers

Details

Summary

The pci bus driver handles the power state, it also manages configuration state saving and restoring for its child devices.
Thus a PCI device driver does not have to worry about those things.
In fact, I observe a hard system hang when trying to suspend a system with active radeonkms driver where both the bus driver and radeonkms driver try to do the same thing.
I suspect that it could be because of an access to a PCI configuration register after the device is placed into \D3 state.

Test Plan

Test the suspend/resume process on systems that use radeonkms.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

avg retitled this revision from to radeon_suspend_kms: don't mess with pci state that's managed by the bus.
avg updated this object.
avg edited the test plan for this revision. (Show Details)
avg added reviewers: adrian, dumbbell, jhb.
jhb edited edge metadata.

I think this looks fine. You are correct that the bus manages this. I thought I my T440 was able to resume ok when I used radeonkms (it can either use Intel or ATI graphics), but perhaps it only resumed ok when I used the Intel graphics and it was that X worked fine in both cases. I'll try to get it out and retest.

This revision is now accepted and ready to land.Sep 3 2015, 10:19 PM
dumbbell edited edge metadata.

I thought this was already fixed :)

FYI, when I applied this to 10.1-STABLE on my T400 it did not fix resume. (When I try to resume it starts (hard drive light blinks a few times) but then goes back to a permanent suspend state from which it never tries to awake.) This laptop does resume fine when Intel (integrated) graphics are used with i915kms. I still think the patch is valid and will try newer 10 and HEAD to see if there are other fixes that might help.

@jhb, just to clarify: is that a regression or not comparing to how your T400 works with radeon without the patch (if you tested that)?

In D3561#73715, @avg wrote:

@jhb, just to clarify: is that a regression or not comparing to how your T400 works with radeon without the patch (if you tested that)?

No, not a regression. However, it doesn't fix this laptop. (If it did it would just be another positive test report is all.) It doesn't help with latest stable/10 (and for some reason HEAD hangs right after enabling MSI interrupts on em0 so I can't boot it to multiuser in HEAD to test it there).

In D3561#73906, @jhb wrote:
In D3561#73715, @avg wrote:

@jhb, just to clarify: is that a regression or not comparing to how your T400 works with radeon without the patch (if you tested that)?

No, not a regression. However, it doesn't fix this laptop. (If it did it would just be another positive test report is all.) It doesn't help with latest stable/10 (and for some reason HEAD hangs right after enabling MSI interrupts on em0 so I can't boot it to multiuser in HEAD to test it there).

Ok, after updating HEAD to get sbruno@'s revert of em, I was able to test on HEAD. HEAD is able to suspend/resume with radeonkms both with and without this patch. However, with this patch in place I no longer get error messages logged about failing to place the video device into D3 during suspend and D0 during resume, so from that standpoint it is an improvement.

One oddity on HEAD is that in both cases I have narrow bars of white at the top and bottom of the screen after resuming (this is resuming at the console, not in X).

This revision was automatically updated to reflect the committed changes.