Re: acpi suspend debugging techniques?

My Radeon card comes back from resume, but the backlight doesn't (it
stays off).  Think this patch might help with that?  I was gonna start a
separate thread to ask for help debugging my backlight issue...

Thanks,
Anthony

On 09/03/15 16:06, Adrian Chadd wrote:
> oioo, would you please put that radeon patch into a review?
>
> I have an older machine with a radeon card in it that doesn't yet
> suspend/resume; I can now test it out!
>
>
> -a
>
>
> On 3 September 2015 at 10:50, Andriy Gapon <avg_at_freebsd.org> wrote:
>> On 31/08/2015 11:53, Adrian Chadd wrote:
>>> Try disabling hardware one at a time. Ie, unload usb; unload wifi;
>>> leave kms loaded for mostly obvious reasons.
>> Adrian, Garrett,
>>
>> thank you very much for your tips.
>> Turned out that it was radeonkms that was causing the problem :-)
>>
>> BTW, here is another tool for the toolkit: on sufficiently recent system devctl
>> suspend and devctl resume can be used to test individual drivers.
>>
>> So, I noticed that I could suspend/resume drmn0 device just fine but with
>> vgapci0 I had a trouble suspending.  One thing led to another and here is a
>> patch that seems to fix the problem for me:
>> -------------------------------------------------------------------------------
>> commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
>> Author: Andriy Gapon <avg_at_icyb.net.ua>
>> Date:   Thu Sep 3 17:24:23 2015 +0300
>>
>>     radeon_suspend_kms: don't mess with pci state that's managed by the bus
>>
>>     The pci bus driver handles the power state and configuration state saving
>>     and restoring for its child devices.
>>
>> diff --git a/sys/dev/drm2/radeon/radeon_device.c
>> b/sys/dev/drm2/radeon/radeon_device.c
>> index e5c676b11ed47..73b2f4c51ada2 100644
>> --- a/sys/dev/drm2/radeon/radeon_device.c
>> +++ b/sys/dev/drm2/radeon/radeon_device.c
>> _at__at_ -1342,14 +1342,10 _at__at_ int radeon_suspend_kms(struct drm_device *dev)
>>
>>         radeon_agp_suspend(rdev);
>>
>> -       pci_save_state(device_get_parent(dev->dev));
>>  #ifdef FREEBSD_WIP
>>         if (state.event == PM_EVENT_SUSPEND) {
>>                 /* Shut down the device */
>>                 pci_disable_device(dev->pdev);
>> -#endif /* FREEBSD_WIP */
>> -               pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3);
>> -#ifdef FREEBSD_WIP
>>         }
>>         console_lock();
>>  #endif /* FREEBSD_WIP */
>> _at__at_ -1380,10 +1376,6 _at__at_ int radeon_resume_kms(struct drm_device *dev)
>>
>>  #ifdef FREEBSD_WIP
>>         console_lock();
>> -#endif /* FREEBSD_WIP */
>> -       pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0);
>> -       pci_restore_state(device_get_parent(dev->dev));
>> -#ifdef FREEBSD_WIP
>>         if (pci_enable_device(dev->pdev)) {
>>                 console_unlock();
>>                 return -1;
>> -------------------------------------------------------------------------------
>>
>> However, I am not sure about an exact mechanism of the hard system hang that I
>> experienced without the patch.
>>
>> BTW, I noticed that only very few drivers make explicit calls to
>> pci_set_powerstate and pci_save_state/pci_restore_state.
>> sys/dev/usb/controller/ohci_pci.c looks like a good use of pci_set_powerstate.
>> sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the functions.
>>
>> --
>> Andriy Gapon
> _______________________________________________
> freebsd-acpi_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe_at_freebsd.org"

-- 
Anthony Jenkins
Software Engineer
VTilt Digital, LLC