summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-02-23drm/i915: make dbuf configurations constJani Nikula
Ensure const data goes to rodata. Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200219154542.19574-1-jani.nikula@intel.com
2020-02-23drm/i915: split i915_driver_modeset_probe() to pre/post irq installJani Nikula
Pair the irq install and uninstall in the same layer. There are no functional changes in the happy day scenario. The cleanup paths are currently a mess though. Note that modeset probe pre-irq + post-irq install are matched by modeset driver remove pre-irq + post-irq uninstall, together, but not independently. They are not symmetric pairs. v2: don't add a new probe failure point here Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200219133756.13224-1-jani.nikula@intel.com
2020-02-22drm/i915/gt: remove redundant assignment to variable dwColin Ian King
Variable dw is being initialized with a value that is never read, it is assigned a new value later on. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200222134755.134209-1-colin.king@canonical.com
2020-02-22drm/i915/gt: Push the GPU cancellation to the backendChris Wilson
Upon unregistering the user interface, we mark the GPU as wedged to ensure we push no new work to the GPU, and to flush all current work from the GPU. Move this call to the GT backend. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221235135.2883006-1-chris@chris-wilson.co.uk
2020-02-22drm/i915: Avoid recursing onto active vma from the shrinkerChris Wilson
We mark the vma as active while binding it in order to protect outselves from being shrunk under mempressure. This only works if we are strict in not attempting to shrink active objects. <6> [472.618968] Workqueue: events_unbound fence_work [i915] <4> [472.618970] Call Trace: <4> [472.618974] ? __schedule+0x2e5/0x810 <4> [472.618978] schedule+0x37/0xe0 <4> [472.618982] schedule_preempt_disabled+0xf/0x20 <4> [472.618984] __mutex_lock+0x281/0x9c0 <4> [472.618987] ? mark_held_locks+0x49/0x70 <4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60 <4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619122] i915_vma_unbind+0xae/0x110 [i915] <4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915] <4> [472.619208] i915_gem_shrink+0x328/0x660 [i915] <4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915] <4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80 <4> [472.619363] ? __alloc_pd+0xb/0x30 [i915] <4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30 <4> [472.619368] ? __module_address+0x23/0xe0 <4> [472.619371] ? is_module_address+0x26/0x40 <4> [472.619374] ? static_obj+0x34/0x50 <4> [472.619376] ? lockdep_init_map+0x4d/0x1e0 <4> [472.619407] setup_page_dma+0xd/0x90 [i915] <4> [472.619437] alloc_pd+0x29/0x50 [i915] <4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915] <4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915] <4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915] <4> [472.619577] __vma_bind+0x26/0x40 [i915] <4> [472.619611] fence_work+0x1c/0x90 [i915] <4> [472.619617] process_one_work+0x26a/0x620 Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") 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/20200221221818.2861432-1-chris@chris-wilson.co.uk
2020-02-21drm/i915/tgl: Add Wa_22010178259:tglMatt Roper
We need to explicitly set the TLB Request Timer initial value in the BW_BUDDY registers to 0x8 rather than relying on the hardware default. v2: Apply missing REG_FIELD_PREP to ensure 0x8 is placed in the correct bits during the rmw. (Jose) Bspec: 52890 Bspec: 50044 Fixes: 3fa01d642fa7 ("drm/i915/tgl: Program BW_BUDDY registers during display init") Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200219215655.2923650-1-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-02-21drm/i915: Check that the vma hasn't been closed before we insert itChris Wilson
As there is a delay before we pin a vma, there is an opportunity for another thread to have closed the vm and its vma (including us). Check as soon as we acquire the vm->mutex and know the vm/vma is stable. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1291 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221121940.2741563-1-chris@chris-wilson.co.uk
2020-02-21drm/i915/gem: Break up long lists of object reclaimChris Wilson
Call cond_resched() between each freed object in case we have a really, really long list, and we don't want to block normal processes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221100953.2587176-1-chris@chris-wilson.co.uk
2020-02-21drm/i915/pmu: Avoid using globals for PMU eventsMichał Winiarski
Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915, will cause us to try and double free the global state, hitting null ptr deref in free_event_attributes. Let's move it to i915_pmu. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200219161822.24592-2-michal.winiarski@intel.com
2020-02-21drm/i915/pmu: Avoid using globals for CPU hotplug stateMichał Winiarski
Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915 can lead to leaks and warnings from cpuhp: Error: Removing state XXX which has instances left. Let's move the state to i915_pmu. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200219161822.24592-1-michal.winiarski@intel.com
2020-02-21drm/i915/perf: conversion to struct drm_device based logging macros.Wambui Karuga
Manual conversion of instances of printk based drm logging macros to the struct drm_device based logging macros in i915/i915_perf.c. Also involves extraction of the struct drm_i915_private device from various intel types for use in the macros. Instances of the DRM_DEBUG printk macro were not converted due to the lack of an analogous struct drm_device based logging macro. v2: remove instances of DRM_DEBUG that were converted. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218173936.19664-1-wambui.karugax@gmail.com
2020-02-20drm/i915/tgl: Program MBUS_ABOX{1,2}_CTL during display initMatt Roper
On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL during display initialization, but on gen12 we're now supposed to program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well. v2: - Program registers with rmw to preserve contents of unrelated bits. - Switch to the new display uncore helpers. Bspec: 49213 Bspec: 50096 Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204011032.582737-2-matthew.d.roper@intel.com Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
2020-02-20drm/i915: Program MBUS with rmw during initializationMatt Roper
It wasn't terribly clear from the bspec's wording, but after discussion with the hardware folks, it turns out that we need to preserve the pre-existing contents of the MBUS ABOX control register when initializing a few specific bits. Bspec: 49213 Bspec: 50096 Fixes: 4cb4585e5a7f ("drm/i915/icl: initialize MBus during display init") Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204011032.582737-1-matthew.d.roper@intel.com Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
2020-02-20drm/i915: Use intel_de_write_fw() for skl+ scaler registersVille Syrjälä
We have to write quite a few registers when programming the pipe scaler. Let's use intel_de_write_fw() for these to reduce the lockdep overhead a bit. All plane registers (including plane scaler) already do this. We already had a few accidental intel_de_write_fw() in there. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915: Parametrize PFIT_PIPEVille Syrjälä
Make the PFIT_PIPE stuff less ugly via parametrization. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915: Mark all HPD capabled connectors as suchVille Syrjälä
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT} bits in intel_connector->polled (the base setting), leading to some confusing looking code to reset drm_connector->polled (the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd capable connectors, and then we don't need so many special cases in the hotplug code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915/hpd: Replace the loop-within-loop with two independent loopsVille Syrjälä
No point in looping over all connectors for each hpd pin. Just loop over each connector first and deal with each one's hpd pin. Then loop over all the hpd pins to mark them as enabled again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915: Add i9xx_lut_8()Ville Syrjälä
We have a nice little helper to compute a single LUT entry for everything except the 8bpc legacy gamma mode. Let's complete the set. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-5-ville.syrjala@linux.intel.com Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2020-02-21Merge tag 'drm-misc-next-2020-02-10' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.7: UAPI Changes: - lima: Add support for heap buffers Cross-subsystem Changes: Core Changes: - Implement mode_config mode_valid for memory constrained drivers - Bus format negociation between bridges - Consolidate fake vblank events for drivers without vblank interrupts - drm/bufs: dma_alloc related cleanups - drm/dp_mst: Various fixes - drm/print: New drm_device based print helpers - Thomas is a drm-misc maintainer now! Driver Changes: - DPMS cleanups for atomic drivers - Removal of owner field in SPI tinydrm drivers - Removal of explicit dependency on DT for tinydrm drivers - Conversion to YAML schemas for DT bindings - tidss: New driver - virtio: various reworks and fixes - Our usual dozen or so new panels or bridges Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200210093421.xu4sofldm6wm6xq6@gilmour.lan
2020-02-20drm/i915/uc: consolidate firmware cleanupDaniele Ceraolo Spurio
We are quite trigger happy in cleaning up the firmware blobs, as we do so from several error/fini paths in GuC/HuC/uC code. We do have the __uc_cleanup_firmwares cleanup function, which unwinds __uc_fetch_firmwares and is already called both from the error path of gem_init and from gem_driver_release, so let's stop cleaning up from all the other paths. The fact that we're not cleaning the firmware immediately means that we can't consider firmware availability as an indication of initialization success. A "LOADABLE" status has been added to indicate that the initialization was successful, to be used to selectively load HuC only if HuC init has completed (HuC init failure is not considered a fatal error). v2: s/ready_to_load/loadable (Michal), only run guc/huc_fini if the fw is in loadable state Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-9-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: Abort early on uc_init failureDaniele Ceraolo Spurio
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is restricted to running only if we have successfully fetched the required blob(s) and are committed to using the microcontroller(s). The only remaining thing that can go wrong in uc_init is the allocation of GuC/HuC related objects; if we get such a failure better to bail out immediately instead of wedging later, like we do for e.g. intel_engines_init, since without objects we can't use the HW, including not being able to attempt the firmware load. While at it, remove the unneeded fw_cleanup call (this is handled outside of gt_init) and add a probe failure injection point for testing. Also, update the logs for <g/h>uc_init failures to probe_failure() since they will cause the driver load to fail. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-8-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Apply new uC status tracking to GuC submission as wellDaniele Ceraolo Spurio
To be able to differentiate the before and after of our commitment to GuC submission, which will be used in follow-up patches to early set-up the submission structures. v2: move functions to guc_submission.h (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-7-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: Improve tracking of uC init statusDaniele Ceraolo Spurio
To be able to setup GuC submission functions during engine init we need to commit to using GuC as soon as possible. Currently, the only thing that can stop us from using the microcontrollers once we've fetched the blobs is a fundamental error (e.g. OOM); given that if we hit such an error we can't really fall-back to anything, we can "officialize" the FW fetching completion as the moment at which we're committing to using GuC. To better differentiate this case, the uses_guc check, which indicates that GuC is supported and was selected in modparam, is renamed to wants_guc and a new uses_guc is introduced to represent the case were we're committed to using the GuC. Note that uses_guc does still not imply that the blob is actually loaded on the HW (is_running is the check for that). Also, since we need to have attempted the fetch for the result of uses_guc to be meaningful, we need to make sure we've moved away from INTEL_UC_FIRMWARE_SELECTED. All the GuC changes have been mirrored on the HuC for coherency. v2: split fetch return changes and new macros to their own patches, support HuC only if GuC is wanted, improve "used" state description (Michal) v3: s/wants_huc/uses_huc in uc_init_wopcm Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-6-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: autogenerate uC checker functionsDaniele Ceraolo Spurio
We want to map uC-level checks to GuC/HuC-level ones. The mapping from the uC state to the GuC/HuC one follows the same pattern for all the functions: uc_xxx_guc() -> guc_is_yyy() So we can easily use a macro to autogenerate the functions via macros by passing in the 2 mapped states. v2: Split this change to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-5-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: Update the FW status on injected fetch errorDaniele Ceraolo Spurio
In a follow up patch we will rely on the fact that the status always moves away from "SELECTED" after the fetch is attempted to decide what to do with the GuC. v2: Split this change to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-4-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Kill USES_GUC_SUBMISSION macroDaniele Ceraolo Spurio
use intel_uc_uses_guc_submission() directly instead, to be consistent in the way we check what we want to do with the GuC. v2: do not go through ctx->vm->gt, use i915->gt instead Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-3-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Kill USES_GUC macroDaniele Ceraolo Spurio
use intel_uc_uses_guc() directly instead, to be consistent in the way we check what we want to do with the GuC. v2: split guc_log_info changes to their own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-2-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/debugfs: Pass guc_log struct to i915_guc_log_infoDaniele Ceraolo Spurio
The log struct is the only thing the function needs (apart from the seq_file), so we can pass just that instead of the whole dev_priv. v2: Split this change to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-1-daniele.ceraolospurio@intel.com
2020-02-20drm/i915: Double check bumping after the spinlockChris Wilson
In preparation for making GEM execbuf parallel, we need to be prepared to handle very early declaration of dependencies -- even before our signaler has itself been submitted. References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200220123608.1666271-1-chris@chris-wilson.co.uk
2020-02-20drm/i915/gt: Protect signaler walk with RCUChris Wilson
While we know that the waiters cannot disappear as we walk our list (only that they might be added), the same cannot be said for our signalers as they may be completed by the HW and retired as we process this request. Ergo we need to use rcu to protect the list iteration and remember to mark up the list_del_rcu. v2: Mark the deps as safe-for-rcu Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new waiters") Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200220075025.1539375-1-chris@chris-wilson.co.uk
2020-02-20drm/i915: remove the other slab_dependenciesMatthew Auld
The real one can be found in i915_scheduler.c. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200220105707.344522-1-matthew.auld@intel.com
2020-02-20drm/i915/gvt: make gvt oblivious of kvmgt data structuresJulian Stecklina
Instead of defining KVMGT per-device state in struct intel_vgpu directly, add an indirection. This makes the GVT code oblivious of what state KVMGT needs to keep. The intention here is to eventually make it possible to build hypervisor backends for the mediator, without having to touch the mediator itself. This is a first step. v2: - rebased onto gvt-staging (no conflicts) Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200217163858.26496-1-julian.stecklina@cyberus-technology.de
2020-02-20drm/i915/dp: Add all tiled and port sync conns to modesetManasi Navare
If one of the synced crtcs needs a full modeset, we need to make sure all the synced crtcs are forced a full modeset. v3: * Remove ~BIT(cpu_trans) which is a nop (Ville) * use get_new_crtc_state and remove error check (Ville) v2: * Add tiles based on cpu_trans check (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-3-manasi.d.navare@intel.com
2020-02-20drm/i915/dp: Compute port sync crtc states post compute_config()Manasi Navare
This patch pushes out the computation of master and slave transcoders in crtc states after encoder's compute_config hook. This ensures that the assigned master slave crtcs have exact same mode and timings which is a requirement for Port sync mode to be enabled. v3: * Make crtc_state const, remove crtc state NULL init (Ville) v2: * Correct indentation * Rename to intel_ddi_port_sync_transcoders (Ville) * remove unwanted debug (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-2-manasi.d.navare@intel.com
2020-02-20drm/i915: Introduce encoder->compute_config_late()Ville Syrjälä
Add an optional secondary encoder state compute hook. This gets called after the normak .compute_config() has been called for all the encoders in the state. Thus in the new hook we can rely on all derived state populated by .compute_config() to be already set up. Should be useful for MST and port sync master/slave transcoder selection. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-1-manasi.d.navare@intel.com
2020-02-20Merge drm-intel-next-queued into gvt-nextZhenyu Wang
Backmerge to pull in https://patchwork.freedesktop.org/patch/353621/?series=73544&rev=1 Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-02-19drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfxChris Wilson
For dgfx, we do not need to reconfigure the IA/ring frequencies of the main processors as they are distinct devices. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200219130119.1457693-1-chris@chris-wilson.co.uk
2020-02-19drm/i915/selftests: Mark GPR checking more hostileChris Wilson
Currently, we check that a new context has a clear set of general purpose registers. Add a little bit of hostility by preempting our new context and re-poisoning the GPR to ensure that there is no context leakage from preemption. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200219123418.1447428-1-chris@chris-wilson.co.uk
2020-02-19drm/i915/selftest: Analyse timestamp behaviour across context switchesChris Wilson
Check that the CTX_TIMESTAMP is monotonic across context save/restore and upon preemption. References: https://gitlab.freedesktop.org/drm/intel/issues/1233 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200219112004.1412791-1-chris@chris-wilson.co.uk
2020-02-19drm/i915: Read rawclk_freq earlierChris Wilson
Read the rawclk_freq during runtime info probing, prior to its first use in computing the CS timestamp frequency. Then store it in the runtime info, and include it in the debug printouts. Closes: https://gitlab.freedesktop.org/drm/intel/issues/834 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200216163445.555786-1-chris@chris-wilson.co.uk
2020-02-19drm/i915/gt: Refactor l3cc/mocs availabilityChris Wilson
On dgfx, we only use l3cc and not mocs, but we share the table containing both register definitions with Tigerlake. This confuses our selftest that verifies that both sets of registers do contain the values in our tables after various events (idling, reset, activity etc). When constructing the table of register definitions, also include the flags for which registers are valid so that information is computed centrally and available to all callers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Brian Welty <brian.welty@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218162150.1300405-10-chris@chris-wilson.co.uk
2020-02-19drm/i915: split i915_driver_modeset_remove() to pre/post irq uninstallJani Nikula
Push irq uninstall further up, by splitting i915_driver_modeset_remove() to two, the part with working irqs before irq uninstall, and the part after irq uninstall. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214135058.7580-2-jani.nikula@intel.com
2020-02-19drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstallJani Nikula
Split intel_modeset_driver_remove() to two, the part with working irqs before irq uninstall, and the part after irq uninstall. Move irq_unintall() closer to the layer it belongs. The error path in i915_driver_modeset_probe() looks obviously weird after this, but remains as good or broken as it ever was. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214135058.7580-1-jani.nikula@intel.com
2020-02-19drm/i915/gem: use spinlock_t instead of struct spinlockJani Nikula
spinlock_t is one case where the typedef is to be preferred over struct spinlock. Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests on changing engines") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200217184219.15325-1-jani.nikula@intel.com
2020-02-18drm/i915/gt: Show the cumulative context runtime in engine debugChris Wilson
As we have the total runtime known to us, show it when dumping the engine state for debug. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218162150.1300405-2-chris@chris-wilson.co.uk
2020-02-18drm/i915/selftests: Flush tasklet on wait_for_submit()Chris Wilson
Always flush the tasklet if we have pending submissions in wait_for_submit(), so that even if we see the HW has started before we process its ack, when we return the execlists state is well defined. Fixes: 06289949b8dd ("drm/i915/selftests: Check for any sign of request starting in wait_for_submit()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218211215.1336341-1-chris@chris-wilson.co.uk
2020-02-18drm/i915/gt: Fix up missing error propagation for heartbeat pulsesChris Wilson
Just missed setting err along an interruptible error path for the intel_engine_pulse(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218162150.1300405-4-chris@chris-wilson.co.uk
2020-02-18drm/i915/selftests: Check for any sign of request starting in wait_for_submit()Chris Wilson
We only want to wait until the request has been submitted at least once; that is it is either in flight, or has been. References: fcf7df7aae24 ("drm/i915/selftests: Check for the error interrupt before we wait!") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200218141305.1258394-1-chris@chris-wilson.co.uk
2020-02-18drm/i915/tgl: Add Wa_1808121037 to tgl.Rafael Antognolli
It's not clear whether this workaround is final yet, but the BSpec indicates that userspace needs to set bit 9 of this register on demand: "To avoid sporadic corruptions “Set 0x7010[9] when Depth Buffer Surface Format is D16_UNORM , surface type is not NULL & 1X_MSAA" Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2501 Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com> [mattrope: Tweaked comment while applying] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212191728.25227-1-rafael.antognolli@intel.com
2020-02-18drm/i915/display: use intel_de_*() functions for register accessJani Nikula
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214140910.23194-2-jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-02 21:38:11 +0000