- 28 Sep, 2018 4 commits
-
-
Dhinakaran Pandiyan authored
A crtc modeset lock was added for link retraining but intel_dp_retrain_link() knows to take the necessary locks since commit c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") v2: Drop AUX power domain reference in the early return path Fixes: c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-4-dhinakaran.pandiyan@intel.com
-
Dhinakaran Pandiyan authored
We have two cases of intel_dp to intel_encoder conversions, use a local variable to store the conversion. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
Commit '3cf71bc9 ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")' applies a work around for sinks that don't signal link loss. The work around does not need to have to be that broad as the issue was seen with only one particular monitor; limit this only for external displays as eDP features like PSR turn off the link and the driver ends up retraining the link seeeing that link is not synchronized. Cc: Lyude Paul <lyude@redhat.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> References: 3cf71bc9 ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") Signed-off-by:
-
Dhinakaran Pandiyan authored
Comment claims link needs to be retrained because the connected sink raised a long pulse to indicate link loss. If the sink did so, intel_dp_hotplug() would have handled link retraining. Looking at the logs in Bugzilla referenced in commit '3cf71bc9 ("drm/i915: Re-apply Perform link quality check, unconditionally during long pulse"")', the issue is that the sink does not trigger an interrupt. What we want is ->detect() from user space to check link status and retrain. Ville's review for the original patch also indicates the same root cause. So, rewrite the comment. v2: Patch split and rewrote comment. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> References: 3cf71bc9 ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") Signed-off-by:
-
- 27 Sep, 2018 16 commits
-
-
Chris Wilson authored
If the request is currently on the HW (in port 0), then we do not need to kick the submission tasklet to evaluate whether we should be preempting itself in order to execute it again. In the case that was annoying me: execlists_schedule: rq(18:211173).prio=0 -> 2 need_preempt: last(18:211174).prio=0, queue.prio=2 We are bumping the priority of the first of a pair of requests running in the current context. Then when evaluating preempt, we would see that that our priority request is higher than the last executing request in ELSP0 and so trigger preemption, not realising that our intended request was already executing. v2: As we assume state of the execlists->port[] that is only valid while we hold the timeline lock we have to repeat some earlier tests that on the validity of the node. v3: Wrap guc submission under the timeline.lock as is now the way of all things. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180925083205.2229-2-chris@chris-wilson.co.uk
-
Jani Nikula authored
Use uniform prefixes for firmware path, version and size. Unify alignments. Order macro groups as in the if ladder using them. Add platform specific max firmware size macros for all platforms for clarity in the if ladder. Place the max firmware size macros in the platform specific macro groups. No functional changes. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927075311.5076-1-jani.nikula@intel.com
-
Hans de Goede authored
So far we have only been calling drm_connector_init_panel_orientation_property(), which checks for panel orientation quirks in the drm_panel_orientation_quirks.c file, for DSI panels as so far only devices with DSI panels have had panels which are not mounted up right. The new GPD win2 device uses a portrait screen in a landscape case, so now we've a device with an eDP panel which needs the panel-orientation property to let the fbcon code and userspace know that the image needs to be fixed-up. This commit makes intel_edp_init_connector() call drm_connector_init_panel_orientation_property() so that the property gets added. Reported-and-tested-by: russianneuromancer@ya.ru Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180909133457.10636-2-hdegoede@redhat.com
-
Chris Wilson authored
Now that we are confident in providing full-ppgtt where supported, remove the ability to override the context isolation. v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted. v3: s/USES/HAS/ to match usage and reject attempts to load the module on old GVT-g setups that do not provide support for full-ppgtt. v4: Insulate ABI ppGTT values from our internal enum (later plans involve moving ppGTT depth out of the enum, thus potentially breaking ABI unless we document the current values). Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by:
Zhi Wang <zhi.a.wang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926201222.5643-1-chris@chris-wilson.co.uk
-
Tvrtko Ursulin authored
We mix hexa- and decimal which is confusing when reading the logs. So make the single odd one out instance decimal for consistency. v2: * Do the intel_ringbuffer.c as well. (Chris Wilson) Signed-off-by:
-
Tvrtko Ursulin authored
Partial views are small but there can be many of them, and since the sg list space for them is allocated pessimistically, we can save some slab by trimming the unused tail entries. Signed-off-by:
-
Chris Wilson authored
Very light stress test to bombard the submission backends with a large stream with requests of randomly assigned priorities. Preemption will be occasionally requested, but unlikely to ever succeed! (Although we may build a long queue of requests and so may trigger an attempt to inject a preempt context, as we emit no batch, the arbitration window is limited to between requests inside the ringbuffer. The likelihood of actually causing a preemption event is therefore very small. A later variant should try to improve the likelihood of preemption events!) v2: Include a second pattern with more frequent preemption Signed-off-by:
-
Jani Nikula authored
With i915.dmc_firmware_path="" it's obvious the intention is to disable CSR firmware loading. Bypass the firmware request altogether in this case, with more obvious debug logging. v2: Use DRM_INFO for logging (Chris) Reviewed-by:
-
Jani Nikula authored
Move max firmware size to the same if ladder with firmware name and required version. This allows us to detect the missing max size for a platform without actually loading the firmware, and makes the whole thing easier to maintain. We need to move the power get earlier to allow for early return in the missing platform case. While at it, extend the comment on why we return with the reference held on errors. We also need to move the module parameter override later to reuse the max firmware size, which is independent of the override. v2: Add comment on why we leak the wakeref on errors (Chris) v3: Rebase Reviewed-by:
-
Jani Nikula authored
Having two separate if ladders gets increasingly hard to maintain. Put them together. v2: Rebase Reviewed-by:
-
José Roberto de Souza authored
A few line above we have another definition of intel_update_rawclk() keeping that one as the function is implemented in intel_cdclk.c. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
José Roberto de Souza authored
symmetric_memory do not change after initialization so lets just set ipc_enabled once for this WA. Reviewed-by:
-
José Roberto de Souza authored
SKL has IPC but it should not be set according to the WA, so lets just mark as it don't have it to simply the code and avoid unnecessary MMIO writes at every call to intel_enable_ipc(). Reviewed-by:
-
José Roberto de Souza authored
IPC was only added in SKL+(actually we don't even enable for SKL due WA) so without this change, driver was writing to a reserved bit. Also removing the uncessary dev_priv->ipc_enabled = false; as now gens without IPC will not have IPC enabled. v2(Rodrigo): - moved the new handling of WA #0477 to the next patch Reviewed-by:
-
José Roberto de Souza authored
Right now RESET_PCH_HANDSHAKE_ENABLE is enabled all the times inside of intel_power_domains_init_hw() and if PCH is NOP it is unsed in i915_gem_init_hw(). So making skl_pch_reset_handshake() handle both cases and calling it for the missing gens in intel_power_domains_init_hw(). Ivybridge have a different register and bits but with the same objective so moving it too. v2(Rodrigo): - handling IVYBRIDGE case inside intel_pch_reset_handshake() v4(Rodrigo and Ville): - moving the enable/disable decision to callers Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Instead of have the same code spread into 4 platforms lets share it. BXT do not have a PCH so here also handling this case by unseting RESET_PCH_HANDSHAKE_ENABLE. v2(Rodrigo): - renamed to intel_pch_reset_handshake() - added comment about why BXT need the bit to be unset v3(Rodrigo and Ville): - added bool have_pch to intel_pch_reset_handshake() - added back BXT comment Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 26 Sep, 2018 5 commits
-
-
Madhav Chauhan authored
This patch defines DSI_TA_TIMING_PARAM and DPHY_TA_TIMING_PARAM registers used in dphy programming. v2: Changes (Jani N) - Define mask/shift for bitfields - Use bitfields name as per BSPEC - Define remaining bitfields Signed-off-by:Madhav Chauhan <madhav.chauhan@intel.com> Signed-off-by:
-
Madhav Chauhan authored
This patch defines DSI_CLK_TIMING_PARAM, DPHY_CLK_TIMING_PARAM, DSI_DATA_TIMING_PARAM, DPHY_DATA_TIMING_PARAM register used in dphy programming. v2: Define mask/shift for bitfields and keep names as per BSPEC (Jani N) Signed-off-by:
-
Chris Wilson authored
/kisskb/src/drivers/gpu/drm/i915/i915_irq.c: warning: 'gu_misc_iir' may be used uninitialized in this function [-Wuninitialized]: => 3120:10 Silence the compiler warning by ensuring that the local variable is initialised and removing the guard that is confusing the older gcc. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Fixes: df0d28c1 ("drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926104718.17462-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
In commit 9144d75e ("include/linux/bitops.h: introduce BITS_PER_TYPE"), we made BITS_PER_TYPE available to all and now we can use the macro to replace some open-coded computation of sizeof(T) * BITS_PER_BYTE. Suggested-by:
-
Jani Nikula authored
Catch up in general, and get DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT specifically. Signed-off-by:
-
- 25 Sep, 2018 5 commits
-
-
Ville Syrjälä authored
commit 4e0b83a5 ("drm/i915: Extract per-platform plane->check() functions") removed the plane max stride check for sprite planes. I was going to add it back when introducing GTT remapping for the display, but after further thought it seems better to re-introduce it separately. So let's add the max stride check back. And let's do it in a nicer form than what we had before and do it for all plane types (easy now that we have the ->max_stride() plane vfunc). Only sprite planes really need this for now since primary planes are capable of scanning out the current max fb size we allow, and cursors have more stringent stride checks elsewhere. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: 4e0b83a5 ("drm/i915: Extract per-platform plane->check() functions") Signed-off-by:
-
Juha-Pekka Heikkila authored
From gen11 onwards RGB565 90/270 plane rotation is supported on hardware. IGT: https://patchwork.freedesktop.org/series/48756/Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1535373473-3594-3-git-send-email-juhapekka.heikkila@gmail.com
-
Chris Wilson authored
Our execlist dispatch code requires a ppGTT so make sure we enforce that option in intel_sanitize_enable_ppgtt(). The comment already tries to explain that execlists requires ppgtt, but was written when gen8 may have also taken the legacy path; so rewrite the code to match the comment by using HAS_EXECLISTS() feature instead of the gen. Signed-off-by:
-
Mahesh Kumar authored
This cleanup patch makes changes to use for_each_pipe loop during bit-mask assignment of allowed crtc with encoder. changes: - use BIT(i) macro instead of (1 << i) (Chris) changes from V2: - use int for consistency (Jani) changes from V3: - instead use enum pipe (Ville) changes from V4: - drop DP/HDMI changes, as already part of patch from ville Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Chris Wilson authored
In the sequence <0>[ 531.960431] drv_self-4806 7.... 527402570us : intel_gpu_reset: engine_mask=1, ret=0, retry=0 <0>[ 531.960431] drv_self-4806 7.... 527402571us : execlists_reset: rcs0 request global=115de, current=71133 <0>[ 531.960431] drv_self-4806 7d..1 527402571us : execlists_cancel_port_requests: rcs0:port0 global=71134 (fence 826b:198), (current 71133) <0>[ 531.960431] drv_self-4806 7d..1 527402572us : execlists_cancel_port_requests: rcs0:port1 global=71135 (fence 826c:53), (current 71133) <0>[ 531.960431] drv_self-4806 7d..1 527402572us : __i915_request_unsubmit: rcs0 fence 826c:53 <- global=71135, current 71133 <0>[ 531.960431] drv_self-4806 7d..1 527402579us : __i915_request_unsubmit: rcs0 fence 826b:198 <- global=71134, current 71133 <0>[ 531.960431] drv_self-4806 7.... 527402613us : intel_engine_cancel_stop_cs: rcs0 <0>[ 531.960431] drv_self-4806 7.... 527402624us : execlists_reset_finish: rcs0 we are missing the execlists_submission_tasklet() invocation before the execlists_reset_fini() implying that either the queue is empty, or we failed to schedule and run the tasklet on finish. Add an assert so we are sure that on unsubmitting the incomplete request after reset, the queue is indeed populated. Signed-off-by:
-
- 24 Sep, 2018 4 commits
-
-
Madhav Chauhan authored
This patch programs the time (in escape clocks) to drive the link in the initialization (i.e. LP-11) state. v2: Rebase v3: Remove step hard coding comments (Jani N) Signed-off-by:
-
Madhav Chauhan authored
This patch enables DDI buffer by writing to DDI_BUF_CTL register and wait for DDI status to be *not idle* for a port. v2: Rebase v3: Remove step hard coding comments (Jani N) Signed-off-by:
-
Madhav Chauhan authored
This patch setup voltage swing before enabling combo PHY DDI (shared with DSI). Note that DSI voltage swing programming is for high speed data buffers. HW automatically handles the voltage swing for the low power data buffers. v2: Rebase v3: Address various review comments related to VSWING programming (Jani N) Signed-off-by: -
Madhav Chauhan authored
This patch set the loadgen select and latency optimization for aux and transmit lanes of combo phy transmitters. It will be used for MIPI DSI HS operations. v2: Rebase v3: Add empty line to make code more legible (Ville). Signed-off-by:
-
- 21 Sep, 2018 6 commits
-
-
Maarten Lankhorst authored
We can't make NV12 work any other way. The scaler doesn't handle odd coordinates well, and we will get visual corruption on the screen. Changes since v1: - Put the check in intel_plane_check_src_coordinates. (Ville) Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-9-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
This cleans the code up slightly, and will make other changes easier. Signed-off-by:
-
Maarten Lankhorst authored
On skylake we can switch to a high quality scaler mode when only 1 out of 2 scalers are used, but on GLK and later bit 28 has a different meaning. Don't set it, and make clear the distinction between SKL and later PS values. Changes since v1: - Add missing break statement. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_commit_planes_on_crtc calls begin_commit, then plane_update hooks, then flush_commit. Because we keep our own visibility tracking through plane_state->visible there's no need to rely on the atomic hooks for this. By explicitly writing our own helper, we can update visible planes as needed, which is useful to make NV12 support work as intended. Changes since v1: - Reword commit message. (Matt Roper) - Rename to intel_update_planes_on_crtc(). (Matt) Signed-off-by:
-
Maarten Lankhorst authored
This will only disable planes we actually had marked as visible in crtc_state->visible_planes and cleans up intel_crtc_disable_plane() slightly. This is also useful for when we start enabling NV12 support for gen11, in which we will make the separate Y plane visible, but ignore the Y plane's state. Signed-off-by:
-
Maarten Lankhorst authored
We need to assume the plane has been visible before, even if no CRTC is assigned to the plane. This is because when enabling a nv12 plane on gen11, we will have to enable an extra plane and make it visible by marking it in crtc_state->active_planes for intel_update_planes_on_crtc(). Additionally, clear visible flag in intel_plane_atomic_check, in case we ever hit a bug with visibility. Our code implicitly assumes that plane_state->visible is only true when crtc and fb are set, so we will either null deref in intel_fbc_choose_crtc() or do something bad during the actual commit which cares even more. Changes since v1: - Unconditionally clear crtc_state->active_planes as well. - Reword commit message, since this is now a preparation patch for NV12 Y / UV plane linking. Signed-off-by:
-
