Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both in skl_pcode_try_request()

On Wed, Feb 22, 2017 at 10:25:44AM +0800, Weinan Li wrote: > skl_pcode_try_request() call sandybridge_pcode_read(), check both return > status and value simultanously, ensure it got correct value without error. > > Signed-off-by: Weinan Li > --- >

Re: [Intel-gfx] [RFC] drm/i915: Temporarily go realtime when polling PCODE

On 21/02/2017 18:48, Imre Deak wrote: On Tue, Feb 21, 2017 at 05:01:58PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Elevate task scheduling policy to realtime when polling on PCODE to guarantee a good poll rate before falling back to busy wait. We only do

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix Geminilake DDI power well enable timeouts (rev3)

== Series Details == Series: Fix Geminilake DDI power well enable timeouts (rev3) URL : https://patchwork.freedesktop.org/series/19451/ State : success == Summary == Series 19451v3 Fix Geminilake DDI power well enable timeouts

[Intel-gfx] [PATCH v3 0/6] Fix Geminilake DDI power well enable timeouts

Hi, Here's an updated version of the series, with an extra patch to prevent us from converting a analog encoder to a struct intel_digital_port. With this we can aboid the wrong conversion in intel_ddi_post_disable() which leads to a put to a reference to the wrong power domain. Thanks, Ander

[Intel-gfx] [PATCH v3 2/6] drm/i915: Store encoder power domain in struct intel_encoder

The encoder power domain is obviously tied to the encoder, so store it in struct intel_encoder. This avoids some indirection. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Imre Deak ---

[Intel-gfx] [PATCH v3 6/6] drm/i915: Only enable DDI IO power domains after enabling DPLL

According to bspec, the DDI IO power domains should be enabled after enabling the DPLL and mapping it to the DDI. The current order doesn't seem to create problems with Skylake and Kabylake, but causes enable timeouts in Geminilake. v2: Rebase. - Take power domain references before sanitizing

[Intel-gfx] [PATCH v3 5/6] drm/i915/glk: Don't enable DDI IO power domains during init

In Geminilake, the DDI IO power domains can't be enabled before a DPLL is running and mapped to the appropriate DDI. At least on Geminilake, attempting to enable those during init will lead to a timeout. The failure to enable the power domain also causes issues with the state verifier during

[Intel-gfx] [PATCH v3 4/6] drm/i915/glk: Implement WaDDIIOTimeout

Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO power domains. Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Imre Deak --- drivers/gpu/drm/i915/i915_drv.h | 6 ++ drivers/gpu/drm/i915/i915_reg.h |

[Intel-gfx] [PATCH v3 1/6] drm/i915: Store aux power domain in intel_dp

The aux power domain only makes sense in the DP code. Storing it in struct intel_dp avoids some indirection. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Imre Deak --- drivers/gpu/drm/i915/intel_display.c | 50

[Intel-gfx] [PATCH v3 3/6] drm/i915: Check encoder type in enc_to_dig_port()

Don't allow conversion from arbitraty encoder types to a digital port. Calling enc_to_dig_port() with the wrong encoder may seem far fetched, but certain paths of the ddi code may be called with hasell's analog encoder and the conversion is wrong for DP mst encoders too, so safe guard against it.

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

On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote: On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: Hi, On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote: It is necessary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: check status and reply value both in skl_pcode_try_request()

== Series Details == Series: drm/i915: check status and reply value both in skl_pcode_try_request() URL : https://patchwork.freedesktop.org/series/20032/ State : success == Summary == Series 20032v1 drm/i915: check status and reply value both in skl_pcode_try_request()

[Intel-gfx] [PATCH] drm/i915: check status and reply value both in skl_pcode_try_request()

skl_pcode_try_request() call sandybridge_pcode_read(), check both return status and value simultanously, ensure it got correct value without error. Signed-off-by: Weinan Li --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [Intel-gfx] [PATCH v2] drm: Add DPCD definitions for DP 1.4 DSC feature

On Fri, 17 Feb 2017, Manasi Navare wrote: > Display stream compression is supported on DP 1.4 DP devices. This > patch adds the corersponding DPCD register definitions for DSC. > > v2: > * Rebased on drm-tip > > Signed-off-by: Manasi Navare

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

On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: > > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: > >> Hi, > >> > >> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote: > >>> It is necessary to track states for objects other

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: move the {skl, bxt}_{i, uni}nit_cdclk declarations

== Series Details == Series: drm/i915: move the {skl, bxt}_{i, uni}nit_cdclk declarations URL : https://patchwork.freedesktop.org/series/20023/ State : success == Summary == Series 20023v1 drm/i915: move the {skl, bxt}_{i, uni}nit_cdclk declarations

[Intel-gfx] [PATCH] drm/i915: move the {skl, bxt}_{i, uni}nit_cdclk declarations

Move the {skl,bxt}_{i,uni}nit_cdclk declarations to the place where the intel_cdclk.c functions are declared since these functions have moved there. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_drv.h | 8 1 file changed, 4 insertions(+), 4

Re: [Intel-gfx] [PATCH 3/3] drm/i915: reorganize the get_cdclk assignment

Em Ter, 2017-02-21 às 14:26 +0200, Ander Conselvan De Oliveira escreveu: > On Mon, 2017-02-20 at 17:00 -0300, Paulo Zanoni wrote: > > > > Possible problems of the current if-ladder: > >   - It's a huge if ladder with almost a different check for each of > > our platforms. > >   - It mixes 3

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop using RP_DOWN_EI on Baytrail

== Series Details == Series: drm/i915: Stop using RP_DOWN_EI on Baytrail URL : https://patchwork.freedesktop.org/series/20019/ State : success == Summary == Series 20019v1 drm/i915: Stop using RP_DOWN_EI on Baytrail https://patchwork.freedesktop.org/api/1.0/series/20019/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 3/3] drm/i915: reorganize the get_cdclk assignment

Em Ter, 2017-02-21 às 13:51 +0200, Ville Syrjälä escreveu: > On Mon, Feb 20, 2017 at 05:00:42PM -0300, Paulo Zanoni wrote: > > > > Possible problems of the current if-ladder: > >   - It's a huge if ladder with almost a different check for each of > > our platforms. > >   - It mixes 3

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Temporarily go realtime when polling PCODE

== Series Details == Series: drm/i915: Temporarily go realtime when polling PCODE URL : https://patchwork.freedesktop.org/series/20017/ State : success == Summary == Series 20017v1 drm/i915: Temporarily go realtime when polling PCODE

Re: [Intel-gfx] [RFC] drm/i915: Temporarily go realtime when polling PCODE

On Tue, Feb 21, 2017 at 05:01:58PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Elevate task scheduling policy to realtime when polling on PCODE > to guarantee a good poll rate before falling back to busy wait. > > We only do this for tasks with normal

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add VBT firmware loading mechanism

== Series Details == Series: drm/i915: add VBT firmware loading mechanism URL : https://patchwork.freedesktop.org/series/20016/ State : success == Summary == Series 20016v1 drm/i915: add VBT firmware loading mechanism https://patchwork.freedesktop.org/api/1.0/series/20016/revisions/1/mbox/

[Intel-gfx] [PATCH] drm/i915: Stop using RP_DOWN_EI on Baytrail

On Baytrail, we manually calculate busyness over the evaluation interval to avoid issues with miscaluations with RC6 enabled. However, it turns out that the DOWN_EI interrupt generator is completely bust - it operates in two modes, continuous or never. Neither of which are conducive to good

Re: [Intel-gfx] [PATCH] drm: Use a common test for no holes before find_hole

On Tue, Feb 21, 2017 at 06:13:57PM +, Chris Wilson wrote: > Signed-off-by: Chris Wilson Not the patch I intended to send... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list

[Intel-gfx] [PATCH] drm: Use a common test for no holes before find_hole

Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 89df9e51f21d..73b9137797e4 100644 --- a/drivers/gpu/drm/drm_mm.c

[Intel-gfx] [RFC] drm/i915: Temporarily go realtime when polling PCODE

From: Tvrtko Ursulin Elevate task scheduling policy to realtime when polling on PCODE to guarantee a good poll rate before falling back to busy wait. We only do this for tasks with normal policy and priority in order to simplify policy restore and also assuming that

Re: [Intel-gfx] [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote: > On Tue, 21 Feb 2017, Andy Shevchenko m> wrote: > > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element > > support") enables GPIO support for Broxton based platforms. > > > > While using that

Re: [Intel-gfx] [PATCH 5/5] drm/i915/opregion: let user specify override VBT via firmware load

On Tue, Feb 21, 2017 at 06:40:25PM +0200, Jani Nikula wrote: > Sometimes it would be most enlightening to debug systems by replacing > the VBT to be used. For example, in the referenced bug the BIOS provides > different VBT depending on the boot mode (UEFI vs. legacy). It would be > interesting to

[Intel-gfx] [PATCH 1/5] drm/i915: Add i915_param charp macro magic

From: Chris Wilson Handling the dynamic charp module parameter requires us to copy it for the error state, or remember to lock it when reading (in case it used with 0600). v2: Use __always_inline and __builtin_strcmp Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 5/5] drm/i915/opregion: let user specify override VBT via firmware load

Sometimes it would be most enlightening to debug systems by replacing the VBT to be used. For example, in the referenced bug the BIOS provides different VBT depending on the boot mode (UEFI vs. legacy). It would be interesting to try the failing boot mode with the VBT from the working boot, and

[Intel-gfx] [PATCH 0/5] drm/i915: add VBT firmware loading mechanism

Some cleanups, Chris' patch as a dependency, and an untested idea to load the VBT using the firmware loader if requested by the user. BR, Jani. Chris Wilson (1): drm/i915: Add i915_param charp macro magic Jani Nikula (4): drm/i915/opregion: bail out early for systems with no opregion VBT

[Intel-gfx] [PATCH 4/5] drm/i915/opregion: debug log about invalid ACPI OpRegion VBT

Leave more breadcrumbs for debuggers. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_opregion.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index

[Intel-gfx] [PATCH 3/5] drm/i915/opregion: try to validate RVDA VBT only if it's there

Seems more sensible this way, and reduces indent for the more common case. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_opregion.c | 41 +-- 1 file changed, 20 insertions(+), 21 deletions(-) diff --git

[Intel-gfx] [PATCH 2/5] drm/i915/opregion: bail out early for systems with no opregion VBT

Reduce indent. No functional changes. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_opregion.c | 64 +-- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_opregion.c

Re: [Intel-gfx] [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

On Tue, 21 Feb 2017, Andy Shevchenko wrote: > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element > support") enables GPIO support for Broxton based platforms. > > While using that API we might get into troubles in the future, because > we can't

[Intel-gfx] [PATCH] drm/i915: Add i915_param charp macro magic

Handling the dynamic charp module parameter requires us to copy it for the error state, or remember to lock it when reading (in case it used with 0600). v2: Use __always_inline and __builtin_strcmp Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Add i915_param charp macro magic

On Tue, 07 Feb 2017, Chris Wilson wrote: > On Mon, Feb 06, 2017 at 02:32:17PM +0200, Joonas Lahtinen wrote: >> On ma, 2017-02-06 at 09:51 +, Chris Wilson wrote: >> > Handling the dynamic charp module parameter requires us to copy it for >> > the error state, or

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: use NULL for GPIO connection ID

== Series Details == Series: drm/i915/bxt: use NULL for GPIO connection ID URL : https://patchwork.freedesktop.org/series/20011/ State : success == Summary == Series 20011v1 drm/i915/bxt: use NULL for GPIO connection ID https://patchwork.freedesktop.org/api/1.0/series/20011/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

On ke, 2017-02-15 at 18:28 -0800, Daniele Ceraolo Spurio wrote: > > On 14/02/17 05:53, Joonas Lahtinen wrote: > > > > Started adding proper teardown to guc_client_alloc, ended up removing > > quite a few dead ends where errors communicating with the GuC were > > silently ignored. There also

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/atomic: Make drm_framebuffer_remove atomic, again.

== Series Details == Series: drm/atomic: Make drm_framebuffer_remove atomic, again. URL : https://patchwork.freedesktop.org/series/20008/ State : failure == Summary == Series 20008v1 drm/atomic: Make drm_framebuffer_remove atomic, again.

[Intel-gfx] [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element support") enables GPIO support for Broxton based platforms. While using that API we might get into troubles in the future, because we can't rely on label "panel" in the driver since vendor firmware might provide any GPIO pin there,

Re: [Intel-gfx] [PATCH] drm/fb: Proper support of boundary conditions in bitmasks.

On ma, 2017-02-20 at 10:00 +0200, Jani Nikula wrote: > On Fri, 17 Feb 2017, Tomasz Lis wrote: > > > > The recently introduced patch changed behavior of masks when > > the bit number is negative. Instead of no bits set, the new way > > makes all bits set. Problematic patch:

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Perform object clflushing asynchronously

On ma, 2017-02-20 at 20:59 +, Chris Wilson wrote: > Flushing the cachelines for an object is slow, can be as much as 100ms > for a large framebuffer. We currently do this under the struct_mutex BKL > on execution or on pageflip. But now with the ability to add fences to > obj->resv for both

Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating

On pe, 2017-02-17 at 15:10 +, Chris Wilson wrote: > The object already stores (computed on the fly) the index to dma address > so use it instead of reallocating a large temporary array every time we > bind a rotated framebuffer. > > Signed-off-by: Chris Wilson > Cc:

Re: [Intel-gfx] [PATCH 8/8] drm/i915/uc: Simplify firwmare path handling

On Fri, Feb 17, 2017 at 03:29:17PM +0100, Michal Wajdeczko wrote: > On Fri, Feb 17, 2017 at 02:05:57PM +0100, Arkadiusz Hiler wrote: > > Typo in subject s/firwmare/firmware > > > > Currently fw->path values can represent one of three possible states: > > > > 1) NULL - device without the uC >

Re: [Intel-gfx] [PATCH i-g-t] kms_frontbuffer_tracking: Fix badstride test skipping with atomic

On Tue, 2017-02-21 at 11:43 -0300, Paulo Zanoni wrote: > Em Ter, 2017-02-21 às 15:37 +0200, Ander Conselvan de Oliveira > escreveu: > > In the new atomic reality, the page flip in the end of the badstride > > test succeeds. That flip is to an fb which has a stride too large to > > allow FBC to be

Re: [Intel-gfx] [PATCH i-g-t] kms_frontbuffer_tracking: Fix badstride test skipping with atomic

Em Ter, 2017-02-21 às 15:37 +0200, Ander Conselvan de Oliveira escreveu: > In the new atomic reality, the page flip in the end of the badstride > test succeeds. That flip is to an fb which has a stride too large to > allow FBC to be enabled. Adjust the test expections accordingly.

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/reservation: Wrap ww_mutex_trylock (rev2)

== Series Details == Series: dma-buf/reservation: Wrap ww_mutex_trylock (rev2) URL : https://patchwork.freedesktop.org/series/19997/ State : success == Summary == Series 19997v2 dma-buf/reservation: Wrap ww_mutex_trylock https://patchwork.freedesktop.org/api/1.0/series/19997/revisions/2/mbox/

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms

On Tue, Feb 21, 2017 at 01:19:37PM +, Chris Wilson wrote: > On Tue, Feb 21, 2017 at 02:43:30PM +0200, Imre Deak wrote: > > On Tue, Feb 21, 2017 at 10:06:45AM +, Tvrtko Ursulin wrote: > > > > > > On 21/02/2017 09:37, Chris Wilson wrote: > > > >On Tue, Feb 21, 2017 at 11:22:12AM +0200, Imre

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms

On 21/02/2017 14:13, Imre Deak wrote: On Tue, Feb 21, 2017 at 01:11:27PM +, Tvrtko Ursulin wrote: On 21/02/2017 12:43, Imre Deak wrote: On Tue, Feb 21, 2017 at 10:06:45AM +, Tvrtko Ursulin wrote: On 21/02/2017 09:37, Chris Wilson wrote: On Tue, Feb 21, 2017 at 11:22:12AM +0200,

Re: [Intel-gfx] [PATCH v2 0/4] drm: handle override/firmware edid at the lowest level

On Fri, 17 Feb 2017, Ville Syrjälä wrote: > On Fri, Feb 17, 2017 at 05:20:50PM +0200, Jani Nikula wrote: >> v2 of cover.1487241304.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1487241304.git.jani.nikula@intel.com > > lgtm. For the series >

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms

On Tue, Feb 21, 2017 at 01:11:27PM +, Tvrtko Ursulin wrote: > > On 21/02/2017 12:43, Imre Deak wrote: > >On Tue, Feb 21, 2017 at 10:06:45AM +, Tvrtko Ursulin wrote: > >> > >>On 21/02/2017 09:37, Chris Wilson wrote: > >>>On Tue, Feb 21, 2017 at 11:22:12AM +0200, Imre Deak wrote: > On

Re: [Intel-gfx] [PATCH 7/8] drm/i915/guc: Simplify intel_guc_init_hw()

On Tue, Feb 21, 2017 at 02:56:46PM +0100, Arkadiusz Hiler wrote: > On Fri, Feb 17, 2017 at 03:03:04PM +0100, Michal Wajdeczko wrote: > > On Fri, Feb 17, 2017 at 02:05:56PM +0100, Arkadiusz Hiler wrote: > > > Current version of intel_guc_init_hw() does a lot: > > > - cares about submission > > >

Re: [Intel-gfx] [PATCH 7/8] drm/i915/guc: Simplify intel_guc_init_hw()

On Fri, Feb 17, 2017 at 03:03:04PM +0100, Michal Wajdeczko wrote: > On Fri, Feb 17, 2017 at 02:05:56PM +0100, Arkadiusz Hiler wrote: > > Current version of intel_guc_init_hw() does a lot: > > - cares about submission > > - loads huc > > - implement WA > > > > This change offloads some of the

[Intel-gfx] [PATCH 3/3] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb.

This introduces a slight behavioral change to rmfb. Instead of disabling a crtc when the primary plane is disabled, we try to preserve it. Apart from old versions of the vmwgfx xorg driver, there is nothing depending on rmfb disabling a crtc. Since vmwgfx is a legacy driver we can safely only

[Intel-gfx] [PATCH 2/3] drm: Convert drm_framebuffer_remove to atomic, v4.

Instead of trying to do everything in 1 go, just do a basic safe conversion first. We've been bitten by too many regressions in the past. This patch only converts drm_framebuffer_remove to atomic. The regression sensitive part is split out to a separate patch. v2: - Remove plane->fb assignment,

[Intel-gfx] [PATCH 1/3] drm/atomic: Make disable_all helper fully disable the crtc.

It seems that nouveau requires this, so best to do this in the helper. This allows nouveau to use the atomic suspend helper. Cc: nouv...@lists.freedesktop.org Acked-by: Ben Skeggs #irc Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH 0/3] drm/atomic: Make drm_framebuffer_remove atomic, again.

This fixes a connector leak first when disabling the device, and then converts rmfb to atomic. The behavior change is done as a separate patch, so it can be reverted if it breaks, again.. Maarten Lankhorst (3): drm/atomic: Make disable_all helper fully disable the crtc. drm: Convert

Re: [Intel-gfx] [PATCH 6/8] drm/i915/guc: Extract param logic form guc_init

On Fri, Feb 17, 2017 at 02:52:00PM +0100, Michal Wajdeczko wrote: > On Fri, Feb 17, 2017 at 02:05:55PM +0100, Arkadiusz Hiler wrote: > > Let intel_guc_fetch_fw() focus on determining and fetching the correct > > firmware. > > > > This patch introduces intel_sanitize_uc_params() that is called

[Intel-gfx] [PATCH i-g-t] kms_frontbuffer_tracking: Fix badstride test skipping with atomic

In the new atomic reality, the page flip in the end of the badstride test succeeds. That flip is to an fb which has a stride too large to allow FBC to be enabled. Adjust the test expections accordingly. Cc: Maarten Lankhorst Cc: Paulo Zanoni

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy execlists_init_reg_state

On 21/02/2017 11:22, Patchwork wrote: == Series Details == Series: drm/i915: Tidy execlists_init_reg_state URL : https://patchwork.freedesktop.org/series/19998/ State : success == Summary == Series 19998v1 drm/i915: Tidy execlists_init_reg_state

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/tracepoints: Tidy request event class (rev4)

On 21/02/2017 11:52, Patchwork wrote: == Series Details == Series: series starting with [1/8] drm/i915/tracepoints: Tidy request event class (rev4) URL : https://patchwork.freedesktop.org/series/19994/ State : success == Summary == Series 19994v4 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms

On Tue, Feb 21, 2017 at 02:43:30PM +0200, Imre Deak wrote: > On Tue, Feb 21, 2017 at 10:06:45AM +, Tvrtko Ursulin wrote: > > > > On 21/02/2017 09:37, Chris Wilson wrote: > > >On Tue, Feb 21, 2017 at 11:22:12AM +0200, Imre Deak wrote: > > >>On Mon, Feb 20, 2017 at 04:05:33PM +, Chris

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms

On 21/02/2017 12:43, Imre Deak wrote: On Tue, Feb 21, 2017 at 10:06:45AM +, Tvrtko Ursulin wrote: On 21/02/2017 09:37, Chris Wilson wrote: On Tue, Feb 21, 2017 at 11:22:12AM +0200, Imre Deak wrote: On Mon, Feb 20, 2017 at 04:05:33PM +, Chris Wilson wrote: So that our preempt-off

Re: [Intel-gfx] [PATCH] drm/i915: Use reservation_object_lock()

On Tue, Feb 21, 2017 at 02:28:27PM +0200, Joonas Lahtinen wrote: > On ti, 2017-02-21 at 09:17 +, Chris Wilson wrote: > > Replace the calls to ww_mutex_lock(>lock) with the helper > > reservation_object_lock(resv) and similarly for unlock. > > > > Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2] dma-buf/reservation: Wrap ww_mutex_trylock

In a similar fashion to reservation_object_lock() and reservation_object_unlock(), ww_mutex_trylock is also useful and so is worth wrapping for consistency. v2: Add __must_check Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms

On Tue, Feb 21, 2017 at 10:06:45AM +, Tvrtko Ursulin wrote: > > On 21/02/2017 09:37, Chris Wilson wrote: > >On Tue, Feb 21, 2017 at 11:22:12AM +0200, Imre Deak wrote: > >>On Mon, Feb 20, 2017 at 04:05:33PM +, Chris Wilson wrote: > >>>So that our preempt-off period doesn't grow completely

Re: [Intel-gfx] [PATCH] dma-buf/reservation: Wrap ww_mutex_trylock

On ti, 2017-02-21 at 09:30 +, Chris Wilson wrote: > In a similar fashion to reservation_object_lock() and > reservation_object_unlock(), ww_mutex_trylock is also useful and so is > worth wrapping for consistency. > > Signed-off-by: Chris Wilson > Cc: Sumit Semwal

Re: [Intel-gfx] [PATCH 1/8] drm/i915/tracepoints: Tidy request event class

On Tue, Feb 21, 2017 at 09:51:51AM +, Chris Wilson wrote: > On Tue, Feb 21, 2017 at 09:13:43AM +, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > At the moment only the global seqno is logged which is not set > > until the request is ready for submission.

Re: [Intel-gfx] [PATCH] drm/i915: Use reservation_object_lock()

On ti, 2017-02-21 at 09:17 +, Chris Wilson wrote: > Replace the calls to ww_mutex_lock(>lock) with the helper > reservation_object_lock(resv) and similarly for unlock. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 3/3] drm/i915: reorganize the get_cdclk assignment

On Mon, 2017-02-20 at 17:00 -0300, Paulo Zanoni wrote: > Possible problems of the current if-ladder: > - It's a huge if ladder with almost a different check for each of > our platforms. > - It mixes 3 different types of checks: IS_GENX, IS_PLATFORM and > IS_GROUP_OF_PLATFORMS. > - As

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Skip waiting for fifo when awake

== Series Details == Series: series starting with [1/2] drm/i915: Skip waiting for fifo when awake URL : https://patchwork.freedesktop.org/series/20002/ State : success == Summary == Series 20002v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/tracepoints: Tidy request event class (rev4)

== Series Details == Series: series starting with [1/8] drm/i915/tracepoints: Tidy request event class (rev4) URL : https://patchwork.freedesktop.org/series/19994/ State : success == Summary == Series 19994v4 Series without cover letter

Re: [Intel-gfx] [PATCH 3/3] drm/i915: reorganize the get_cdclk assignment

On Mon, Feb 20, 2017 at 05:00:42PM -0300, Paulo Zanoni wrote: > Possible problems of the current if-ladder: > - It's a huge if ladder with almost a different check for each of > our platforms. > - It mixes 3 different types of checks: IS_GENX, IS_PLATFORM and > IS_GROUP_OF_PLATFORMS. >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: remove potentially confusing IS_G4X checks

On Mon, Feb 20, 2017 at 05:00:41PM -0300, Paulo Zanoni wrote: > The IS_G4X macro is defined as IS_G45 || IS_GM45. We have two points > in our code where we have an if statement checking for GM45 followed > by an else if statement checking for IS_G4X. This can be confusing > since the IS_G4X check

Re: [Intel-gfx] [PATCH 5/8] drm/i915/uc: Make intel_uc_fw_fetch() static

On Fri, Feb 17, 2017 at 02:39:35PM +0100, Michal Wajdeczko wrote: > On Fri, Feb 17, 2017 at 02:05:54PM +0100, Arkadiusz Hiler wrote: > > intel_uc_fw_fetch() is confusingly named in the light of recent changes. > > > > It's also in the worng place - 'guc_loader.h' - it's used for both guc > >

Re: [Intel-gfx] [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw()

On Fri, Feb 17, 2017 at 02:31:09PM +0100, Michal Wajdeczko wrote: > On Fri, Feb 17, 2017 at 02:05:53PM +0100, Arkadiusz Hiler wrote: > > Trying to have subject_verb_object ordering and more descriptive names, > > the intel_huc_init() and intel_guc_init() functions are renamed: > > > > *

[Intel-gfx] [PATCH 1/2] drm/i915: Skip waiting for fifo when awake

If the GT device is already awake, we can skip checking the FIFO for sufficient entires to store the mmio write, as the write will go directly to the device. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_uncore.c | 6 ++ 1 file changed, 2

[Intel-gfx] [PATCH 2/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

Remove the per-mmio checking of the FIFO debug register into the common conditional mmio debug handling. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_uncore.c | 43 ++--- 1 file changed, 11 insertions(+), 32 deletions(-)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy execlists_init_reg_state

== Series Details == Series: drm/i915: Tidy execlists_init_reg_state URL : https://patchwork.freedesktop.org/series/19998/ State : success == Summary == Series 19998v1 drm/i915: Tidy execlists_init_reg_state https://patchwork.freedesktop.org/api/1.0/series/19998/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

On 02/20/2017 11:22 PM, Daniel Vetter wrote: > On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom wrote: >> So I think we need a quick revert of this commit or a quick stable >> follow-up to unbreak things on our side. > I'd much prefer we just register control nodes for

Re: [Intel-gfx] [PATCH igt] intel-ci: Exercise all basic relocation targets

On Sat, Feb 04, 2017 at 04:20:27PM +, Chris Wilson wrote: > There are several possible relocation methods the kernel uses depending > upon the placement and caching of the buffers. Lots of different code > paths not being covered by BAT - expand the testing to cover them. Even > though there

[Intel-gfx] [PATCH v4 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints

From: Tvrtko Ursulin Two new tracepoints placed at the call sites where requests are actually passed to the GPU enable userspace to track engine utilisation. These tracepoints are only enabled when the DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option is enabled. v2: Fix

[Intel-gfx] [PATCH v2 5/8] drm/i915/tracepoints: Add request submit and execute tracepoints

From: Tvrtko Ursulin These new tracepoints are emitted once the request is ready to be submitted to the GPU and once the request is about to be submitted to the GPU, respectively. Former condition triggers as soon as all the fences and dependencies have been resolved,

[Intel-gfx] [PATCH v4 3/8] drm/i915/tracepoints: Tidy i915_gem_request_wait_begin

From: Tvrtko Ursulin Provide the same information as the other request event classes. v2: Pass in flags so we can properly report the blocking status. (Chris Wilson) v3: Log hex with 0x prefix for clarity. v4: Derive blocking status from flags. (Chris Wilson)

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/reservation: Wrap ww_mutex_trylock

== Series Details == Series: dma-buf/reservation: Wrap ww_mutex_trylock URL : https://patchwork.freedesktop.org/series/19997/ State : success == Summary == Series 19997v1 dma-buf/reservation: Wrap ww_mutex_trylock https://patchwork.freedesktop.org/api/1.0/series/19997/revisions/1/mbox/

Re: [Intel-gfx] DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

On 02/21/2017 06:34 AM, David Airlie wrote: >> No. >> >> IMO Not fixing this immediately through stable is out of the question. >> The deal is that we don't break userspace. >> Having said that, I'm not against a long term vmwgfx-only solution. But >> let's fix this now. >> >> Admittedly we missed

Re: [Intel-gfx] [PATCH 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints

On Tue, Feb 21, 2017 at 10:22:40AM +, Tvrtko Ursulin wrote: > > On 21/02/2017 09:47, Chris Wilson wrote: > >On Tue, Feb 21, 2017 at 09:13:49AM +, Tvrtko Ursulin wrote: > >>@@ -593,6 +595,8 @@ static void intel_lrc_irq_handler(unsigned long data) > >>

Re: [Intel-gfx] [PATCH 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints

On 21/02/2017 09:47, Chris Wilson wrote: On Tue, Feb 21, 2017 at 09:13:49AM +, Tvrtko Ursulin wrote: @@ -593,6 +595,8 @@ static void intel_lrc_irq_handler(unsigned long data) execlists_context_status_change(port[0].request,

Re: [Intel-gfx] [PATCH 5/8] drm/i915/tracepoints: Add request submit and execute tracepoints

On Tue, Feb 21, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote: > > > On 21/02/2017 09:41, Chris Wilson wrote: > >On Tue, Feb 21, 2017 at 09:13:47AM +, Tvrtko Ursulin wrote: > >>@@ -468,6 +469,7 @@ execute_notify(struct i915_sw_fence *fence, enum > >>i915_sw_fence_notify state) > >> > >>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use reservation_object_lock()

== Series Details == Series: drm/i915: Use reservation_object_lock() URL : https://patchwork.freedesktop.org/series/19995/ State : success == Summary == Series 19995v1 drm/i915: Use reservation_object_lock() https://patchwork.freedesktop.org/api/1.0/series/19995/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 3/8] drm/i915/tracepoints: Tidy i915_gem_request_wait_begin

On Tue, Feb 21, 2017 at 10:10:09AM +, Tvrtko Ursulin wrote: > > On 21/02/2017 09:50, Chris Wilson wrote: > >Hmm. How should we handle global changing value in the course of the > >wait? > > How would you do that? It will get logged at the end of the wait and > ctx/ring/seqno can be used as

Re: [Intel-gfx] [PATCH 5/8] drm/i915/tracepoints: Add request submit and execute tracepoints

On 21/02/2017 09:41, Chris Wilson wrote: On Tue, Feb 21, 2017 at 09:13:47AM +, Tvrtko Ursulin wrote: @@ -468,6 +469,7 @@ execute_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state) switch (state) { case FENCE_COMPLETE: +

Re: [Intel-gfx] [PATCH i-g-t v2 1/5] lib/igt_kms: Fix drm_plane leak

Hi, tsa@freenode was kind enough to run some piglit testing on this. I gave the following test list: igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy igt@kms_plane_multiple@legacy-pipe-A-tiling-none

Re: [Intel-gfx] [PATCH 3/8] drm/i915/tracepoints: Tidy i915_gem_request_wait_begin

On 21/02/2017 09:50, Chris Wilson wrote: On Tue, Feb 21, 2017 at 09:13:45AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Provide the same information as the other request event classes. v2: Pass in flags so we can properly report the blocking status.

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms

On 21/02/2017 09:37, Chris Wilson wrote: On Tue, Feb 21, 2017 at 11:22:12AM +0200, Imre Deak wrote: On Mon, Feb 20, 2017 at 04:05:33PM +, Chris Wilson wrote: So that our preempt-off period doesn't grow completely unchecked, or do we need that 34ms loop? Yes, that's at least how I

Re: [Intel-gfx] [PATCH] drm/i915: Tidy execlists_init_reg_state

On Tue, Feb 21, 2017 at 09:58:39AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Compact the name of the macro and reg_state variable, and cache > some data in local variables to make the function more compact > and more readable. > > Signed-off-by: Tvrtko

[Intel-gfx] [PATCH] drm/i915: Tidy execlists_init_reg_state

From: Tvrtko Ursulin Compact the name of the macro and reg_state variable, and cache some data in local variables to make the function more compact and more readable. Signed-off-by: Tvrtko Ursulin --- Not that valuable but those ",0);" in new

Re: [Intel-gfx] [PATCH 1/8] drm/i915/tracepoints: Tidy request event class

On Tue, Feb 21, 2017 at 09:13:43AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > At the moment only the global seqno is logged which is not set > until the request is ready for submission. > > Add the per-contex seqno and the context hardware id which are >

  1   2   >