[Intel-gfx] [PATCH 5/6] drm/i915: Pull scheduling under standalone lock

Currently, the backend scheduling code abuses struct_mutex into order to have a global lock to manipulate a temporary list (without widespread allocation) and to protect against list modifications. This is an extraneous coupling to struct_mutex and further can not extend beyond the local device. P

[Intel-gfx] [PATCH 3/6] drm/i915: Combine multiple internal plists into the same i915_priolist bucket

As we are about to allow ourselves to slightly bump the user priority into a few different sublevels, packthose internal priority lists into the same i915_priolist to keep the rbtree compact and avoid having to allocate the default user priority even after the internal bumping. The downside to havi

[Intel-gfx] [PATCH 2/6] drm/i915: Reserve some priority bits for internal use

In the next few patches, we will want to give a small priority boost to some requests/queues but not so much that we perturb the user controlled order. As such we shift the user priority bits higher leaving ourselves a few low priority bits for our bumping. Signed-off-by: Chris Wilson --- driver

[Intel-gfx] [PATCH 4/6] drm/i915: Priority boost for new clients

Taken from an idea used for FQ_CODEL, we give new request flows a priority boost. These flows are likely to correspond with interactive tasks and so be more latency sensitive than the long queues. As soon as the client has more than one request in the queue, further requests are not boosted and it

[Intel-gfx] [PATCH 1/6] drm/i915: Limit C-states when waiting for the active request

If we are waiting for the currently executing request, we have a good idea that it will be completed in the very near future and so want to cap the CPU_DMA_LATENCY to ensure that we wake up the client quickly. v2: Not allowed to block in kmalloc after setting TASK_INTERRUPTIBLE. v3: Avoid the bloc

[Intel-gfx] [PATCH 6/6] drm/i915: Priority boost for waiting clients

Latency is in the eye of the beholder. In the case where a client stops and waits for the gpu, give that request chain a small priority boost (not so that it overtakes higher priority clients, to preserve the external ordering) so that ideally the wait completes earlier. Testcase: igt/gem_sync/swi

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Limit C-states when waiting for the active request

== Series Details == Series: series starting with [1/6] drm/i915: Limit C-states when waiting for the active request URL : https://patchwork.freedesktop.org/series/47739/ State : warning == Summary == $ dim checkpatch origin/drm-tip ffbc30b340a9 drm/i915: Limit C-states when waiting for the a

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915: Limit C-states when waiting for the active request

== Series Details == Series: series starting with [1/6] drm/i915: Limit C-states when waiting for the active request URL : https://patchwork.freedesktop.org/series/47739/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Limit C-states when waiting for the active req

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Limit C-states when waiting for the active request

== Series Details == Series: series starting with [1/6] drm/i915: Limit C-states when waiting for the active request URL : https://patchwork.freedesktop.org/series/47739/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4618 -> Patchwork_9855 = == Summary - SUCCESS == No r

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Limit C-states when waiting for the active request

On 06/08/2018 09:30, Chris Wilson wrote: If we are waiting for the currently executing request, we have a good idea that it will be completed in the very near future and so want to cap the CPU_DMA_LATENCY to ensure that we wake up the client quickly. I cannot shake the opinion that we shouldn'

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915: Limit C-states when waiting for the active request

== Series Details == Series: series starting with [1/6] drm/i915: Limit C-states when waiting for the active request URL : https://patchwork.freedesktop.org/series/47739/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4618_full -> Patchwork_9855_full = == Summary - FAILURE

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Priority boost for new clients

On 06/08/2018 09:30, Chris Wilson wrote: Taken from an idea used for FQ_CODEL, we give new request flows a priority boost. These flows are likely to correspond with interactive tasks and so be more latency sensitive than the long queues. As soon as the client has more than one request in the que

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Priority boost for waiting clients

On 06/08/2018 09:30, Chris Wilson wrote: Latency is in the eye of the beholder. In the case where a client stops and waits for the gpu, give that request chain a small priority boost (not so that it overtakes higher priority clients, to preserve the external ordering) so that ideally the wait co

[Intel-gfx] [PATCH v2 04/10] drm/i915: Constify power well descriptors

It makes sense to keep unchanging data const. Extract such fields from the i915_power_well struct into a new i915_power_well_desc struct that we initialize during compile time. For the rest of the dynamic fields allocate an array of i915_power_well objects in i915 dev_priv, and link to each of thes

[Intel-gfx] [PATCH v2 00/10] drm/i915: Clean up power well descriptors

This is v2 of [1], fixing the issues Paulo noticed. [1] https://patchwork.freedesktop.org/series/46952/ Cc: Chris Wilson Cc: Ville Syrjala Cc: Paulo Zanoni Cc: Jani Nikula Cc: Rodrigo Vivi Imre Deak (10): drm/i915/icl: Fix power well anonymous union initializers drm/i915: Rename intel_p

[Intel-gfx] [PATCH v2 01/10] drm/i915/icl: Fix power well anonymous union initializers

Similarly to commit 0a445945be6d ("drm/i915: Work around GCC anonymous union initialization bug") we need to initialize anonymous unions inside extra braces to work around a GCC4.4 build error. v2: - Fix checkpatch errors in commit log. (Paulo) Cc: Chris Wilson Cc: Ville Syrjala Cc: Paulo Zanon

[Intel-gfx] [PATCH v2 05/10] drm/i915/vlv: Use power well CTL IDX instead of ID

Atm, we determine the control/status flag offsets within the PUNIT control/status registers based on the power well's ID. Since the power well ID enum is global across all platforms, the associated macros to get the flag offsets involves some magic. This makes checking the register/bit definitions

[Intel-gfx] [PATCH v2 03/10] drm/i915/vlv: Remove redundant power well ID asserts

The callbacks these asserts are called from are used from a single power well, so not much point in checking that. The check also requires a unique power well ID that we would need to keep around only for this purpose. (A follow-up patch removes power well IDs not needed for direct power well acce

[Intel-gfx] [PATCH v2 02/10] drm/i915: Rename intel_power_domains_fini() to intel_power_domains_fini_hw()

intel_power_domains_fini() rolls back what was done in intel_power_domains_init_hw(), so rename and move it accordingly. This allows us adding a cleanup function later for intel_power_domains_init() in a cleaner way. No functional change. v2: - Fix checkpatch error adding missing param name to fu

[Intel-gfx] [PATCH v2 08/10] drm/i915: Make power well ID names more uniform

The format for the ID names is _DISP_PW_* so rename the IDs not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll change that to use another existing ID in the next patch. v2: - Fix line over 80 chars checkpatch warning. Cc: Ville Syrjala Cc: Paulo Zanoni Cc: Jani Nikula Sign

[Intel-gfx] [PATCH v2 07/10] drm/i915: Remove redundant power well IDs

Now that we removed dependence on the power well IDs to determine the control register and request/status flag offsets the only purpose of power well IDs is to look up power wells directly bypassing the power domains framework. However this direct lookup isn't needed for most of the exisiting power

[Intel-gfx] [PATCH v2 06/10] drm/i915/ddi: Use power well CTL IDX instead of ID

Similarly to the previous patch use a separate request/status HW flag index defined right after the corresponding control registers instead of depending for this on the power well IDs. Since the set of control/status registers varies among the different power wells (on a single platform), also add

[Intel-gfx] [PATCH v2 09/10] drm/i915: Use existing power well IDs where possible

There is no need for separate IDs for power wells on a new platform with the same functionality as an other power well on a previous platform, we can just reuse the ID from the previous platform. This is only possible after the previous patches where we removed dependence on the actual enum values.

[Intel-gfx] [PATCH v2 10/10] drm/i915/icl: Add missing power gate enums

On ICL there are 5 fused power gates, so add the two missing ones for clarity. Cc: Ville Syrjala Cc: Paulo Zanoni Cc: Jani Nikula Signed-off-by: Imre Deak Reviewed-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Limit C-states when waiting for the active request

Quoting Tvrtko Ursulin (2018-08-06 10:34:54) > > On 06/08/2018 09:30, Chris Wilson wrote: > > If we are waiting for the currently executing request, we have a good > > idea that it will be completed in the very near future and so want to > > cap the CPU_DMA_LATENCY to ensure that we wake up the cl

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Priority boost for waiting clients

Quoting Tvrtko Ursulin (2018-08-06 10:53:52) > > On 06/08/2018 09:30, Chris Wilson wrote: > > Latency is in the eye of the beholder. In the case where a client stops > > and waits for the gpu, give that request chain a small priority boost > > (not so that it overtakes higher priority clients, to

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Clean up power well descriptors (rev2)

== Series Details == Series: drm/i915: Clean up power well descriptors (rev2) URL : https://patchwork.freedesktop.org/series/46952/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6c5eac3775d7 drm/i915/icl: Fix power well anonymous union initializers 69d41b65c165 drm/i915: Rename

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up power well descriptors (rev2)

== Series Details == Series: drm/i915: Clean up power well descriptors (rev2) URL : https://patchwork.freedesktop.org/series/46952/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/icl: Fix power well anonymous union initializers Okay! Commit: drm/i915: Rename intel_

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Limit C-states when waiting for the active request

On 06/08/2018 10:59, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-08-06 10:34:54) On 06/08/2018 09:30, Chris Wilson wrote: If we are waiting for the currently executing request, we have a good idea that it will be completed in the very near future and so want to cap the CPU_DMA_LATENCY to

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Priority boost for waiting clients

On 06/08/2018 11:03, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-08-06 10:53:52) On 06/08/2018 09:30, Chris Wilson wrote: Latency is in the eye of the beholder. In the case where a client stops and waits for the gpu, give that request chain a small priority boost (not so that it overtake

[Intel-gfx] [PATCH] drm/i915: Pull seqno started checks together

We have a few instances of checking seqno-1 to see if the HW has started the request. Pull those together under a helper. Suggested-by: Tvrtko Ursulin Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_request.c | 9 +++--- drivers/gpu/drm/i915/i915_request.h

Re: [Intel-gfx] [PATCH] drm/i915: Enforce TYPESAFE_BY_RCU vs refcount mb on reinitialisation

Chris Wilson writes: > By using TYPESAFE_BY_RCU, we accept that requests may be swapped out from > underneath us, even when using rcu_read_lock(). We use a strong barrier > on acquiring the refcount during lookup, but this needs to be paired > with a barrier on re-initialising it. Currently we ca

Re: [Intel-gfx] [PATCH] drm/i915: Pull seqno started checks together

Chris Wilson writes: > We have a few instances of checking seqno-1 to see if the HW has started > the request. Pull those together under a helper. > Could you elaborate why you want both completed and signaled? Otherwise it looks good. -Mika > Suggested-by: Tvrtko Ursulin > Signed-off-by: Chri

Re: [Intel-gfx] [PATCH] drm/i915: Pull seqno started checks together

Quoting Mika Kuoppala (2018-08-06 12:17:16) > Chris Wilson writes: > > > We have a few instances of checking seqno-1 to see if the HW has started > > the request. Pull those together under a helper. > > > > Could you elaborate why you want both completed and signaled? Purely on context. In some

[Intel-gfx] [PATCH] drm/i915: Pull seqno started checks together

We have a few instances of checking seqno-1 to see if the HW has started the request. Pull those together under a helper. v2: Pull the !seqno assertion higher, as we given seqno==1 we may indeed check to see if we have started using seqno==0. Suggested-by: Tvrtko Ursulin Signed-off-by: Chris Wil

Re: [Intel-gfx] [PATCH] drm/i915: Enforce TYPESAFE_BY_RCU vs refcount mb on reinitialisation

Quoting Mika Kuoppala (2018-08-06 12:12:15) > Chris Wilson writes: > > > By using TYPESAFE_BY_RCU, we accept that requests may be swapped out from > > underneath us, even when using rcu_read_lock(). We use a strong barrier > > on acquiring the refcount during lookup, but this needs to be paired >

Re: [Intel-gfx] [PATCH] drm/i915: Enforce TYPESAFE_BY_RCU vs refcount mb on reinitialisation

Chris Wilson writes: > Quoting Mika Kuoppala (2018-08-06 12:12:15) >> Chris Wilson writes: >> >> > By using TYPESAFE_BY_RCU, we accept that requests may be swapped out from >> > underneath us, even when using rcu_read_lock(). We use a strong barrier >> > on acquiring the refcount during lookup,

[Intel-gfx] [v2] drm/i915: Add detection of changing of edid on between suspend and resume

The hotplug detection routine of i915 uses drm_helper_hpd_irq_event(). This helper can detect changing of status of connector, but it can not detect changing of edid. Following scenario requires detection of changing of edid. 1) plug display device to a connector 2) system suspend 3) unplug 1)

[Intel-gfx] [PATCH i-g-t] amdgpu: Exporting a dmabuf from amdgpu waits for outstanding fences

Since amdgpu is synchronous for exporting a dmabuf, exercise both paths to highlight the issue. References: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Signed-off-by: Chris Wilson --- tests/amdgpu/amd_prime.c | 27 +-- 1 file changed, 21 insertions(+), 6 deletions

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Pull seqno started checks together (rev2)

== Series Details == Series: drm/i915: Pull seqno started checks together (rev2) URL : https://patchwork.freedesktop.org/series/47753/ State : warning == Summary == $ dim checkpatch origin/drm-tip 95cd3d8b15e9 drm/i915: Pull seqno started checks together -:69: CHECK:PARENTHESIS_ALIGNMENT: Alig

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pull seqno started checks together (rev2)

== Series Details == Series: drm/i915: Pull seqno started checks together (rev2) URL : https://patchwork.freedesktop.org/series/47753/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9857 = == Summary - SUCCESS == No regressions found. External URL: h

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add detection of changing of edid on between suspend and resume (rev2)

== Series Details == Series: drm/i915: Add detection of changing of edid on between suspend and resume (rev2) URL : https://patchwork.freedesktop.org/series/47680/ State : warning == Summary == $ dim checkpatch origin/drm-tip 93959254664e drm/i915: Add detection of changing of edid on between

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add detection of changing of edid on between suspend and resume (rev2)

== Series Details == Series: drm/i915: Add detection of changing of edid on between suspend and resume (rev2) URL : https://patchwork.freedesktop.org/series/47680/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9858 = == Summary - FAILURE == Serious unk

[Intel-gfx] [PATCH i-g-t] amdgpu: Exporting a dmabuf from amdgpu waits for outstanding fences

Since amdgpu is synchronous for exporting a dmabuf, exercise both paths to highlight the issue. v2: More action required to trigger the dmabuf-mapping References: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Signed-off-by: Chris Wilson --- tests/amdgpu/amd_prime.c | 47 ++

[Intel-gfx] [PATCH] drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start

Experience teaches us over and over again that coherency on Baytrail requires the odd heavy hammer, and in particular clflush alone is not enough to guarrantee that writes from the CPU are picked up by the CS. Do as we do elsewhere and ensure we have an unconditional i915_gem_chipset_flush() after

[Intel-gfx] [PATCH] drm/i915: Stop dropping irq around resets

A long time ago, we were afraid of handling interrupts and signaling waiters during a reset, worrying that the confusion in request handling would interfere with our attempts to process the reset in an orderly fashion. Since then, we have isolated our irq-driven request handling by virtual of the e

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start

== Series Details == Series: drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start URL : https://patchwork.freedesktop.org/series/47767/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9859 = == Summary - SUCCESS == No regressions f

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Pull seqno started checks together (rev2)

== Series Details == Series: drm/i915: Pull seqno started checks together (rev2) URL : https://patchwork.freedesktop.org/series/47753/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9857_full = == Summary - WARNING == Minor unknown changes coming wi

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: kill resource streamer

On 04/08/2018 00:24, Lucas De Marchi wrote: After disabling resource streamer on ICL (due to it actually not existing there), I got feedback that there have been some experimental patches for mesa to use RS years ago, but nothing ever landed or shipped because there was no performance improvemen

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop dropping irq around resets

== Series Details == Series: drm/i915: Stop dropping irq around resets URL : https://patchwork.freedesktop.org/series/47769/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9860 = == Summary - SUCCESS == No regressions found. External URL: https://pat

Re: [Intel-gfx] [PATCH v2] RFC drm/i915: Mark runtime_pm as a special class of lock

On Fri, Jul 13, 2018 at 02:29:58PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2018-07-12 13:58:11) > > On Thu, Jul 12, 2018 at 09:41:07AM +0100, Chris Wilson wrote: > > > Quoting Chris Wilson (2018-07-12 09:36:33) > > > > Signed-off-by: Chris Wilson > > > > --- > > > > drivers/gpu/drm/i9

[Intel-gfx] [PATCH] v2 drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"

This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was droppe

Re: [Intel-gfx] [PATCH] Revert "drm/i915/icl: WaEnableFloatBlendOptimization"

Quoting Anuj Phogat (2018-08-03 20:24:09) > > > On Mon, Jul 30, 2018 at 5:07 AM Mika Kuoppala > wrote: > > The register for 0xe420 is unable to hold any value, including > this bit. The documentation is also mixed between having a > register bit for toggle and having a state command

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: kill resource streamer

Quoting Tvrtko Ursulin (2018-08-06 16:31:48) > > On 04/08/2018 00:24, Lucas De Marchi wrote: > > After disabling resource streamer on ICL (due to it actually not > > existing there), I got feedback that there have been some experimental > > patches for mesa to use RS years ago, but nothing ever la

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse" (rev2)

== Series Details == Series: drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse" (rev2) URL : https://patchwork.freedesktop.org/series/47694/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9861 = == Summary - SUCCESS == No

Re: [Intel-gfx] [PATCH] drm/i915: Stop dropping irq around resets

Quoting Chris Wilson (2018-08-06 15:56:47) > A long time ago, we were afraid of handling interrupts and signaling > waiters during a reset, worrying that the confusion in request handling > would interfere with our attempts to process the reset in an orderly > fashion. Since then, we have isolated

[Intel-gfx] [PATCH] drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming

Add the newly added slice_row_per_frame parameter in the Picture Parameter Set registers. Credits to Manasi for noticing bSpec change. Suggested-by: Manasi Navare Cc: Manasi Navare Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/i915_reg.h | 1 + 1 file changed, 1 insertion(+) diff -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming

== Series Details == Series: drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming URL : https://patchwork.freedesktop.org/series/47774/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4622 -> Patchwork_9862 = == Summary - SUCCESS == No regressions found. Externa

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start

== Series Details == Series: drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start URL : https://patchwork.freedesktop.org/series/47767/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9859_full = == Summary - WARNING == Minor

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Stop dropping irq around resets

== Series Details == Series: drm/i915: Stop dropping irq around resets URL : https://patchwork.freedesktop.org/series/47769/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9860_full = == Summary - WARNING == Minor unknown changes coming with Patchwo

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming

On Mon, Aug 06, 2018 at 10:33:48AM -0700, Anusha Srivatsa wrote: > Add the newly added slice_row_per_frame parameter > in the Picture Parameter Set registers. > Might be helpful to specify that this indicates number of slices stacked in vertical direction when DSC is enabled. With this: Reviewed

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start

On 6 August 2018 at 15:46, Chris Wilson wrote: > Experience teaches us over and over again that coherency on Baytrail > requires the odd heavy hammer, and in particular clflush alone is not > enough to guarrantee that writes from the CPU are picked up by the CS. > Do as we do elsewhere and ensure

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse" (rev2)

== Series Details == Series: drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse" (rev2) URL : https://patchwork.freedesktop.org/series/47694/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9861_full = == Summary - WARNIN

[Intel-gfx] [PATCH v3] drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling

After encoder->pre_enable() hook, after link training sequence is completed, PPS registers for DSC encoder are configured using the DSC state parameters in intel_crtc_state as part of DSC enabling routine in the source. DSC enabling routine is called after encoder->pre_enable() before enbaling the

[Intel-gfx] [PATCH v3] drm/i915/dp: Configure Display stream splitter registers during DSC enable

Display Stream Splitter registers need to be programmed to enable the joiner if two DSC engines are used and also to enable the left and the right DSC engines. This happens as part of the DSC enabling routine in the source in atomic commit. v2: * Rebase (Manasi) Cc: Jani Nikula Cc: Ville Syrjala

[Intel-gfx] ✗ Fi.CI.BAT: failure for Display Stream Compression enabling on eDP/DP (rev2)

== Series Details == Series: Display Stream Compression enabling on eDP/DP (rev2) URL : https://patchwork.freedesktop.org/series/47514/ State : failure == Summary == Applying: drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT Applying: drm/i915/dp: Cache the DP/eDP DSC

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start

Quoting Matthew Auld (2018-08-06 19:53:47) > On 6 August 2018 at 15:46, Chris Wilson wrote: > > Experience teaches us over and over again that coherency on Baytrail > > requires the odd heavy hammer, and in particular clflush alone is not > > enough to guarrantee that writes from the CPU are picke

Re: [Intel-gfx] [PATCH] drm/i915: Stop dropping irq around resets

Quoting Chris Wilson (2018-08-06 18:21:45) > Quoting Chris Wilson (2018-08-06 15:56:47) > > A long time ago, we were afraid of handling interrupts and signaling > > waiters during a reset, worrying that the confusion in request handling > > would interfere with our attempts to process the reset in

[Intel-gfx] [PATCH v3] drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling

After encoder->pre_enable() hook, after link training sequence is completed, PPS registers for DSC encoder are configured using the DSC state parameters in intel_crtc_state as part of DSC enabling routine in the source. DSC enabling routine is called after encoder->pre_enable() before enbaling the

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Display Stream Compression enabling on eDP/DP (rev3)

== Series Details == Series: Display Stream Compression enabling on eDP/DP (rev3) URL : https://patchwork.freedesktop.org/series/47514/ State : warning == Summary == $ dim checkpatch origin/drm-tip 260bd82c6e63 drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT ad45004f

Re: [Intel-gfx] SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed 01-08-18 10:46:35, Dmitry Vyukov wrote: > I guess it would be useful to have such extensive comment for each > SLAB_TYPESAFE_BY_RCU use explaining why it is needed and how all the > tricky aspects are handled. > > For example, the one in jbd2 is interesting because it memsets the > whole ob

[Intel-gfx] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Restore modparams around test

Save the module parameters from setup and restore them on teardown, so that we leave the system in the same state as we found it. Signed-off-by: Chris Wilson --- tests/kms_frontbuffer_tracking.c | 43 +--- 1 file changed, 39 insertions(+), 4 deletions(-) diff --git a

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Display Stream Compression enabling on eDP/DP (rev3)

== Series Details == Series: Display Stream Compression enabling on eDP/DP (rev3) URL : https://patchwork.freedesktop.org/series/47514/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT Okay! Commit: dr

[Intel-gfx] ✓ Fi.CI.BAT: success for Display Stream Compression enabling on eDP/DP (rev3)

== Series Details == Series: Display Stream Compression enabling on eDP/DP (rev3) URL : https://patchwork.freedesktop.org/series/47514/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4624 -> Patchwork_9864 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming

== Series Details == Series: drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming URL : https://patchwork.freedesktop.org/series/47774/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4622_full -> Patchwork_9862_full = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Restore modparams around test

Em Seg, 2018-08-06 às 21:22 +0100, Chris Wilson escreveu: > Save the module parameters from setup and restore them on teardown, > so > that we leave the system in the same state as we found it. Currently kms_fbt uses igt_set_module_param_int() which uses igt_save_module_param(), which installs an

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Restore modparams around test

Quoting Paulo Zanoni (2018-08-06 21:56:15) > Em Seg, 2018-08-06 às 21:22 +0100, Chris Wilson escreveu: > > Save the module parameters from setup and restore them on teardown, > > so > > that we leave the system in the same state as we found it. > > Currently kms_fbt uses igt_set_module_param_int()

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Restore modparams around test

Em Seg, 2018-08-06 às 22:07 +0100, Chris Wilson escreveu: > Quoting Paulo Zanoni (2018-08-06 21:56:15) > > Em Seg, 2018-08-06 às 21:22 +0100, Chris Wilson escreveu: > > > Save the module parameters from setup and restore them on > > > teardown, > > > so > > > that we leave the system in the same st

Re: [Intel-gfx] [PATCH v2 04/10] drm/i915: Constify power well descriptors

Em Seg, 2018-08-06 às 12:58 +0300, Imre Deak escreveu: > It makes sense to keep unchanging data const. Extract such fields > from > the i915_power_well struct into a new i915_power_well_desc struct > that > we initialize during compile time. For the rest of the dynamic > fields allocate an array of

Re: [Intel-gfx] [PATCH v2 09/10] drm/i915: Use existing power well IDs where possible

Em Seg, 2018-08-06 às 12:58 +0300, Imre Deak escreveu: > There is no need for separate IDs for power wells on a new platform > with > the same functionality as an other power well on a previous platform, > we > can just reuse the ID from the previous platform. This is only > possible > after the pr

Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: Remove redundant power well IDs

Em Seg, 2018-08-06 às 12:58 +0300, Imre Deak escreveu: > Now that we removed dependence on the power well IDs to determine the > control register and request/status flag offsets the only purpose of > power well IDs is to look up power wells directly bypassing the power > domains framework. However

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

Hi Dave, Initial fixes for 4.19. Starting by the one where gvt compilation gets broken after a silent conflict between next and fixes. Here goes drm-intel-next-fixes-2018-08-06: - Fix gvt compilation broken on a silent conflict on fixes vs next merge - Fix runtime PM for LPE audio - Revert on ICL

[Intel-gfx] ✓ Fi.CI.IGT: success for Display Stream Compression enabling on eDP/DP (rev3)

== Series Details == Series: Display Stream Compression enabling on eDP/DP (rev3) URL : https://patchwork.freedesktop.org/series/47514/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4624_full -> Patchwork_9864_full = == Summary - WARNING == Minor unknown changes coming w

Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: Fix potential Spectre v1

On 2018.08.02 22:40:19 -0500, Gustavo A. R. Silva wrote: > info.index can be indirectly controlled by user-space, hence leading > to a potential exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: > > drivers/gpu/drm/i915/gvt/kvmgt.c:1232 inte

Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: fix an error code in gvt_dma_map_page()

On 2018.07.19 11:19:21 +0300, Dan Carpenter wrote: > The dma_mapping_error() returns true on error but we want to return > -ENOMEM here. > > Fixes: 79e542f5af79 ("drm/i915/kvmgt: Support setting dma map for huge pages") > Signed-off-by: Dan Carpenter > Applied, thanks! > diff --git a/drivers/gp

[Intel-gfx] [PATCH] drm/i915/gvt: Off by one in intel_vgpu_write_fence()

The > should be >= here so that we don't read one element beyond the end of the array. Fixes: 28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management") Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c b/drivers/gpu/drm/i915/gvt/aperture_gm.c index 380eeb2a0e83..