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.
Details
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
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.
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)?
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).