kernel.git/drivers/gpu/drm/i915/intel_runtime_pm.c, branch linux-4.7.y

drm/i915: Enable polling when we don't have hpd

2016-09-07T06:34:51Z

commit 84c8e0963da434d37355079b568465cd121af295 upstream. Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get their display to turn on. For instance; if we boot a Valleyview system without any monitors connected, it won't need any of it's power wells and thus shut them off. Since this causes us to lose HPD, this means that unless the user knows how to ssh into their machine and do a manual reprobe for monitors, none of the monitors they connect after booting will actually work. Eventually we should come up with a better fix then having to enable polling for this, since this makes rpm a lot less useful, but for now the infrastructure in i915 just isn't there yet to get hpd in these situations. Changes since v1: - Add comment explaining the addition of the if (!mode_config->poll_running) in intel_hpd_init() - Remove unneeded if (!dev->mode_config.poll_enabled) in i915_hpd_poll_init_work() - Call to drm_helper_hpd_irq_event() after we disable polling - Add cancel_work_sync() call to intel_hpd_cancel_work() Changes since v2: - Apparently dev->mode_config.poll_running doesn't actually reflect whether or not a poll is currently in progress, and is actually used for dynamic module paramter enabling/disabling. So now we instead keep track of our own poll_running variable in dev_priv->hotplug - Clean i915_hpd_poll_init_work() a little bit Changes since v3: - Remove the now-redundant connector loop in intel_hpd_init(), just rely on intel_hpd_poll_enable() for setting connector->polled correctly on each connector - Get rid of poll_running - Don't assign enabled in i915_hpd_poll_init_work before we actually lock dev->mode_config.mutex - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE() for doc purposes - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in intel_hpd_poll_enable() - Add some comments about racing not mattering in intel_hpd_poll_enable Changes since v4: - Rename intel_hpd_poll_enable() to intel_hpd_poll_init() - Drop the bool argument from intel_hpd_poll_init() - Remove redundant calls to intel_hpd_poll_init() - Rename poll_enable_work to poll_init_work - Add some kerneldoc for intel_hpd_poll_init() - Cross-reference intel_hpd_poll_init() in intel_hpd_init() - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init() Changes since v5: - Minor kerneldoc nitpicks Cc: stable@vger.kernel.org Cc: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Lyude Signed-off-by: Daniel Vetter (cherry picked from commit 19625e85c6ec56038368aa72c44f5f55b221f0fc) Signed-off-by: Greg Kroah-Hartman

drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

2016-09-07T06:34:51Z

commit 4c732e6ee9e71903934d75b12a021eb3520b6197 upstream. While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA get cleared and consequently VGA hotplugging gets disabled. This causes bugs such as one we found on an Intel NUC, where doing the following sequence of hotplugs: - Disconnect all monitors - Connect VGA - Disconnect VGA - Connect HDMI Would result in VGA hotplugging becoming disabled, due to the powerwells getting toggled in the process of connecting HDMI. Changes since v3: - Expose intel_crt_reset() through intel_drv.h and call that in vlv_display_power_well_init() instead of encoder->base.funcs->reset(&encoder->base); Changes since v2: - Use intel_encoder structs instead of drm_encoder structs Changes since v1: - Instead of handling the register writes ourself, we just reuse intel_crt_detect() - Instead of resetting the ADPA during display IRQ installation, we now reset them in vlv_display_power_well_init() Acked-by: Daniel Vetter Signed-off-by: Lyude Reviewed-by: Ville Syrjälä [danvet: Rebase over dev_priv/drm_device embedding.] Signed-off-by: Daniel Vetter (cherry picked from commit 9504a89247595b6c066c68aea0c34af1fc78d021) Signed-off-by: Greg Kroah-Hartman

drm/i915/bxt: Enable DC5 during runtime resume

2016-04-22T12:12:05Z

Right after runtime resume we know that we can re-enable DC5, since we just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly instead of delaying this until the next time we disable power well 2. Signed-off-by: Imre Deak Reviewed-by: Bob Paauwe Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-5-git-send-email-imre.deak@intel.com

drm/i915/bxt: Sanitize DC state tracking during system resume

2016-04-22T12:12:04Z

After suspend-to-ram or -disk we don't know what power state the display HW will be, DC0 or DC9 are both possible states, so reset the software DC state tracking in these cases. This gets rid of 'DC state mismatch' error messages during resuming from ram or disk where we expected to be in DC9 (as set by the suspend handler) but we are in DC0. v2: - Remove extra WS in gen9_sanitize_dc_state() (Bob) Signed-off-by: Imre Deak Reviewed-by: Bob Paauwe Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-4-git-send-email-imre.deak@intel.com

drm/i915/kbl: Don't WARN for expected secondary MISC IO power well request

2016-04-21T16:34:56Z

In commit 5f304c873634 ("drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMR") I forgot about the fact that SKL==KBL most of the time and that a secondary MISC IO power well request left on by the DMC is "expected". Tune down the corresponding WARN to be a debug message. This was caught by CI suspend tests. CC: Patrik Jakobsson Signed-off-by: Imre Deak Reviewed-by: Patrik Jakobsson Link: http://patchwork.freedesktop.org/patch/msgid/1461060036-19043-1-git-send-email-imre.deak@intel.com

drm/i915: Define HSW/BDW display power domains the right way up

2016-04-19T11:43:22Z

Currently we're trying to define HSW/BDW power wells by what's not included. Let's do it the other way around, so that you can actually tell when the power well would get enabled. This will also allow us to add new power domains without accidentally adding it to the HSW/BDW display power domains. The current set of domains looks rather buggy even: - POWER_DOMAIN_MODESET is included in the display power well needlessly - DDI-B to DDI-E were not part of the display power well when they should be So let's fix that up while at it. Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak

drm/i915: Define VLV/CHV display power well domains properly

2016-04-19T11:42:57Z

Currently we're using POWER_DOMAIN_MASK as the power domains for the display power well on VLV/CHV. That includes all power domains even though the disp2d/pipe-a power well is not needed for a lot of things. Let's reduce these to what we actually need. Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak

drm/i915: Set .domains=POWER_DOMAIN_MASK for the always-on well

2016-04-19T11:42:45Z

The always-on well is the same as runtime PM, so we should just "enable" it for any power domain. Throw out the usless FOO_ALWAYS_ON_DOMAINS defines and just use POWER_DOMAIN_MASK. Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak

drm/i915/gen9: Fix runtime PM refcounting in case DMC firmware isn't loaded

2016-04-19T09:33:48Z

While we disable runtime PM and with that display power well support if the DMC firmware isn't loaded, we still want to disable power wells during system suspend and driver unload. So drop/reacquire the corresponding power refcount during suspend/resume and driver unloading. This also means we have to check if DMC is not loaded and skip enabling DC states in the power well code. v2: - Reuse intel_csr_ucode_suspend() in intel_csr_ucode_fini() instead of opencoding the former. (Chris) - Add docbook comment to the public resume and suspend functions. CC: Chris Wilson Signed-off-by: Imre Deak Reviewed-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1460980101-14713-1-git-send-email-imre.deak@intel.com

drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMR

2016-04-18T17:16:36Z

The workaround added in commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR") needs to be applied on Kabylake too as shown by the corresponding timeout errors about power well 1 and MISC IO power well disabling in the latest CI run. CC: Patrik Jakobsson Signed-off-by: Imre Deak Reviewed-by: Patrik Jakobsson Link: http://patchwork.freedesktop.org/patch/msgid/1460748778-4484-1-git-send-email-imre.deak@intel.com