From: Paulo Zanoni Date: Thu, 21 Aug 2014 20:09:38 +0000 (-0300) Subject: drm/i915: send PCI_D3hot adapter opregion message on BDW RPM suspend X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=c8a0bd42df69fe76646b45dea04c7cf4995fa6a3;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git drm/i915: send PCI_D3hot adapter opregion message on BDW RPM suspend On BDW we're seeing a problem that after we runtime resume, the outputs connected to DDI C are not detected: they don't appear in the SDEISR register and GMBUS transactions don't work. They stop working at the moment we call intel_opregion_notify_adapter() during runtime suspend, but they don't go back to work when we call the same function during runtime resume. They only work after we do a modeset and call intel_opregion_notify_encoder(), but this point is already too late. While debugging, I tried to pass PCI_D3hot which is the value that matches the spec, and it seems to have solved the problem. I couldn't find any explanation of why this solves the problem, but there's also no documented explanation - besides our code and git log - of why Haswell should use PCI_D1, so keep this for now in order to keep BDW runtime PM working. Also add a comment to point the fact that there's no spec documenting all the weirdness involved here. Cc: kristen.c.accardi@intel.com Testcase: igt/pm_rpm/drm-resources-equal Testcase: igt/pm_rpm/i2c Signed-off-by: Paulo Zanoni Reviewed-by: Damien Lespiau Signed-off-by: Daniel Vetter --- diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 683be99117c6..d02398720237 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1462,13 +1462,29 @@ static int intel_runtime_suspend(struct device *device) dev_priv->pm.suspended = true; /* - * current versions of firmware which depend on this opregion - * notification have repurposed the D1 definition to mean - * "runtime suspended" vs. what you would normally expect (D3) - * to distinguish it from notifications that might be sent - * via the suspend path. + * FIXME: We really should find a document that references the arguments + * used below! */ - intel_opregion_notify_adapter(dev, PCI_D1); + if (IS_HASWELL(dev)) { + /* + * current versions of firmware which depend on this opregion + * notification have repurposed the D1 definition to mean + * "runtime suspended" vs. what you would normally expect (D3) + * to distinguish it from notifications that might be sent via + * the suspend path. + */ + intel_opregion_notify_adapter(dev, PCI_D1); + } else { + /* + * On Broadwell, if we use PCI_D1 the PCH DDI ports will stop + * being detected, and the call we do at intel_runtime_resume() + * won't be able to restore them. Since PCI_D3hot matches the + * actual specification and appears to be working, use it. Let's + * assume the other non-Haswell platforms will stay the same as + * Broadwell. + */ + intel_opregion_notify_adapter(dev, PCI_D3hot); + } DRM_DEBUG_KMS("Device suspended\n"); return 0;