- 14 Jul, 2016 22 commits
-
-
Lionel Landwerlin authored
The i915 driver checks for color management properties changes as part of a plane update. Therefore a color management update must imply a plane update, otherwise we never update the transformation matrixes and degamma/gamma LUTs. v2: add comment about moving the commit of color management registers to an async worker v3: Commit color management register right after vblank v4: Move back color management commit condition together with planes commit v5: Trigger color management commit through the planes commit (Daniel) v6: Make plane change update more readable Fixes: 20a34e78 (drm/i915: Update color management during vblank evasion.) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:Lionel Landwerlin <lionel.g.landwerlin@intel.com> References: https://lkml.org/lkml/2016/7/14/614Reviewed-and-tested-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464183041-8478-1-git-send-email-lionel.g.landwerlin@intel.com
-
Lyude authored
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ä <ville.syrjala@linux.intel.com> Reviewed-by:
Lyude <cpaul@redhat.com> Signed-off-by:
-
Lyude authored
One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the ADPA - output_poll_exec does force probe on VGA, triggering a hpd - HPD handler waits for poll to unlock dev->mode_config.mutex - output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex - HPD handler runs, resets ADPA and brings us back to the start This results in an endless irq storm getting sent from the ADPA whenever a VGA connector gets detected in the middle of polling. Somewhat based off of the "drm/i915: Disable CRT HPD around force trigger" patch Ville Syrjälä sent a while back Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Lyude authored
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() Cc: stable@vger.kernel.org Acked-by:Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Rebase over dev_priv/drm_device embedding.] Signed-off-by:
-
Lyude authored
This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Chris Wilson authored
This function is no longer used outside of intel_pm.c so we can stop exposing it and rename the __gen6_update_ring_freq() to take its place. Suggested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Chris Wilson authored
Some hardware requires a valid render context before it can initiate rc6 power gating of the GPU; the default state of the GPU is not sufficient and may lead to undefined behaviour. The first execution of any batch will load the "golden render state", at which point it is safe to enable rc6. As we do not forcibly load the kernel context at resume, we have to hook into the batch submission to be sure that the render state is setup before enabling rc6. However, since we don't enable powersaving until that first batch, we queued a delayed task in order to guarantee that the batch is indeed submitted. v2: Rearrange intel_disable_gt_powersave() to match. v3: Apply user specified cur_freq (or idle_freq if not set). v4: Give in, and supply a delayed work to autoenable rc6 v5: Mika suggested a couple of better names for delayed_resume_work v6: Rebalance rpm_put around the autoenable task Signed-off-by:
-
Chris Wilson authored
Instead of flushing the outstanding enabling, remember the requested frequency to apply when the powersave work runs. Signed-off-by:
-
Chris Wilson authored
To allow the user finer control over waitboosting, allow them to set the frequency we request for the boost. This also them allows to effectively disable the boosting by setting the boost request to a low frequency. Signed-off-by:
-
Chris Wilson authored
Move the overclocking max frequency detection alongside the regular frequency detection, before we expose the undefined value to userspace. Signed-off-by:
-
Chris Wilson authored
As these RPS frequency values are part of our userspace interface, they must be established before that userspace interface is registered. Signed-off-by:
-
Chris Wilson authored
Select idle frequency during initialisation, then reset the last known frequency when re-enabling. This allows us to preserve the user selected frequency across resets. v2: Stop CHV from overriding the user's choice in cherryview_enable_rps() Signed-off-by:
-
Chris Wilson authored
Upon resetting the GPU, we force the engines to be idle by clearing their request lists. However, I neglected to clear the GT active status and so the next request following the reset was not marking the device as busy again. (We had to wait until any outstanding retire worker finally ran and cleared the active status.) Fixes: 67d97da3 ("drm/i915: Only start retire worker when idle") Testcase: igt/pm_rps/reset Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Matthew Auld authored
This should already be handled by drm_gem_object_release, which is called later on. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Dell XPS 13 9350 apparently doesn't like it when we use the panel type from OpRegion. The OpRegion panel type (0) tells us to use use low vswing for eDP, whereas the VBT panel type (2) tells us to use normal vswing. The problem is that low vswing results in some display flickers. Since no one seems to know how this stuff is supposed to be handled, let's just ignore the OpRegion panel type on SKL for now. v2: Print the panel type correctly in the debug output Reported-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: drm-intel-fixes@lists.freedesktop.org References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Fixes: a0562819 ("drm/i915: Get panel_type from OpRegion panel details") Signed-off-by:
-
Tvrtko Ursulin authored
Created two common helpers for engine setup and engine init phases respectively to help with code sharing. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468422221-12132-1-git-send-email-tvrtko.ursulin@linux.intel.com Reviewed-by: Chris Wilson <chris-wilson.co.uk>
-
Tvrtko Ursulin authored
Common code deserves to be put in a separate file from legacy and execlists implementation for clarity and ease of maintenance. Signed-off-by: -
Tvrtko Ursulin authored
Engine contains dev_priv so need to pass it in. Signed-off-by:
-
Tvrtko Ursulin authored
Use more of the shared engine setup data for legacy engine initialization. This time to simplify the irq initialization code. Signed-off-by: -
Tvrtko Ursulin authored
With the unified common engine setup done, and the execlist engine initialization loop clearly split into two phases, we can eliminate the separate legacy engine initialization code. v2: Fix cleanup path for legacy. v3: Rename constructors. (Chris Wilson) Signed-off-by:
-
Tvrtko Ursulin authored
Move the execlist engine setup to vfuncs so that the engine init loop is clearly split into the mode agnostic and specific steps. Signed-off-by:
-
Dave Gordon authored
intel_lrc.c has a table of "logical rings" (meaning engines), while intel_ringbuffer.c has separately open-coded initialisation for each engine. We can deduplicate this somewhat by using the same first-stage engine-setup function for both modes. So here we expose the function that transfers information from the static table of (all) known engines to the dev_priv->engine array of engines available on this device (adjusting the names along the way) and then embed calls to it in both the LRC and the legacy-mode setup. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk> Signed-off-by:
-
- 13 Jul, 2016 1 commit
-
-
Ville Syrjälä authored
Prior to gen6 we didn't have per-ring IMR registers, which means that since commit 61ff75ac ("drm/i915: Simplify enabling user-interrupts with L3-remapping") we're now masking off all interrupts when init_render_ring() gets called. That's rather rude. Let's limit the ring IMR frobbing to machines that actually have the per-ring IMR registers. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 61ff75ac ("drm/i915: Simplify enabling user-interrupts with L3-remapping") Signed-off-by:
-
- 12 Jul, 2016 3 commits
-
-
Chris Wilson authored
Make sure we keep kbuilder happy in all of its random configs by providing argument names for compile-time stubs. In file included from drivers/gpu/drm/i915/intel_dp_mst.c:27:0: drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_register': >> drivers/gpu/drm/i915/i915_drv.h:3612:48: error: parameter name omitted static inline int i915_debugfs_register(struct drm_i915_private *) {return 0;} ^~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_unregister': drivers/gpu/drm/i915/i915_drv.h:3613:51: error: parameter name omitted static inline void i915_debugfs_unregister(struct drm_i915_private *) {} Reported-by: 0day Signed-off-by: -
Chris Wilson authored
In commit 7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when appropriate") the owner field in the mutex was updated from being dependent upon CONFIG_SMP to using optimistic spin. Update our peek function to suite. Fixes:7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...") Reported-by:
Hong Liu <hong.liu@intel.com> Signed-off-by:
-
Chris Wilson authored
Now that the last couple of hacks have been removed from the runtime powermanagement users, we can fully enable the asserts by preventing the temptation to disable them when our code is buggy. Signed-off-by:
-
- 11 Jul, 2016 3 commits
-
-
Chris Wilson authored
Let's ensure that we cannot run indefinitely without the hangcheck worker being queued. We removed it from being kicked on every request because we were kicking it a few millions times in every hangcheck interval and only once is necessary! However, that leaves us with the issue of what if userspace never waits for a request, or runs out of resources, what if userspace just issues a request then spins on BUSY_IOCTL? Testcase: igt/gem_busy Signed-off-by:
-
Chris Wilson authored
Never go to sleep waiting on the GPU without first ensuring that we will get woken up. We have a choice of queuing the hangcheck before every schedule() or the first time we wakeup. In order to simply accommodate both the signaler and the ordinary waiter, move the queuing to the common point of enabling the irq. We lose the paranoid safety of ensuring that the hangcheck is active before the sleep, but avoid code duplication (and redundant hangcheck queuing). Testcase: igt/prime_busy Fixes: c81d4613 ("drm/i915: Convert trace-irq to the breadcrumb waiter") Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 10 Jul, 2016 2 commits
-
-
Chris Wilson authored
igt/prime_vgem (and others) depends upon VGEM so automatically select it when enabling i915 debugging. Signed-off-by:
-
Chris Wilson authored
igt/pm_rpm depends upon /dev/*/msr so automatically select it when enabling i915 debugging. Signed-off-by:
-
- 08 Jul, 2016 1 commit
-
-
Chris Wilson authored
One of the numerous VT-d workarounds we require is that the display hardware reads past the end of the buffer triggering VT-d faults. This is acknowledged in the code as being safe "since we fill the unused portions of the GGTT with the scratch page". Alas, that is no longer always true and so we trigger DMAR read faults. Skylake also requires another workaround to avoid mixing VT-d and unpopulated PTE, and so there we also need to ensure we fill unused entries with the scratch page. Reported-by:
Mike Lothian <mike@fireburn.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96584 Fixes: f7770bfd ("drm/i915: Skip clearing the GGTT on full-ppgtt systems") Signed-off-by:
David Weinehall <david.weinehall@intel.com>
-
- 07 Jul, 2016 8 commits
-
-
Rodrigo Vivi authored
Some Kabylake SKUs are going to use Kabypoint PCH. It is mainly for Halo and DT ones. >From our specs it doesn't seem that KBP brings any change on the display south engine. So let's consider this as a continuation of SunrisePoint, i.e., SPT+. Since it is easy to get confused by a letter change: KBL = Kabylake - CPU/GPU codename. KBP = Kabypoint - PCH codename. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96826 Link: http://patchwork.freedesktop.org/patch/msgid/1467418032-15167-1-git-send-email-rodrigo.vivi@intel.comSigned-off-by:
-
Tim Gore authored
This patch applies WaMediaPoolStateCmdInWABB which fixes a problem with the restoration of thread counts on resuming from RC6. References: HSD#2137167 Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Move the encoder cloning check to happen earlier in the modeset. The main benefit will be that the debug output from a failed modeset will be less confusing as output_types can not indicate an invalid configuration during the later computation stages. For instance, what happened to me was kms_setmode was attempting one of its invalid cloning checks during which it asked for DP+VGA cloning on HSW. In this case the DP .compute_config() was executed after the FDI .compute_config() leaving the DP link clock (1.62 in this case) in port_clock, and then later the FDI BW computation tried to use that as the FDI link clock (which should always be 2.7). 1.62 x 2 wasn't enough for the mode it was trying to use, and so it ended up rejecting the modeset, not because of an invalid cloning configuration, but because of supposedly running out of FDI bandwidth. Took me a while to figure out what had actually happened. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466621833-5054-12-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
With the output_types bitmask there's no need to loop through the encoders anymore when checking for HDMI+non-HDMI cloning. v2: Use output_types bitmask v3: Fix the logic to really check that there are no non-HDMI encoders Signed-off-by:
-
Ville Syrjälä authored
has_dsi_encoder was introduced to indicate that the pipe is driving a DSI encoder. Now that we have the output_types bitmask that can tell us the same thing, let's just kill has_dsi_encoder. v2: Rebase, handle BXT DSI transcoder, rewrote commit message Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
INTEL_OUTPUT_DISPLAYPORT hsa been bugging me for a long time. It always looks out of place besides INTEL_OUTPUT_EDP and INTEL_OUTPUT_DP_MST. Let's just rename it to INTEL_OUTPUT_DP. v2: Rebase Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Ville Syrjälä authored
A bunch of places still look for DP encoders manually. Just call intel_crtc_has_dp_encoder(). Note that many of these places don't look for EDP or DP_MST, but it's still fine to replace them because * for audio we don't enable audio on eDP anyway * the code that lack DP MST check is only for plaforms that don't support MST anyway v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
Use the new output_types bitmask instead of has_dp_encoder. To make it less oainlful provide a small helper (intel_crtc_has_dp_encoder()) to do the bitsy stuff. v2: Rebase Signed-off-by:
-
