[Intel-gfx] ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev5)

== Series Details == Series: Link Training failure handling by sending Hotplug Uevent (rev5) URL : https://patchwork.freedesktop.org/series/16399/ State : failure == Summary == Series 16399v5 Link Training failure handling by sending Hotplug Uevent

[Intel-gfx] [PATCH v7 3/4] 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 and limits the max link_rate and lane_count values to these

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add Automation Support for DP Compliance Testing (Rev 2)

== Series Details == Series: Add Automation Support for DP Compliance Testing (Rev 2) URL : https://patchwork.freedesktop.org/series/16591/ State : failure == Summary == Series 16591v1 Add Automation Support for DP Compliance Testing (Rev 2)

[Intel-gfx] [PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests

The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color

[Intel-gfx] [PATCH 0/5] Add Automation Support for DP Compliance Testing (Rev 2)

This addresses all the review comments from the earlier patch series: https://patchwork.freedesktop.org/series/15771/ DP 1.2 compliance testing can be acheived using DPR-120's CTS suite. This compliance unit sends a short pulse to initiate link training and video pattern generation compliance

[Intel-gfx] [PATCH 4/5] drm: Add definitions for DP compliance Video pattern tests

v2: * Add all the other DP Complianec TEST register defs (Jani Nikula) Cc: dri-de...@lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH 1/5] drm/i915: Move all the DP compliance data to a separate struct

This patch does not change anything functionally, just cleans up the DP compliance related variables and stores them all together in a separate struct intel_dp_compliance. There is another struct intel_dp_compliance_data to store all the test data. This makes it easy to reset the compliance

[Intel-gfx] [PATCH 2/5] drm/i915: Add support for DP link training compliance

This patch adds support to handle automated DP compliance link training test requests. This patch has been tested with Unigraf DPR-120 DP Compliance device for testing Link Training Compliance. After we get a short pulse Compliance test request, test request values are read and hotplug uevent is

[Intel-gfx] [PATCH 3/5] drm/i915: Fixes to support DP Compliance EDID tests

This patch addresses a few issues from the original patch for DP Compliance EDID test support submitted by Todd Previte Video Mode requested in the EDID test handler for the EDID Read test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec. Signed-off-by: Manasi

Re: [Intel-gfx] [PATCH v7 7/8] drm/i915: Decode system memory bandwidth

Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: > This patch adds support to decode system memory bandwidth > which will be used for arbitrated display memory percentage > calculation in GEN9 based system. > > Changes from v1: >  - Address comments from Paulo >  - implement decode

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote: > From: Peter Antoine > > This patch will allow for getparams to return the status of the HuC. > As the HuC has to be validated by the GuC this patch uses the validated > status to show when the HuC is loaded and

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

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/16584/ State : success == Summary == Series 16584v1 HuC Loading Patches https://patchwork.freedesktop.org/api/1.0/series/16584/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

From: Peter Antoine Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. v8: rebased. v9: rebased. v10: rebased. v11: rebased on top of drm-tip v12: rebased. Tested-by: Xiang Haihao

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

From: Anusha Srivatsa 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.

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

From: Anusha Srivatsa This patch adds the HuC Loading for the BXT by using the updated file construction. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased on top of drm-tip v4: rebased. Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

From: Peter Antoine This patch will allow for getparams to return the status of the HuC. As the HuC has to be validated by the GuC this patch uses the validated status to show when the HuC is loaded and ready for use. You cannot use the loaded status as with the GuC as

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

From: Peter Antoine Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

From: Peter Antoine HuC firmware css header has almost exactly same definition as GuC firmware except for the sw_version. Also, add a new member fw_type into intel_uc_fw to indicate what kind of fw it is. So, the loader will pull right sw_version from header. v2:

[Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

From: Peter Antoine The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

[Intel-gfx] [PATCH 0/8]HuC Loading Patches

These patches add HuC loading support. The GuC is required to authenticate the HuC. The userspace patches that check for a fully loaded HuC firmware and use it can be found at: https://lists.freedesktop.org/archives/libva/2016-September/004554.html

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

From: Anusha Srivatsa This patch adds the support to load HuC on KBL Version 2.0 v2: rebased. v3: rebased on top of drm-tip v4: rebased. Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa Reviewed-by: Jeff McGee

Re: [Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.

Hi Daniel, On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote: > > Atomic drivers may set properties like rotation on the same fb, which > > may require a call to prepare_fb even when framebuffer stays identical. > > > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Test all fw tables during mock selftests

On Thu, Dec 08, 2016 at 04:52:24PM +, Tvrtko Ursulin wrote: > Idea for another late test: > > for (offset = 0; offset < 0x4; offset++) { > fw_domain = intel_uncore_forcewake_for_reg(dev_priv, { .reg = > offset }, FW_REG_READ | FW_REG_WRITE); > if (WARN_ON(fw_domain &

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

On Thu, Dec 08, 2016 at 11:51:30PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > 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

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

On Thu, Dec 08, 2016 at 11:46:02PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > 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

Re: [Intel-gfx] [PATCH] dim: Update docs for update-branches

On Thu, 08 Dec 2016, Daniel Vetter wrote: > It's been years since drm-intel had only one maintainer, and the > primary use-case for dim ub was only to sync between machines. Update > the docs to reflect this, to avoid misleading committers. Also update > the

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

On Tue, 06 Dec 2016, Manasi Navare wrote: > 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

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

On Tue, 06 Dec 2016, Manasi Navare wrote: > 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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

Daniel, can we merge this patch? It has no dependency on other link train patches, it is just a clean up for the existing driver code that uses max link rate and lane count values. Other link train patches have dependency on this thats why it was part of the series. But it would be great if this

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

On Thu, Dec 08, 2016 at 11:23:39PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > Sink's capabilities are advertised through DPCD registers and get > > updated only on hotplug. So they should be computed only once in the > > long pulse handler

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

On Tue, 06 Dec 2016, Manasi Navare wrote: > Sink's capabilities are advertised through DPCD registers and get > updated only on hotplug. So they should be computed only once in the > long pulse handler and saved off in intel_dp structure for the use > later. For this

Re: [Intel-gfx] [PATCH 05/16] drm/i915: Add unit tests for the breadcrumb rbtree, wakeups

On Thu, Dec 08, 2016 at 05:38:34PM +, Tvrtko Ursulin wrote: > > On 07/12/2016 13:58, Chris Wilson wrote: > >Third retroactive test, make sure that the seqno waiters are woken. > > > >Signed-off-by: Chris Wilson > >--- > > drivers/gpu/drm/i915/intel_breadcrumbs.c |

Re: [Intel-gfx] [PATCH 1/2] drm/i915: split off Pineview desktop and mobile device info

On Thu, 08 Dec 2016, Ville Syrjälä wrote: > On Thu, Dec 08, 2016 at 04:58:21PM +0100, Daniel Vetter wrote: >> On Thu, Dec 08, 2016 at 11:11:50AM +0200, Jani Nikula wrote: >> > On Thu, 08 Dec 2016, Jani Nikula wrote: >> > > On Thu, 08 Dec

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification

On Mon, 2016-12-05 at 18:59 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v6,1/2] drm/i915/gen9: Fix PCODE polling during > CDCLK change notification > URL   : https://patchwork.freedesktop.org/series/16375/ > State : success > > == Summary == > > Series

Re: [Intel-gfx] [PATCH 07/16] drm/i915: Move intel_lrc_context_pin() to avoid the forward declaration

On Thu, Dec 08, 2016 at 05:45:23PM +, Tvrtko Ursulin wrote: > > On 07/12/2016 13:58, Chris Wilson wrote: > >Just a simple move to avoid a forward declaration. > > Patch subject is wrong - you are moving > intel_logical_ring_alloc_request_extras. I moved what I said, what diff shows is the

[Intel-gfx] ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev4)

== Series Details == Series: Link Training failure handling by sending Hotplug Uevent (rev4) URL : https://patchwork.freedesktop.org/series/16399/ State : failure == Summary == Series 16399v4 Link Training failure handling by sending Hotplug Uevent

[Intel-gfx] ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev3)

== Series Details == Series: Link Training failure handling by sending Hotplug Uevent (rev3) URL : https://patchwork.freedesktop.org/series/16399/ State : failure == Summary == Series 16399v3 Link Training failure handling by sending Hotplug Uevent

Re: [Intel-gfx] [PATCH v5 1/4] drm: Add a new connector atomic property for link status

Thanks Sean. Done, fixed the typo and submitted the patch. Regards Manasi On Thu, Dec 08, 2016 at 02:36:25PM -0500, Sean Paul wrote: > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > > index 72fa5b2..34eddb9 100644 > > --- a/drivers/gpu/drm/drm_atomic.c > > +++

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

At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the

Re: [Intel-gfx] [PATCH v5 1/4] drm: Add a new connector atomic property for link status

> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 72fa5b2..34eddb9 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1087,6 +1087,22 @@ int drm_atomic_connector_set_property(struct > drm_connector *connector, >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: report psr2 status from psr2_ctl

== Series Details == Series: drm/i915/psr: report psr2 status from psr2_ctl URL : https://patchwork.freedesktop.org/series/16577/ State : success == Summary == Series 16577v1 drm/i915/psr: report psr2 status from psr2_ctl

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

At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the

[Intel-gfx] [PATCH] drm/i915/psr: report psr2 status from psr2_ctl

Reads psr2 enable status from EDP_PSR2_CTL Cc: Rodrigo Vivi Signed-off-by: vathsala nagaraju --- drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

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

Hi Jani, Could you please review this patch? This patch was changed a bit from the last time you reviewed it based on feedback from Sean Paul that the driver need not validate the modes and prune the mode on link training failure. Instead it should just send the hotplug uevent after setting link

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

Hi Jani, This patch uses the simplified fallback logic where if link train fails, we first lower the max sink link rate to a lower value until it reaches RBR keeping the max lane count unchanged and then lower the lane count and set max lane count to this lowered lane count and resetting the link

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

Jani, Could you please review this patch? This is the patch that calculates the max sink link rate and max sink lane count only once at hotplug and then anytime the max lane count and common rates are requested, the helper functions use these values. This simplifies the fallback logic since we

[Intel-gfx] [PATCH] dim: Update docs for update-branches

It's been years since drm-intel had only one maintainer, and the primary use-case for dim ub was only to sync between machines. Update the docs to reflect this, to avoid misleading committers. Also update the maintainer-tools branch, which is something Paulo's script also does. Motivated because

Re: [Intel-gfx] [PATCH] drm/i915: Do not reset detect_done flag in intel_dp_detect

On Thu, Dec 08, 2016 at 05:58:44PM +0200, Ville Syrjälä wrote: > On Wed, Dec 07, 2016 at 07:51:21PM -0800, Manasi Navare wrote: > > Ville, > > You mentioned that this detect_done should be set to false also > > in the resume case so in i915_display_resume where it calls > > intel_hpd_init that

Re: [Intel-gfx] [PATCH 07/16] drm/i915: Move intel_lrc_context_pin() to avoid the forward declaration

On 07/12/2016 13:58, Chris Wilson wrote: Just a simple move to avoid a forward declaration. Patch subject is wrong - you are moving intel_logical_ring_alloc_request_extras. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 132

Re: [Intel-gfx] [PATCH 06/16] drm/i915: Add a reminder that i915_vma_move_to_active() requires struct_mutex

On 07/12/2016 13:58, Chris Wilson wrote: i915_vma_move_to_active() requires the struct_mutex for serialisation with retirement, so mark it up with lockdep_assert_held(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 + 1 file

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Don't clflush before release phys object

On Thu, 2016-12-08 at 19:22 +0200, Saarinen, Jani wrote: > > == Series Details == > > > > Series: drm/i915: Don't clflush before release phys object > > URL   : https://patchwork.freedesktop.org/series/16569/ > > State : warning > > > > == Summary == > > > > Series 16569v1 drm/i915: Don't

Re: [Intel-gfx] [PATCH 05/16] drm/i915: Add unit tests for the breadcrumb rbtree, wakeups

On 07/12/2016 13:58, Chris Wilson wrote: Third retroactive test, make sure that the seqno waiters are woken. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 171 +++ 1 file changed, 171 insertions(+) diff --git

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Don't clflush before release phys object

> == Series Details == > > Series: drm/i915: Don't clflush before release phys object > URL : https://patchwork.freedesktop.org/series/16569/ > State : warning > > == Summary == > > Series 16569v1 drm/i915: Don't clflush before release phys object >

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Don't clflush before release phys object

== Series Details == Series: drm/i915: Don't clflush before release phys object URL : https://patchwork.freedesktop.org/series/16569/ State : warning == Summary == Series 16569v1 drm/i915: Don't clflush before release phys object

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Test all fw tables during mock selftests

On 07/12/2016 18:52, Chris Wilson wrote: In addition to just testing the fw table we load, during the initial mock testing we can test that all tables are valid (so the testing is not limited to just the platforms that load that particular table). Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/2] drm/i915: split off Pineview desktop and mobile device info

On Thu, Dec 08, 2016 at 04:58:21PM +0100, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 11:11:50AM +0200, Jani Nikula wrote: > > On Thu, 08 Dec 2016, Jani Nikula wrote: > > > On Thu, 08 Dec 2016, Jani Nikula wrote: > > >> This lets us use

Re: [Intel-gfx] [PATCH 08/11] drm/i915: Reorganize overlay filter coeffs into a nicer form

On Thu, Dec 08, 2016 at 06:17:28PM +0200, Ville Syrjälä wrote: > On Thu, Dec 08, 2016 at 08:45:31AM +, Chris Wilson wrote: > > On Wed, Dec 07, 2016 at 07:28:10PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > Use

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reorder phys backing storage release (rev3)

== Series Details == Series: drm/i915: Reorder phys backing storage release (rev3) URL : https://patchwork.freedesktop.org/series/16468/ State : success == Summary == Series 16468v3 drm/i915: Reorder phys backing storage release

Re: [Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC

On Thu, Dec 08, 2016 at 04:12:37PM +, Zanoni, Paulo R wrote: > Em Qui, 2016-12-08 às 17:00 +0100, Daniel Vetter escreveu: > > On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote: > > > > > > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: > > > > > > > > This series

Re: [Intel-gfx] [PATCH 08/11] drm/i915: Reorganize overlay filter coeffs into a nicer form

On Thu, Dec 08, 2016 at 08:45:31AM +, Chris Wilson wrote: > On Wed, Dec 07, 2016 at 07:28:10PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Use two-dimensional arrays and named initializers to make the > > overlay filter

Re: [Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC

Em Qui, 2016-12-08 às 17:00 +0100, Daniel Vetter escreveu: > On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote: > > > > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: > > > > > > This series implements following set of functionality > > > Implement IPC WA's for

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Use pipe_src_w in overlay code

On Thu, Dec 08, 2016 at 08:35:48AM +, Chris Wilson wrote: > On Wed, Dec 07, 2016 at 07:28:07PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Replace the use of crtc->mode.h/vdisplay with the more appropriate > >

[Intel-gfx] [PATCH] drm/i915: Don't clflush before release phys object

When we teardown the backing storage for the phys object, we copy from the coherent contiguous block back to the shmemfs object, clflushing as we go. Trying to clflush the invalid sg beforehand just oops and would be redundant (due to it already being coherent, and clflushed afterwards).

Re: [Intel-gfx] [PATCH] drm/i915: Respect ring_mask and num_pipes when install IRQ

On Thu, Dec 08, 2016 at 06:46:49PM +0800, Wang Elaine wrote: > From: Elaine Wang > > Some platforms only have VCS ring in VDBox. To avoid accessing the > non-existent rings or display registers, check the ring_mask > and num_pipes in gen8 IRQ install and reset functions. >

Re: [Intel-gfx] [PATCH 02/16] kselftests: Exercise hw-independent mock tests for i915.ko

On Thu, Dec 08, 2016 at 08:50:17AM -0700, Shuah Khan wrote: > On 12/07/2016 07:09 AM, Chris Wilson wrote: > > On Wed, Dec 07, 2016 at 01:58:19PM +, Chris Wilson wrote: > >> Although being a GPU driver most functionality of i915.ko depends upon > >> real hardware, many of its internal

Re: [Intel-gfx] [PATCH i-g-t] igt_kms: Remove support for drivers with <1 drm_plane

On Wed, Dec 07, 2016 at 07:16:13PM -0500, Lyude wrote: > We've had support for universal planes since kernel version 3.15, so > there's not really a good reason to try supporting drivers that lack > plane support now. As well, the current has_universal_planes logic is > broken anyway as it makes

Re: [Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC

On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote: > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: > > This series implements following set of functionality > > Implement IPC WA's for Broxton/KBL > > Enable IPC in supported platforms > > Convert WM calculation to

Re: [Intel-gfx] [PATCH] drm/i915: Do not reset detect_done flag in intel_dp_detect

On Wed, Dec 07, 2016 at 07:51:21PM -0800, Manasi Navare wrote: > Ville, > You mentioned that this detect_done should be set to false also > in the resume case so in i915_display_resume where it calls > intel_hpd_init that eventually schedules the hpd_poll_init_work and > calls

Re: [Intel-gfx] [PATCH 1/2] drm/i915: split off Pineview desktop and mobile device info

On Thu, Dec 08, 2016 at 11:11:50AM +0200, Jani Nikula wrote: > On Thu, 08 Dec 2016, Jani Nikula wrote: > > On Thu, 08 Dec 2016, Jani Nikula wrote: > >> This lets us use IS_MOBILE() for distinguishing the desktop and mobile > >> parts instead of

Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

On Wed, Dec 07, 2016 at 09:40:33PM +, Robert Bragg wrote: > This adds a 'Perf' section to i915.rst with the following sub sections: > - Overview > - Comparison with Core Perf > - i915 Driver Entry Points > - i915 Perf Stream > - i915 Perf Observation Architecture Stream > - All i915 Perf

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Remove drm_atomic_helper_framebuffer_changed

== Series Details == Series: drm/atomic: Remove drm_atomic_helper_framebuffer_changed URL : https://patchwork.freedesktop.org/series/16561/ State : success == Summary == Series 16561v1 drm/atomic: Remove drm_atomic_helper_framebuffer_changed

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Don't print an error if the checksum of a CEA block is wrong

> == Series Details == > > Series: drm/edid: Don't print an error if the checksum of a CEA block is wrong > URL : https://patchwork.freedesktop.org/series/16556/ > State : warning > > == Summary == > > Series 16556v1 drm/edid: Don't print an error if the checksum of a CEA block > is > wrong

Re: [Intel-gfx] [PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.

On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote: > The current api doesn't take into account that whenever properties like > rotation or z-pos change we have to wait for vblank. To make sure > that we wait correctly, err on the side of caution and wait whenever > a plane is added

Re: [Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.

On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote: > Atomic drivers may set properties like rotation on the same fb, which > may require a call to prepare_fb even when framebuffer stays identical. > > Instead of handling all the special cases in the core, let the driver > decide

Re: [Intel-gfx] [PATCH 3/6] drm/atomic: Clean up wait_for_vblanks

On Thu, Dec 08, 2016 at 02:45:26PM +0100, Maarten Lankhorst wrote: > Stop relying on a per crtc_state last_vblank_count, we know in advance > how many there can be. Also stop re-using new_crtc_state->enable, > we can now simply set a bitmask with crtc_crtc_mask. > --- >

Re: [Intel-gfx] [PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.

On Thu, Dec 08, 2016 at 02:45:24PM +0100, Maarten Lankhorst wrote: > When DPMS was introduced to atomic, vblanks only worked when the crtc > was enabled and active. wait_for_vblanks were not converted to check for > crtc_state->active, which may cause an attempt for vblank_get to fail. > > This

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

On Mon, Dec 05, 2016 at 12:42:11PM -0800, Srivatsa, Anusha wrote: > > > >-Original Message- > >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] > >Sent: Thursday, December 1, 2016 5:11 AM > >To: Srivatsa, Anusha ; intel- >

Re: [Intel-gfx] [PATCH v4 1/4] drm: Add a new connector atomic property for link status

On Thu, Dec 08, 2016 at 05:05:54PM +0200, Jani Nikula wrote: > On Tue, 06 Dec 2016, Manasi Navare wrote: > > At the time userspace does setcrtc, we've already promised the mode > > would work. The promise is based on the theoretical capabilities of > > the link, but

[Intel-gfx] ✗ Fi.CI.BAT: warning for Claw back the IS_ optimisation (rev2)

== Series Details == Series: Claw back the IS_ optimisation (rev2) URL : https://patchwork.freedesktop.org/series/16544/ State : warning == Summary == Series 16544v2 Claw back the IS_ optimisation https://patchwork.freedesktop.org/api/1.0/series/16544/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH v4 1/4] drm: Add a new connector atomic property for link status

On Tue, 06 Dec 2016, Manasi Navare wrote: > At the time userspace does setcrtc, we've already promised the mode > would work. The promise is based on the theoretical capabilities of > the link, but it's possible we can't reach this in practice. The DP > spec describes

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Don't print an error if the checksum of a CEA block is wrong

== Series Details == Series: drm/edid: Don't print an error if the checksum of a CEA block is wrong URL : https://patchwork.freedesktop.org/series/16556/ State : warning == Summary == Series 16556v1 drm/edid: Don't print an error if the checksum of a CEA block is wrong

[Intel-gfx] [CI] drm/i915: Reorder phys backing storage release

In commit a4f5ea64f0a8 ("drm/i915: Refactor object page API"), I reordered the object->pages teardown to be more friendly wrt to a separate obj->mm.lock. However, I overlooked the phys object and left it with a dangling use-after-free of its phys_handle. Move the allocation of the phys handle to

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification

On Thu, Dec 08, 2016 at 04:18:50PM +0200, Imre Deak wrote: > Yep. Btw, I also pondered if we could just make this part of > wait_for(), but not sure if we want the corresponding code increase > (and for -stable we'd want a minimal diff). It's not required in other > cases, although it could speed

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Kill the 830 MI_OVERLAY_OFF workaround

Hi Ville, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20161208] [cannot apply to v4.9-rc8] [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/ville

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification

On to, 2016-12-08 at 14:02 +, Chris Wilson wrote: > On Mon, Dec 05, 2016 at 06:27:37PM +0200, Imre Deak wrote: > > commit 848496e5902833600f7992f4faa82dc1546051ba > > Author: Ville Syrjälä > > Date:   Wed Jul 13 16:32:03 2016 +0300 > > > > drm/i915: Wait up

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Respect ring_mask and num_pipes when install IRQ

== Series Details == Series: drm/i915: Respect ring_mask and num_pipes when install IRQ URL : https://patchwork.freedesktop.org/series/16547/ State : success == Summary == Series 16547v1 drm/i915: Respect ring_mask and num_pipes when install IRQ

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros

On 08/12/2016 14:00, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: On 08/12/2016 13:37, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: On 08/12/2016 10:46, Jani Nikula wrote: On Thu, 08 Dec

Re: [Intel-gfx] [PATCH] drm: Take ownership of the dmabuf->obj when exporting

On Thu, Dec 08, 2016 at 03:03:29PM +0200, Joonas Lahtinen wrote: > On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote: > > Currently the reference for the dmabuf->obj is incremented for the > > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace > > interface), but is released in

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.

On 8 December 2016 at 13:45, Maarten Lankhorst wrote: > Do something similar to vc4, only allow updating the cursor state > in-place through a fastpath when the watermarks are unaffected. This > will allow cursor movement to be smooth, but changing cursor size

Re: [Intel-gfx] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

On Thu, Dec 08, 2016 at 11:57:25AM +, Robert Bragg wrote: > On Thu, Dec 8, 2016 at 12:17 AM, Daniel Vetter wrote: > > > > On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote: > > > This is still missing corresponding documentation changes, and I haven't > > > moved

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification

On Mon, Dec 05, 2016 at 06:27:37PM +0200, Imre Deak wrote: > commit 848496e5902833600f7992f4faa82dc1546051ba > Author: Ville Syrjälä > Date: Wed Jul 13 16:32:03 2016 +0300 > > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on > SKL > >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros

On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: > On 08/12/2016 13:37, Jani Nikula wrote: >> On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: >>> On 08/12/2016 10:46, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin

[Intel-gfx] [PATCH 5/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed.

This function is now completely unused, zap it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 35 --- include/drm/drm_atomic_helper.h | 3 --- 2 files changed, 38 deletions(-) diff --git

[Intel-gfx] [PATCH 0/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed

drm_atomic_helpers use framebuffer_changed to skip some vblank waits in case properties don't change. This may skip vblank waits also when properties like rotation are changed. Fix this by always waiting for vblank if planes are added to the state, and always calling prepare_fb even when fb stays

[Intel-gfx] [PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.

The current api doesn't take into account that whenever properties like rotation or z-pos change we have to wait for vblank. To make sure that we wait correctly, err on the side of caution and wait whenever a plane is added to state. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH 3/6] drm/atomic: Clean up wait_for_vblanks

Stop relying on a per crtc_state last_vblank_count, we know in advance how many there can be. Also stop re-using new_crtc_state->enable, we can now simply set a bitmask with crtc_crtc_mask. --- drivers/gpu/drm/drm_atomic_helper.c | 29 +++-- include/drm/drm_crtc.h

[Intel-gfx] [PATCH 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.

Do something similar to vc4, only allow updating the cursor state in-place through a fastpath when the watermarks are unaffected. This will allow cursor movement to be smooth, but changing cursor size or showing/hiding cursor will still fall back so watermarks can be updated. Only moving and

[Intel-gfx] [PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.

When DPMS was introduced to atomic, vblanks only worked when the crtc was enabled and active. wait_for_vblanks were not converted to check for crtc_state->active, which may cause an attempt for vblank_get to fail. This is probably harmless, but convert from enable to active anyway.

[Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.

Atomic drivers may set properties like rotation on the same fb, which may require a call to prepare_fb even when framebuffer stays identical. Instead of handling all the special cases in the core, let the driver decide when prepare_fb and cleanup_fb are noops. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros

On 08/12/2016 13:37, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: On 08/12/2016 10:46, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of listing

  1   2   >