Re: acpi suspend debugging techniques?

From: Adrian Chadd <adrian.chadd_at_gmail.com>
Date: Thu, 3 Sep 2015 13:06:52 -0700
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
Received on Thu Sep 03 2015 - 18:06:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC