[Intel-gfx] [PATCH 06/13] drm/i915/gt: Expose engine properties via sysfs

Preliminary stub to add engines underneath /sys/class/drm/cardN/, so that we can expose properties on each engine to the sysadmin. To start with we have basic analogues of the i915_query ioctl so that we can pretty print engine discovery from the shell, and flesh out the directory structure. Later

[Intel-gfx] [PATCH 05/13] drm/i915: Disable preemption support on Icelake

Our pre-emption support on Icelake is broken on all kernels, so disable until resolved. Reported-by: Jason Ekstrand Closes: https://gitlab.freedesktop.org/drm/intel/issues/809 Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Jon Bloomfield Cc: Jason Ekstrand --- drivers/gpu/drm/i915/i915_

[Intel-gfx] [PATCH 12/13] drm/i915/gt: Expose heartbeat interval via sysfs

We monitor the health of the system via periodic heartbeat pulses. The pulses also provide the opportunity to perform garbage collection. However, we interpret an incomplete pulse (a missed heartbeat) as an indication that the system is no longer responsive, i.e. hung, and perform an engine or full

[Intel-gfx] [PATCH 09/13] drm/i915/gt: Expose busywait duration to sysfs

We busywait on an inflight request (one that is currently executing on HW, and so might complete quickly) prior to setting up an interrupt and sleeping. The trade off is that we keep an expensive CPU core busy in order to avoid wake up latency: where that trade off should lie is best left to the sy

[Intel-gfx] [PATCH 10/13] drm/i915/gt: Expose reset stop timeout via sysfs

When we allow ourselves to sleep before a GPU reset after disabling submission, even for a few milliseconds, gives an innocent context the opportunity to clear the GPU before the reset occurs. However, how long to sleep depends on the typical non-preemptible duration (a similar problem to determini

[Intel-gfx] [PATCH 11/13] drm/i915/gt: Expose preempt reset timeout via sysfs

After initialising a preemption request, we give the current resident a small amount of time to vacate the GPU. The preemption request is for a higher priority context and should be immediate to maintain high quality of service (and avoid priority inversion). However, the preemption granularity of

[Intel-gfx] [PATCH 02/13] drm/i915: Allow userspace to specify ringsize on construction

No good reason why we must always use a static ringsize, so let userspace select one during construction. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Janusz Krzysztofik --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 1

[Intel-gfx] [PATCH 01/13] drm/i915: Flush idle barriers when waiting

If we do find ourselves with an idle barrier inside our active while waiting, attempt to flush it by emitting a pulse using the kernel context. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_active.c | 21 - drivers/gpu/drm/i915/selftests/i915_active.c | 46 +

[Intel-gfx] [PATCH 03/13] drm/i915/gem: Honour O_NONBLOCK before throttling execbuf submissions

Check the user's flags on the struct file before deciding whether or not to stall before submitting a request. This allows us to reasonably cheaply honour O_NONBLOCK without checking at more critical phases during request submission. Suggested-by: Joonas Lahtinen Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH 08/13] drm/i915/gt: Expose timeslice duration to sysfs

Execlists uses a scheduling quantum (a timeslice) to alternate execution between ready-to-run contexts of equal priority. This ensures that all users (though only if they of equal importance) have the opportunity to run and prevents livelocks where contexts may have implicit ordering due to userspa

[Intel-gfx] [PATCH 13/13] drm/i915/gt: Limit C-states while waiting for requests

Allow the sysadmin to specify whether we should prevent the CPU from entering higher C-states while waiting for the CPU, in order to reduce the latency of request completions and so speed up client continuations. The target dma latency can be adjusted per-engine using, /sys/class/drm/card

[Intel-gfx] [PATCH 07/13] drm/i915/gt: Expose engine->mmio_base via sysfs

Use the per-engine sysfs directory to let userspace discover the mmio_base of each engine. Prior to recent generations, the user accessible registers on each engine are at a fixed offset relative to each engine -- but require absolute addressing. As the absolute address depends on the actual physic

[Intel-gfx] [PATCH 04/13] drm/i915: Only retire requests when eviction is allowed to blocked

We want to keep the PIN_NONBLOCK search quick, avoiding evicting recently active nodes. To that end, skip performing the more laborious retirement prior to beginning the fast search. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_evict.c | 6 -- 1 file changed, 4 insertions(+)

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/13] drm/i915: Flush idle barriers when waiting

== Series Details == Series: series starting with [01/13] drm/i915: Flush idle barriers when waiting URL : https://patchwork.freedesktop.org/series/71998/ State : warning == Summary == $ dim checkpatch origin/drm-tip 74de6c3a485c drm/i915: Flush idle barriers when waiting f64bad15a29b drm/i915

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v3] i915/perf: Find the associated perf-type for a particular device

On 10/01/2020 11:53, Chris Wilson wrote: Since with multiple devices, we may have multiple different perf_pmu each with their own type, we want to find the right one for the job. The tests are run with a specific fd, from which we can extract the appropriate bus-id and find the associated perf

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/13] drm/i915: Flush idle barriers when waiting

== Series Details == Series: series starting with [01/13] drm/i915: Flush idle barriers when waiting URL : https://patchwork.freedesktop.org/series/71998/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915: Flush idle barriers when waiting Okay!

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v3] i915/perf: Find the associated perf-type for a particular device

Quoting Tvrtko Ursulin (2020-01-14 10:09:15) > > On 10/01/2020 11:53, Chris Wilson wrote: > > -uint64_t i915_type_id(void) > > +static char *bus_address(int i915, char *path, int pathlen) > > +{ > > + struct stat st; > > + int len = -1; > > + int dir; > > + char *s; > > + > > +

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v3] i915/perf: Find the associated perf-type for a particular device

On 14/01/2020 10:15, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-01-14 10:09:15) On 10/01/2020 11:53, Chris Wilson wrote: -uint64_t i915_type_id(void) +static char *bus_address(int i915, char *path, int pathlen) +{ + struct stat st; + int len = -1; + int dir; + char *s;

[Intel-gfx] ✗ Fi.CI.BUILD: warning for series starting with [01/13] drm/i915: Flush idle barriers when waiting

== Series Details == Series: series starting with [01/13] drm/i915: Flush idle barriers when waiting URL : https://patchwork.freedesktop.org/series/71998/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compil

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/13] drm/i915: Flush idle barriers when waiting

== Series Details == Series: series starting with [01/13] drm/i915: Flush idle barriers when waiting URL : https://patchwork.freedesktop.org/series/71998/ State : success == Summary == CI Bug Log - changes from CI_DRM_7737 -> Patchwork_16089

Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: Introduce CT_ERROR

On Mon, 13 Jan 2020 22:59:46 +0100, Daniele Ceraolo Spurio wrote: On 1/13/2020 12:52 PM, Michal Wajdeczko wrote: On Mon, 13 Jan 2020 21:20:25 +0100, Daniele Ceraolo Spurio wrote: On 1/11/2020 3:11 PM, Michal Wajdeczko wrote: We should start using dev variants of error logging and t

[Intel-gfx] [PATCH 1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we start measuruing I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from 0 and then upon first activity (park/unpark) add in all the rc6 residency since boot. After

[Intel-gfx] [PATCH 2/2] drm/i915/gt: Clear rc6 residency trackers across suspend

On suspend, the rc6 residency counters (stored in HW registers) will be lost and cleared. However, we keep track of the rc6 residency to provide a continuous 64b sampling, and if we see the HW value go backwards, we assume it overflowed and add on 32b/40b -- an interesting artifact when sampling ac

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

Quoting Chris Wilson (2020-01-14 10:56:47) > The rc6 residency starts ticking from 0 from BIOS POST, but the kernel > starts measuring the time from its boot. If we start measuruing > I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from > 0 and then upon first activity (park/unpa

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use common priotree lists for virtual engine

On 13/01/2020 10:44, Chris Wilson wrote: > Since commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a > plain list"), we used the default embedded priotree slot for the virtual > engine request queue, which means we can also use the same solitary slot > with the scheduler. However, th

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Clear rc6 residency trackers across suspend

On 14/01/2020 10:56, Chris Wilson wrote: On suspend, the rc6 residency counters (stored in HW registers) will be lost and cleared. However, we keep track of the rc6 residency to provide a continuous 64b sampling, and if we see the HW value go backwards, we assume it overflowed and add on 32b/40

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use common priotree lists for virtual engine

Quoting Tvrtko Ursulin (2020-01-14 11:13:06) > > > On 13/01/2020 10:44, Chris Wilson wrote: > > Since commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a > > plain list"), we used the default embedded priotree slot for the virtual > > engine request queue, which means we can also use

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use common priotree lists for virtual engine

Quoting Tvrtko Ursulin (2020-01-14 11:13:06) > > > On 13/01/2020 10:44, Chris Wilson wrote: > > @@ -2473,6 +2475,7 @@ static void execlists_submit_request(struct > > i915_request *request) > > spin_lock_irqsave(&engine->active.lock, flags); > > > > queue_request(engine, &request->

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

On 14/01/2020 11:06, Chris Wilson wrote: Quoting Chris Wilson (2020-01-14 10:56:47) The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we start measuruing I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from 0 a

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

== Series Details == Series: series starting with [1/2] drm/i915/pmu: Correct the rc6 offset upon enabling URL : https://patchwork.freedesktop.org/series/72001/ State : success == Summary == CI Bug Log - changes from CI_DRM_7737 -> Patchwork_16090 =

[Intel-gfx] ✗ Fi.CI.BUILD: warning for series starting with [1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

== Series Details == Series: series starting with [1/2] drm/i915/pmu: Correct the rc6 offset upon enabling URL : https://patchwork.freedesktop.org/series/72001/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated

[Intel-gfx] [PULL] drm-intel-next

t (2020-01-09 10:53:58 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-01-14 for you to fetch changes up to f2221a50494037af98206713155c8d4f2e7bccaa: drm/i915: Update DRIVER_DATE to 20200114 (2020-0

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

On 14/01/2020 11:37, Tvrtko Ursulin wrote: On 14/01/2020 11:06, Chris Wilson wrote: Quoting Chris Wilson (2020-01-14 10:56:47) The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we start measuruing I915_PMU_RC6_RESIDENCY while th

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

Quoting Tvrtko Ursulin (2020-01-14 11:37:09) > > On 14/01/2020 11:06, Chris Wilson wrote: > > Quoting Chris Wilson (2020-01-14 10:56:47) > >> The rc6 residency starts ticking from 0 from BIOS POST, but the kernel > >> starts measuring the time from its boot. If we start measuruing > >> I915_PMU_RC

[Intel-gfx] [PATCH v2] drm/i915: Use common priotree lists for virtual engine

Since commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list"), we used the default embedded priotree slot for the virtual engine request queue, which means we can also use the same solitary slot with the scheduler. However, the priolist is expected to be guarded by the engine->

Re: [Intel-gfx] [PULL] drm-intel-next

Quoting Jani Nikula (2020-01-14 11:43:22) > > Hi Dave & Daniel - > > Last batch for v5.6, slightly delayed I'm afraid. I'd like to close https://gitlab.freedesktop.org/drm/intel/issues/738 for 5.6, otherwise we'll have some more nasty emails from bewildered users/devs. https://patchwork.freedes

Re: [Intel-gfx] [PULL] drm-intel-next

On Tue, 14 Jan 2020, Chris Wilson wrote: > Quoting Jani Nikula (2020-01-14 11:43:22) >> >> Hi Dave & Daniel - >> >> Last batch for v5.6, slightly delayed I'm afraid. > > I'd like to close https://gitlab.freedesktop.org/drm/intel/issues/738 > for 5.6, otherwise we'll have some more nasty emails f

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Correct the rc6 offset upon enabling

On 14/01/2020 11:49, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-01-14 11:37:09) On 14/01/2020 11:06, Chris Wilson wrote: Quoting Chris Wilson (2020-01-14 10:56:47) The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we star

[Intel-gfx] [PATCH] drm/i915/selftests: Add a mock i915_vma to the mock_ring

Add a i915_vma to the mock_engine/mock_ring so that the core code can always assume the presence of ring->vma. Fixes: 8ccfc20a7d56 ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/mock_engine.c | 8 1 file changed, 8 insertio

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/i915/gt: Always reset the timeslice after a context switch (rev2)

== Series Details == Series: series starting with [1/4] drm/i915/gt: Always reset the timeslice after a context switch (rev2) URL : https://patchwork.freedesktop.org/series/71951/ State : failure == Summary == Applying: drm/i915/gt: Always reset the timeslice after a context switch Using inde

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Add a mock i915_vma to the mock_ring

== Series Details == Series: drm/i915/selftests: Add a mock i915_vma to the mock_ring URL : https://patchwork.freedesktop.org/series/72005/ State : warning == Summary == $ dim checkpatch origin/drm-tip 63ab231fcfb0 drm/i915/selftests: Add a mock i915_vma to the mock_ring -:21: CHECK:COMPARISON

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

== Series Details == Series: drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex URL : https://patchwork.freedesktop.org/series/71889/ State : success == Summary == CI Bug Log - changes from CI_DRM_7720_full -> Patchwork_16054_full S

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/selftests: Add a mock i915_vma to the mock_ring

== Series Details == Series: drm/i915/selftests: Add a mock i915_vma to the mock_ring URL : https://patchwork.freedesktop.org/series/72005/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arc

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Add a mock i915_vma to the mock_ring

== Series Details == Series: drm/i915/selftests: Add a mock i915_vma to the mock_ring URL : https://patchwork.freedesktop.org/series/72005/ State : success == Summary == CI Bug Log - changes from CI_DRM_7738 -> Patchwork_16092 Summary -

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use common priotree lists for virtual engine

On 14/01/2020 11:20, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-01-14 11:13:06) On 13/01/2020 10:44, Chris Wilson wrote: Since commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list"), we used the default embedded priotree slot for the virtual engine request queue, w

Re: [Intel-gfx] [PATCH 23/23] drm: Cleanup VBLANK callbacks in struct drm_driver

Hi Am 12.01.20 um 23:53 schrieb Daniel Vetter: > On Fri, Jan 10, 2020 at 10:21:27AM +0100, Thomas Zimmermann wrote: >> All non-legacy users of VBLANK functions in struct drm_driver have been >> converted to use the respective interfaces in struct drm_crtc_funcs. The >> remaining users of VBLANK ca

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use common priotree lists for virtual engine

Quoting Tvrtko Ursulin (2020-01-14 13:48:11) > > On 14/01/2020 11:20, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-01-14 11:13:06) > >> On 13/01/2020 10:44, Chris Wilson wrote: > >>> Since commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a > >>> plain list"), we used the defau

[Intel-gfx] [PATCH v2 5/5] drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel

From: Lyude Paul Annoyingly, the VBT on the ThinkPad X1 Extreme 2nd Gen indicates that the system uses plain PWM based backlight controls, when in reality the only backlight controls that work are the standard VESA eDP DPCD backlight controls. Honestly, this makes me wonder how many other system

[Intel-gfx] [PATCH v2 3/5] drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight()

From: Lyude Paul For eDP panels, it appears it's expected that so long as the panel is in DPCD control mode that the brightness value is never set to 0. Instead, if the desired effect is to set the panel's backlight to 0 we're expected to simply turn off the backlight through the DP_EDP_DISPLAY_C

[Intel-gfx] [PATCH v2 1/5] drm/i915: Fix eDP DPCD aux max backlight calculations

From: Lyude Paul Max backlight value for the panel was being calculated using byte count i.e. 0x if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus,

[Intel-gfx] [PATCH v2 0/5] drm/i915: eDP DPCD aux backlight fixes

v2 of Lyude's series [1]. I've postponed reviewing the series so long that I was too embarrassed to ask for a small fix in patch 1. Otherwise it's just rebasing. :| BR, Jani. [1] https://patchwork.freedesktop.org/series/69914/ Cc: Lyude Paul Lyude Paul (5): drm/i915: Fix eDP DPCD aux max

[Intel-gfx] [PATCH v2 2/5] drm/i915: Assume 100% brightness when not in DPCD control mode

From: Lyude Paul Currently we always determine the initial panel brightness level by simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This seems wrong though, because if the panel is not currently in DPCD control mode there's not really any reason why there would be any brightne

[Intel-gfx] [PATCH v2 4/5] drm/i915: Auto detect DPCD backlight support by default

From: Lyude Paul Turns out we actually already have some companies, such as Lenovo, shipping machines with AMOLED screens that don't allow controlling the backlight through the usual PWM interface and only allow controlling it through the standard EDP DPCD interface. One example of one of these l

Re: [Intel-gfx] [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

On Mon, 06 Jan 2020, Kai-Heng Feng wrote: > Hi Jani, > >> On Dec 24, 2019, at 16:42, Kai-Heng Feng wrote: >> >> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port >> becomes useless and never responds to cable hotplugging: >> [3.031904] [drm:lspcon_init [i915]] *ERROR* F

Re: [Intel-gfx] [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

On Tue, 14 Jan 2020, Wambui Karuga wrote: > Converts the printk based logging macros in i915/display/intel_audio.c > to the struct drm_device based logging macros. Couple of comments inline. BR, Jani. > This transformation was achieved using the following coccinelle script > that matches the e

Re: [Intel-gfx] [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

On Tue, 14 Jan 2020, Jani Nikula wrote: > On Tue, 14 Jan 2020, Wambui Karuga wrote: >> Converts the printk based logging macros in i915/display/intel_audio.c >> to the struct drm_device based logging macros. > > Couple of comments inline. PS. This is Reviewed-by: Jani Nikula and I'm fine with

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Validation rotated vma bounds are within the object (rev2)

== Series Details == Series: drm/i915/gt: Validation rotated vma bounds are within the object (rev2) URL : https://patchwork.freedesktop.org/series/71827/ State : success == Summary == CI Bug Log - changes from CI_DRM_7720_full -> Patchwork_16056_full ==

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Consolidate HDMI force_dvi handling

On Wed, 08 Jan 2020, Ville Syrjala wrote: > From: Ville Syrjälä > > Move the force_dvi check to a single function that can be called from > both mode validation and compute_config(). > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_hdmi.c |

Re: [Intel-gfx] [PATCH 3/9] drm/i915/sdvo: Consolidate SDVO HDMI force_dvi handling

On Wed, 08 Jan 2020, Ville Syrjala wrote: > From: Ville Syrjälä > > Move the force_dvi check to a single function that can be called from > both mode validation and compute_config(). Note that currently we > don't call it from mode validation, but that will change soon. > > Signed-off-by: Ville S

Re: [Intel-gfx] [PATCH 1/9] drm/i915/sdvo: Reduce the size of the on stack buffers

On Wed, 08 Jan 2020, Ville Syrjala wrote: > From: Ville Syrjälä > > The strings we want to print to the on stack buffers should > be no more than > 8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61 > bytes. So let's shrink the buffers down to 64 bytes. > > Also switch the BUG_ON()s

Re: [Intel-gfx] [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

On Tue, Jan 14, 2020 at 04:11:40PM +0200, Jani Nikula wrote: > On Mon, 06 Jan 2020, Kai-Heng Feng wrote: > > Hi Jani, > > > >> On Dec 24, 2019, at 16:42, Kai-Heng Feng > >> wrote: > >> > >> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port > >> becomes useless and never re

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: eDP DPCD aux backlight fixes (rev5)

== Series Details == Series: drm/i915: eDP DPCD aux backlight fixes (rev5) URL : https://patchwork.freedesktop.org/series/69914/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boot/

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: eDP DPCD aux backlight fixes (rev5)

== Series Details == Series: drm/i915: eDP DPCD aux backlight fixes (rev5) URL : https://patchwork.freedesktop.org/series/69914/ State : success == Summary == CI Bug Log - changes from CI_DRM_7739 -> Patchwork_16093 Summary --- **SUC

[Intel-gfx] [PATCH] drm/i915/gt: Undo partial gt-pm enabling on error paths

Undo the rps/llc enabling operations if we fail to bring up the engine subsequently. For bonus paranoia, scrub the GT state along the error path. Signed-off-by: Chris Wilson Cc: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 19 +-- 1 file changed, 9 insertions(+), 10 de

Re: [Intel-gfx] [PATCH 13/13] drm/i915/gt: Limit C-states while waiting for requests

Chris Wilson writes: > Allow the sysadmin to specify whether we should prevent the CPU from > entering higher C-states while waiting for the CPU, in order to reduce s/higher/deeper s/CPU/GPU > the latency of request completions and so speed up client continuations. > > The target dma latency ca

Re: [Intel-gfx] [PATCH 13/13] drm/i915/gt: Limit C-states while waiting for requests

Quoting Mika Kuoppala (2020-01-14 15:12:03) > Chris Wilson writes: > > > Allow the sysadmin to specify whether we should prevent the CPU from > > entering higher C-states while waiting for the CPU, in order to reduce > > s/higher/deeper > s/CPU/GPU > > > the latency of request completions and s

Re: [Intel-gfx] [PATCH] drm/i915/gem: Take local vma references for the parser

Chris Wilson writes: > Take and hold a reference to each of the vma (and their objects) as we > process them with the cmdparser. This stops them being freed during the > work if the GEM execbuf is interrupted and the request we expected to > keep the objects alive is incomplete. > > Fixes: 686c7c

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Add a mock i915_vma to the mock_ring

Chris Wilson writes: > Add a i915_vma to the mock_engine/mock_ring so that the core code can > always assume the presence of ring->vma. > > Fixes: 8ccfc20a7d56 ("drm/i915/gt: Mark ring->vma as active while pinned") > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/gt/mock_engine.c | 8

Re: [Intel-gfx] [PATCH 09/23] drm: Remove struct drm_driver.get_scanout_position()

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: All users of struct drm_driver.get_scanout_position() have been covnerted to the respective CRTC helper function. Remove the callback from struct drm_d

[Intel-gfx] [CI] drm/i915/selftests: Add a mock i915_vma to the mock_ring

Add a i915_vma to the mock_engine/mock_ring so that the core code can always assume the presence of ring->vma. Fixes: 8ccfc20a7d56 ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/mock_engine.c | 17 +++

Re: [Intel-gfx] [PATCH 08/23] drm/stm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm over.

Re: [Intel-gfx] [PATCH 23/23] drm: Cleanup VBLANK callbacks in struct drm_driver

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: All non-legacy users of VBLANK functions in struct drm_driver have been converted to use the respective interfaces in struct drm_crtc_funcs. The remain

Re: [Intel-gfx] [PATCH 19/23] drm/stm: Convert to CRTC VBLANK callbacks

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert stm over. Signed-off-by: Thomas Z

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Re-init lspcon after HPD if lspcon probe failed (rev5)

== Series Details == Series: drm/i915: Re-init lspcon after HPD if lspcon probe failed (rev5) URL : https://patchwork.freedesktop.org/series/71314/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Ker

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Re-init lspcon after HPD if lspcon probe failed (rev5)

== Series Details == Series: drm/i915: Re-init lspcon after HPD if lspcon probe failed (rev5) URL : https://patchwork.freedesktop.org/series/71314/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7739 -> Patchwork_16094 Summa

Re: [Intel-gfx] [PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs

Thanks for the patch. Tested-by: Yannick Fertré BR Yannick Fertré On 1/10/20 10:21 AM, Thomas Zimmermann wrote: The new callback get_scanout_position() reads the current location of the scanout process. The operation is currentyl located in struct drm_driver, but

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915: Make a copy of the ggtt view for slave plane

== Series Details == Series: series starting with [1/6] drm/i915: Make a copy of the ggtt view for slave plane URL : https://patchwork.freedesktop.org/series/71896/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16058_full ===

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev4)

== Series Details == Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev4) URL : https://patchwork.freedesktop.org/series/71760/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16060_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Undo partial gt-pm enabling on error paths

== Series Details == Series: drm/i915/gt: Undo partial gt-pm enabling on error paths URL : https://patchwork.freedesktop.org/series/72010/ State : success == Summary == CI Bug Log - changes from CI_DRM_7740 -> Patchwork_16095 Summary --

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/gt: Undo partial gt-pm enabling on error paths

== Series Details == Series: drm/i915/gt: Undo partial gt-pm enabling on error paths URL : https://patchwork.freedesktop.org/series/72010/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch

[Intel-gfx] ✓ Fi.CI.IGT: success for Add ops to intel_uc (rev4)

== Series Details == Series: Add ops to intel_uc (rev4) URL : https://patchwork.freedesktop.org/series/70716/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16061_full Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Clean up VBLANK callbacks in struct drm_driver (rev6)

== Series Details == Series: drm: Clean up VBLANK callbacks in struct drm_driver (rev6) URL : https://patchwork.freedesktop.org/series/71873/ State : failure == Summary == Applying: drm: Add get_scanout_position() to struct drm_crtc_helper_funcs error: corrupt patch at line 18 error: could not

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/selftests: Add a mock i915_vma to the mock_ring (rev2)

== Series Details == Series: drm/i915/selftests: Add a mock i915_vma to the mock_ring (rev2) URL : https://patchwork.freedesktop.org/series/72005/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kern

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Add a mock i915_vma to the mock_ring (rev2)

== Series Details == Series: drm/i915/selftests: Add a mock i915_vma to the mock_ring (rev2) URL : https://patchwork.freedesktop.org/series/72005/ State : success == Summary == CI Bug Log - changes from CI_DRM_7740 -> Patchwork_16096 Summar

Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Allow temporary suspension of inflight requests

On 13/01/2020 10:44, Chris Wilson wrote: In order to support out-of-line error capture, we need to remove the active request from HW and put it to one side while a worker compresses and stores all the details associated with that request. (As that compression may take an arbitrary user-controll

Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Allow temporary suspension of inflight requests

Quoting Tvrtko Ursulin (2020-01-14 18:33:07) > > On 13/01/2020 10:44, Chris Wilson wrote: > > In order to support out-of-line error capture, we need to remove the > > active request from HW and put it to one side while a worker compresses > > and stores all the details associated with that request

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp/tgl+: Update combo phy vswing tables

== Series Details == Series: drm/i915/dp/tgl+: Update combo phy vswing tables URL : https://patchwork.freedesktop.org/series/71909/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16062_full Summary ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

== Series Details == Series: drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER URL : https://patchwork.freedesktop.org/series/71912/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16063_full Summary

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp/tgl+: Update combo phy vswing tables

On Tue, 2020-01-14 at 19:12 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/dp/tgl+: Update combo phy vswing tables > URL : https://patchwork.freedesktop.org/series/71909/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16062_

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

On Tue, 2020-01-14 at 20:18 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER > URL : https://patchwork.freedesktop.org/series/71912/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Add Wa_1409825376 to tgl (rev5)

== Series Details == Series: drm/i915/tgl: Add Wa_1409825376 to tgl (rev5) URL : https://patchwork.freedesktop.org/series/71853/ State : success == Summary == CI Bug Log - changes from CI_DRM_7742 -> Patchwork_16098 Summary --- **SUC

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/tgl: Add Wa_1409825376 to tgl (rev5)

== Series Details == Series: drm/i915/tgl: Add Wa_1409825376 to tgl (rev5) URL : https://patchwork.freedesktop.org/series/71853/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boot/

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen11: Add additional pcode status values

== Series Details == Series: drm/i915/gen11: Add additional pcode status values URL : https://patchwork.freedesktop.org/series/71915/ State : success == Summary == CI Bug Log - changes from CI_DRM_7721_full -> Patchwork_16064_full Summary -

Re: [Intel-gfx] [RFC 7/7] drm/i915/dp: Program vswing, pre-emphasis, test-pattern

On Fri, Dec 13, 2019 at 10:54:20PM +0530, Animesh Manna wrote: > Hi Manasi/Jani, > > Thanks for helping phy compliance design. > > Added my understanding/doubts below. > > > On 12/12/2019 5:20 AM, Manasi Navare wrote: > >Hi Animesh/Jani, > > > >Is this the right way to force a full modeset by a

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen11: Add additional pcode status values

On Tue, Jan 14, 2020 at 09:25:44PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen11: Add additional pcode status values > URL : https://patchwork.freedesktop.org/series/71915/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_7721_full -> Patchwo

[Intel-gfx] [RFC PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission

From: Mika Kuoppala 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. Signed-off-by: Mika Kuoppala Signed-off-by: Akeem G Abodunrin Cc: Kumar Valsan Prathap Cc: Chris Wilson Cc: Balestrieri Franc

[Intel-gfx] [RFC PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

From: Prathap Kumar Valsan On gen7 and gen7.5 devices, there could be leftover data residuals in EU/L3 from the retiring context. This patch introduces workaround to clear that residual contexts, by submitting a batch buffer with dedicated HW context to the GPU with ring allocation for each conte

[Intel-gfx] [RFC PATCH 0/2] Security mitigation for Intel Gen7 and Gen7.5

Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via l

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

Quoting Akeem G Abodunrin (2020-01-14 14:51:36) > From: Prathap Kumar Valsan > > On gen7 and gen7.5 devices, there could be leftover data residuals in > EU/L3 from the retiring context. This patch introduces workaround to clear > that residual contexts, by submitting a batch buffer with dedicated

Re: [Intel-gfx] [RFC] drm/i915: Restrict legacy color key ioctl to pre-gen12

Quoting Matt Roper (2020-01-14 22:45:08) > Since gen12 platform support isn't finalized yet, let's kill off the > legacy color key ioctl for this platform; there's no userspace today > that can run on this platform that utilizes this legacy ioctl, so we can > safely kill it now before it becomes AB

  1   2   >