[PATCH] drm/xe/d3cold: Set power state to D3Cold during s2idle/s3

[Gupta, Anshuman]

/snip
> That's true in principle, but care needs to be taken.
> 
> First of all, DPM_FLAG_SMART_PREPARE and DPM_FLAG_SMART_SUSPEND
> are about different things.
> 
> DPM_FLAG_SMART_PREPARE is about the direct-complete optimization that
> allows the suspend and resume of the device to be skipped completely if some
> additional conditions are met and it allows the driver to control the behavior
> related to this optimization (see "Entering System Suspend" in
> Documentation/driver-api/pm/devices.rst for details).  The bottom line here is
> that because xe doesn't provide a
> ->prepare() callback in xe_pm_ops, this flag will have no effect.  xe
> may want to set DPM_FLAG_NO_DIRECT_COMPLETE to disable the direct-
> complete optimization completely, though (i915 does this for some reason
> unclear to me).
I915 has disabled the direct complete optimization due to hdac_hdmi module relies on jack detection from
I915 resume and requires i915 to enable audio power domain.

Thanks,
Anshuman
> 
> DPM_FLAG_SMART_SUSPEND is about leaving the device in runtime suspend
> across the entire system suspend transition if it is still runtime-suspended after
> running its driver's ->suspend() callback.
> 
> This means in particular that if DPM_FLAG_SMART_SUSPEND is set, the
> ->suspend() callback may run in parallel with xe_pci_runtime_resume(),
> so it cannot be the current xe_pci_suspend() because it cannot manipulate the
> device or call pci_save_state() on it or similar.  The most straightforward way
> to overcome this would be to point
> ->suspend_late() to xe_pci_suspend(), but this would cause the device
> to be suspended later unless it was runtime-suspended already.  In turn,
> suspending it later may cause the total duration of the system suspend
> transition to increase (because the device will now be suspended in a different
> phase of the transition).
> 
> The suspend time can be distributed somewhat differently if the core is
> allowed to take care of putting the device into a low-power state.
> Simply removing the pci_save_state() and pci_set_power_state() calls from
> xe_pci_suspend() should be sufficient to make this happen and that would be
> my first step (after fixing the device disable/enable issue described above).
> 
> Next, you can point ->suspend_late(), instead of ->suspend(), to
> xe_pci_suspend() and that is still expected to work, but the total system
> suspend timing will change.
> 
> If this works, you'll be ready to set DPM_FLAG_SMART_SUSPEND.