Re: [Intel-gfx] [PATCH 01/12] tests/kms_atomic_transition: use select + read instead of blocking read

On Mon, Nov 14, 2016 at 06:59:14PM +0900, Gustavo Padovan wrote: > From: Gustavo Padovan > > If the event never arrives we can timeout with select and end the test. > > Signed-off-by: Gustavo Padovan > --- >

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote: > In the usual working scenarios, this property is "Good". > If something fails during modeset, the DRM driver can > set the link status to "Bad", prune the mode list based on the > link rate/lane count fallback values and send

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

On Mon, Nov 14, 2016 at 07:23:33PM -0800, Manasi Navare wrote: > None of the other functions that set the connector property hold the > mode config locks while setting the connector property, I am following > the same convention. > Also we dont need to grab and release the locks in

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote: > In the usual working scenarios, this property is "Good". > If something fails during modeset, the DRM driver can > set the link status to "Bad", prune the mode list based on the > link rate/lane count fallback values and send

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/bxt: add bxt dsi gpio element support

Tested-by: Mika Kahola On Tue, 2016-04-26 at 13:27 +0300, Jani Nikula wrote: > Request the GPIO by index through the consumer API. For now, use a > quick > hack to store the already requested ones, simply because I have no > idea > whether this actually works or not, and I

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios

== Series Details == Series: series starting with [1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios URL : https://patchwork.freedesktop.org/series/15321/ State : success == Summary == Series 15321v1 Series without cover letter

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

Overall this patch set makes sense but I think it would be good to move some stuff to common code instead of leaving it in i915. I'm thinking about patch 2 (setting the link status property) in particular but also tend to agree with Ville and Daniel about their comments for patch 5. That

Re: [Intel-gfx] [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

On Mon, Nov 14, 2016 at 04:37:09PM +0100, Christian König wrote: > Am 14.11.2016 um 12:55 schrieb Chris Wilson: > > The current code is subject to a race where we may try to acquire a > > reference on a stale fence: > > > > [13703.335118] WARNING: CPU: 1 PID: 14975 at ./include/linux/kref.h:46 >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: Broxton decoupled MMIO (rev4)

== Series Details == Series: drm/i915/bxt: Broxton decoupled MMIO (rev4) URL : https://patchwork.freedesktop.org/series/12028/ State : success == Summary == Series 12028v4 drm/i915/bxt: Broxton decoupled MMIO https://patchwork.freedesktop.org/api/1.0/series/12028/revisions/4/mbox/

Re: [Intel-gfx] [PATCH v11 3/4] drm/i915: Use new CRC debugfs API

On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote: > On Thu, 06 Oct 2016, Tomeu Vizoso wrote: > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 23a6c7213eca..7412a05fa5d9 100644 > > ---

[Intel-gfx] [PATCH 1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios

From: Libin Yang When bootup, audio driver may not know it is MST or not. The audio driver will poll all the port & pipe combinations in either MST or Non-MST mode. get_saved_enc() should handle this situation. Signed-off-by: Libin Yang

[Intel-gfx] [PATCH 2/2] drm/i915/audio: Extend audio sync rate support for DP MST

From: Libin Yang This patch extends the support of audio sample rate sync up to DP MST. Signed-off-by: Libin Yang --- drivers/gpu/drm/i915/intel_audio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass

> > == Series Details == > > > > Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own > lockclass > > URL : https://patchwork.freedesktop.org/series/15303/ > > State : warning > > > > == Summary == > > > > Series 15303v1 Series without cover letter > >

[Intel-gfx] [PATCH v4] drm/i915/bxt: Broxton decoupled MMIO

Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles for a single read/write and avoids frequent software forcewake. This certainly gives advantage over the forcewake as this new mechanism “decouples” CPU cycles and allow them to complete even when

Re: [Intel-gfx] [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math

Hi Dhinakaran, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.9-rc5 next-20161114] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dhinakaran-Pandiyan/drm-dp

[Intel-gfx] ✓ Fi.CI.BAT: success for Handle Link Training Failure during modeset (rev2)

== Series Details == Series: Handle Link Training Failure during modeset (rev2) URL : https://patchwork.freedesktop.org/series/15080/ State : success == Summary == Series 15080v2 Handle Link Training Failure during modeset

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

None of the other functions that set the connector property hold the mode config locks while setting the connector property, I am following the same convention. Also we dont need to grab and release the locks in i915_modeset_work_func that first validates the modes and then sets this link status

[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure. v2: Squash the patch that returns the link rate index (Jani

[Intel-gfx] [PATCH 0/5] Handle link training failure during modeset

Submitting new series that adds proper commit messages/cover letter and kernel documentation. It also moved the set_link_status function to drm core so other kernel drivers can make use of it. The idea presented in these patches is to address link training failure in a way that: a) changes the

[Intel-gfx] [PATCH 1/5] drm: Add a new connector property for link status

A new default connector property is added for keeping track of whether the link is good (link training passed) or link is bad (link training failed). If the link status property is not good, then userspace should fire off a new modeset at the current mode even if there have not been any changes

[Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

In the usual working scenarios, this property is "Good". If something fails during modeset, the DRM driver can set the link status to "Bad", prune the mode list based on the link rate/lane count fallback values and send hotplug uevent so that userspace that is aware of this property can take an

[Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

CRTC state connector_changed needs to be set to true if connector link status property has changed. This will tell the driver to do a complete modeset due to change in connector property. Acked-by: Harry Wentland Acked-by: Tony Cheng Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for HuC Loading Patches (rev2)

== Series Details == Series: HuC Loading Patches (rev2) URL : https://patchwork.freedesktop.org/series/15135/ State : success == Summary == Series 15135v2 HuC Loading Patches https://patchwork.freedesktop.org/api/1.0/series/15135/revisions/2/mbox/ fi-bdw-5557u total:244 pass:229

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

On Mon, Nov 14, 2016 at 08:07:39PM -0500, Harry Wentland wrote: > Overall this patch set makes sense but I think it would be good to > move some stuff to common code instead of leaving it in i915. I'm > thinking about patch 2 (setting the link status property) in > particular but also tend to

[Intel-gfx] [PATCH-v11] drm/i915/huc: Add HuC fw loading support

From: Peter Antoine The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2: rebased on-top of drm-intel-nightly.

Re: [Intel-gfx] [PATCH v2] drm/dp: Make space for null terminator in the DP device ID char array

Adding Cc's. On Mon, 2016-11-07 at 15:22 -0800, Dhinakaran Pandiyan wrote: > The DP device identification string read from the DPCD registers is 6 > characters long at max. and we store it in a char array of the same length > without space for the NULL terminator. Fix this by increasing the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: cleanup use of INSTR_CLIENT_MASK

== Series Details == Series: drm/i915: cleanup use of INSTR_CLIENT_MASK URL : https://patchwork.freedesktop.org/series/15306/ State : success == Summary == Series 15306v1 drm/i915: cleanup use of INSTR_CLIENT_MASK https://patchwork.freedesktop.org/api/1.0/series/15306/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915: cleanup use of INSTR_CLIENT_MASK

On Mon, Nov 14, 2016 at 10:39:34PM +, Matthew Auld wrote: > Doing cmd_header >> 29 to extract our 3-bit client value where we know > cmd_header is a u32 shouldn't then also require the use of a mask. So > remove the redundant operation and get rid of INSTR_CLIENT_MASK now that > there are no

[Intel-gfx] [PATCH] drm/i915: cleanup use of INSTR_CLIENT_MASK

Doing cmd_header >> 29 to extract our 3-bit client value where we know cmd_header is a u32 shouldn't then also require the use of a mask. So remove the redundant operation and get rid of INSTR_CLIENT_MASK now that there are no longer any users. Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v3 14/14] drm/i915: Support explicit fencing for execbuf

Hi Chris, I'm not sure you are waiting for this kind of feedback, but I've managed to test this particular patch with Mesa, and I have some piglit tests for it too. They are waiting for review, but at least the feature is working as expected:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/dp/i915: Fix DP link rate math (rev2)

== Series Details == Series: series starting with [v2,1/2] drm/dp/i915: Fix DP link rate math (rev2) URL : https://patchwork.freedesktop.org/series/15305/ State : success == Summary == Series 15305v2 Series without cover letter

[Intel-gfx] [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math

We store DP link rates as link clock frequencies in kHz, just like all other clock values. But, DP link rates in the DP Spec. are expressed in Gbps/lane, which seems to have led to some confusion. E.g., for HBR2 Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps where, 8/10 is

[Intel-gfx] [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math

We store DP link rates as link clock frequencies in kHz, just like all other clock values. But, DP link rates in the DP Spec. are expressed in Gbps/lane, which seems to have led to some confusion. E.g., for HBR2 Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps where, 8/10 is

[Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

Not validating the mode rate against max. link rate results in not pruning invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not support 4k@60Hz. But, we do not reject this mode. So, make use of the helpers in intel_dp to validate mode data rate against max. link data rate of a

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote: > On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote: > > Not validating the the mode rate against link rate results not pruning > > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not > > support 4k @ 60Hz.

Re: [Intel-gfx] [PATCH igt v4 06/13] igt/gem_exec_parse: init global parser_version in fixture

On 14 November 2016 at 20:51, Robert Bragg wrote: > This adds a static global int parser_version that can be referenced by > all subtests without needing multiple GETPARAM requests. > > Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH igt v4 05/13] igt/gem_exec_parse: make global vars local to main()

On 14 November 2016 at 20:51, Robert Bragg wrote: > Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass

On Mon, Nov 14, 2016 at 09:16:08PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own > lockclass > URL : https://patchwork.freedesktop.org/series/15303/ > State : warning > > == Summary == > > Series 15303v1 Series

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass

== Series Details == Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass URL : https://patchwork.freedesktop.org/series/15303/ State : warning == Summary == Series 15303v1 Series without cover letter

[Intel-gfx] [PATCH igt v4 13/13] igt/gem_exec_parse: check oacontrol lri bad for >= v9

OACONTROL is no longer white listed in the command parser so this checks at attempted LRI will be disallowed and (more importantly) checks that userspace doesn't get an EINVAL error for an attempted OACONTROL LRI. This is important becase Mesa application attempt OACONTROL LRIs while initializing

[Intel-gfx] [PATCH igt v4 11/13] igt/gem_exec_parse: update hsw_load_register_reg for v >= 8

This updates the checking of disallowed loads to set a distinguishable value before the load and explicitly check the load was a NOOP by reading back the final value. Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld --- tests/gem_exec_parse.c

[Intel-gfx] [PATCH igt v4 10/13] igt/gem_exec_parse: update cmd-crossing-page for >= v8

Since an access violation won't return an error to userspace for v >= 8 of the command parser this updates the cmd-crossing-page test to explicitly read back from SO_WRITE_OFFSET[0] to see that the command wasn't squashed to a NOOP. Signed-off-by: Robert Bragg Reviewed-by:

[Intel-gfx] [PATCH igt v4 07/13] igt/gem_exec_parse: req. v < 9 for oacontrol tracking test

This limits testing the oacontrol tracking (required pairing of oa enable/disable per batch buffer) to version <= 8 of the command parser. Version 9 of the command parser removes all special handling for OACONTROL which is now going to be managed by i915-perf and not programmed from userspace.

[Intel-gfx] [PATCH igt v4 12/13] igt/gem_exec_parse: update registers test for v >= 8

This combines some parts of the recently added store_lri test with the registers test to be able to first load a distinguishable value before the LRI and explicitly read back the register to determine if the command succeeded or was a NOOP. For now though we won't look at OACONTROL without

[Intel-gfx] [PATCH igt v4 08/13] igt/gem_exec_parse: make basic-rejected version agnostic

This adapts the basic-rejected test to focus on invalid commands that will result in an EINVAL errno being returned to userspace even with the upcoming version 8 parser change to stop reporting access violations as EINVAL errors. Signed-off-by: Robert Bragg Reviewed-by:

[Intel-gfx] [PATCH igt v4 09/13] igt/gem_exec_parse: update bitmasks test for v >=8

With v8 of the command parser (where we won't get an EINVAL for an access violation) this updates the bitmasks test to explicitly confirm that the command became a NOOP by reading back from where the QW_WRITE would have otherwise landed. Signed-off-by: Robert Bragg

[Intel-gfx] [PATCH igt v4 04/13] igt/gem_exec_parse: update hsw_load_register_reg

This generalises hsw_load_register_reg to loop through an array of allowed and disallowed registers and to use the exec_batch[_patched] utilities. Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld --- tests/gem_exec_parse.c | 137

[Intel-gfx] [PATCH igt v4 06/13] igt/gem_exec_parse: init global parser_version in fixture

This adds a static global int parser_version that can be referenced by all subtests without needing multiple GETPARAM requests. Signed-off-by: Robert Bragg --- tests/gem_exec_parse.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git

[Intel-gfx] [PATCH igt v4 05/13] igt/gem_exec_parse: make global vars local to main()

Signed-off-by: Robert Bragg --- tests/gem_exec_parse.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c index dcf39a2..ebcd092 100644 --- a/tests/gem_exec_parse.c +++ b/tests/gem_exec_parse.c @@

[Intel-gfx] [PATCH igt v4 03/13] igt/gem_exec_parse: move hsw_load_register_reg down

No functional change, just moving hsw_load_regster_reg test code down below the execbuf utilities in preparation for updating to use them. Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld --- tests/gem_exec_parse.c | 182

[Intel-gfx] [PATCH igt v4 01/13] igt/perf: add i915 perf stream tests for Haswell

Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld --- tests/Makefile.sources |1 + tests/perf.c | 2373 2 files changed, 2374 insertions(+) create mode 100644 tests/perf.c diff

[Intel-gfx] [PATCH igt v4 00/13] corresponding changes for i915-perf interface

The i915-perf series affects the command parser and itself includes new uapi which these i-g-t changes try to cover. This update follows up on review from both Matt and Chris. A minor change I ended up making was to rename the hsw_oa_formats[] array to oa_formats[] indexed by the format ID so

[Intel-gfx] [PATCH igt v4 02/13] igt/gem_exec_parse: some minor cleanups

This normalizes the execbuf utilities in this file to all use memset to clear obj, reloc and execbuf structures and set them up in the same order. As I was debugging some unpredictable test failures I was getting unsure that all these structures were being fully initialized. The same

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

Em Seg, 2016-11-14 às 22:26 +0200, Ville Syrjälä escreveu: > On Fri, Nov 11, 2016 at 06:49:59PM -0200, Paulo Zanoni wrote: > > > > Em Sex, 2016-11-11 às 22:24 +0200, Ville Syrjälä escreveu: > > > > > > On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote: > > > > > > > > > > > > Em

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: rewrite FBC's atomic CRTC-choosing code

== Series Details == Series: drm/i915: rewrite FBC's atomic CRTC-choosing code URL : https://patchwork.freedesktop.org/series/15302/ State : success == Summary == Series 15302v1 drm/i915: rewrite FBC's atomic CRTC-choosing code

[Intel-gfx] [CI 07/10] drm/i915/scheduler: Record all dependencies upon request construction

The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any time and must ensure the dependency tree is not broken. This is in additional to using the fence to only allow execution after all dependencies have been

[Intel-gfx] [CI 05/10] drm/i915: Remove engine->execlist_lock

The execlist_lock is now completely subsumed by the engine->timeline->lock, and so we can remove the redundant layer of locking. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--

[Intel-gfx] [CI 09/10] drm/i915: Store the execution priority on the context

In order to support userspace defining different levels of importance to different contexts, and in particular the preferred order of execution, store a priority value on each context. By default, the kernel's context, which is used for idling and other background tasks, is given minimum priority

[Intel-gfx] [CI 02/10] drm/i915: Create distinct lockclasses for execution vs user timelines

In order to simplify the lockdep annotation, as they become more complex in the future with deferred execution and multiple paths through the same functions, create a separate lockclass for the user timeline and the hardware execution timeline. We should only ever be locking the user timeline and

[Intel-gfx] [CI 06/10] drm/i915/scheduler: Signal the arrival of a new request

The start of the scheduler, add a hook into request submission for the scheduler to see the arrival of new requests and prepare its runqueues. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [CI 01/10] drm/i915: Give each sw_fence its own lockclass

Localise the static struct lock_class_key to the caller of i915_sw_fence_init() so that we create a lock_class instance for each unique sw_fence rather than all sw_fences sharing the same lock_class. This eliminate some lockdep false positive when using fences from within fence callbacks. For the

[Intel-gfx] [CI 10/10] drm/i915/scheduler: Boost priorities for flips

Boost the priority of any rendering required to show the next pageflip as we want to avoid missing the vblank by being delayed by invisible workload. We prioritise avoiding jank and jitter in the GUI over starving background tasks. v2: Descend dma_fence_array when boosting priorities.

[Intel-gfx] [CI 08/10] drm/i915/scheduler: Execute requests in order of priorities

Track the priority of each request and use it to determine the order in which we submit requests to the hardware via execlists. The priority of the request is determined by the user (eventually via the context) but may be overridden at any time by the driver. When we set the priority of the

[Intel-gfx] [CI 04/10] drm/i915: Defer transfer onto execution timeline to actual hw submission

Defer the transfer from the client's timeline onto the execution timeline from the point of readiness to the point of actual submission. For example, in execlists, a request is finally submitted to hardware when the hardware is ready, and only put onto the hardware queue when the request is ready.

[Intel-gfx] [CI 03/10] drm/i915: Split request submit/execute phase into two

In order to support deferred scheduling, we need to differentiate between when the request is ready to run (i.e. the submit fence is signaled) and when the request is actually run (a new execute fence). This is typically split between the request itself wanting to wait upon others (for which we

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

On Fri, Nov 11, 2016 at 06:49:59PM -0200, Paulo Zanoni wrote: > Em Sex, 2016-11-11 às 22:24 +0200, Ville Syrjälä escreveu: > > On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote: > > > > > > Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu: > > > > > > > > On Fri, Nov 11, 2016

[Intel-gfx] [PATCH] drm/i915: rewrite FBC's atomic CRTC-choosing code

Ville pointed out that intel_fbc_choose_crtc() is iterating over all planes instead of just the primary planes. There are no real consequences of this problem for HSW+, and for the other platforms it just means that in some obscure multi-screen cases we'll keep FBC disabled when we could have

Re: [Intel-gfx] [PATCH 0/7] FBC atomic cleanups

Em Sex, 2016-11-11 às 14:57 -0200, Paulo Zanoni escreveu: > Ville pointed out two ugly defects in the FBC code, and while trying > to fix them I spotted a few extra things. No real-world bugs fixed > here, but IMHO the code is much easier to read now. I merged patches 1-5 and 7, and will resend

Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu: > On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote: > > > > The previous spec version said "double Ytile planes minimum lines", > > and I interpreted this as referring to what the spec calls "Y tile > > minimum", but in fact it

Re: [Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

On Fri, 2016-11-11 at 15:09 +0200, Imre Deak wrote: > On to, 2016-11-10 at 17:03 -0800, Rodrigo Vivi wrote: > > According to Bspec we need to > > "Poll for PORT_REF_DW3_A grc_done == 1b" > > only on ports B and C initialization sequence when > > copying rcomp from port A. > > > > So let's follow

Re: [Intel-gfx] [PATCH igt v3 06/11] igt/gem_exec_parse: make basic-rejected version agnostic

On 9 November 2016 at 16:15, Robert Bragg wrote: > This adapts the basic-rejected test to focus on invalid commands that > will result in an EINVAL errno being returned to userspace even with the > upcoming version 8 parser change to stop reporting access violations as >

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Remove some duplicated plane swapping logic

On Tue, Nov 08, 2016 at 03:23:14PM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC > > capable plane

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers

On Mon, Nov 14, 2016 at 08:22:42PM +0200, Ville Syrjälä wrote: > On Mon, Nov 14, 2016 at 06:16:49PM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: A few DP stragglers > > URL : https://patchwork.freedesktop.org/series/15299/ > > State : warning > > > > == Summary ==

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers

On Mon, Nov 14, 2016 at 06:16:49PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: A few DP stragglers > URL : https://patchwork.freedesktop.org/series/15299/ > State : warning > > == Summary == > > Series 15299v1 drm/i915: A few DP stragglers >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Per-plane rotation leftovers

On Mon, Nov 14, 2016 at 05:47:19PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Per-plane rotation leftovers > URL : https://patchwork.freedesktop.org/series/15290/ > State : success And series pushed to dinq. Thanks for the reviews. > > == Summary == > > Series

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers

== Series Details == Series: drm/i915: A few DP stragglers URL : https://patchwork.freedesktop.org/series/15299/ State : warning == Summary == Series 15299v1 drm/i915: A few DP stragglers https://patchwork.freedesktop.org/api/1.0/series/15299/revisions/1/mbox/ Test kms_pipe_crc_basic:

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Add a per-pipe plane identifier enum (rev4)

On Wed, Nov 09, 2016 at 04:24:58PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add a per-pipe plane identifier enum (rev4) > URL : https://patchwork.freedesktop.org/series/14978/ > State : warning > > == Summary == > > Series 14978v4 drm/i915: Add a per-pipe plane

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

Yes driver can chose to have the pre train for kernel hiding unsupported mode, that is completely still possible for the amd driver and it would never use the link_status connector property and no interaction with userspace. Could you please give your ACKs for the patches if you are okay with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Per-plane rotation leftovers

== Series Details == Series: drm/i915: Per-plane rotation leftovers URL : https://patchwork.freedesktop.org/series/15290/ State : success == Summary == Series 15290v1 drm/i915: Per-plane rotation leftovers https://patchwork.freedesktop.org/api/1.0/series/15290/revisions/1/mbox/ fi-bdw-5557u

[Intel-gfx] [PATCH 1/2] drm/i915: Kill dp_encoder_is_mst

From: Ville Syrjälä dp_encoder_is_mst flag in the crtc state can be replaced by intel_crtc_has_type(..., INTEL_OUTPUT_DP_MST). Let's do that. Cc: Maarten Lankhorst Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 0/2] drm/i915: A few DP stragglers

From: Ville Syrjälä Reposting a few trivial DP related stragglers, with Jim's irc r-b slapped on. Ville Syrjälä (2): drm/i915: Kill dp_encoder_is_mst drm/i915: Simplify DP port limited color range bit platform checks drivers/gpu/drm/i915/intel_display.c | 4

Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel parameter into one

>-Original Message- >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] >Sent: Monday, November 14, 2016 1:35 AM >To: Mcgee, Jeff ; Srivatsa, Anusha > >Cc: Ursulin, Tvrtko ;

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

== Series Details == Series: drm/i915: atomic_cdclk_freq fixes URL : https://patchwork.freedesktop.org/series/15288/ State : success == Summary == Series 15288v1 drm/i915: atomic_cdclk_freq fixes https://patchwork.freedesktop.org/api/1.0/series/15288/revisions/1/mbox/ fi-bdw-5557u

[Intel-gfx] [PATCH 2/3] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

From: Ville Syrjälä Move the plane control register rotation setup away from the coordinate munging code. This will result in neater looking code once we add reflection support for CHV. v2: Drop the BIT(), drop some usless parens, Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 3/3] drm/i915: Add horizontal mirroring support for CHV pipe B planes

From: Ville Syrjälä The primary and sprite planes on CHV pipe B support horizontal mirroring. Expose it to the world. Sadly the hardware ignores the mirror bit when the rotate bit is set, so we'll have to reject the 180+X case. v2: Drop the BIT() v3: Pass

[Intel-gfx] [PATCH 1/3] drm/i915: Use & instead if == to check for rotations

From: Ville Syrjälä Using == to check for 180 degree rotation only works as long as the reflection bits aren't set. That will change soon enough for CHV, so let's stop doing things the wrong way. v2: Drop the BIT() Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 0/3] drm/i915: Per-plane rotation leftovers

From: Ville Syrjälä Just a repost of the remainder of my per-plane rotation series, just so I get a proper CI run for them. Ville Syrjälä (3): drm/i915: Use & instead if == to check for rotations drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

Re: [Intel-gfx] [RFC i-g-t 4/4] Add support for hotplug testing with the Chamelium

Well I'm definitely in agreement with the idea of using config files for this. Would be a lot more reliable then these tricks. Will respin with this added On Mon, 2016-11-14 at 08:05 +0100, Daniel Vetter wrote: > On Mon, Nov 07, 2016 at 07:05:16PM -0500, Lyude wrote: > > > > For the purpose of

[Intel-gfx] [PATCH 2/3] drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks

From: Ville Syrjälä A modeset on one pipe can update dev_priv->atomic_cdclk_freq without actually touching the hardware, in which case we won't force a modeset on all the pipes, and thus won't lock any of the other pipes either. That means a parallel plane update

[Intel-gfx] [PATCH 3/3] drm/i915: Simplify error handling in intel_modeset_all_pipes()

From: Ville Syrjälä No need for the extra break statements and whatnot, just return the error directly. And tighten the scope of the local variables while at it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH v2 1/3] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

From: Ville Syrjälä When we end up not recomputing the cdclk, we need to populate intel_state->cdclk with the "atomic_cdclk_freq" instead of the current cdclk_freq. When no pipes are active, the actual cdclk_freq may be lower than what the configuration of the

[Intel-gfx] [PATCH 0/3] drm/i915: atomic_cdclk_freq fixes

From: Ville Syrjälä My little fix for populating intel_state->cdclk with dev_priv->atomic_cdclk_freq became a little meatier after I realized that we really need to protect it with what is essentially a crtc rwlock. That is, writers need to hold all the crtc locks,

[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling (rev5)

== Series Details == Series: Geminilake enabling (rev5) URL : https://patchwork.freedesktop.org/series/15118/ State : success == Summary == Series 15118v5 Geminilake enabling https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/5/mbox/ fi-bdw-5557u total:244 pass:229

Re: [Intel-gfx] [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell

On Thu, Nov 10, 2016 at 11:03 PM, Matthew Auld wrote: > On 11/09, Robert Bragg wrote: > > + > > +igt_main > > +{ > > +igt_skip_on_simulation(); > > + > > +igt_fixture { > > +struct stat sb; > > +int ret; > > + > > +

Re: [Intel-gfx] [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

Am 14.11.2016 um 12:55 schrieb Chris Wilson: The current code is subject to a race where we may try to acquire a reference on a stale fence: [13703.335118] WARNING: CPU: 1 PID: 14975 at ./include/linux/kref.h:46 i915_gem_object_wait+0x1a3/0x1c0 [13703.335184] Modules linked in: [13703.335202]

Re: [Intel-gfx] [PATCH] drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT

On Mon, Nov 14, 2016 at 08:15:56AM +0100, Daniel Vetter wrote: > On Fri, Nov 11, 2016 at 07:14:24PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT > > port information

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

On Mon, Nov 14, 2016 at 04:48:00PM +0200, Joonas Lahtinen wrote: > On ma, 2016-11-14 at 08:56 +, Chris Wilson wrote: > > + static struct lock_class_key __key; \ > > When lockdep is disabled, this becomes zero size. We might still get > rid of the #fence strings, with

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

On ma, 2016-11-14 at 08:56 +, Chris Wilson wrote: > Localise the static struct lock_class_key to the caller of > i915_sw_fence_init() so that we create a lock_class instance for each > unique sw_fence rather than all sw_fences sharing the same > lock_class. This eliminate some lockdep false

[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling (rev5)

== Series Details == Series: Geminilake enabling (rev5) URL : https://patchwork.freedesktop.org/series/15118/ State : success == Summary == Series 15118v5 Geminilake enabling https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/5/mbox/ fi-bdw-5557u total:244 pass:229

  1   2   3   >