[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring URL : https://patchwork.freedesktop.org/series/42491/ State : warning == Summary == $ dim checkpatch origin/drm-tip 16fbdb640928 drm/i915: Move timeline from GTT to ring 8e3b3a1f4eb2 drm/i915: S

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring URL : https://patchwork.freedesktop.org/series/42491/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Move timeline from GTT to ring -drivers/gpu/drm/i915/selftests/.

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring URL : https://patchwork.freedesktop.org/series/42491/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8852 = == Summary - FAILURE == Serious unknown change

[Intel-gfx] [PATCH] drm/i915/guc: Assert we have the doorbell before setting it up

As our early doorbell is split between early allocation and a late setup after we have a channel to the GuC, it may happen due to a lapse of programmer judgement that we try to setup an invalid doorbell. Make use of our has_doorbell() function to check the doorbell does exist for the client before

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring URL : https://patchwork.freedesktop.org/series/42491/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1766d5ad3da0 drm/i915: Move timeline from GTT to ring 7a84075a9cec drm/i915: S

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring URL : https://patchwork.freedesktop.org/series/42491/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Move timeline from GTT to ring -drivers/gpu/drm/i915/selftests/.

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring URL : https://patchwork.freedesktop.org/series/42491/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8853 = == Summary - FAILURE == Serious unknown change

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Assert we have the doorbell before setting it up

== Series Details == Series: drm/i915/guc: Assert we have the doorbell before setting it up URL : https://patchwork.freedesktop.org/series/42509/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8854 = == Summary - SUCCESS == No regressions found. Exter

[Intel-gfx] [PATCH i-g-t] igt/drv_missed_irq: Sleep in the child waiting for the parent

Our parent is RT, we are not. In theory, we should wait until our parent has gone to sleep before we are allowed to proceed (we should both be bound to the same cpu). Double down on this by sleeping in the child until our parent has written a byte along a pipe(). Signed-off-by: Chris Wilson Cc: T

Re: [Intel-gfx] [PATCH] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled

HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Du,Wenkai > Sent: maanantai 30. huhtikuuta 2018 21.23 > To: Kumar, Abhay ; intel-gfx@lists.freedesktop.org > Cc: Nikula, Jani > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Force 2*96

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Assert we have the doorbell before setting it up

== Series Details == Series: drm/i915/guc: Assert we have the doorbell before setting it up URL : https://patchwork.freedesktop.org/series/42509/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116_full -> Patchwork_8854_full = == Summary - WARNING == Minor unknown change

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

Quoting Patchwork (2018-05-01 09:11:28) > == Series Details == > > Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring > URL : https://patchwork.freedesktop.org/series/42491/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4116 -> Patchwork

[Intel-gfx] [PATCH] drm/i915/execlists: Disable submission tasklets when rescheduling

As we reschedule the requests, we do not want the submission tasklet running until we finish updating the priority chains. (We start rewriting priorities from the oldest, but the dequeue looks at the most recent in-flight, so there is a small race condition where dequeue may decide that preemption

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Disable submission tasklets when rescheduling

Quoting Chris Wilson (2018-05-01 10:49:17) > As we reschedule the requests, we do not want the submission tasklet > running until we finish updating the priority chains. (We start > rewriting priorities from the oldest, but the dequeue looks at the most > recent in-flight, so there is a small race

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Disable submission tasklets when rescheduling

== Series Details == Series: drm/i915/execlists: Disable submission tasklets when rescheduling URL : https://patchwork.freedesktop.org/series/42513/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8855 = == Summary - WARNING == Minor unknown changes comin

[Intel-gfx] [PATCH] drm/i915/execlists: Don't trigger preemption if complete

Due to the latency of the tasklet running from ksoftirqd, by the time we process the execlist dequeue may be a long time behind the GPU. If the request was completed when we ran reschedule, we will not have tweaked its priority, but if it is still listed as being in-flight for dequeue we will use i

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Don't trigger preemption if complete

== Series Details == Series: drm/i915/execlists: Don't trigger preemption if complete URL : https://patchwork.freedesktop.org/series/42515/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8856 = == Summary - SUCCESS == No regressions found. External UR

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_missed_irq: Sleep in the child waiting for the parent

On 01/05/2018 10:07, Chris Wilson wrote: Our parent is RT, we are not. In theory, we should wait until our parent has gone to sleep before we are allowed to proceed (we should both be bound to the same cpu). Double down on this by sleeping in the child until our parent has written a byte along a

Re: [Intel-gfx] [PATCH 1/8] drm/i915: expose helper mapping exec flag engine to intel_engine_cs

Quoting Lionel Landwerlin (2018-04-30 15:37:42) > On 25/04/18 12:50, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2018-04-25 12:45:14) > >> This function will be used later by the per (context,engine) power > >> programming interface. > > No. This is not the appropriate uABI, please see > > i

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_missed_irq: Sleep in the child waiting for the parent

Quoting Tvrtko Ursulin (2018-05-01 12:10:22) > > On 01/05/2018 10:07, Chris Wilson wrote: > > Our parent is RT, we are not. In theory, we should wait until our parent > > has gone to sleep before we are allowed to proceed (we should both be > > bound to the same cpu). Double down on this by sleepi

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Disable submission tasklets when rescheduling

== Series Details == Series: drm/i915/execlists: Disable submission tasklets when rescheduling URL : https://patchwork.freedesktop.org/series/42513/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4116_full -> Patchwork_8855_full = == Summary - FAILURE == Serious unknown c

[Intel-gfx] [PATCH v2] drm/i915/execlists: Don't trigger preemption if complete

Due to the latency of the tasklet running from ksoftirqd, by the time we process the execlist dequeue may be a long time behind the GPU. If the request was completed when we ran reschedule, we will not have tweaked its priority, but if it is still listed as being in-flight for dequeue we will use i

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_missed_irq: Sleep in the child waiting for the parent

On 01/05/2018 12:21, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-01 12:10:22) On 01/05/2018 10:07, Chris Wilson wrote: Our parent is RT, we are not. In theory, we should wait until our parent has gone to sleep before we are allowed to proceed (we should both be bound to the same cpu).

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Don't trigger preemption if complete

== Series Details == Series: drm/i915/execlists: Don't trigger preemption if complete URL : https://patchwork.freedesktop.org/series/42515/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4116_full -> Patchwork_8856_full = == Summary - FAILURE == Serious unknown changes co

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Don't trigger preemption if complete (rev2)

== Series Details == Series: drm/i915/execlists: Don't trigger preemption if complete (rev2) URL : https://patchwork.freedesktop.org/series/42515/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8857 = == Summary - SUCCESS == No regressions found. Exte

[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption

Move the tracepoint into the common execlists_context_schedule_out() and call it from preemption completion as well. A small bit of refactoring code should help with when tracing, or else we end up with requests mysteriously disappearing and some being emitted to HW multiple times. Reported-by: Tv

[Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in request tracepoints

Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_trace.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Don't trigger preemption if complete (rev2)

== Series Details == Series: drm/i915/execlists: Don't trigger preemption if complete (rev2) URL : https://patchwork.freedesktop.org/series/42515/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116_full -> Patchwork_8857_full = == Summary - WARNING == Minor unknown chang

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption URL : https://patchwork.freedesktop.org/series/42518/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8858 = == Summary - SUCCESS == No

Re: [Intel-gfx] [PATCH] drm/i915/guc: Assert we have the doorbell before setting it up

On 5/1/2018 12:52 AM, Chris Wilson wrote: As our early doorbell is split between early allocation and a late setup after we have a channel to the GuC, it may happen due to a lapse of programmer judgement that we try to setup an invalid doorbell. Make use of our has_doorbell() function to check th

Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption

On 01/05/2018 14:41, Chris Wilson wrote: Move the tracepoint into the common execlists_context_schedule_out() and call it from preemption completion as well. A small bit of refactoring code should help with when tracing, or else we end up with requests mysteriously disappearing and some being em

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in request tracepoints

On 01/05/2018 14:41, Chris Wilson wrote: Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_trace.h | 6 -- 1 file changed, 4 insert

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in request tracepoints

Quoting Tvrtko Ursulin (2018-05-01 15:41:51) > > On 01/05/2018 14:41, Chris Wilson wrote: > > Include a bool to show whether the request is complete in every > > tracepoint. This especially helps when tracing the flow of requests > > through the HW. > > > > Signed-off-by: Chris Wilson > > --- >

[Intel-gfx] [PATCH v2] drm/i915: Include completed status in HW request tracepoints

Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. v2: Limit to in/out HW events, not all general request tracepoints. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_trace.h | 1

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption URL : https://patchwork.freedesktop.org/series/42518/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116_full -> Patchwork_8858_full = == Summary - WARNIN

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption (rev2) URL : https://patchwork.freedesktop.org/series/42518/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/versio

[Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in HW request tracepoints

Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. v2: Limit to in/out HW events, not all general request tracepoints. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_trace.h | 1

[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption

Move the tracepoint into the common execlists_context_schedule_out() and call it from preemption completion as well. A small bit of refactoring code should help with when tracing, or else we end up with requests mysteriously disappearing and some being emitted to HW multiple times. Reported-by: Tv

Re: [Intel-gfx] [PATCH v2] drm/i915: Include completed status in HW request tracepoints

On 01/05/2018 15:58, Chris Wilson wrote: Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. v2: Limit to in/out HW events, not all general request tracepoints. Signed-off-by: Chris Wilson --- dr

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in HW request tracepoints

On 01/05/2018 16:13, Chris Wilson wrote: Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. v2: Limit to in/out HW events, not all general request tracepoints. Signed-off-by: Chris Wilson --- dr

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption URL : https://patchwork.freedesktop.org/series/42522/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h C

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Don't trigger preemption if complete

On 01/05/2018 11:46, Chris Wilson wrote: Due to the latency of the tasklet running from ksoftirqd, by the time we process the execlist dequeue may be a long time behind the GPU. If the request was completed when we ran reschedule, we will not have tweaked its priority, but if it is still listed

[Intel-gfx] [PATCH v3] drm/i915: Include completed status in HW request tracepoints

Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. v2: Limit to in/out HW events, not all general request tracepoints. v3: ifdeffery Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- driv

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in HW request tracepoints

On 01/05/2018 16:26, Tvrtko Ursulin wrote: On 01/05/2018 16:13, Chris Wilson wrote: Include a bool to show whether the request is complete in every tracepoint. This especially helps when tracing the flow of requests through the HW. v2: Limit to in/out HW events, not all general request tracep

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in HW request tracepoints

Quoting Tvrtko Ursulin (2018-05-01 16:41:15) > > On 01/05/2018 16:26, Tvrtko Ursulin wrote: > > > > On 01/05/2018 16:13, Chris Wilson wrote: > >> Include a bool to show whether the request is complete in every > >> tracepoint. This especially helps when tracing the flow of requests > >> through t

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption (rev2) URL : https://patchwork.freedesktop.org/series/42522/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8861 = == Summary - SUCCESS =

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Include completed status in HW request tracepoints

Hi Chris, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20180501] [cannot apply to v4.17-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Emit i915_trace_request_out for preemption (rev2) URL : https://patchwork.freedesktop.org/series/42522/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116_full -> Patchwork_8861_full = == Summary -

Re: [Intel-gfx] [PATCH] drm/i915/firmware: Correct URL for firmware

>-Original Message- >From: Vivi, Rodrigo >Sent: Monday, April 30, 2018 5:36 PM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org >Subject: Re: [PATCH] drm/i915/firmware: Correct URL for firmware > >On Mon, Apr 30, 2018 at 03:59:28PM -0700, Anusha Srivatsa wrote: >> Replace 01.or

Re: [Intel-gfx] [PATCH 2/5] drm/i915/icl/guc: Pass the bare minimum GuC init parameters for Icelake

On 04/30/2018 04:29 PM, John Spotswood wrote: On Fri, 2018-04-27 at 14:31 -0700, Oscar Mateo wrote: Only enough to achieve HuC authentication. No GuC submission or any other feature for the time being. Signed-off-by: Oscar Mateo Cc: Joonas Lahtinen Cc: Michal Wajdeczko Cc: John Spotswood

Re: [Intel-gfx] [PATCH 3/5] drm/i915/icl/guc: Define the GuC firmware version for Icelake

On 04/30/2018 04:34 PM, John Spotswood wrote: On Fri, 2018-04-27 at 14:31 -0700, Oscar Mateo wrote: A GuC firmware for Icelake is now available. Let's use it. v2: Split out the Cannonlake stuff in a separate patch (Michal) v3: Rebased v4:   - Rebased   - Split out MODULE_FIRMWARE so we do

[Intel-gfx] [PATCH v3] drm/i915: Disable some extra clang warnings

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set warnings to full") enabled extra warnings for i915 to spot possible bugs in new code, and then disabled a subset of these warnings to keep the current code building without warnings (with gcc). Enabling the extra warnings also enab

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Disable some extra clang warnings (rev3)

== Series Details == Series: drm/i915: Disable some extra clang warnings (rev3) URL : https://patchwork.freedesktop.org/series/40145/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Disable some extra clang warnings - +drivers/gpu/drm/i915/gvt/gtt.c:671:9:expect

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable some extra clang warnings (rev3)

== Series Details == Series: drm/i915: Disable some extra clang warnings (rev3) URL : https://patchwork.freedesktop.org/series/40145/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4116 -> Patchwork_8862 = == Summary - SUCCESS == No regressions found. External URL: ht

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Disable some extra clang warnings (rev3)

== Series Details == Series: drm/i915: Disable some extra clang warnings (rev3) URL : https://patchwork.freedesktop.org/series/40145/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4116_full -> Patchwork_8862_full = == Summary - FAILURE == Serious unknown changes coming w

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Don't trigger preemption if complete

Quoting Tvrtko Ursulin (2018-05-01 16:33:15) > > On 01/05/2018 11:46, Chris Wilson wrote: > > Due to the latency of the tasklet running from ksoftirqd, by the time we > > process the execlist dequeue may be a long time behind the GPU. If the > > request was completed when we ran reschedule, we wil

[Intel-gfx] [PATCH] drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update

Just a minor knit. Stumbled across the kernel doc for schedule_timeout() which quotes "In all cases the return value is guaranteed to be non-negative". Also, the return code of schedule_timeout() already checks for negative values "return timeout < 0 ? 0 : timeout;" and returns 0 in such cases. So,

Re: [Intel-gfx] [PATCH libdrm] intel: add support for ICL 11

Em Qua, 2018-04-25 às 17:29 -0700, Michel Thierry escreveu: > On 04/25/2018 05:09 PM, Paulo Zanoni wrote: > > Add the PCI IDs and the basic code to enable ICL. This is the > > current > > PCI ID list in our documentation. > > > > Kernel commit: d55cb4fa2cf0 ("drm/i915/icl: Add the ICL PCI IDs") >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update

== Series Details == Series: drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update URL : https://patchwork.freedesktop.org/series/42527/ State : warning == Summary == $ dim checkpatch origin/drm-tip f9be46078758 drm/i915: Remove redundant check for negative t

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update

== Series Details == Series: drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update URL : https://patchwork.freedesktop.org/series/42527/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4117 -> Patchwork_8863 = == Summary - SUCCESS == No r

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update

On Tue, May 01, 2018 at 01:39:15PM -0700, Tarun Vyas wrote: > Just a minor knit. Stumbled across the kernel doc for schedule_timeout() which > quotes "In all cases the return value is guaranteed to be non-negative". Also, > the return code of schedule_timeout() already checks for negative values >

Re: [Intel-gfx] [PATCH] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled

On 5/1/2018 2:15 AM, Saarinen, Jani wrote: HI, -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Du,Wenkai Sent: maanantai 30. huhtikuuta 2018 21.23 To: Kumar, Abhay ; intel-gfx@lists.freedesktop.org Cc: Nikula, Jani Subject: Re: [Intel-g

Re: [Intel-gfx] [PATCH] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled

+ Ville On 5/1/2018 4:42 PM, Kumar, Abhay wrote: On 5/1/2018 2:15 AM, Saarinen, Jani wrote: HI, -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Du,Wenkai Sent: maanantai 30. huhtikuuta 2018 21.23 To: Kumar, Abhay;intel-gfx@lists.fre

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update

== Series Details == Series: drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update URL : https://patchwork.freedesktop.org/series/42527/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4117_full -> Patchwork_8863_full = == Summary - WARNING

Re: [Intel-gfx] [PATCH] drm/i915: Unconditionally disable/enable dpll0 and apply WA1183 when changing cdclk.

Please fully ignore this patch. On Mon, Apr 30, 2018 at 05:57:22PM -0700, Rodrigo Vivi wrote: > I believe I finally got the platform/panel that WA1183 > was targeting. > > WA 1183 aims to fix the cdclk change for > "CD clock frequency 308.57 or 617.14 MHz" > > I faced one case here where the de

[Intel-gfx] [PATCH] drm/i915: Stash desired logical vco in a reliable place.

On intel_dp_compute_config() we calculate the needed vco for eDP on gen9 and we stash it in intel_atomic_state.cdclk.logical.vco However few moments later on intel_modeset_checks() we fully replace entire intel_atomic_state.cdclk.logical with dev_priv->cdclk.logical fully overwriting the logical d

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Stash desired logical vco in a reliable place.

== Series Details == Series: drm/i915: Stash desired logical vco in a reliable place. URL : https://patchwork.freedesktop.org/series/42537/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4117 -> Patchwork_8864 = == Summary - FAILURE == Serious unknown changes coming with

Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support

> -Original Message- > From: Kristian Høgsberg [mailto:hoegsb...@gmail.com] > Sent: Monday, April 30, 2018 11:58 PM > To: Srinivas, Vidya > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v5 0/6] Enable NV12 support > > On Thu, Apr 19, 2018 at 3:34 AM Vidya Sriniva

Re: [Intel-gfx] Warning for driver i915 for 4.17.0-rcX

On Mon, 30 Apr 2018, Larry Finger wrote: > With kernel 4.17.0-rc3, I noted the following warning from driver i915. > > kernel: [ cut here ] > kernel: Could not determine valid watermarks for inherited state > kernel: WARNING: CPU: 3 PID: 224 at > drivers/gpu/drm/i915/intel

[Intel-gfx] [PATCH v13 03/10] drm/edid: Fix cea mode aspect ratio handling

From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's handle this by considering the aspect

[Intel-gfx] [PATCH v13 00/10] Aspect ratio support in DRM layer

From: Ankit Nautiyal This patch series is a re-attempt to enable aspect ratio support in DRM layer. Currently the aspect ratio information gets lost in translation during a user->kernel mode or vice versa. The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had 4 patches, out

[Intel-gfx] [PATCH v13 04/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the infoframe as it's only capable of s

[Intel-gfx] [PATCH v13 01/10] drm/modes: Introduce drm_mode_match()

From: Ville Syrjälä Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma --- drivers/gpu/drm/drm_modes.c | 134 ++-- include/d

[Intel-gfx] [PATCH v13 02/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

From: Ville Syrjälä Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes from detailed timings and we matc

[Intel-gfx] [PATCH v13 05/10] video/hdmi: Reject illegal picture aspect ratios

From: Ville Syrjälä AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma Cc: Jim Bride Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Cc: Thierry Reding

[Intel-gfx] [PATCH v13 07/10] drm: Handle aspect ratio info in legacy modeset path

From: Ankit Nautiyal If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not be given, if aspect-ratio is n

[Intel-gfx] [PATCH v13 06/10] drm: Add DRM client cap for aspect-ratio

From: Ankit Nautiyal To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing non-atomic user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a new drm client cap is required

[Intel-gfx] [PATCH v13 08/10] drm: Expose modes with aspect ratio, only if requested

From: Ankit Nautiyal We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regardless of whether user space requested this information or not. This patch: -prunes the modes with aspect-ratio information, from a connector's mo