- 04 Mar, 2020 6 commits
-
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200304002331.2126072-1-chris@chris-wilson.co.uk
-
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 22 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 <jose.souza@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302231421.224322-2-jose.souza@intel.com
-
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:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303140009.1494819-1-chris@chris-wilson.co.uk
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-3-ville.syrjala@linux.intel.comReviewed-by:
Swati Sharma <swati2.sharma@intel.com>
-
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:
-
Chris Wilson authored
Update locations for ./drivers/gpu/drm/i915/i915_vma.h:1: warning: 'Virtual Memory Address' not found ./drivers/gpu/drm/i915/i915_gem_gtt.c:1: warning: 'Global GTT views' not found Signed-off-by:
-
José Roberto de Souza authored
New firmware contains minor fixes around context restore. Reviewed-by:
-
Jani Nikula authored
intel_csr.c was moved under display. Fixes: 06d3ff6e ("drm/i915: move intel_csr.[ch] under display/") Reported-by:
-
Daniele Ceraolo Spurio authored
Update to the latest available TGL HuC, which includes changes required by the media team. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Tony Ye <tony.ye@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200229012042.27487-1-daniele.ceraolospurio@intel.com
-
- 02 Mar, 2020 12 commits
-
-
Chris Wilson authored
We only use sentinel requests for "preempt-to-idle" passes, so assert that they are the only request in a new submission. Signed-off-by:
-
Chris Wilson authored
We still need to wait for the initial OA configuration to happen before we enable OA report writes to the OA buffer. Reported-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 15d0ace1 ("drm/i915/perf: execute OA configuration from command stream") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1356 Testcase: igt/perf/stream-open-close Signed-off-by:
-
José Roberto de Souza authored
Just to make easier to check that the Wa was implemetend when comparing to the number in BSpec. BSpec: 52890 Signed-off-by:
-
José Roberto de Souza authored
Different issues with the same fix, so justing adding Wa_1409142259, Wa_1409252684, Wa_1409217633, Wa_1409207793, Wa_1409178076 and 1408979724 to the comment so other devs can check if this Was were implemetend with a simple grep. Signed-off-by:
-
José Roberto de Souza authored
The Wa number for this fix is Wa_1607087056 the BSpec bug id is 1607087056, just updating to match BSpec. BSpec: 52890 Signed-off-by:
-
José Roberto de Souza authored
This issue workaround in Wa_1607063988 has the same fix as Wa_1607138336, so just adding a note in the code. Reviewed-by:
-
José Roberto de Souza authored
Add note about the confliting information in BSpec about this WA. BSpec: 52890 Acked-by:
-
Anusha Srivatsa authored
According to BSpec. Wa_1606931601 applies for all TGL steppings. This patch moves the WA implementation out of A0 only block of rcs_engine_wa_init(). The WA is has also been referred to by an alternate name Wa_1607090982. Bspec: 46045, 52890 Fixes: 3873fd1a ("drm/i915: Use engine wa list for Wa_1607090982") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Atwood authored
Disable Push Constant buffer addition for TGL. v2: typos, add additional Wa reference v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit message. Bspec: 52890 Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
José Roberto de Souza authored
This will whitelist the HIZ_CHICKEN register so mesa can disable the optimizations and avoid hang when using D16_UNORM. v2: moved to the right place and used the right function() (Chris) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
José Roberto de Souza authored
This workaround the CS not done issue on PIPE_CONTROL. v2: - replaced BIT() by REG_BIT() in all GEN7_ROW_CHICKEN2() bits - shortened the name of the new bit BSpec: 52890 BSpec: 46218 Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Imre Deak authored
All platforms using the shared DPLL framework use 3 reference clocks for their DPLLs: SSC, non-SSC and DSI. For a more unified way across platforms store the frequency of these ref clocks as part of the DPLL global state. This also allows us to keep the HW access reading out the ref clock value separate from the DPLL frequency calculation that depends on the ref clock. For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code has its own logic for calculating DPLL parameters instead of the shared DPLL framework. v2: - Apply the ICL combo PHY PLL ref_clock/2 adjustment during the frequency->PLL param conversion direction as well. (CI shards) - s/kHZ/kHz/ (Ville) Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
