forked from Minki/linux
drm/i915/skl: Added a check for the hardware status of csr fw before loading.
Dmc will restore the csr program except DC9, cold boot, warm reset, PCI function level reset, and hibernate/suspend. intel_csr_load_program() function is used to load the firmware data from kernel memory to csr address space. All values of csr address space will be zero if it got reset and the first byte of csr program is always a non-zero if firmware is loaded successfuly. Based on hardware status will load the firmware. Without this condition check if we overwrite the firmware data the counters exposed for dc5/dc6 (help for debugging) will be nullified. Note: Above commit message seems to be confused and the real problem apparently going on is that for suspend-to-idle and system standby the firmware survives (it's like runtime pm), but it doesn't for suspend-to-mem and hibernate-to-disk. All the other talking about DC9 and pci reset are irrelevant for the path touched here (only driver load and system resume functions) and might not be true statements. v1: Initial version. v2: Based on review comments from Daniel, - Added a check to know hardware status and load the firmware if not loaded. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com> [danvet: Explain clearly in the code comment when we need to reload and when not and make it a FIXME. Also deconfuse the commit message with a note. Also: Make. it. compile.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
parent
30c964a6cb
commit
4b7ab5fca1
@ -265,6 +265,15 @@ void intel_csr_load_program(struct drm_device *dev)
|
||||
return;
|
||||
}
|
||||
|
||||
/*
|
||||
* FIXME: Firmware gets lost on S3/S4, but not when entering system
|
||||
* standby or suspend-to-idle (which is just like forced runtime pm).
|
||||
* Unfortunately the ACPI subsystem doesn't yet give us a way to
|
||||
* differentiate this, hence figure it out with this hack.
|
||||
*/
|
||||
if (I915_READ(CSR_PROGRAM(0)))
|
||||
return;
|
||||
|
||||
mutex_lock(&dev_priv->csr_lock);
|
||||
fw_size = dev_priv->csr.dmc_fw_size;
|
||||
for (i = 0; i < fw_size; i++)
|
||||
|
Loading…
Reference in New Issue
Block a user