- 06 Mar, 2020 1 commit
-
-
Mika Kuoppala authored
This patch adds framework to submit an arbitrary batchbuffer on each context switch to clear residual state for render engine on Gen7/7.5 devices. The idea of always emitting the context and vm setup around each request is primary to make reset recovery easy, and not require rewriting the ringbuffer. As each request would set up its own context, leaving it to the HW to notice and elide no-op context switches, we could restart the ring at any point, and reorder the requests freely. However, to avoid emitting clear_residuals() between consecutive requests in the ringbuffer of the same context, we do want to track the current context in the ring. In doing so, we need to be careful to only record a context switch when we are sure the next request will be emitted. This security mitigation change does not trigger any performance regression. Performance is on par with current mainline/drm-tip. v2: Update vm_alias params to point to correct address space "vm" due to changes made in the patch "f2161379" v3-v4: none Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Balestrieri Francesco <francesco.balestrieri@intel.com> Cc: Bloomfield Jon <jon.bloomfield@intel.com> Cc: Dutt Sudeep <sudeep.dutt@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 05 Mar, 2020 9 commits
-
-
Chris Wilson authored
Show the timeslicing priority hint in engine dumps to aide debugging. Signed-off-by:
-
Chris Wilson authored
Requests within a timeline are ordered by that timeline, so awaiting for the start of a request within the timeline is a no-op. This used to work by falling out of the mutex_trylock() as the signaler and waiter had the same timeline and not returning an error. Fixes: 6a79d848 ("drm/i915: Lock signaler timeline while navigating") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200305134822.2750496-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Fix the inverted test to emit the wait on the end of the previous request if we /haven't/ already. Fixes: 6a79d848 ("drm/i915: Lock signaler timeline while navigating") Signed-off-by:
-
Swati Sharma authored
Converting error to debug print if sink fails to configure scrambling or TMDS bit clock ratio. In this case, we are timing out while disabling the scrambling and setting the SCDC ratio, as there is no response to the I2C SCDC write from the sink device. Error isn't due to something wrong done from driver side. Signed-off-by:
Swati Sharma <swati2.sharma@intel.com> Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Display w/a #1140 tells us we have to program the transition watermark to the minimum value on glk/cnl. Let's do that. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228203552.30273-4-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
We are mistakenly skipping transition watermarks on glk. Fix up the condition for glk, and toss in the w/a name from the database. v2: Reorder the ipc enabled vs. platform check to be more sensible Signed-off-by:
-
Ville Syrjälä authored
Currently we're comparing the watermarks between the old and new states before we've fully computed the new watermarks. In particular skl_build_pipe_wm() will not account for the amount of ddb space we'll have. That information is only available during skl_compute_ddb() which will proceed to zero out any watermark level exceeding the ddb allocation. If we're short on ddb space this will end up adding the plane to the state due erronously determining that the watermarks have changed. Fix the problem by deferring skl_wm_add_affected_planes() until we have the final watermarks computed. Noticed this when trying enable transition watermarks on glk. We now computed the trans_wm as 28, but we only had 14 blocks of ddb, and thus skl_compute_ddb() ended up disabling the cursor trans_wm every time. Thus we ended up adding the cursor to every commit that didn't actually affect the cursor at all. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
The hardware never sees the uv_wm values (apart from uv_wm.min_ddb_alloc affecting the ddb allocation). Thus there is no point in comparing uv_wm to determine if we need to reprogram the watermark registers. So let's check only the rgb/y watermark in skl_plane_wm_equals(). But let's leave a comment behind so that the next person reading this doesn't get as confused as I did when I added this check. If the ddb allocation ends up changing due to uv_wm skl_ddb_add_affected_planes() takes care of adding the plane to the state. TODO: we should perhaps just eliminate uv_wm from the state and simply track the min_ddb_alloc for uv instead. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
Enable FtrPerCtxtPreemptionGranularityControl bit and select thread- group as the default preemption level. v2: * Remove register whitelisting (Rafael, Tony). Signed-off-by:
Rafael Antognolli <rafael.antognolli@intel.com> Acked-by:
Jason Ekstrand <jason@jlekstrand.net> Acked-by:
Tony Ye <tony.ye@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200304153144.10675-1-tvrtko.ursulin@linux.intel.com
-
- 04 Mar, 2020 12 commits
-
-
Chris Wilson authored
As we started marking the ce->gem_context as NULL on closure, we can no longer use that to carry closure information. Instead, we can look at whether the context was killed on closure instead. Fixes: 130a95e9 ("drm/i915/gem: Consolidate ctx->engines[] release") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1379Signed-off-by:
-
Hans de Goede authored
The Thundersoft TST178 tablet uses a DSI panel with an external PWM controller (as all DSI panels do). But unlike other DSI panels a duty-cycle of 100% turns the backlight off and 0% sets it to maximum brightness. I've checked the VBT and there is a BDB_LVDS_BACKLIGHT section, but it does not set the active_low_pwm flag. This tablet re-uses the main PCI vendor and product ids for the subsystem ids, so I see no other option then to add a DMI based quirk to fix this. Note that the PWM backlight code in intel_panel.c currently does not honor the vbt.active_low_pwm flag, but that does not matter in this case. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-2-hdegoede@redhat.com
-
Hans de Goede authored
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that we correctly take i915_modparams.invert_brightness and/or QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial brightness value. Signed-off-by:
-
Chris Wilson authored
As we release the head requests back into the queue, propagate any change in error status that may have occurred while the requests were temporarily suspended. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1277Signed-off-by:
-
Chris Wilson authored
Trying to use i915_request_skip() prior to i915_request_add() causes us to try and fill the ring upto request->postfix, which has not yet been set, and so may cause us to memset() past the end of the ring. Instead of skipping the request immediately, just flag the error on the request (only accepting the first fatal error we see) and then clear the request upon submission. Signed-off-by:
-
Matt Roper authored
intel_ddi_clock_get() tests the DPLL ID against DPLL_ID_ICL_TBTPLL (2) to determine whether to try to descend into a TBT-specific handler. However this test will also be true when DPLL4 on EHL is used since that shares the same DPLL ID (2). Add an extra check to ensure the PHY is actually a Type-C PHY before descending into the TBT handling. This should ensure EHL still takes the correct code path and somewhat future-proof the code as well. v2: Drop the gen+ check since only gen11+ platforms can have Type-C outputs. (Imre) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Imre Deak <imre.deak@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1369 Fixes: 45e4728b ("drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.c") Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303195043.959913-1-matthew.d.roper@intel.com
-
Chris Wilson authored
drivers/gpu/drm/i915/gvt/gvt.c:264:6: error: no previous prototype for ‘intel_gvt_clean_device’ [-Werror=missing-prototypes] drivers/gpu/drm/i915/gvt/gvt.c:301:5: error: no previous prototype for ‘intel_gvt_init_device’ [-Werror=missing-prototypes] Signed-off-by:
-
Lyude Paul authored
According to Dell, trying to match their panels via OUI is not reliable enough and we've been told that we should check against the EDID instead. As well, Dell seems to have some panels that are actually intended to switch between using PWM for backlight controls and DPCD for backlight controls depending on whether or not the panel is in HDR or SDR mode. Yikes. Regardless, we need to add quirks for these so that DPCD backlight controls get enabled by default, since without additional driver support that's the only form of brightness control that will work. Hopefully in the future we can remove these quirks once we have a better way of probing for this. Changes since v1: * Add one more EDID per Dell's request * Remove model number (which is possibly wrong) and replace with Dell CML 2020 systems Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-4-lyude@redhat.comReviewed-by:
Adam Jackson <ajax@redhat.com>
-
Lyude Paul authored
The X1 Extreme is one of the systems that lies about which backlight interface that it uses in its VBIOS as PWM backlight controls don't work at all on this machine. It's possible that this panel could be one of the infamous ones that can switch between PWM mode and DPCD backlight control mode, but we haven't gotten any more details on this from Lenovo just yet. For the time being though, making sure the backlight 'just works' is a bit more important. So, add a quirk to force DPCD backlight controls on for these systems based on EDID (since this panel doesn't appear to fill in the device ID). Hopefully in the future we'll figure out a better way of probing this. Changes since v2: * The bugzilla URL is deprecated, bug reporting happens on gitlab now. Update the messages we print to reflect this * Also, take the opportunity to move FDO_BUG_URL out of i915_utils.c and into i915_utils.h so that other places which print things that aren't traditional errors but are worth filing bugs about, can actually use it. Signed-off-by:
-
Lyude Paul authored
The whole point of using OUIs is so that we can recognize certain devices and potentially apply quirks for them. Normally this should work quite well, but there appears to be quite a number of laptop panels out there that will fill the OUI but not the device ID. As such, for devices like this I can't imagine it's a very good idea to try relying on OUIs for applying quirks. As well, some laptop vendors have confirmed to us that their panels have this exact issue. So, let's introduce the ability to apply DP quirks based on EDID identification. We reuse the same quirk bits for OUI-based quirks, so that callers can simply check all possible quirks using drm_dp_has_quirk(). Signed-off-by:
-
Anshuman Gupta authored
DP shim's config_stream_type considered to be succeeded when return value of intel_dp_hdcp2_write_msg() equals to size of message to be written, it makes config_stream_type to return a zero success value in order to succeed the HDCP auth. v2: - config_stream_type() returns 0 on success. [Ram] CC: Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
-
Anshuman Gupta authored
HDCP Repeater initializes seq_num_V to 0 at the beginning of hdcp Session i.e. after AKE_init received, refer HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20. HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT considers failure of authentication if the repeater provides a non-zero value in seq_num_V in the first, RepeaterAuth_Send_ReceiverID_List message. Make sure that HDCP repeater initializes seq_num_V to zero at beginning of session i.e. after AKE_Init, fail the Auth if there is non zero seq_num_V. v2: - Used existing hdcp2_encrypted flag instead of declaring new flag. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
-
- 03 Mar, 2020 18 commits
-
-
Chris Wilson authored
As we no longer stash anything inside i915_vma under the exclusive protection of struct_mutex, we do not need to revoke the i915_vma stashes before dropping struct_mutex to handle pagefaults. Knowing that we must drop the struct_mutex while keeping the eb->vma around, means that we are required to hold onto to the object reference until we have marked the vma as active. Fixes: 155ab883 ("drm/i915: Move object close under its own lock") Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
For our convenience, and to avoid frequent allocations, we placed some lists we use for execbuf inside the common i915_vma struct. As we look to parallelise execbuf, such fields guarded by the struct_mutex BKL must be pulled under local control. Instead of using the i915_vma as our primary means of tracking the user's list of objects and their virtual mappings, we use a local eb_vma with the same lists as before (just now local not global). This should allow us to only perform the lookup of vma used for execution once during the execbuf ioctl, as currently we need to remove our secrets from inside i915_vma everytime we drop the struct_mutex as another execbuf may use the shared locations. Once potential user visible consequence is that we can remove the requirement that the execobj[] be unique, and only require that they do not conflict (i.e. you cannot softpin the same object into two locations. Signed-off-by:
-
Chris Wilson authored
With the goal of removing the serialisation from around execbuf, we will no longer have the privilege of there being a single execbuf in flight at any time and so will only be able to inspect the user's flags within the carefully controlled execbuf context. i915_gem_evict_for_node() is the only user outside of execbuf that currently peeks at the flag to convert an overlapping softpinned request from ENOSPC to EINVAL. Retract this nicety and only report ENOSPC if the location is in current use, either due to this execbuf or another. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-1-chris@chris-wilson.co.uk
-
José Roberto de Souza authored
Following the changes in the previous patch "drm/i915/gen11: Moving WAs to rcs_engine_wa_init()" also moving TGL Wa_1408615072 to rcs_engine_wa_init() this way after a engine reset it will be reapplied also restricting it to A0 as it is fixed in B0 stepping. BSpec: 52890 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
José Roberto de Souza authored
This are register of render engine, so after a render reset those would return to the default value and init_clock_gating() is not called for single engine reset. So here moving it rcs_engine_wa_init() that will guarantee that this WAs will not be lost. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Aditya Swarup authored
Static code analysis tool identified struct lrc_timestamp data as being uninitialized and then data.ce[] is being checked for NULL/negative value in the error path. Initializing data variable fixes the issue. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Reviewed-by:
-
Chris Wilson authored
As we have pinned the timeline (using tl->active_count), we can safely drop the tl->mutex as we wait for what we believe to be the final request on that timeline. This is useful for ensuring that we do not block the engine heartbeat by hogging the kernel_context's timeline on a dead GPU. References: https://gitlab.freedesktop.org/drm/intel/issues/1364 Fixes: 058179e7 ("drm/i915/gt: Replace hangcheck by heartbeats") Fixes: f33a8a51 ("drm/i915: Merge wait_for_timelines with retire_request") Signed-off-by:
-
Chris Wilson authored
The is-closed flag may be added after we have acquired the vma under the ctx->mutex, but will not take effect until after we release the vm->mutex. i.e. the flag may be set on the vma as attempt to bind it and that will cause the vma to be unbound later after we unpin it. Signed-off-by:
-
Chris Wilson authored
As setup takes a long time, the user may close the context during the construction of the execbuf. In order to make sure we correctly track all outstanding work with non-persistent contexts, we need to serialise the submission with the context closure and mop up any leaks. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
If a context is banned even before we submit our first request to it, report the failure before we attempt to allocate any resources for the context. Signed-off-by:
-
Chris Wilson authored
Use the same engine_idle_release() routine for cleaning all old ctx->engine[] state, closing any potential races with concurrent execbuf submission. v2ish: Use the ce->pin_count to close the execbuf gap. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241Signed-off-by:
-
Ville Syrjälä authored
It irks me to use crtc_state_is_legacy_gamma() inside the guts of the CHV color management code. Let's get rid of it and instead just consult cgm_mode to figure out if we want to enable the pipe gamma or the CGM gamma. Also CHV display engine is based on i965/g4x so we should fall back to the i965 path when the CGM gamma is not used. Signed-off-by:
-
Jani Nikula authored
i915_drv.c is the only caller. Reviewed-by:
-
Jani Nikula authored
Nobody else uses it. Signed-off-by:
-
Jani Nikula authored
Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to intel_vgpu_detect() to match other function naming, un-inline intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and intel_vgpu_has_huge_gtt() to reduce header interdependencies. The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Anshuman Gupta authored
has_transcoder() was unused because function which was using it, intel_display_capture_error_state() defined under CONFIG_DRM_I915_CAPTURE_ERROR. Moving has_transcoder() to under CONFIG_DRM_I915_CAPTURE_ERROR. No functional change. Fixes: d54c1a51 ("drm/i915: Fix broken transcoder err state") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by:
kbuild test robot <lkp@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227175147.11362-1-anshuman.gupta@intel.com
-
Ramalingam C authored
Converts remaining instances of the printk based logging macros in i915/display/intel_hdcp.c with the struct drm_device based macros manually. This is continuation of commit 65833c46 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.") v2: i915_dev_priv is used instead of drm_device for reusability [JaniN] v3: Made it independent from the series. once instance of dev_priv naming is changed to i915 [Jani N] Signed-off-by:
Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212123007.6659-1-ramalingam.c@intel.com
-
Jani Nikula authored
Shrink i915_drv.h a bit by moving watermark structs where they are needed. Reviewed-by:
-
