[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Simplify platform checks in intel_fb_pitch_limit()

== Series Details == Series: drm/i915: Simplify platform checks in intel_fb_pitch_limit() URL : https://patchwork.freedesktop.org/series/19330/ State : success == Summary == Series 19330v1 drm/i915: Simplify platform checks in intel_fb_pitch_limit()

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Move calling engine->init_hw() to its own function

== Series Details == Series: series starting with [CI,1/3] drm/i915: Move calling engine->init_hw() to its own function URL : https://patchwork.freedesktop.org/series/19313/ State : success == Summary == Series 19313v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code

== Series Details == Series: drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code URL : https://patchwork.freedesktop.org/series/19329/ State : failure == Summary == Series 19329v1 drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Split device release from unload

== Series Details == Series: series starting with [CI,1/3] drm/i915: Split device release from unload URL : https://patchwork.freedesktop.org/series/19312/ State : success == Summary == Series 19312v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: A hotfix for making aliasing PPGTT work

On Wed, Feb 08, 2017 at 09:03:33PM +0800, Zhi Wang wrote: > This patch makes PPGTT page table non-shrinkable when using aliasing PPGTT > mode. It's just a temporary solution for making aliasing PPGTT mode work. > > Cc: Tvrtko Ursulin > Cc: Michal Winiarski

[Intel-gfx] [PATCH] drm/i915: Make power domain masks 64 bit long

There are currently 30 power domains, which puts us pretty close to the limit with 32 bit masks. Prepare for the future and increase the limit to 64 bit. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: A hotfix for making aliasing PPGTT work

== Series Details == Series: drm/i915: A hotfix for making aliasing PPGTT work URL : https://patchwork.freedesktop.org/series/19309/ State : success == Summary == Series 19309v1 drm/i915: A hotfix for making aliasing PPGTT work

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy workaround batch buffer emission

== Series Details == Series: drm/i915: Tidy workaround batch buffer emission URL : https://patchwork.freedesktop.org/series/19310/ State : success == Summary == Series 19310v1 drm/i915: Tidy workaround batch buffer emission

Re: [Intel-gfx] [PATCH] A possible hotfix for aliasing PPGTT in kernel 4.11.x or 4.10.x

On Thu, Feb 09, 2017 at 10:32:39AM +0800, Zhi Wang wrote: > Thanks for the reply! Any inputs and ideas are welcome. :P Get a test into CI to cover your uses... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list

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

Hi Dave, drm-misc-fixes-2017-02-09: Last-minute vc4 fix for 4.10. Cheers, Daniel The following changes since commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c: Linux 4.10-rc7 (2017-02-05 15:10:58 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc

Re: [Intel-gfx] [PATCH i-g-t 8/8] tests: Use BIT macro instead of (1<<x)

On Wed, Feb 08, 2017 at 06:18:28PM -0800, Michel Thierry wrote: > Mostly done with coccinelle, > @@ > expression x; > @@ > ( > - (1< + BIT(x) > | > - (1 << x) > + BIT(x) > | > - 1 << x > + BIT(x) > | > - (1UL< + BIT(x) > | > - (1UL << x) > + BIT(x) > | > - 1UL << x > + BIT(x) > | > -

Re: [Intel-gfx] [PATCH i-g-t 5/8] lib/igt_draw: Use igt_bitops

On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote: > Moving bit operations to the new header file. > > Signed-off-by: Michel Thierry > #define BIT_GET(num, bit)  (((num) >> (bit)) & 1) Maybe name the args (val, nr) for consistency with BIT() Reviewed-by:

Re: [Intel-gfx] [PATCH i-g-t 4/8] lib/intel_device_info: Use igt_bitops

On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote: > BIT macro already defined in the new bitops header. > > Signed-off-by: Michel Thierry Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology

Re: [Intel-gfx] [PATCH i-g-t 3/8] lib: Define a common bit operations library

On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote: > Bring the test/set/clear bit functions we have into a single place. > > Signed-off-by: Michel Thierry Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open

Re: [Intel-gfx] [PATCH i-g-t 2/8] lib/igt_draw: rename BIT macro to BIT_GET

On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote: > Keeping macros names unique. We'll soon have a bit operations header > file and BIT is already taken. > > Signed-off-by: Michel Thierry Reviewed-by: Joonas Lahtinen Regards,

Re: [Intel-gfx] [PATCH i-g-t 1/8] lib/igt: remove duplicate igt_core include

On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote: > igt_core must be really important, but no need to do it twice. > > Signed-off-by: Michel Thierry Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source

[Intel-gfx] [PATCH v3 0/8] Adding driver-private objects to atomic state

Link bandwidth is a shared resource between multiple displays in DP MST configurations. For atomic modesetting drivers, checking if there is sufficient link bandwidth for a mode needs to be done during the atomic_check phase to avoid failed modesets when multiple CRTC's and connectors are

[Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

Having a ->atomic_release callback is useful to release shared resources that get allocated in compute_config(). This function is expected to be called in the atomic_check() phase before new resources are acquired. v2: Moved the caller hunk to this patch (Daniel) Suggested-by: Daniel Vetter

[Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

It is necessary to track states for objects other than connector, crtc and plane for atomic modesets. But adding objects like DP MST link bandwidth to drm_atomic_state would mean that a non-core object will be modified by the core helper functions for swapping and clearing it's state. So, lets add

[Intel-gfx] [PATCH v3 6/8] drm/dp: Add DP MST helpers to atomically find and release vcpi slots

drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to check there are sufficient vcpi slots for a mode and to add that to the state. This should be followed by a call to drm_dp_mst_allocate_vcpi() in ->atomic_commit() to initialize a struct vcpi for the port.

[Intel-gfx] [PATCH v3 5/8] drm/dp: Introduce MST topology state to track available link bandwidth

Link bandwidth is shared between multiple display streams in DP MST configurations. The DP MST topology manager structure maintains the shared link bandwidth for a primary link directly connected to the GPU. For atomic modesetting drivers, checking if there is sufficient link bandwidth for a mode

[Intel-gfx] [PATCH v3 2/8] drm/dp: Kill unused MST vcpi slot availability tracking

The avail_slots member in the MST topology manager is never updated to reflect the available vcpi slots. The check is effectively against total slots, 63. So, let's make that check obvious and remove avail_slots. While at it, make debug messages more descriptive. Signed-off-by: Dhinakaran

[Intel-gfx] [PATCH v3 1/8] drm/dp: Kill total_pbn and total_slots in struct drm_dp_mst_topology_mgr

The total vcpi time slots is always 63 and does not depend on the link BW, remove total_slots from MST topology manager struct. The next change is to remove total_pbn which is hardcoded to 2560. The total PBN that the topology manager allocates from depends on the link rate and is not a constant.

[Intel-gfx] [PATCH v3 3/8] drm/dp: Split drm_dp_mst_allocate_vcpi

drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure, also finds if there are enough slots available. This check is a duplicate of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check if

[Intel-gfx] [PATCH v3 8/8] drm/dp: Track MST link bandwidth

Use the added helpers to track MST link bandwidth for atomic modesets. Link bw is acquired in the ->atomic_check() phase when CRTCs are being enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots(). Similarly, link bw is released during ->atomic_check() with the connector helper

[Intel-gfx] [PATCH v2] drm/i915/debugfs: Add i915_hpd_storm_ctl

This adds a file in i915's debugfs directory that allows userspace to manually control HPD storm detection. This is mainly for hotplugging tests, where we might want to test HPD storm functionality or disable storm detection to speed up hotplugging tests without breaking anything. Changes since

Re: [Intel-gfx] [PATCH] A possible hotfix for aliasing PPGTT in kernel 4.11.x or 4.10.x

Thanks for the reply! Any inputs and ideas are welcome. :P On 02/08/17 21:22, Chris Wilson wrote: On Wed, Feb 08, 2017 at 09:03:32PM +0800, Zhi Wang wrote: Redhat guys have choose kernel stable 4.10 as their target. As you know, currently the aliasing PPGTT mode required by GVT-g doesn't work

[Intel-gfx] [PATCH i-g-t 7/8] test/gem_create: import igt_bitops

It will make sense once we use the BIT macro. Signed-off-by: Michel Thierry --- tests/gem_create.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/gem_create.c b/tests/gem_create.c index de7b8209..4036dbe6 100644 --- a/tests/gem_create.c +++

[Intel-gfx] [PATCH i-g-t 6/8] lib/igt_gt: Define HANG_ALLOW_* as bit flags

As that is what they are meant to be. It will prevent any confusion when we have to add other flags in the future. v2: use BIT (Joonas). Reviewed-by: Joonas Lahtinen Signed-off-by: Michel Thierry --- lib/igt_gt.h | 5 +++-- 1 file

[Intel-gfx] [PATCH i-g-t 4/8] lib/intel_device_info: Use igt_bitops

BIT macro already defined in the new bitops header. Signed-off-by: Michel Thierry --- lib/intel_device_info.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c index db4f3831..b5ad6236 100644 ---

[Intel-gfx] [PATCH i-g-t 2/8] lib/igt_draw: rename BIT macro to BIT_GET

Keeping macros names unique. We'll soon have a bit operations header file and BIT is already taken. Signed-off-by: Michel Thierry --- lib/igt_draw.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/lib/igt_draw.c b/lib/igt_draw.c index

[Intel-gfx] [PATCH i-g-t 0/8] Add a bit operations library

These patches consolidate some of the handy bit macros and functions that we have across igt. Note 1 - tools/intel_audio_dump has its own BIT macro, but since this tool doesn't include igt.h, I didn't think is necessary to rename it. Note 2 - using test_bit implies that the flags to test are

[Intel-gfx] [PATCH i-g-t 5/8] lib/igt_draw: Use igt_bitops

Moving bit operations to the new header file. Signed-off-by: Michel Thierry --- lib/igt_bitops.h | 1 + lib/igt_draw.c | 3 +-- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/igt_bitops.h b/lib/igt_bitops.h index 11e0d8b5..331946f6 100644 ---

[Intel-gfx] [PATCH i-g-t 8/8] tests: Use BIT macro instead of (1<<x)

Mostly done with coccinelle, @@ expression x; @@ ( - (1<

[Intel-gfx] [PATCH i-g-t 1/8] lib/igt: remove duplicate igt_core include

igt_core must be really important, but no need to do it twice. Signed-off-by: Michel Thierry --- lib/igt.h | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/igt.h b/lib/igt.h index a97923ec..4f54698d 100644 --- a/lib/igt.h +++ b/lib/igt.h @@ -29,7 +29,6 @@

[Intel-gfx] [PATCH i-g-t 3/8] lib: Define a common bit operations library

Bring the test/set/clear bit functions we have into a single place. Signed-off-by: Michel Thierry --- lib/igt.h| 1 + lib/igt_bitops.h | 69 lib/igt_primes.c | 25 +--- 3 files changed,

Re: [Intel-gfx] [patch v2] drm/i915/gvt/kvmgt: remove some dead code

On 2017.02.08 14:49:22 +0200, Joonas Lahtinen wrote: > On ti, 2017-02-07 at 17:53 +0300, Dan Carpenter wrote: > > "caps.buf" is always NULL here and "caps.size" is always zero.  The code > > is a no-op and can be removed. > > > > Signed-off-by: Dan Carpenter > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Emit to ringbuffer directly (rev7)

== Series Details == Series: drm/i915: Emit to ringbuffer directly (rev7) URL : https://patchwork.freedesktop.org/series/12186/ State : failure == Summary == LD net/ipv6/built-in.o LD [M] sound/pci/hda/snd-hda-codec-generic.o LD sound/pci/built-in.o LD

Re: [Intel-gfx] [PATCH] drm/i915: i915_gem_shrink_all() needs an awake device

On Wed, Feb 08, 2017 at 03:26:26PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > Since to unbind an object, we may need a powered up device to access the > > GTT entries, we only shrink bound objects if awake. Callers to > > i915_gem_shrink_all() had to take

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt: Define HANG_ALLOW_* as bit flags

On Wed, Feb 08, 2017 at 10:25:19AM -0800, Michel Thierry wrote: > > > On 08/02/17 04:49, Chris Wilson wrote: > >On Wed, Feb 08, 2017 at 02:42:03PM +0200, Joonas Lahtinen wrote: > >>On ti, 2017-02-07 at 18:00 -0800, Michel Thierry wrote: > >>>As that is what they are meant to be. It will prevent

Re: [Intel-gfx] [PATCH] drm/i915: fix for WaDisableDopClockGating:bdw

On Wed, Feb 08, 2017 at 06:10:31PM +, Robert Bragg wrote: > This workaround for BDW was incomplete as it also requires EUTC clock > gating to be disabled via UCGCTL1. IIRC that matches what I told Ben years ago when the w/a was first being added, and matches what I put in the CHV code when it

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt: Define HANG_ALLOW_* as bit flags

On 08/02/17 04:49, Chris Wilson wrote: On Wed, Feb 08, 2017 at 02:42:03PM +0200, Joonas Lahtinen wrote: On ti, 2017-02-07 at 18:00 -0800, Michel Thierry wrote: As that is what they are meant to be. It will prevent any confusion if we have to add other flags in the future. Signed-off-by:

Re: [Intel-gfx] [PATCH v6] drm/i915: Emit to ringbuffer directly

On Wed, Feb 08, 2017 at 06:04:20PM +, Tvrtko Ursulin wrote: > @@ -868,10 +869,11 @@ void __i915_add_request(struct drm_i915_gem_request > *request, bool flush_caches) >* GPU processing the request, we never over-estimate the >* position of the ring's HEAD. >*/ > -

Re: [Intel-gfx] [PATCH] drm/i915: Check for timeout completion when waiting for the rq to submitted

On Wed, Feb 08, 2017 at 06:08:43PM +, Tvrtko Ursulin wrote: > > On 08/02/2017 17:54, Chris Wilson wrote: > >On Wed, Feb 08, 2017 at 05:28:39PM +, Tvrtko Ursulin wrote: > >> > >>On 08/02/2017 16:54, Chris Wilson wrote: > >>>We first wait for a request to be submitted to hw and assigned a

[Intel-gfx] [PATCH v2] drm/i915: Check for timeout completion when waiting for the rq to submitted

We first wait for a request to be submitted to hw and assigned a seqno, before we can wait for the hw to signal completion (otherwise we don't know the hw id we need to wait upon). Whilst waiting for the request to be submitted, we may exceed the user's timeout and need to propagate the error

[Intel-gfx] [PATCH] drm/i915: fix for WaDisableDopClockGating:bdw

This workaround for BDW was incomplete as it also requires EUTC clock gating to be disabled via UCGCTL1. Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

Re: [Intel-gfx] [PATCH] drm/i915: Check for timeout completion when waiting for the rq to submitted

On 08/02/2017 17:54, Chris Wilson wrote: On Wed, Feb 08, 2017 at 05:28:39PM +, Tvrtko Ursulin wrote: On 08/02/2017 16:54, Chris Wilson wrote: We first wait for a request to be submitted to hw and assigned a seqno, before we can wait for the hw to signal completion (otherwise we don't

[Intel-gfx] [PATCH v6] drm/i915: Emit to ringbuffer directly

From: Tvrtko Ursulin This removes the usage of intel_ring_emit in favour of directly writing to the ring buffer. intel_ring_emit was preventing the compiler for optimising fetch and increment of the current ring buffer pointer and therefore generating very verbose code

Re: [Intel-gfx] [PATCH 18/19] drm/i915: Remove defunct GTT tracepoints

On 2 February 2017 at 15:02, Chris Wilson wrote: > The tracepoints are now entirely synonymous with binding and unbinding the > VMA (and the tracepoints there). > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH] drm/i915: Check for timeout completion when waiting for the rq to submitted

On Wed, Feb 08, 2017 at 05:28:39PM +, Tvrtko Ursulin wrote: > > On 08/02/2017 16:54, Chris Wilson wrote: > >We first wait for a request to be submitted to hw and assigned a seqno, > >before we can wait for the hw to signal completion (otherwise we don't > >know the hw id we need to wait

[Intel-gfx] [PATCH] drm/i915: Simplify platform checks in intel_fb_pitch_limit()

From: Ville Syrjälä Replace the VLV/CHV check with a HAS_GMCH_DISPLAY check intel_fb_pitch_limit(), because it's shorter. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 3 +-- 1 file changed, 1

Re: [Intel-gfx] [PATCH 17/19] drm/i915: Always mark the PDP as dirty when altered

On 2 February 2017 at 15:02, Chris Wilson wrote: > We want to reload the PDP (and flush the TLB) when the addresses are > changed. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld

[Intel-gfx] [PATCH] drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code

From: Ville Syrjälä Until recently vlv_steal_power_sequencer() wasn't being called for normal DP ports, and hence it could assert that it should only be called for pipe A and B (since pipe C doesn't support eDP). However that changed when we started to consider

Re: [Intel-gfx] [GLK MIPI DSI V4 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

> -Original Message- > From: Nikula, Jani > Sent: Wednesday, February 8, 2017 8:29 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Shankar, Uma ; Mukherjee, Indranil > ; Kamath, Sunil

Re: [Intel-gfx] [PATCH v5] drm/i915: Emit to ringbuffer directly

Just recording a couple of BUG_ON for posterity, would be nice additions to this patch: diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 11d355d314e1..702c023cd502 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++

Re: [Intel-gfx] [PATCH 16/19] drm/i915: Remove superfluous posting reads after clear GGTT

On 2 February 2017 at 15:02, Chris Wilson wrote: > The barrier here is not required - we apply the barrier before the range > is ever reused by the GPU instead. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH 15/19] drm/i915: Remove bitmap tracking for used-pml4

On 2 February 2017 at 15:02, Chris Wilson wrote: > We only operate on known extents (both for alloc/clear) and so we can use > both the knowledge of the bind/unbind range along with the knowledge of > the existing pagetable to avoid having to allocate temporary and >

Re: [Intel-gfx] [PATCH 14/19] drm/i915: Remove bitmap tracking for used-pdpes

On 2 February 2017 at 15:02, Chris Wilson wrote: > We only operate on known extents (both for alloc/clear) and so we can use > both the knowledge of the bind/unbind range along with the knowledge of > the existing pagetable to avoid having to allocate temporary and >

Re: [Intel-gfx] [PATCH] drm/i915: Check for timeout completion when waiting for the rq to submitted

On 08/02/2017 16:54, Chris Wilson wrote: We first wait for a request to be submitted to hw and assigned a seqno, before we can wait for the hw to signal completion (otherwise we don't know the hw id we need to wait upon). Whilst waiting for the request to be submitted, we may exceed the user's

Re: [Intel-gfx] [GLK MIPI DSI V4 1/8] drm/i915/glk: Program dphy param reg for GLK

> -Original Message- > From: Nikula, Jani > Sent: Wednesday, February 8, 2017 8:24 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Shankar, Uma ; Mukherjee, Indranil > ; Kamath, Sunil

[Intel-gfx] [PATCH] drm/i915: Check for timeout completion when waiting for the rq to submitted

We first wait for a request to be submitted to hw and assigned a seqno, before we can wait for the hw to signal completion (otherwise we don't know the hw id we need to wait upon). Whilst waiting for the request to be submitted, we may exceed the user's timeout and need to propagate the error

Re: [Intel-gfx] [PATCH v3 00/14] drm/i915: Introduce intel_cdclk_state (v3)

On Fri, Jan 20, 2017 at 08:21:51PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Here's the latest version of my cdclk state work. I tried to accomodate > most of the review feedback, although there were some comments which > I think are

Re: [Intel-gfx] [PATCH 13/19] drm/i915: Remove bitmap tracking for used-pdes

On 2 February 2017 at 15:02, Chris Wilson wrote: > We only operate on known extents (both for alloc/clear) and so we can use > both the knowledge of the bind/unbind range along with the knowledge of > the existing pagetable to avoid having to allocate temporary and >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Log significant events at the info level (rev2)

On 07/02/2017 09:23, Patchwork wrote: == Series Details == Series: drm/i915/guc: Log significant events at the info level (rev2) URL : https://patchwork.freedesktop.org/series/19158/ State : success == Summary == Series 19158v2 drm/i915/guc: Log significant events at the info level

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Use for_each_power_domain() in i915_power_domain_info()

On ke, 2017-02-08 at 13:39 +, Chris Wilson wrote: > On Wed, Feb 08, 2017 at 03:12:10PM +0200, Joonas Lahtinen wrote: > > > > Macro seems to do exactly the same thing. > > And a chance there for BIT()! > > > > > > Signed-off-by: Joonas Lahtinen > > Cc:

Re: [Intel-gfx] [GLK MIPI DSI V4 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

On Tue, 07 Feb 2017, Madhav Chauhan wrote: > From: Deepak M > > v2: Addressed Jani's Review comments(renamed bit field macros) > v3: Jani's Review comment for aligning code to platforms and added > wrapper functions. > v4: Corrected enable/disable

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max - 1, 0)

== Series Details == Series: series starting with [v2,1/2] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max - 1, 0) URL : https://patchwork.freedesktop.org/series/19308/ State : failure == Summary == Series 19308v1 Series without cover letter

Re: [Intel-gfx] [GLK MIPI DSI V4 1/8] drm/i915/glk: Program dphy param reg for GLK

On Tue, 07 Feb 2017, Madhav Chauhan wrote: > From: Deepak M > > For GEMINILAKE, dphy param reg values are programmed in terms > of HS byte clock count while for older platforms in terms of > HS ddr clk count. > > v2: Added comments to clarify ddr

[Intel-gfx] [PATCH] drm-misc: quickstart paragraph

I'm typing this too often on irc. Acked-by: Sean Paul Signed-off-by: Daniel Vetter --- drm-misc.rst | 8 1 file changed, 8 insertions(+) diff --git a/drm-misc.rst b/drm-misc.rst index 5c1bef57e3b7..73882dc55be6 100644 --- a/drm-misc.rst

Re: [Intel-gfx] [PATCH] drm/i915: Remove i915_execbuffer_params

On 03/02/2017 12:45, Joonas Lahtinen wrote: On pe, 2017-02-03 at 10:46 +, Chris Wilson wrote: On Fri, Feb 03, 2017 at 10:33:44AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Tidy i915_gem_do_execbuffer by removing the structure which is under no plans

Re: [Intel-gfx] [PATCH] drm/i915: Tidy workaround batch buffer emission

On 08/02/2017 13:20, Chris Wilson wrote: On Wed, Feb 08, 2017 at 01:13:48PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin -static int gen9_init_perctx_bb(struct intel_engine_cs *engine, - struct i915_wa_ctx_bb *wa_ctx, -

[Intel-gfx] [CI 3/3] drm/i915: Disable engine->irq_tasklet around resets

When we restart the engines, and we have active requests, a request on the first engine may complete and queue a request to the second engine before we try to restart the second engine. That queueing of the request may race with the engine to restart, and so may corrupt the current state.

[Intel-gfx] [CI 1/3] drm/i915: Move calling engine->init_hw() to its own function

Just a simple refactor to move a loop and some support code out of i915_gem_init_hw(). This is in preparation for avoiding a race between the tasklet writing to ELSP whilst simultaneously being written by engine->init_hw() following a GPU reset. Signed-off-by: Chris Wilson

[Intel-gfx] [CI 2/3] drm/i915: Split GEM resetting into 3 phases

Currently we do a reset prepare/finish around the call to reset the GPU, but it looks like we need a later stage after the hw has been reinitialised to allow GEM to restart itself. Start by splitting the 2 GEM phases into 3: prepare - before the reset, check if GEM recovered, then stop GEM

Re: [Intel-gfx] [PATCH v2 1/6] drm: Add SCDC helpers

Hi Shashank, On 08-02-2017 12:59, Sharma, Shashank wrote: > Regards > > Shashank > > > On 2/8/2017 4:57 PM, Jose Abreu wrote: >> Hi Shashank, >> >> >> >> On 07-02-2017 16:09, Sharma, Shashank wrote: >>> Thanks for the review Jose, my comments inline. >>> >>> >>> Regards >>> >>> Shashank >>> >>>

[Intel-gfx] [PATCH v5] drm/i915: Emit to ringbuffer directly

From: Tvrtko Ursulin This removes the usage of intel_ring_emit in favour of directly writing to the ring buffer. intel_ring_emit was preventing the compiler for optimising fetch and increment of the current ring buffer pointer and therefore generating very verbose code

[Intel-gfx] [CI 3/3] drm/i915: Flush the freed object queue on device release

As dmabufs may live beyond the PCI device removal, we need to flush the freed object worker on device release, and include a warning in case there is a leak. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [CI 1/3] drm/i915: Split device release from unload

We may need to keep our memory management alive after we have unloaded the physical pci device. For example, if we have exported an object via dmabuf, that will keep the device around but the pci device may be removed before the dmabuf itself is released, use of the pci hardware will be revoked,

[Intel-gfx] [CI 2/3] drm/i915: Unbind any residual objects/vma from the Global GTT on shutdown

We may unload the PCI device before all users (such as dma-buf) are completely shutdown. This may leave VMA in the global GTT which we want to revoke, whilst keeping the objects themselves around to service the dma-buf. Signed-off-by: Chris Wilson Reviewed-by: Joonas

Re: [Intel-gfx] [PATCH] drm/i915: Emit to ringbuffer directly

On Wed, Feb 08, 2017 at 01:36:53PM +, Chris Wilson wrote: > On Wed, Feb 08, 2017 at 01:10:56PM +, Tvrtko Ursulin wrote: > > @@ -2288,32 +2264,33 @@ int intel_ring_begin(struct drm_i915_gem_request > > *req, int num_dwords) > > ring->space -= remain_actual; > > } > > > >

Re: [Intel-gfx] [PATCH 02/46] drm/i915: Split device release from unload

On to, 2017-02-02 at 09:08 +, Chris Wilson wrote: > We may need to keep our memory management alive after we have unloaded > the physical pci device. For example, if we have exported an object via > dmabuf, that will keep the device around but the pci device may be > removed before the dmabuf

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max - 1, 0)

On Wed, Feb 08, 2017 at 03:12:09PM +0200, Joonas Lahtinen wrote: > "BIT(max) - 1" will overflow when max = 32, and GCC will complain. > We already have GENMASK for generating the mask, use it! > > v2: Majestic off by one spotted (Chris) > > Signed-off-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Use for_each_power_domain() in i915_power_domain_info()

On Wed, Feb 08, 2017 at 03:12:10PM +0200, Joonas Lahtinen wrote: > Macro seems to do exactly the same thing. And a chance there for BIT()! > > Signed-off-by: Joonas Lahtinen > Cc: Chris Wilson Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCH 04/46] drm/i915: Flush the freed object queue on device release

On to, 2017-02-02 at 09:08 +, Chris Wilson wrote: > As dmabufs may live beyond the PCI device removal, we need to flush the > freed object worker on device release, and include a warning in case > there is a leak. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas

Re: [Intel-gfx] [PATCH] drm/i915: Emit to ringbuffer directly

On Wed, Feb 08, 2017 at 01:10:56PM +, Tvrtko Ursulin wrote: > @@ -2288,32 +2264,33 @@ int intel_ring_begin(struct drm_i915_gem_request > *req, int num_dwords) > ring->space -= remain_actual; > } > > + out = (u32 *)(ring->vaddr + ring->tail); Checkpatch will complain

Re: [Intel-gfx] [PATCH 03/46] drm/i915: Unbind any residual objects/vma from the Global GTT on shutdown

On to, 2017-02-02 at 09:08 +, Chris Wilson wrote: > We may unload the PCI device before all users (such as dma-buf) are > completely shutdown. This may leave VMA in the global GTT which we want > to revoke, whilst keeping the objects themselves around to service the > dma-buf. > >

Re: [Intel-gfx] drm/edid: Don't print an error if the checksum of a CEA block is wrong

On Wed, Feb 08, 2017 at 01:19:23PM +, Tahvanainen, Jari wrote: > I applied this change on the couple-days old drm-tip, and was not able to get > any "EDID checksum is invalid" messages with it on my SKL. Without this patch > I could generate the ERROR quite easily by switching the outputs

Re: [Intel-gfx] [PATCH] drm/i915: i915_gem_shrink_all() needs an awake device

Chris Wilson writes: > Since to unbind an object, we may need a powered up device to access the > GTT entries, we only shrink bound objects if awake. Callers to > i915_gem_shrink_all() had to take this into account and take the rpm > wakeref, but we can move this

Re: [Intel-gfx] [PATCH] A possible hotfix for aliasing PPGTT in kernel 4.11.x or 4.10.x

On Wed, Feb 08, 2017 at 09:03:32PM +0800, Zhi Wang wrote: > Redhat guys have choose kernel stable 4.10 as their target. As you know, > currently the aliasing PPGTT mode required by GVT-g doesn't work now. > > Thanks Chris who has already pushed the fixes, but it seems that the > kernel 4.11

Re: [Intel-gfx] [PATCH] drm/i915: Tidy workaround batch buffer emission

On Wed, Feb 08, 2017 at 01:13:48PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > -static int gen9_init_perctx_bb(struct intel_engine_cs *engine, > -struct i915_wa_ctx_bb *wa_ctx, > -uint32_t *batch, > -

Re: [Intel-gfx] drm/edid: Don't print an error if the checksum of a CEA block is wrong

I applied this change on the couple-days old drm-tip, and was not able to get any "EDID checksum is invalid" messages with it on my SKL. Without this patch I could generate the ERROR quite easily by switching the outputs and displays manually. I don't know if this hides something that it should

[Intel-gfx] [PATCH] drm/i915: Tidy workaround batch buffer emission

From: Tvrtko Ursulin Use the "*batch++ = " style as in the ring emission for better readability and also simplify the logic a bit by consolidating the offset and size calculations and overflow checking. The latter is a programming error so it is not required to check

[Intel-gfx] [PATCH] drm/i915: A hotfix for making aliasing PPGTT work

This patch makes PPGTT page table non-shrinkable when using aliasing PPGTT mode. It's just a temporary solution for making aliasing PPGTT mode work. Cc: Tvrtko Ursulin Cc: Michal Winiarski Cc: Michel Thierry

[Intel-gfx] [PATCH] A possible hotfix for aliasing PPGTT in kernel 4.11.x or 4.10.x

Redhat guys have choose kernel stable 4.10 as their target. As you know, currently the aliasing PPGTT mode required by GVT-g doesn't work now. Thanks Chris who has already pushed the fixes, but it seems that the kernel 4.11 merging window has already open and those fixes might be merged in 4.12.x

[Intel-gfx] [PATCH v2 2/2] drm/i915: Use for_each_power_domain() in i915_power_domain_info()

Macro seems to do exactly the same thing. Signed-off-by: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git

[Intel-gfx] [PATCH v2 1/2] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max - 1, 0)

"BIT(max) - 1" will overflow when max = 32, and GCC will complain. We already have GENMASK for generating the mask, use it! v2: Majestic off by one spotted (Chris) Signed-off-by: Joonas Lahtinen Cc: Chris Wilson ---

[Intel-gfx] [PATCH] drm/i915: Emit to ringbuffer directly

From: Tvrtko Ursulin This removes the usage of intel_ring_emit in favour of directly writing to the ring buffer. intel_ring_emit was preventing the compiler for optimising fetch and increment of the current ring buffer pointer and therefore generating very verbose code

Re: [Intel-gfx] [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB

Regards Shashank On 2/8/2017 5:06 PM, Jose Abreu wrote: Hi, On 07-02-2017 16:36, Thierry Reding wrote: On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote: Regards Shashank On 2/7/2017 4:31 PM, Jose Abreu wrote: Hi Shashank, On 06-02-2017 13:59, Shashank Sharma wrote:

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

Regards Shashank On 2/8/2017 5:01 PM, Jose Abreu wrote: Hi Shashank, On 07-02-2017 16:19, Sharma, Shashank wrote: Regards Shashank On 2/7/2017 4:44 PM, Jose Abreu wrote: Hi Shashank, On 06-02-2017 13:59, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel

Re: [Intel-gfx] [PATCH v2 1/6] drm: Add SCDC helpers

Regards Shashank On 2/8/2017 4:57 PM, Jose Abreu wrote: Hi Shashank, On 07-02-2017 16:09, Sharma, Shashank wrote: Thanks for the review Jose, my comments inline. Regards Shashank On 2/7/2017 4:24 PM, Jose Abreu wrote: Hi Shashank, Sorry for the late review. On 06-02-2017 13:59,

  1   2   >