- 22 Jan, 2019 5 commits
-
-
Chris Wilson authored
Prior to adding a third instance of intel_context_init() and extending the information stored therewithin, refactor out the common assignments. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190121222117.23305-8-chris@chris-wilson.co.uk
-
Chris Wilson authored
Replace the open-coding of advance with a call instead. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190121222117.23305-19-chris@chris-wilson.co.uk
-
Chris Wilson authored
Before adding yet another copy of struct live_test and its handler, refactor the existing code into a common framework for live selftests. For many live selftests, we want to know if the GPU hung or otherwise misbehaved during the execution of the test (beyond any infraction in the behaviour under test), live_test provides this by comparing the GPU state before and after, alerting if it unexpectedly changed (e.g. the reset counter changed). It also ensures that the GPU is idle before and after the test, so that residual code running on the GPU is flushed before testing. Signed-off-by:
-
Chris Wilson authored
Some tests (e.g. igt_vma_pin1) presume that we have a completely clean GGTT so that it can probe boundaries without fear that something is already allocated there. However, the mock device is starting to get complicated and following similar rules to the live device, i.e. we can't guarantee that i915->ggtt remains clean, so create a temporary address_space equivalent to the mock ggtt for the purpose. Signed-off-by:
-
Chris Wilson authored
During review of commit 71fc448c ("drm/i915/selftests: Make evict tolerant of foreign objects"), Matthew mentioned it would be better if we explicitly tracked the objects we created. We have an obj->st_link hook for this purpose, so add the corresponding list of objects and reduce our loops to only consider our own list. References: 71fc448c ("drm/i915/selftests: Make evict tolerant of foreign objects") Signed-off-by:
-
- 21 Jan, 2019 10 commits
-
-
Hans de Goede authored
The display engine has 2 dithering enable bits which both need to be set for dithering to happen, 1 in the PIPECONF register which is taken care of by i9xx_set_pipeconf() and a second bit at the encoder level. The dsi code was not setting the encoder level dithering enable bit causing dithering to be disabled, this commit fixes this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181201113148.23184-2-hdegoede@redhat.com
-
Hans de Goede authored
There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc pixel-formats which this commit addresses: 1) It assumes that the pipe_bpp is the same as the bpp going over the dsi lanes. This assumption is not valid for MIPI_DSI_FMT_RGB666, where pipe_bpp should be 18 so that we do proper dithering but we actually send 24 bpp over the dsi lanes (MIPI_DSI_FMT_RGB666_PACKED sends 18 bpp). This assumption is enforced by an assert in *_dsi_get_pclk(). This assert triggers on the initial hw-state readback on BYT/CHT devices which use MIPI_DSI_FMT_RGB666, such as the Prowise PT301 tablet. PIPECONF is set to 6BPC / 18 bpp by the GOP, while mipi_dsi_pixel_format_to_bpp() returns 24. This commits switches the calculations in *_dsi_get_pclk() to use the bpp from mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format) which returns the bpp going over the mipi lanes and drops the assert. 2) On BXT bxt_dsi_get_pipe_config() wrongly overrides the pipe_bpp which i9xx_get_pipe_config() reads from PIPECONF with the return value from mipi_dsi_pixel_format_to_bpp(). This avoids the assert from 1. but is wrong since the pipe is actually running at the value configured in PIPECONF. This commit drops the override of pipe_bpp from bxt_dsi_get_pipe_config(). 3) The dsi encoder's compute_config() never assigns a value to pipe_bpp, unlike most other encoders. Falling back on compute_baseline_pipe_bpp() which always picks 24. 24 is only correct for MIPI_DSI_FMT_RGB88 for the others we should use 18 bpp so that we correctly do 6bpc color dithering. This commit adds code to intel_dsi_compute_config() to properly set pipe_bpp based on intel_dsi->pixel_format. Signed-off-by:
-
Chris Wilson authored
We are not allowed to assign rq->global_seqno=0 as it has a special meaning of "inactive" (not executing on HW). Fixes: 6faf5916 ("drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation") Signed-off-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch fixes sprinkled on top of the changed lines. Acked-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190118120125.15484-8-jani.nikula@intel.com
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Acked-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch/whitepace fixes sprinkled on top of the changed lines. v2: more whitespace fixes (Ville, José) Acked-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Acked-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch fixes sprinkled on top of the changed lines. Acked-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Acked-by:
-
- 18 Jan, 2019 7 commits
-
-
Chris Wilson authored
To correctly simulate preemption between contexts, we need independent timelines along each context. Make it so. Signed-off-by:
-
Jani Nikula authored
It's superfluous. Reviewed-by:
-
Chris Wilson authored
The evict selftests presumed that all objects in use had been allocated by itself. This is a dubious claim and so instead of asserting complete control over the object lists, take (temporary) ownership of them instead. Signed-off-by:
-
Chris Wilson authored
Since commit d4ccceb0 ("drm/i915/icl: Ringbuffer interrupt handling") we have required a mechanism to avoid touching the interrupt hardware for breadcrumbs, superseding our mock interface for selftests. The residual problem (ideas welcome) is in probing the mock ring registers for ring_is_idle. Hmm, maybe we should just install mock handlers for i915->uncore.mmio__write and friends? Only problem being is that we would to truly mock some expected reads. :( References: d4ccceb0 ("drm/i915/icl: Ringbuffer interrupt handling") Signed-off-by:
-
Chris Wilson authored
Since we have the ppgtt we want to test, we can ask it directly if it is suitable for the hugepage test we intend to undertake. v2: Not everyone has full-ppgtt Signed-off-by:
-
Chris Wilson authored
The motivation for introducing the check that we only enable breadcrumb irqs if the device's irq was installed was once upon a time we waited during suspend after disabling interrupts (which was quite slow until the bug was discovered). Since then we have the notion of pinning the breadcrumb irq, broadening it from the sole purpose of user interrupt notification and waiting, and more importantly decoupling it from a very defined time period during which enabling the irq was expected. So stop insisting the irq is installed before we setup our IMR masks, if the IER isn't yet enabled, nothing will happen and we will timeout instead, revealing the lack of irq in the hang debug messages. Signed-off-by:
-
Tvrtko Ursulin authored
To avoid a false positive of a leaked wakeref, we can store the cookie in file->private_data and use it in intel_runtime_pm_put. Signed-off-by:
-
- 17 Jan, 2019 10 commits
-
-
Chris Wilson authored
Let static analyzers (smatch) know that we are not going to wander off the end of the array by providing a tight upper bound: drivers/gpu/drm/i915/intel_display.c:9532 hsw_get_transcoder_state() error: buffer overflow 'dev_priv->__info.trans_offsets' 6 <= 31 References: 0716931a ("drm/i915/icl: fix transcoder state readout") Signed-off-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch/whitespace fixes sprinkled on top of the changed lines. Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch/whitespace fixes sprinkled on top of the changed lines. Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch fixes sprinkled on top of the changed lines. Reviewed-by:
-
- 16 Jan, 2019 4 commits
-
-
Chris Wilson authored
Currently the code to reset the GPU and our state is spread widely across a few files. Pull the logic together into a common file. Signed-off-by:
-
Chris Wilson authored
Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more consistent if called concurrently, and only do the wedging and reporting once, curtailing any possible race where we start unwedging in the middle of a wedge. Signed-off-by:
-
Lyude Paul authored
Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae147 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320Reviewed-by:
Daniel Vetter <daniel@ffwll.ch>
-
Chris Wilson authored
mutex_lock_killable() returns -EINTR on failure, not the anticipate bool return like trylock. (Oh no, not again.) Fixes: 484d9a84 ("drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start") Signed-off-by:
-
- 15 Jan, 2019 4 commits
-
-
Chris Wilson authored
Move the debug pretty printer into a standalone routine prior to extending it in upcoming feature work. Signed-off-by:
-
Chris Wilson authored
Since commit 93065ac7 ("mm, oom: distinguish blockable mode for mmu notifiers") we have been able to report failure from mmu_invalidate_range_start which allows us to use a trylock on the struct_mutex to avoid potential recursion and report -EBUSY instead. Furthermore, this allows us to pull the work into the main callback and avoid the sleight-of-hand in using a workqueue to avoid lockdep. However, not all paths to mmu_invalidate_range_start are prepared to handle failure, so instead of reporting the recursion, deal with it by propagating the failure upwards, who can decide themselves to handle it or report it. v2: Mark up the recursive lock behaviour and comment on the various weak points. v3: Follow commit 3824e419 ("drm/i915: Use mutex_lock_killable() from inside the shrinker") and also use mutex_lock_killable(). v3.1: No leak on EINTR. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375 References: 93065ac7 ("mm, oom: distinguish blockable mode for mmu notifiers") Signed-off-by:
-
Imre Deak authored
Registering an output for a non-existent port (on a given SKU) can lead to problems when trying to use the port, for instance timeouts during power well enabling. Since there are no strap bits for port detection we have to rely on VBT for this, so do that here. There are no known SKUs where any of the A-E ports are non-existent, so to reduce the likelihood of breakage due to incorrect VBT information, do this detection only for port F (which is known to be missing on some ICL SKUs). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108915 Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181220132604.25222-2-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
We have already a function to detect DDI ports using VBT, so instead of opencoding the DDI specific version of this, move the opencoded part to the existing helper. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
