Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On 2017.03.23 14:43:44 +0100, Frans Klaver wrote: > On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > > From: Colin Ian King > > > > info is being checked to see if it is a null pointer, however, vpgu is > > dereferencing info before this

Re: [Intel-gfx] [PATCH] drm: Make the decision to keep vblank irq enabled earlier

On 03/23/2017 02:26 PM, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote: We want to provide the vblank irq shadow for pageflip events as well as vblank queries. Such events are completed within the vblank interrupt handler, and so the current check for

Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On 2017.03.23 16:11:00 +0200, Joonas Lahtinen wrote: > Dropping the irrelevant Cc's. > > On to, 2017-03-23 at 12:39 +, Chris Wilson wrote: > > On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote: > > > > > > From: Colin Ian King > > > > > > info is being

[Intel-gfx] [PATCH v4] drm/i915/scheduler: add gvt notification for guc submission

GVT request needs a manual mmio load/restore. Before GuC submit a request, send notification to gvt for mmio loading. And after the GuC finished this GVT request, notify gvt again for mmio restore. This follows the usage when using execlists submission. v2: use context_status_change instead of

[Intel-gfx] [PATCH v2] drm/i915: Add 'render basic' Gen8+ OA unit configs

Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic render metrics on Broadwell, Cherryview, Skylake and Broxton. These are auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml >

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs

On Fri, Mar 24, 2017 at 12:52 AM, Robert Bragg wrote: > On Thu, Mar 23, 2017 at 8:48 PM, Matthew Auld > wrote: >> On 23 March 2017 at 20:18, Robert Bragg wrote: >>> Adds a static OA unit, MUX, B Counter + Flex EU

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs

On Thu, Mar 23, 2017 at 8:48 PM, Matthew Auld wrote: > On 23 March 2017 at 20:18, Robert Bragg wrote: >> Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic >> render metrics on Broadwell, Cherryview, Skylake and Broxton.

[Intel-gfx] [PATCH v2] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters

From: Clint Taylor Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane signal if the Data Link N is greater than 0x8. Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum value 20 bit instead of the maximum

Re: [Intel-gfx] [PATCH v4 03/13] drm/i915/guc: Add onion teardown to the GuC setup

On 03/23/2017 03:57 PM, Chris Wilson wrote: On Wed, Mar 22, 2017 at 10:39:46AM -0700, Oscar Mateo wrote: Starting with intel_guc_loader, down to intel_guc_submission and finally to intel_guc_log. v2: - Null execbuf client outside guc_client_free (Daniele) - Assert if things try to get

[Intel-gfx] [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining

Currently intel_dp_check_link_status() tries to retrain the link if Clock recovery or Channel EQ for any of the lanes indicated by intel_dp->lane_count is not set. However these values cached in intel_dp structure can be stale if link training has failed for these values during previous modeset.

[Intel-gfx] [PATCH] drm/i915/guc: Refactor the retrieval of guc_process_desc

Move the common "client->vaddr + client->proc_desc_offset" to its own function, __get_process_desc() to match the newly established pattern. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_guc_submission.c | 24 +++- 1 file changed, 11

Re: [Intel-gfx] [PATCH v4 03/13] drm/i915/guc: Add onion teardown to the GuC setup

On Wed, Mar 22, 2017 at 10:39:46AM -0700, Oscar Mateo wrote: > Starting with intel_guc_loader, down to intel_guc_submission > and finally to intel_guc_log. > > v2: > - Null execbuf client outside guc_client_free (Daniele) > - Assert if things try to get allocated twice (Daniele/Joonas) > -

Re: [Intel-gfx] [PATCH I-G-T 4/4] tests/kms_fbcon_fbt: Refactor to use IGT PSR library functions

On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote: > Cc: Rodrigo Vivi > Cc: Paulo Zanoni > Signed-off-by: Jim Bride > --- > tests/kms_fbcon_fbt.c | 47 +++ > 1 file

Re: [Intel-gfx] [PATCH I-G-T 3/4] tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library functions

Reviewed-by: Rodrigo Vivi On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote: > Cc: Rodrigo Vivi > Cc: Paulo Zanoni > Signed-off-by: Jim Bride > --- > tests/kms_frontbuffer_tracking.c | 47 >

Re: [Intel-gfx] [PATCH I-G-T 2/4] tests/kms_psr_sink_crc: Refactor to use new PSR library primitives

On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote: > Cc: Rodrigo Vivi > Signed-off-by: Jim Bride > --- > tests/kms_psr_sink_crc.c | 53 > ++-- > 1 file changed, 11 insertions(+), 42 deletions(-) >

Re: [Intel-gfx] [PATCH I-G-T 1/4] lib: Add PSR utility functions to igt library.

On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote: > Factor out some code that was replicated in three test utilities into > some new IGT library functions so that we are checking PSR status in > a consistent fashion across all of our PSR tests. > > Cc: Rodrigo Vivi >

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)

On Thu, Mar 23, 2017 at 04:51:54PM +, Tvrtko Ursulin wrote: > > On 23/03/2017 13:48, Chris Wilson wrote: > >We only need to care about the ordering of the clearing of the bit with > >the uncached CSB read in order to correctly detect a new interrupt > >before the read completes. The uncached

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Various improvements around the GuC topic

On 03/23/2017 06:20 AM, Joonas Lahtinen wrote: Merged this series except the HAX patch (also, reordered the S-o-b, R-b and Cc lines to canonical form), so do rebase your work. Regards, Joonas Thanks! On to, 2017-03-23 at 11:06 +, Patchwork wrote: == Series Details == Series: Various

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Nuke ironlake_plane_ctl()

On Thu, Mar 23, 2017 at 09:27:08PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Share the code to compute the primary plane control register value > between the i9xx and ilk codepaths as the differences are minimal. > Actually there are no

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl()

On Thu, Mar 23, 2017 at 09:27:07PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Pull the code to calculate the pre-SKL primary plane control register > value into separate functions. Allows us to pre-compute it in the > future. > > v2:

Re: [Intel-gfx] Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8

On 03/23/2017 03:44 PM, Chris Wilson wrote: On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote: Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered intermittent hangs with the following information in the logs: linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce,

[Intel-gfx] [PATCH dim 2/2] dim: Curate and insert tags into patch(es)

Launch $EDITOR when extracting tags to curate the tags immediately. Once the tags are proper, automatically add them before the first Signed-off-by line to all patches in the range. Signed-off-by: Sean Paul --- dim | 13 ++--- 1 file changed, 10 insertions(+), 3

[Intel-gfx] [PATCH dim 1/2] dim: Add support for multiple messages in extract-tags

Make extract-tags process tags from all messages in the supplied mbox. This allows the user to tag multiple replies and extract all tags at once. Signed-off-by: Sean Paul --- dim | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/dim b/dim

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs

On 23 March 2017 at 20:18, Robert Bragg wrote: > Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic > render metrics on Broadwell, Cherryview, Skylake and Broxton. These are > auto generated from an XML description of metric sets, currently > maintained

Re: [Intel-gfx] Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8

On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote: > Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered > intermittent hangs with the following information in the logs: > > linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in > plasmashell [1283], reason: Hang

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: expose _SUBSLICE_MASK GETPARM

On 23 March 2017 at 20:18, Robert Bragg wrote: > Assuming a uniform mask across all slices, this enables userspace to > determine the specific sub slices enabled. This information is required, > for example, to be able to analyse some OA counter reports where the > counter

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915: expose _SLICE_MASK GETPARM

On 23 March 2017 at 20:18, Robert Bragg wrote: > Enables userspace to determine the number of slices enabled and also > know what specific slices are enabled. This information is required, for > example, to be able to analyse some OA counter reports where the counter >

[Intel-gfx] [PATCH v2 4/5] drm/i915: Add OA unit support for Gen 8+

Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all share (more-or-less) the same OA unit design. Of particular note in comparison to Haswell: some OA unit HW config state has become per-context state and as a consequence it is somewhat more complicated to manage synchronous

[Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs

Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic render metrics on Broadwell, Cherryview, Skylake and Broxton. These are auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml >

[Intel-gfx] [PATCH v2 2/5] drm/i915: expose _SUBSLICE_MASK GETPARM

Assuming a uniform mask across all slices, this enables userspace to determine the specific sub slices enabled. This information is required, for example, to be able to analyse some OA counter reports where the counter configuration depends on the HW sub slice configuration. Signed-off-by: Robert

[Intel-gfx] [PATCH v2 1/5] drm/i915: expose _SLICE_MASK GETPARM

Enables userspace to determine the number of slices enabled and also know what specific slices are enabled. This information is required, for example, to be able to analyse some OA counter reports where the counter configuration depends on the HW slice configuration. Signed-off-by: Robert Bragg

[Intel-gfx] [PATCH v2 0/5] Enable OA unit for Gen 8 and 9 in i915 perf

Compared to the last Gen8+ OA series I've been investigating and debugging a number of issues with the configuration of the Flexible EU counters whose state is per-context: * Removes assumption about the mmio registers having a contiguous range of addresses which wasn't true. * Ensures that

[Intel-gfx] [PATCH 6/6] drm/i915: Use i9xx_check_plane_surface() for sprite planes as well

From: Ville Syrjälä All the pre-SKL sprite planes compute the x/y/tile offsets in a similar way. There are a couple of minor differences but the primary planes have those as well. Thus i9xx_check_plane_surface() already does what we need, so let's use it.

[Intel-gfx] [PATCH v2 4/6] drm/i915: Introduce i9xx_check_plane_surface()

From: Ville Syrjälä Extract the primary plane surfae offset/x/y calculations for pre-SKL platforms into a common function, and call it during the atomic check phase to reduce the amount of stuff we have to do during the commit phase. SKL is already doing this. v2:

[Intel-gfx] [PATCH 3/6] drm/i915: Pre-compute plane control register value

From: Ville Syrjälä Computing the plane control register value is branchy so moving it out from the plane commit hook seems prudent. Let's pre-compute it during the atomic check phase and store the result in the plane state. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 5/6] drm/i915: Eliminate ironlake_update_primary_plane()

From: Ville Syrjälä The effective difference between i9xx_update_primary_plane() and ironlake_update_primary_plane() is only the HSW/BDW DSPOFFSET special case. So bring that over into i9xx_update_primary_plane() and eliminate the duplicated code. Signed-off-by:

[Intel-gfx] [PATCH 2/6] drm/i915: Nuke ironlake_plane_ctl()

From: Ville Syrjälä Share the code to compute the primary plane control register value between the i9xx and ilk codepaths as the differences are minimal. Actually there are no differences between g4x and ilk, so the current split doesn't really make any sense. Cc:

[Intel-gfx] [PATCH v2 0/6] drm/i915: Moar plane update optimizations (v2)

From: Ville Syrjälä Here are the easy leftovers from the previous series. I left out the more experimental parts (single lock/unlock, posting read elimination) for now. I'll have to revisit those after we get this stuff in. This time I even took the precaution of

[Intel-gfx] [PATCH v2 1/6] drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl()

From: Ville Syrjälä Pull the code to calculate the pre-SKL primary plane control register value into separate functions. Allows us to pre-compute it in the future. v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris) Cc: Chris Wilson

[Intel-gfx] [PATCH v2] drm/i915/perf: rate limit spurious oa report notice

This change is pre-emptively aiming to avoid a potential cause of kernel logging noise in case some condition were to result in us seeing invalid OA reports. The workaround for the OA unit's tail pointer race condition is what avoids the primary know cause of invalid reports being seen and with

[Intel-gfx] [PATCH] drm/i915: Replace literal tabs in ns2501 debug messages with spaces

From: Ville Syrjälä Literal tabs in printk() come out as garbage. Let's just use spaces. Cc: Thomas Richter Fixes: 14f1fa2d0c86 ("drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010") Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters

On Thu, 2017-03-23 at 10:59 -0700, Clint Taylor wrote: > On 03/23/2017 10:23 AM, Jani Nikula wrote: > > On Thu, 23 Mar 2017, Clint Taylor wrote: > >> On 03/23/2017 05:30 AM, Jani Nikula wrote: > >>> On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote: > From:

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 18:14, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 17:42, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:43,

[Intel-gfx] Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8

Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered intermittent hangs with the following information in the logs: linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in plasmashell [1283], reason: Hang on render ring, action: reset linux-4v1g.suse kernel: [drm] GPU hangs

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: > Hi Ville, > > > On 23-03-2017 17:42, Ville Syrjälä wrote: > > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:43, Sharma, Shashank wrote: > >>> Regards > >>> > >>> Shashank

Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters

On 03/23/2017 10:23 AM, Jani Nikula wrote: On Thu, 23 Mar 2017, Clint Taylor wrote: On 03/23/2017 05:30 AM, Jani Nikula wrote: On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote: From: Clint Taylor Several major vendor USB-C->HDMI

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 17:42, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:43, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 6:33 PM, Jose Abreu wrote: Hi Shashank,

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 16:43, Sharma, Shashank wrote: > > Regards > > > > Shashank > > > > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:08, Sharma, Shashank wrote: > >>>

Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters

On Thu, 23 Mar 2017, Clint Taylor wrote: > On 03/23/2017 05:30 AM, Jani Nikula wrote: >> On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote: >>> From: Clint Taylor >>> >>> Several major vendor USB-C->HDMI converters fail to recover a 5.4

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 16:43, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:08, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville,

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 06:31:33PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:52 PM, Jose Abreu wrote: > > Hi Ville, > > > > > > On 23-03-2017 15:36, Ville Syrjälä wrote: > >> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: > >>> HDMI 1.4b

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)

On 23/03/2017 13:48, Chris Wilson wrote: We only need to care about the ordering of the clearing of the bit with the uncached CSB read in order to correctly detect a new interrupt before the read completes. The uncached read itself acts as a full memory barrier, so we do not to enforce another

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Add uncore mmio api for per-context registers

On Thu, Feb 23, 2017 at 3:35 PM, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 04:36:31PM +, Robert Bragg wrote: >> Since the exponent for periodic OA counter sampling is maintained in a >> per-context register while we want to treat it as if it were global >> state

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 6:33 PM, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: Regards Shashank On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:57 PM, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 15:45, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:28 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank wrote: On 3/23/2017 5:17 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: HDMI 1.4b support

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:52 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:36, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in

Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters

On 03/23/2017 05:30 AM, Jani Nikula wrote: On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote: From: Clint Taylor Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane signal if the Data Link N is greater than 0x8. Patch detects when 1

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/edid: Complete CEA modedb(VIC 1-107)

== Series Details == Series: series starting with [v4,1/2] drm/edid: Complete CEA modedb(VIC 1-107) URL : https://patchwork.freedesktop.org/series/21772/ State : success == Summary == Series 21772v1 Series without cover letter

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 15:14, Shashank Sharma wrote: >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >>> For any other mode, the VIC

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 15:36, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >> For any other mode, the VIC filed in AVI infoframes should be 0. >> HDMI 2.0 sinks, support

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

Hi Dave, drm-misc-fixes-2017-03-23: One fbdev regression fix from Michel Cheers, Daniel The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c: Linux 4.11-rc3 (2017-03-19 19:09:39 -0700) are available in the git repository at:

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 15:14, Shashank Sharma wrote: > > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > > For any other mode, the VIC filed in AVI infoframes should be 0. > > HDMI 2.0 sinks,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check we have an wake device before flushing GTT writes (rev2)

== Series Details == Series: drm/i915: Check we have an wake device before flushing GTT writes (rev2) URL : https://patchwork.freedesktop.org/series/20899/ State : success == Summary == Series 20899v2 drm/i915: Check we have an wake device before flushing GTT writes

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > extended

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > extended to (VIC

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank wrote: > On 3/23/2017 5:17 PM, Ilia Mirkin wrote: >> >> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma >> wrote: >>> >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:17 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec,

[Intel-gfx] [PATCH v4 1/2] drm/edid: Complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65

[Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if

[Intel-gfx] [PATCH] drm/i915: Check we have an wake device before flushing GTT writes

We can assume that if the device is asleep then all pending GTT writes will have been posted, and so we can defer the flush from i915_gem_object_flush_gtt_write_domain() [ 1957.462568] WARNING: CPU: 0 PID: 6132 at drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915] [

Re: [Intel-gfx] [PATCH v2] drm/i915: Store a direct lookup from object handle to vma

On Thu, Mar 23, 2017 at 03:23:28PM +0100, Daniel Vetter wrote: > On Wed, Mar 22, 2017 at 04:22:38PM +0200, Joonas Lahtinen wrote: > > + Daniel for the rsvd2 > > I'd go with a shadow struct definition which matches the uapi one exactly, > except for having a proper name and type for this ... Or we

Re: [Intel-gfx] [dim PATCH 7/7] dim: propagate errors from check_maintainer

On Thu, Mar 23, 2017 at 12:06:22PM +0200, Jani Nikula wrote: > Signed-off-by: Jani Nikula Ack on the entire pile. -Daniel > --- > dim | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/dim b/dim > index 7b6275e7796f..989674ab7a91 100755 >

Re: [Intel-gfx] [dim PATCH 1/7] dim: don't fail on grep not matching

On Thu, Mar 23, 2017 at 12:06:16PM +0200, Jani Nikula wrote: > Oops, the comment told us to watch out for this. > > Fixes: 56e53a49e28f ("dim: declare and assign separately") I just hacked around this with a || true :-) Ack. -Daniel > Signed-off-by: Jani Nikula > --- >

Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: SKL+ render decompression support

Hi Ville, On 21 March 2017 at 18:12, wrote: > Another iteration of the i915 CCS support. Main change is lifting the > fb dimensions hsub/vsub alignment restrictions from the core. Without that > userspace would have to align the fb size be a multiple of 8x16

Re: [Intel-gfx] [PATCH v2] drm/i915: Store a direct lookup from object handle to vma

On Wed, Mar 22, 2017 at 04:22:38PM +0200, Joonas Lahtinen wrote: > + Daniel for the rsvd2 I'd go with a shadow struct definition which matches the uapi one exactly, except for having a proper name and type for this ... Or we do the anynomous union thing again. -Daniel > > On ke, 2017-03-22 at

Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

Dropping the irrelevant Cc's. On to, 2017-03-23 at 12:39 +, Chris Wilson wrote: > On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote: > > > > From: Colin Ian King > > > > info is being checked to see if it is a null pointer, however, vpgu is > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)

== Series Details == Series: drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST) URL : https://patchwork.freedesktop.org/series/21767/ State : failure == Summary == Series 21767v1 drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)

Re: [Intel-gfx] [PATCH 00/14] drm/i915: Moar plane update optimizations

On Fri, Mar 17, 2017 at 11:17:54PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The plane updates are still taking far too long, at least with > heavy kernel debug knobs turned on. Using kms_atomic_transitions > I'm currently seeing numbers

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/15] drm/i915: Copy user requested buffers into the error state (rev4)

== Series Details == Series: series starting with [01/15] drm/i915: Copy user requested buffers into the error state (rev4) URL : https://patchwork.freedesktop.org/series/21377/ State : failure == Summary == drivers/gpu/drm/i915/i915_gem_execbuffer.c:1891:1: error: expected expression

Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification for guc submission

> -Original Message- > From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] > Sent: Thursday, March 23, 2017 5:52 PM > To: Dong, Chuanxiao; intel-gfx@lists.freedesktop.org > Cc: intel-gvt-...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt

Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification for guc submission

> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Chris Wilson > Sent: Thursday, March 23, 2017 5:43 PM > To: Joonas Lahtinen > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; > Dong, Chuanxiao >

[Intel-gfx] [PATCH] drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)

We only need to care about the ordering of the clearing of the bit with the uncached CSB read in order to correctly detect a new interrupt before the read completes. The uncached read itself acts as a full memory barrier, so we do not to enforce another in the form of a locked clear_bit.

Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification for guc submission

> -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Thursday, March 23, 2017 5:38 PM > To: Dong, Chuanxiao; intel-gfx@lists.freedesktop.org > Cc: intel-gvt-...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add

Re: [Intel-gfx] [PATCH] drm: Make the decision to keep vblank irq enabled earlier

On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote: > We want to provide the vblank irq shadow for pageflip events as well as > vblank queries. Such events are completed within the vblank interrupt > handler, and so the current check for disabling the irq will disable it > from with the

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Various improvements around the GuC topic

Merged this series except the HAX patch (also, reordered the S-o-b, R-b and Cc lines to canonical form), so do rebase your work. Regards, Joonas On to, 2017-03-23 at 11:06 +, Patchwork wrote: > == Series Details == > > Series: Various improvements around the GuC topic > URL   :

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

== Series Details == Series: drm/i915/kvmgt: avoid dereferencing a potentially null info pointer URL : https://patchwork.freedesktop.org/series/21762/ State : warning == Summary == Series 21762v1 drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

Re: [Intel-gfx] [PATCH 02/19] drm: Add acquire ctx parameter to ->update_plane

On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index 34cb73d0db77..b54fd8cbd3a6 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++

[Intel-gfx] [PATCH] drm/i915: Pass vma to relocate entry

We can simplify our tracking of pending writes in an execbuf to the single bit in the vma->exec_entry->flags, but that requires the relocation function knowing the object's vma. Pass it along. Note we have only been using a single bit to track flushing since commit

Re: [Intel-gfx] [PATCH] drm/scdc: declare drm_scdc_get_scrambling_status

On Wed, 22 Mar 2017, "Sharma, Shashank" wrote: > Thanks for this patch, Jani. > > Reviewed-by: Shashank Sharma And pushed to drm-misc-next, thanks for the review. BR, Jani. > > > Regards > Shashank > On 3/22/2017 4:33 PM, Jani Nikula

[Intel-gfx] [PATCH i-g-t v4 2/7] tests/kms_plane_multiple: Add TEST_ONLY flag

Add TEST_ONLY flag to test atomic modesetting commits without actual real-life commit. v2: Use flag to indicate to test with TEST_ONLY flag with atomic commit v3: Moved force_test_atomic flag set to 'test_plane_position()' v4: Fix typo in subject field Signed-off-by: Mika Kahola

Re: [Intel-gfx] [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On Thu, Mar 23, 2017 at 11:32:49AM +0100, Thomas Hellstrom wrote: > On 03/23/2017 11:10 AM, Daniel Vetter wrote: > > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote: > >> Hi, Daniel, > >> > >> On 03/23/2017 08:31 AM, Daniel Vetter wrote: > >>> On Thu, Mar 23, 2017 at 08:28:32AM

[Intel-gfx] [PATCH i-g-t v4 3/7] tests/kms_atomic_transition: Add TEST_ONLY flag

Add TEST_ONLY flag to test atomic transition display commits without actual real-life commit. v2: use flag to force atomic commit with TEST_ONLY flag v3: Rebase Signed-off-by: Mika Kahola --- tests/kms_atomic_transition.c | 72 +++

[Intel-gfx] [PATCH i-g-t v4 7/7] tests/kms_cursor_legacy: Add TEST_ONLY flag

Add TEST_ONLY flag to test atomic modesetting commits without actual real-life commit. Signed-off-by: Mika Kahola --- tests/kms_cursor_legacy.c | 230 -- 1 file changed, 204 insertions(+), 26 deletions(-) diff --git

[Intel-gfx] [PATCH i-g-t v4 4/7] tests/kms_plane_scaling: Add TEST_ONLY flag

Add TEST_ONLY flag to test atomic scaling without actually committing the changes. v2: Create subtests with TEST_ONLY flag and one without v3: Rename subtest 'force-atomic-test' as 'with-atomic-test' Signed-off-by: Mika Kahola --- tests/kms_plane_scaling.c | 28

[Intel-gfx] [PATCH i-g-t v4 1/7] lib/igt_kms: Add forcing TEST_ONLY for atomic commits

Add an option to force atomic commits to do commits with TEST_ONLY flag first before doing the actual commit. v2: Clear force_test_atomic flag if atomic commit with TEST_ONLY flag fails (Maarten) Signed-off-by: Mika Kahola --- lib/igt_kms.c | 22

[Intel-gfx] [PATCH i-g-t v4 2/7] tests/kms_plane_multiple: Add TEST_ONLY flag Cc: maarten.lankho...@linux.intel.com

Add TEST_ONLY flag to test atomic modesetting commits without actual real-life commit. v2: Use flag to indicate to test with TEST_ONLY flag with atomic commit v3: Moved force_test_atomic flag set to 'test_plane_position()' Signed-off-by: Mika Kahola ---

[Intel-gfx] [PATCH i-g-t v4 2/3] tests/kms_plane_multiple: Add TEST_ONLY flag Cc: maarten.lankho...@linux.intel.com

Add TEST_ONLY flag to test atomic modesetting commits without actual real-life commit. v2: Use flag to indicate to test with TEST_ONLY flag with atomic commit v3: Moved force_test_atomic flag set to 'test_plane_position()' Signed-off-by: Mika Kahola ---

  1   2   >