- 21 Jan, 2019 9 commits
-
-
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:
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-1-hdegoede@redhat.com
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190119143024.26971-1-chris@chris-wilson.co.uk
-
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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-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:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190117230512.4789-1-chris@chris-wilson.co.uk
-
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 9 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:
-
Chris Wilson authored
As we may frequently mark the device as wedged to flush requests off it during the normal course of events, quite often we have a large state dump that is of no interest. Don't bother dumping it all if the engines are all idle. Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member 'wakeref' not described in 'i915_perf_stream' Reported-by: kbuild-all@01.org Fixes: 6619c007 ("drm/i915/perf: Track the rpm wakeref") Signed-off-by:
-
Radhakrishna Sripada authored
intel_dp->dsc_dpcd is defined as an array making the if check redundant. Fixes: e845f099 ("drm/i915/dsc: Add Per connector debugfs node for DSC support/enable") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Aditya Swarup authored
CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP. v2: Jani suggested to keep the macros organized semantically i.e., by function, secondarily by port/pipe/transcoder.->(dw, port) Fixes: 4e53840f ("drm/i915/icl: Introduce new macros to get combophy registers") Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
-
Chris Wilson authored
On Braswell, under heavy stress, if we update the GGTT while simultaneously accessing another region inside the GTT, we are returned the wrong values. To prevent this we stop the machine to update the GGTT entries so that no memory traffic can occur at the same time. This was first spotted in commit 5bab6f60 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Oct 23 18:43:32 2015 +0100 drm/i915: Serialise updates to GGTT with access through GGTT on Braswell but removed again in forlorn hope with commit 4509276e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Feb 20 12:47:18 2017 +0000 drm/i915: Remove Braswell GGTT update w/a However, gem_concurrent_blit is once again only stable with the patch applied and CI is detecting the odd failure in forked gem_mmap_gtt tests (which smell like the same issue). Fwiw, a wide variety of CPU memory barriers (around GGTT flushing, fence updates, PTE updates) and GPU flushes/invalidates (between requests, after PTE updates) were tried as part of the investigation to find an alternate cause, nothing comes close to serialised GGTT updates. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105591 Testcase: igt/gem_concurrent_blit Testcase: igt/gem_mmap_gtt/*forked* References: 5bab6f60 ("drm/i915: Serialise updates to GGTT with access through GGTT on Braswell") References: 4509276e ("drm/i915: Remove Braswell GGTT update w/a") Signed-off-by:
-
- 14 Jan, 2019 1 commit
-
-
Chris Wilson authored
We have two classes of VM, global GTT and per-process GTT. In order to allow ourselves the freedom to mix both along call chains, distinguish the two classes with regards to their mutex and lockdep maps. Signed-off-by:
-
