[Intel-gfx] [PATCH 01/10] drm/i915: Note the addition of timeslicing to the pretend scheduler

2019-10-10 Thread Chris Wilson
Since writing the comment that the scheduler is entirely passive, we've added minimal timeslicing which adds the most primitive of active elements (a timeout and reschedule). Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Ramalingam C --- drivers/gpu/drm/i915/i915_scheduler_types.h | 9 +++

[Intel-gfx] [PATCH 05/10] drm/i915: Mark up "sentinel" requests

2019-10-10 Thread Chris Wilson
Sometimes we want to emit a terminator request, a request that flushes the pipeline and allows no request to come after it. This can be used for a "preempt-to-idle" to ensure that upon processing the context-switch to that request, all other active contexts have been flushed. Signed-off-by: Chris

[Intel-gfx] [PATCH 06/10] drm/i915/gt: Introduce barrier pulses along engines

2019-10-10 Thread Chris Wilson
To flush idle barriers, and even inflight requests, we want to send a preemptive 'pulse' along an engine. We use a no-op request along the pinned kernel_context at high priority so that it should run or else kick off the stuck requests. We can use this to ensure idle barriers are immediately flushe

[Intel-gfx] [PATCH 09/10] drm/i915: Replace hangcheck by heartbeats

2019-10-10 Thread Chris Wilson
Replace sampling the engine state every so often with a periodic heartbeat request to measure the health of an engine. This is coupled with the forced-preemption to allow long running requests to survive so long as they do not block other users. The heartbeat interval can be adjusted per-engine us

[Intel-gfx] [PATCH 07/10] drm/i915/execlists: Cancel banned contexts on schedule-out

2019-10-10 Thread Chris Wilson
On completion of a banned context, scrub the context image so that we do not replay the active payload. The intent is that we skip banned payloads on request submission so that the timeline advancement continues on in the background. However, if we are returning to a preempted request, i915_request

[Intel-gfx] [PATCH 04/10] drm/i915/execlists: Force preemption

2019-10-10 Thread Chris Wilson
If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging

[Intel-gfx] [PATCH 08/10] drm/i915: Cancel non-persistent contexts on close

2019-10-10 Thread Chris Wilson
Normally, we rely on our hangcheck to prevent persistent batches from hogging the GPU. However, if the user disables hangcheck, this mechanism breaks down. Despite our insistence that this is unsafe, the users are equally insistent that they want to use endless batches and will disable the hangchec

[Intel-gfx] [PATCH 03/10] drm/i915: Expose engine properties via sysfs

2019-10-10 Thread Chris Wilson
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 02/10] drm/i915/execlists: Leave tell-tales as to why pending[] is bad

2019-10-10 Thread Chris Wilson
Before we BUG out with bad pending state, leave a telltale as to which test failed. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_lrc.c | 30 - drivers/gpu/drm/i915/i915_gem.h | 8 2 files changed, 2

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

2019-10-10 Thread Chris Wilson
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 --- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 + .../gpu/drm/i915/gt/intel_engine_heartbeat.h | 1 +

[Intel-gfx] [PATCH 1/2] drm/i915/perf: store the associated engine of a stream

2019-10-10 Thread Chris Wilson
From: Lionel Landwerlin We'll use this information later to verify that a client trying to reconfigure the stream does so on the right engine. For now, we want to pull the knowledge of which engine we use into a central property. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_p

[Intel-gfx] [PATCH 2/2] drm/i915/perf: Store shortcut to intel_uncore

2019-10-10 Thread Chris Wilson
Now that we have the engine stored in i915_perf, we have a means of accessing intel_gt should we require it. However, we are currently only using the intel_gt to find the right intel_uncore, so replace our i915_perf.gt pointer with the more useful i915_perf.uncore. Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH i-g-t 2/2] Add i915/gem_ctx_persistence

2019-10-10 Thread Chris Wilson
Sanity test existing persistence and new exciting non-persistent context behaviour. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Michał Winiarski Cc: Jon Bloomfield Cc: Tvrtko Ursulin Cc: Andi Shyti --- lib/i915/gem_context.c | 37 +++ lib/i915/gem_context.h |

[Intel-gfx] [PATCH i-g-t 1/2] i915_drm.h sync

2019-10-10 Thread Chris Wilson
Update to commit fef476f3ab47527a00818ddaf4b46b8c0936 (not upstream!) Author: Chris Wilson Date: Mon Aug 5 22:55:44 2019 +0100 drm/i915: Cancel non-persistent contexts on close for I915_CONTEXT_PARAM_PERSISTENCE --- include/drm-uapi/i915_drm.h | 22 -- 1 file chang

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/guc: improve documentation

2019-10-10 Thread Martin Peres
On 10/10/2019 04:02, Daniele Ceraolo Spurio wrote: > Add a short description of what we expect from GuC and some minor > improvements to existing documentation. Also remove a comment about a > difference between GuC and HuC that is not true anymore. > > v2: add that the GuC is not mandatory (Marti

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm/i915: Note the addition of timeslicing to the pretend scheduler

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [01/10] drm/i915: Note the addition of timeslicing to the pretend scheduler URL : https://patchwork.freedesktop.org/series/67827/ State : warning == Summary == $ dim checkpatch origin/drm-tip cdd8a8ed5e08 drm/i915: Note the addition of timesli

[Intel-gfx] [PATCH] drm/i915/execlists: Mark up expected state during reset

2019-10-10 Thread Chris Wilson
Move the BUG_ON around slightly and add some explanations for each to try and capture the expected state more carefully. We want to compare the expected active state of our bookkeeping as compared to the tracked HW state. References: https://bugs.freedesktop.org/show_bug.cgi?id=111937 Signed-off-b

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Move SAGV block time to dev_priv (rev2)

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915: Move SAGV block time to dev_priv (rev2) URL : https://patchwork.freedesktop.org/series/67799/ State : success == Summary == CI Bug Log - changes from CI_DRM_7046_full -> Patchwork_14733_full =

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Note the addition of timeslicing to the pretend scheduler

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [01/10] drm/i915: Note the addition of timeslicing to the pretend scheduler URL : https://patchwork.freedesktop.org/series/67827/ State : success == Summary == CI Bug Log - changes from CI_DRM_7047 -> Patchwork_14742 ==

Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: the BCS engine supports relative MMIO

2019-10-10 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2019-10-10 00:04:23) > The specs don't mention any specific HW limitation on the blitter and > manual inspection shows that the HW does set the relative MMIO bit in > the LRI of the blitter context image, so we can remove our limitations. I concur, the HW itself set

Re: [Intel-gfx] [PATCH 2/2] drm/i915/tgl: simplify the lrc register list for !RCS

2019-10-10 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2019-10-10 00:04:24) > There are small differences between the blitter and the video engines in > the xcs context image (e.g. registers 0x200 and 0x204 only exist on the > blitter). Since we never explicitly set a value for those register and > given that we don't ne

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/perf: store the associated engine of a stream

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/perf: store the associated engine of a stream URL : https://patchwork.freedesktop.org/series/67828/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7047 -> Patchwork_14743 =

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/tgl: the BCS engine supports relative MMIO

2019-10-10 Thread Chris Wilson
Quoting Patchwork (2019-10-10 03:08:10) > == Series Details == > > Series: series starting with [1/2] drm/i915/tgl: the BCS engine supports > relative MMIO > URL : https://patchwork.freedesktop.org/series/67809/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_7046 ->

Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops

2019-10-10 Thread Jason Wang
On 2019/9/25 上午7:06, Alex Williamson wrote: On Tue, 24 Sep 2019 21:53:30 +0800 Jason Wang wrote: This patch implements basic support for mdev driver that supports virtio transport for kernel virtio driver. Signed-off-by: Jason Wang --- include/linux/mdev.h| 2 + include/linux/vi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Leave tell-tales as to why pending[] is bad (rev2)

2019-10-10 Thread Patchwork
== Series Details == Series: drm/i915/execlists: Leave tell-tales as to why pending[] is bad (rev2) URL : https://patchwork.freedesktop.org/series/67786/ State : success == Summary == CI Bug Log - changes from CI_DRM_7046_full -> Patchwork_14734_full ===

Re: [Intel-gfx] [PATCH 8/8] drm/print: introduce new struct drm_device based logging macros

2019-10-10 Thread Jani Nikula
On Wed, 09 Oct 2019, "Ruhl, Michael J" wrote: >>-Original Message- >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >>Jani Nikula >>+/* Helper for struct drm_device based logging. */ >>+#define __drm_printk(drm, level, type, fmt, ...) \ >

Re: [Intel-gfx] [PATCH] drm/i915/gt: Warn CI about an unrecoverable wedge

2019-10-10 Thread Janusz Krzysztofik
Hi Chris, On Wednesday, October 2, 2019 6:00:34 PM CEST Chris Wilson wrote: > If we have a wedged GPU that we need to recover, but fail, add a taint > for CI to pickup and schedule a reboot. As your approach has been chosen by CI, FWIW: Reviewed-by: Janusz Krzysztofik Thanks, Janusz > > Sign

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/huc: improve documentation

2019-10-10 Thread Martin Peres
On 10/10/2019 04:02, Daniele Ceraolo Spurio wrote: > Better explain the usage of the microcontroller and what i915 is > responsible of. While at it, fix the documentation for the auth > function, which doesn't do any pinning anymore. > > v2: add a comment on HuC being optional and descrive how HuC

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Gen12 E2E compression (rev3)

2019-10-10 Thread Patchwork
== Series Details == Series: Gen12 E2E compression (rev3) URL : https://patchwork.freedesktop.org/series/67078/ State : warning == Summary == $ dim checkpatch origin/drm-tip a2306a44f000 drm/framebuffer: Format modifier for Intel Gen-12 render compression 7fceadb0dd8f drm/i915: Use intel_tile

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/9] drm/i915/perf: store the associated engine of a stream

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [1/9] drm/i915/perf: store the associated engine of a stream URL : https://patchwork.freedesktop.org/series/67804/ State : success == Summary == CI Bug Log - changes from CI_DRM_7046_full -> Patchwork_14736_full ===

[Intel-gfx] [PATCH] drm/i915/selftests: Check that registers are preserved between virtual engines

2019-10-10 Thread Chris Wilson
Make sure that we copy across the registers from one engine to the next, as we hop around a virtual engine. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 176 + 1 file changed, 176 insertions(+) diff --git a/drivers/gpu/drm/

[Intel-gfx] ✗ Fi.CI.BAT: failure for Gen12 E2E compression (rev3)

2019-10-10 Thread Patchwork
== Series Details == Series: Gen12 E2E compression (rev3) URL : https://patchwork.freedesktop.org/series/67078/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7049 -> Patchwork_14744 Summary --- **FAILURE** Serious

Re: [Intel-gfx] [PATCH 3/4] [v5] drm/i915/color: Extract icl_read_luts()

2019-10-10 Thread Sharma, Swati2
On 09-Oct-19 7:46 PM, Ville Syrjälä wrote: On Wed, Oct 09, 2019 at 12:25:41PM +0530, Swati Sharma wrote: For icl+, have hw read out to create hw blob of gamma lut values. icl+ platforms supports multi segmented gamma mode by default, add hw lut creation for this mode. This will be used to valid

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Check that registers are preserved between virtual engines

2019-10-10 Thread Chris Wilson
Quoting Chris Wilson (2019-10-10 11:36:57) > Make sure that we copy across the registers from one engine to the next, > as we hop around a virtual engine. Looking at Broadwell's HW context image, there are no GPR registers for xcs. Weird. -Chris ___ Inte

[Intel-gfx] [PATCH] drm/i915/selftests: Check that registers are preserved between virtual engines

2019-10-10 Thread Chris Wilson
Make sure that we copy across the registers from one engine to the next, as we hop around a virtual engine. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- Skip the test on gen8 as the context image is devoid of CS_GPR. --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 180 +++

[Intel-gfx] [PULL] drm-misc-fixes

2019-10-10 Thread Maxime Ripard
Hi Dave, Daniel, Here's this week drm-misc-fixes PR, dealing mostly with SPI probing related issues. Maxime drm-misc-fixes-2019-10-10: Short summary of fixes pull (less than what git shortlog provides): - SPI Aliases fixes for panels - One fix for the tc358767 bridge dealing with visual artifact

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp-mst: Drop connection_mutex check

2019-10-10 Thread Patchwork
== Series Details == Series: drm/dp-mst: Drop connection_mutex check URL : https://patchwork.freedesktop.org/series/67807/ State : success == Summary == CI Bug Log - changes from CI_DRM_7046_full -> Patchwork_14738_full Summary --- *

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Mark up expected state during reset

2019-10-10 Thread Patchwork
== Series Details == Series: drm/i915/execlists: Mark up expected state during reset URL : https://patchwork.freedesktop.org/series/67830/ State : success == Summary == CI Bug Log - changes from CI_DRM_7050 -> Patchwork_14745 Summary --

Re: [Intel-gfx] [PATCH 07/24] drm/i915: Introduce intel_atomic_get_plane_state_after_check()

2019-10-10 Thread Maarten Lankhorst
Op 08-10-2019 om 19:03 schreef Ville Syrjälä: > On Fri, Oct 04, 2019 at 01:34:57PM +0200, Maarten Lankhorst wrote: >> Use this in all the places where we try to acquire planes after the planes >> atomic_check(). >> >> In case of intel_modeset_all_pipes() this is not yet done after atomic_check, >>

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/tgl: the BCS engine supports relative MMIO

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/tgl: the BCS engine supports relative MMIO URL : https://patchwork.freedesktop.org/series/67809/ State : success == Summary == CI Bug Log - changes from CI_DRM_7046_full -> Patchwork_14739_full ==

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Check that registers are preserved between virtual engines (rev2)

2019-10-10 Thread Patchwork
== Series Details == Series: drm/i915/selftests: Check that registers are preserved between virtual engines (rev2) URL : https://patchwork.freedesktop.org/series/67837/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7050 -> Patchwork_14746 =

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Check that registers are preserved between virtual engines

2019-10-10 Thread Chris Wilson
Make sure that we copy across the registers from one engine to the next, as we hop around a virtual engine. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 180 + 1 file changed, 180 insertions(+) diff --git a/drivers/gpu/drm/

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Check known register values within the context

2019-10-10 Thread Chris Wilson
Check the logical ring context by asserting that the registers hold expected start during execution. (It's a bit chicken-and-egg for how could we manage to execute our request if the registers were not being updated. Still, it's nice to verify that the HW is working as expected.) Signed-off-by: Ch

Re: [Intel-gfx] [PATCH 04/24] drm/i915: Remove cursor use of properties for coordinates

2019-10-10 Thread Maarten Lankhorst
Op 07-10-2019 om 21:37 schreef Matt Roper: > On Fri, Oct 04, 2019 at 01:34:54PM +0200, Maarten Lankhorst wrote: >> We have a src and dect rectangle, use it instead of relying on >> the core drm properties. >> >> This removes the special case in the watermark code for cursor w/h. >> >> Signed-off-by

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Check that registers are preserved between virtual engines

2019-10-10 Thread Tvrtko Ursulin
On 10/10/2019 12:02, Chris Wilson wrote: Make sure that we copy across the registers from one engine to the next, as we hop around a virtual engine. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- Skip the test on gen8 as the context image is devoid of CS_GPR. --- drivers/gpu/drm/i915/gt

Re: [Intel-gfx] [PATCH v4 5/5] drm/i915/pmu: Support multiple GPUs

2019-10-10 Thread Tvrtko Ursulin
Hi guys, Any feedback on the below? On 06/09/2019 16:47, Tvrtko Ursulin wrote: Peter, Thomas, If you could spare a moment for some brainstorming on the topic of uncore PMU and multiple providers it would be appreciated. So from i915 we export some metrics as uncore PMU, which shows up und

Re: [Intel-gfx] [PATCH 07/24] drm/i915: Introduce intel_atomic_get_plane_state_after_check()

2019-10-10 Thread Ville Syrjälä
On Thu, Oct 10, 2019 at 01:56:42PM +0200, Maarten Lankhorst wrote: > Op 08-10-2019 om 19:03 schreef Ville Syrjälä: > > On Fri, Oct 04, 2019 at 01:34:57PM +0200, Maarten Lankhorst wrote: > >> Use this in all the places where we try to acquire planes after the planes > >> atomic_check(). > >> > >> In

Re: [Intel-gfx] [PATCH 15/24] drm/i915: Try to make bigjoiner work in atomic check, v2.

2019-10-10 Thread Maarten Lankhorst
Op 08-10-2019 om 21:40 schreef Ville Syrjälä: > On Fri, Oct 04, 2019 at 01:35:05PM +0200, Maarten Lankhorst wrote: >> When the clock is higher than the dotclock, try with 2 pipes enabled. >> If we can enable 2, then we will go into big joiner mode, and steal >> the adjacent crtc. >> >> This only li

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Mark up expected state during reset

2019-10-10 Thread Mika Kuoppala
Chris Wilson writes: > Move the BUG_ON around slightly and add some explanations for each to > try and capture the expected state more carefully. We want to compare > the expected active state of our bookkeeping as compared to the tracked > HW state. > > References: https://bugs.freedesktop.org/s

[Intel-gfx] Does the i915 VBT tell us if a panel is an OLED panel?

2019-10-10 Thread Hans de Goede
Hi Jani, During plumbers I had some discussions with Daniel about supporting OLED screens. Userspace may need to know that a panel is OLED for 2 reasons: 1) To avoid screen burn-in 2) OLED screens do not have a classic backlight, so in some cases some sort of brightness/contrast emulation throug

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Check that registers are preserved between virtual engines

2019-10-10 Thread Chris Wilson
Quoting Tvrtko Ursulin (2019-10-10 13:31:04) > > On 10/10/2019 12:02, Chris Wilson wrote: > > Make sure that we copy across the registers from one engine to the next, > > as we hop around a virtual engine. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > --- > > Skip the test on g

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: Add microcontrollers documentation section

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [v2,1/3] drm/i915: Add microcontrollers documentation section URL : https://patchwork.freedesktop.org/series/67810/ State : success == Summary == CI Bug Log - changes from CI_DRM_7046_full -> Patchwork_14740_full ==

Re: [Intel-gfx] [PATCH 07/24] drm/i915: Introduce intel_atomic_get_plane_state_after_check()

2019-10-10 Thread Maarten Lankhorst
Op 10-10-2019 om 14:39 schreef Ville Syrjälä: > On Thu, Oct 10, 2019 at 01:56:42PM +0200, Maarten Lankhorst wrote: >> Op 08-10-2019 om 19:03 schreef Ville Syrjälä: >>> On Fri, Oct 04, 2019 at 01:34:57PM +0200, Maarten Lankhorst wrote: Use this in all the places where we try to acquire planes a

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Check that registers are preserved between virtual engines

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/selftests: Check that registers are preserved between virtual engines URL : https://patchwork.freedesktop.org/series/67843/ State : success == Summary == CI Bug Log - changes from CI_DRM_7051 -> Patchwork_14747 =

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Check known register values within the context

2019-10-10 Thread Chris Wilson
Check the logical ring context by asserting that the registers hold expected start during execution. (It's a bit chicken-and-egg for how could we manage to execute our request if the registers were not being updated. Still, it's nice to verify that the HW is working as expected.) Signed-off-by: Ch

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Check that GPR are cleared for new contexts

2019-10-10 Thread Chris Wilson
We want the general purpose registers to be clear in all new contexts so that we can be confident that no information is leaked from one to the next. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 185 ++--- 1 file changed, 166 in

Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftests: Check that GPR are cleared for new contexts

2019-10-10 Thread Chris Wilson
Quoting Chris Wilson (2019-10-10 14:15:21) > +static int __live_gpr_clear(struct i915_gem_context *fixme, > + struct intel_engine_cs *engine, > + struct i915_vma *scratch) > +{ > + struct intel_context *ce; > + struct i915_request *rq;

Re: [Intel-gfx] Does the i915 VBT tell us if a panel is an OLED panel?

2019-10-10 Thread Jani Nikula
On Thu, 10 Oct 2019, Hans de Goede wrote: > Hi Jani, > > During plumbers I had some discussions with Daniel about supporting > OLED screens. Userspace may need to know that a panel is OLED for 2 > reasons: > > 1) To avoid screen burn-in > 2) OLED screens do not have a classic backlight, so in some

Re: [Intel-gfx] [PATCH] drm/dp-mst: Drop connection_mutex check

2019-10-10 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 06:46:38PM -0400, Lyude Paul wrote: > oh, completely forgot about this one > > Reviewed-by: Lyude Paul Thanks for your review, applied to drm-misc-next. -Daniel > > On Thu, 2019-10-10 at 00:41 +0200, Daniel Vetter wrote: > > Private atomic objects have grown their own lo

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/vbt: Handle generic DTD block

2019-10-10 Thread Patchwork
== Series Details == Series: drm/i915/vbt: Handle generic DTD block URL : https://patchwork.freedesktop.org/series/67811/ State : success == Summary == CI Bug Log - changes from CI_DRM_7046_full -> Patchwork_14741_full Summary --- **

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

2019-10-10 Thread Chris Wilson
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:

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

2019-10-10 Thread Chris Wilson
Quoting Chris Wilson (2019-10-10 14:48:49) > 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. One might rea

Re: [Intel-gfx] [PATCH 04/24] drm/i915: Remove cursor use of properties for coordinates

2019-10-10 Thread Maarten Lankhorst
Op 07-10-2019 om 21:37 schreef Matt Roper: > On Fri, Oct 04, 2019 at 01:34:54PM +0200, Maarten Lankhorst wrote: >> We have a src and dect rectangle, use it instead of relying on >> the core drm properties. >> >> This removes the special case in the watermark code for cursor w/h. >> >> Signed-off-by

Re: [Intel-gfx] [PATCH 08/24] drm/i915: Prepare to split crtc state in uapi and hw state

2019-10-10 Thread Maarten Lankhorst
Op 08-10-2019 om 19:06 schreef Ville Syrjälä: > On Fri, Oct 04, 2019 at 01:34:58PM +0200, Maarten Lankhorst wrote: >> We want to split drm_crtc_state into the user visible state >> and actual hardware state. To prepare for this, we need some >> ground rules what should be in each state: >> >> In ua

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

2019-10-10 Thread Chris Wilson
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 --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 83 +++-- include/uapi/drm/i915_drm.h | 12 +++ 2 files cha

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

2019-10-10 Thread Rodrigo Vivi
Hi Dave and Daniel, This pull request includes the ones we missed for -rc1 drm-intel-next-fixes-2019-09-26 & drm-intel-next-fixes-2019-09-19 plus few fixes for execlists requests and CML display. Here goes drm-intel-fixes-2019-10-10: - Fix CML display by adding a missing ID. - Drop redundant list

Re: [Intel-gfx] [PATCH 08/24] drm/i915: Prepare to split crtc state in uapi and hw state

2019-10-10 Thread Ville Syrjälä
On Thu, Oct 10, 2019 at 04:21:00PM +0200, Maarten Lankhorst wrote: > Op 08-10-2019 om 19:06 schreef Ville Syrjälä: > > On Fri, Oct 04, 2019 at 01:34:58PM +0200, Maarten Lankhorst wrote: > >> We want to split drm_crtc_state into the user visible state > >> and actual hardware state. To prepare for t

[Intel-gfx] [PATCH 2/5] drm/i915: s/hdcp2_hdmi_msg_data/hdcp2_hdmi_msg_timeout/

2019-10-10 Thread Ville Syrjala
From: Ville Syrjälä The array is there only for timeout, "data" doesn't mean anything so let's rename the thing to be more descriptive. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_hdmi.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/

[Intel-gfx] [PATCH 1/5] drm/i915: Shrink eDRAM ways/sets arrays

2019-10-10 Thread Ville Syrjala
From: Ville Syrjälä Make the ways/sets arrays static cosnt u8 to shrink things a bit. text data bss dec hex filename - 23935629 128 246926074 i915_drv.o + 23818629 128 245755fff i915_drv.o Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 3/5] drm/i915: Remove dead weight from hdcp2_msg_timeout[]

2019-10-10 Thread Ville Syrjala
From: Ville Syrjälä The .read_2_2() hooks is never called for any of the message types with a zero timeout. So it's all just dead weight which we can chuck. text data bss dec hex filename - 34701360 0 3506188f5 intel_hdmi.o + 346333

[Intel-gfx] [PATCH 5/5] drm/i915: Make hdcp2_msg_timeout.timeout u16

2019-10-10 Thread Ville Syrjala
From: Ville Syrjälä All the timeout values fit in u16, so let's shrink the structure a bit. This ends up actually increasing the .text size a bit due to some changes in instructions (constant imul+small jmps replaced with mov+bigger jmpqs). Seems pretty arbitrary to me so I'll just pretend I did

[Intel-gfx] [PATCH 4/5] drm/i915: Remove hdcp2_hdmi_msg_timeout.timeout2

2019-10-10 Thread Ville Syrjala
From: Ville Syrjälä The only reason for the timeout2 value in the array is the HDCP_2_2_AKE_SEND_HPRIME message. But that one still needs special casing inside the loop, and so just ends up making the code harder to read. Let's just remove this leaky timeout2 abstraction and special case that one

Re: [Intel-gfx] [PATCH 1/2] drm/i915/perf: store the associated engine of a stream

2019-10-10 Thread Lionel Landwerlin
On 10/10/2019 10:27, Chris Wilson wrote: From: Lionel Landwerlin We'll use this information later to verify that a client trying to reconfigure the stream does so on the right engine. For now, we want to pull the knowledge of which engine we use into a central property. Signed-off-by: Lionel L

Re: [Intel-gfx] [PATCH 2/2] drm/i915/perf: Store shortcut to intel_uncore

2019-10-10 Thread Lionel Landwerlin
On 10/10/2019 10:27, Chris Wilson wrote: Now that we have the engine stored in i915_perf, we have a means of accessing intel_gt should we require it. However, we are currently only using the intel_gt to find the right intel_uncore, so replace our i915_perf.gt pointer with the more useful i915_per

Re: [Intel-gfx] [PATCH 1/2] drm/i915/perf: store the associated engine of a stream

2019-10-10 Thread Chris Wilson
Quoting Lionel Landwerlin (2019-10-10 15:57:32) > On 10/10/2019 10:27, Chris Wilson wrote: > > From: Lionel Landwerlin > > > > We'll use this information later to verify that a client trying to > > reconfigure the stream does so on the right engine. For now, we want to > > pull the knowledge of wh

[Intel-gfx] [CI 1/2] drm/i915/perf: store the associated engine of a stream

2019-10-10 Thread Chris Wilson
From: Lionel Landwerlin We'll use this information later to verify that a client trying to reconfigure the stream does so on the right engine. For now, we want to pull the knowledge of which engine we use into a central property. Signed-off-by: Lionel Landwerlin Reviewed-by: Chris Wilson ---

[Intel-gfx] [CI 2/2] drm/i915/perf: Store shortcut to intel_uncore

2019-10-10 Thread Chris Wilson
Now that we have the engine stored in i915_perf, we have a means of accessing intel_gt should we require it. However, we are currently only using the intel_gt to find the right intel_uncore, so replace our i915_perf.gt pointer with the more useful i915_perf.uncore. Signed-off-by: Chris Wilson Cc:

Re: [Intel-gfx] [PATCH 7/9] drm/i915/perf: Allow dynamic reconfiguration of the OA stream

2019-10-10 Thread Lionel Landwerlin
On 10/10/2019 00:19, Chris Wilson wrote: From: Lionel Landwerlin Introduce a new perf_ioctl command to change the OA configuration of the active stream. This allows the OA stream to be reconfigured between batch buffers, giving greater flexibility in sampling. We inject a request into the OA co

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Check known register values within the context

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/selftests: Check known register values within the context URL : https://patchwork.freedesktop.org/series/67849/ State : success == Summary == CI Bug Log - changes from CI_DRM_7055 -> Patchwork_14748 =

Re: [Intel-gfx] [PATCH 7/9] drm/i915/perf: Allow dynamic reconfiguration of the OA stream

2019-10-10 Thread Chris Wilson
Quoting Lionel Landwerlin (2019-10-10 16:22:25) > On 10/10/2019 00:19, Chris Wilson wrote: > > From: Lionel Landwerlin > > > > Introduce a new perf_ioctl command to change the OA configuration of the > > active stream. This allows the OA stream to be reconfigured between > > batch buffers, giving

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Check known register values within the context

2019-10-10 Thread Chris Wilson
Check the logical ring context by asserting that the registers hold expected start during execution. (It's a bit chicken-and-egg for how could we manage to execute our request if the registers were not being updated. Still, it's nice to verify that the HW is working as expected.) Signed-off-by: Ch

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Check that GPR are cleared for new contexts

2019-10-10 Thread Chris Wilson
We want the general purpose registers to be clear in all new contexts so that we can be confident that no information is leaked from one to the next. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 185 ++--- 1 file changed, 166 in

[Intel-gfx] [PATCH] drm/i915: Don't disable interrupts independently of the lock

2019-10-10 Thread Sebastian Andrzej Siewior
The locks (active.lock and rq->lock) need to be taken with disabled interrupts. This is done in i915_request_retire() by disabling the interrupts independently of the locks itself. While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla it does not on PREEMPT_RT. Also, it is not obv

Re: [Intel-gfx] [PATCH 7/9] drm/i915/perf: Allow dynamic reconfiguration of the OA stream

2019-10-10 Thread Lionel Landwerlin
On 10/10/2019 18:44, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-10-10 16:22:25) On 10/10/2019 00:19, Chris Wilson wrote: From: Lionel Landwerlin Introduce a new perf_ioctl command to change the OA configuration of the active stream. This allows the OA stream to be reconfigured betwee

Re: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Prevent merging requests with conflicting flags

2019-10-10 Thread Lionel Landwerlin
On 10/10/2019 00:19, Chris Wilson wrote: We set out-of-bound parameters inside the i915_requests.flags field, such as disabling preemption or marking the end-of-context. We should not coalesce consecutive requests if they have differing instructions as we only inspect the last active request in a

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/10] drm/i915: Note the addition of timeslicing to the pretend scheduler

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [01/10] drm/i915: Note the addition of timeslicing to the pretend scheduler URL : https://patchwork.freedesktop.org/series/67827/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7047_full -> Patchwork_14742_full

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Enable bigjoiner support, second approach. (rev3)

2019-10-10 Thread Patchwork
== Series Details == Series: Enable bigjoiner support, second approach. (rev3) URL : https://patchwork.freedesktop.org/series/67590/ State : failure == Summary == Applying: HAX to make DSC work on the icelake test system Applying: drm/i915: Fix for_each_intel_plane_mask definition Using index

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Honour O_NONBLOCK before throttling execbuf submissions

2019-10-10 Thread Patchwork
== Series Details == Series: drm/i915: Honour O_NONBLOCK before throttling execbuf submissions URL : https://patchwork.freedesktop.org/series/67850/ State : success == Summary == CI Bug Log - changes from CI_DRM_7056 -> Patchwork_14749 Summ

[Intel-gfx] ✗ Fi.CI.BUILD: failure for RFC drm/i915: Allow userspace to specify ringsize on construction

2019-10-10 Thread Patchwork
== Series Details == Series: RFC drm/i915: Allow userspace to specify ringsize on construction URL : https://patchwork.freedesktop.org/series/67852/ State : failure == Summary == Applying: RFC drm/i915: Allow userspace to specify ringsize on construction Using index info to reconstruct a base

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Shrink eDRAM ways/sets arrays

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [1/5] drm/i915: Shrink eDRAM ways/sets arrays URL : https://patchwork.freedesktop.org/series/67853/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7056 -> Patchwork_14752 Sum

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Move SAGV block time to dev_priv (rev2)

2019-10-10 Thread Lucas De Marchi
On Wed, Oct 09, 2019 at 10:37:21PM +, Patchwork wrote: == Series Details == Series: series starting with [CI,1/2] drm/i915: Move SAGV block time to dev_priv (rev2) URL : https://patchwork.freedesktop.org/series/67799/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7da5381

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/perf: store the associated engine of a stream

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915/perf: store the associated engine of a stream URL : https://patchwork.freedesktop.org/series/67857/ State : success == Summary == CI Bug Log - changes from CI_DRM_7056 -> Patchwork_14753 ==

Re: [Intel-gfx] [PATCH] drm/i915: Don't disable interrupts independently of the lock

2019-10-10 Thread Chris Wilson
Quoting Sebastian Andrzej Siewior (2019-10-10 17:06:40) > The locks (active.lock and rq->lock) need to be taken with disabled > interrupts. This is done in i915_request_retire() by disabling the > interrupts independently of the locks itself. > While local_irq_disable()+spin_lock() equals spin_lock

Re: [Intel-gfx] [PATCH] drm/i915: Don't disable interrupts independently of the lock

2019-10-10 Thread Sebastian Andrzej Siewior
On 2019-10-10 19:11:27 [+0100], Chris Wilson wrote: > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -251,15 +251,13 @@ static bool i915_request_retire(struct i > > active->retire(active, rq); > > } > > > > - local_ir

[Intel-gfx] [PATCH v8 3/6] drm/i915/display/icl: HW state readout for transcoder port sync config

2019-10-10 Thread Manasi Navare
After the state is committed, we readout the HW registers and compare the HW state with the SW state that we just committed. For Transcdoer port sync, we add master_transcoder and the salves bitmask to the crtc_state, hence we need to read those during the HW state readout to avoid pipe state misma

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Check known register values within the context

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/selftests: Check known register values within the context URL : https://patchwork.freedesktop.org/series/67862/ State : success == Summary == CI Bug Log - changes from CI_DRM_7057 -> Patchwork_14754 =

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Don't disable interrupts independently of the lock (rev2)

2019-10-10 Thread Patchwork
== Series Details == Series: drm/i915: Don't disable interrupts independently of the lock (rev2) URL : https://patchwork.freedesktop.org/series/59289/ State : failure == Summary == Applying: drm/i915: Don't disable interrupts independently of the lock error: sha1 information is lacking or usel

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v7,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync (rev2)

2019-10-10 Thread Patchwork
== Series Details == Series: series starting with [v7,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync (rev2) URL : https://patchwork.freedesktop.org/series/67806/ State : failure == Summary == Applying: drm/i915/display/icl: Save Master transco

[Intel-gfx] [PATCH 4/4] drm/i915/display: Check if FBC and DMC are fused off

2019-10-10 Thread José Roberto de Souza
Those features could be fused off on GEN9 non-low power and newer GENs. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_device_info.c | 6 ++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/

[Intel-gfx] [PATCH 1/4] drm/i915/display: Handle fused off display correctly

2019-10-10 Thread José Roberto de Souza
If all pipes are fused off it means that display is disabled, similar like we handle for GEN 7 and 8 right above. On GEN 9 the bit 31 is "Internal Graphics Disable" and on newer GENs it has another function, probably on GEN 9 when bit 31 is set all the 3 pipes disable bit are set, so we can unify

  1   2   >