Re: [Intel-gfx] [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

Regards Shashank On 7/12/2017 10:54 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote: LSPCON chips can't pick the HDMI AVI infoframes from direct link. In order to pass AVI infoframes from display controller to LSPCON, we have to write infoframe

Re: [Intel-gfx] [PATCH 02/20] drm/edid: complete CEA modedb(VIC 1-107)

Regards Shashank On 7/12/2017 10:48 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:30PM +0530, Shashank Sharma wrote: 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

Re: [Intel-gfx] [PATCH 07/20] drm/edid: parse ycbcr 420 deep color information

Regards Shashank On 7/12/2017 10:48 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:35PM +0530, Shashank Sharma wrote: CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420

Re: [Intel-gfx] [PATCH 06/20] drm: add helper to validate YCBCR420 modes

Regards Shashank On 7/12/2017 10:48 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:34PM +0530, Shashank Sharma wrote: YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This

Re: [Intel-gfx] [PATCH 09/20] drm: add helper functions for YCBCR420 handling

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:37PM +0530, Shashank Sharma wrote: This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is

Re: [Intel-gfx] [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:38PM +0530, Shashank Sharma wrote: This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420

Re: [Intel-gfx] [PATCH 11/20] drm/i915: prepare scaler for YCBCR420 modeset

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:39PM +0530, Shashank Sharma wrote: To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI

Re: [Intel-gfx] [PATCH 13/20] drm/i915: prepare csc unit for YCBCR420 output

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:41PM +0530, Shashank Sharma wrote: To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. Current Intel platforms have only one pipe CSC unit, so we can either do color

Re: [Intel-gfx] [PATCH 08/20] drm: set output colorspace in AVI infoframe

Regards Shashank On 7/12/2017 10:47 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:36PM +0530, Shashank Sharma wrote: A source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. This patch adds a function to add the

Re: [Intel-gfx] [PATCH 16/20] drm: add function to read vendor OUI

Regads Shashank On 7/12/2017 10:45 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:44PM +0530, Shashank Sharma wrote: This patch adds a helper function in DP dual mode layer to read the vendor's IEEE OUI signature from a Dual mode adapter. This will be used to differentiate between

Re: [Intel-gfx] [PATCH 18/20] drm/i915: YCBCR 420 support for LSPCON

Regards Shashank On 7/12/2017 10:45 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:46PM +0530, Shashank Sharma wrote: LSPCON chips support YCBCR420 outputs. To be able to get YCBCR420 output from LSPCON chip, the source should: - Generate YCBCR444 HDMI output - Set AVI infoframes for

Re: [Intel-gfx] [PATCH 19/20] drm/i915: Move AVI infoframe function to DDI layer

Thanks for the review, Ville. My comments, inline. Regards Shashank On 7/12/2017 10:45 PM, Ville Syrjälä wrote: On Mon, Jul 10, 2017 at 04:48:47PM +0530, Shashank Sharma wrote: We have an existing function to prepare AVI infoframes for HDMI, this patch moves that function from HDMI layer, to

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä wrote: > > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote: > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: > > > > > In several instances the driver passes an 'enum pipe' value

Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Read the context-status buffer from the HWSP

On 7/12/2017 3:58 PM, Chris Wilson wrote: The engine provides a mirror of the CSB in the HWSP. If we use the cacheable reads from the HWSP, we can shave off a few mmio reads per context-switch interrupt (which are quite frequent!). Just removing a couple of mmio is not enough to actually reduce

Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Read the context-status HEAD from the HWSP

On 7/12/2017 4:41 PM, Daniele Ceraolo Spurio wrote: On 12/07/17 15:58, Chris Wilson wrote: The engine provides also provides mirror of the CSB write pointer in the HWSP, but not of our read pointer. To take advantage of this we need to remember where we read up to on the last interrupt and

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/cnl: New DMC release: 1.05.

== Series Details == Series: drm/i915/cnl: New DMC release: 1.05. URL : https://patchwork.freedesktop.org/series/27208/ State : warning == Summary == Series 27208v1 drm/i915/cnl: New DMC release: 1.05. https://patchwork.freedesktop.org/api/1.0/series/27208/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 1/3] drm/i915/lrc: allocate separate page for HWSP

On 7/12/2017 3:57 PM, Chris Wilson wrote: From: Daniele Ceraolo Spurio On gen8+ we're currently using the PPHWSP of the kernel ctx as the global HWSP. However, when the kernel ctx gets submitted (e.g. from __intel_autoenable_gt_powersave) the HW will use that

[Intel-gfx] [PATCH] drm/i915/cnl: New DMC release: 1.05.

Version 1.05 is now available for CNL. According to its release notes the only difference is: - Change from aux A pwrreq always turn on during restore, to saving and restoring aux A pwrreq. Anusha Srivatsa Signed-off-by: Rodrigo Vivi ---

Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Read the context-status HEAD from the HWSP

On 12/07/17 15:58, Chris Wilson wrote: The engine provides also provides mirror of the CSB write pointer in the HWSP, but not of our read pointer. To take advantage of this we need to remember where we read up to on the last interrupt and continue off from there. This poses a problem following

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/lrc: allocate separate page for HWSP

== Series Details == Series: series starting with [1/3] drm/i915/lrc: allocate separate page for HWSP URL : https://patchwork.freedesktop.org/series/27207/ State : success == Summary == Series 27207v1 Series without cover letter

[Intel-gfx] [PATCH 1/3] drm/i915/lrc: allocate separate page for HWSP

From: Daniele Ceraolo Spurio On gen8+ we're currently using the PPHWSP of the kernel ctx as the global HWSP. However, when the kernel ctx gets submitted (e.g. from __intel_autoenable_gt_powersave) the HW will use that page as both HWSP and PPHWSP. This causes a

[Intel-gfx] [PATCH 3/3] drm/i915/execlists: Read the context-status HEAD from the HWSP

The engine provides also provides mirror of the CSB write pointer in the HWSP, but not of our read pointer. To take advantage of this we need to remember where we read up to on the last interrupt and continue off from there. This poses a problem following a reset, as we don't know where the hw

[Intel-gfx] [PATCH 2/3] drm/i915/execlists: Read the context-status buffer from the HWSP

The engine provides a mirror of the CSB in the HWSP. If we use the cacheable reads from the HWSP, we can shave off a few mmio reads per context-switch interrupt (which are quite frequent!). Just removing a couple of mmio is not enough to actually reduce any latency, but a small reduction in

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/edp: Be less aggressive about changing link config on eDP

On Wed, Jul 12, 2017 at 02:53:36PM -0700, Manasi Navare wrote: > On Wed, Jul 12, 2017 at 10:38:03PM +0100, Chris Wilson wrote: > > Quoting Manasi Navare (2017-07-12 22:36:49) > > > On Wed, Jul 12, 2017 at 12:16:13AM +0100, Chris Wilson wrote: > > > > Quoting Jim Bride (2017-07-11 23:19:56) > > > >

Re: [Intel-gfx] [RFC] drm/i915/lrc: allocate separate page for HWSP

Quoting Daniele Ceraolo Spurio (2017-07-06 17:10:40) > On gen8+ we're currently using the PPHWSP of the kernel ctx as the > global HWSP. However, when the kernel ctx gets submitted (e.g. from > __intel_autoenable_gt_powersave) the HW will use that page as both > HWSP and PPHWSP. Currently we're

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/edp: Be less aggressive about changing link config on eDP

On Wed, Jul 12, 2017 at 10:38:03PM +0100, Chris Wilson wrote: > Quoting Manasi Navare (2017-07-12 22:36:49) > > On Wed, Jul 12, 2017 at 12:16:13AM +0100, Chris Wilson wrote: > > > Quoting Jim Bride (2017-07-11 23:19:56) > > > > @@ -174,21 +176,25 @@ intel_dp_link_training_clock_recovery(struct >

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/edp: Be less aggressive about changing link config on eDP

Quoting Manasi Navare (2017-07-12 22:36:49) > On Wed, Jul 12, 2017 at 12:16:13AM +0100, Chris Wilson wrote: > > Quoting Jim Bride (2017-07-11 23:19:56) > > > @@ -174,21 +176,25 @@ intel_dp_link_training_clock_recovery(struct > > > intel_dp *intel_dp) > > > > > > if

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/edp: Be less aggressive about changing link config on eDP

On Wed, Jul 12, 2017 at 12:16:13AM +0100, Chris Wilson wrote: > Quoting Jim Bride (2017-07-11 23:19:56) > > @@ -174,21 +176,25 @@ intel_dp_link_training_clock_recovery(struct intel_dp > > *intel_dp) > > > > if (!intel_dp_get_link_status(intel_dp, link_status)) { > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915/lrc: Clarify the format of the context image

On 7/12/2017 12:45 PM, Chris Wilson wrote: Quoting Michel Thierry (2017-07-12 20:30:31) Not only the context image consist of two parts (the PPHWSP, and the logical context state), but we also allocate a header at the start of for sharing data with GuC. Thus every lrc looks like this: |

Re: [Intel-gfx] [RFC] drm/i915/lrc: allocate separate page for HWSP

Quoting Daniele Ceraolo Spurio (2017-07-06 17:10:40) > On gen8+ we're currently using the PPHWSP of the kernel ctx as the > global HWSP. However, when the kernel ctx gets submitted (e.g. from > __intel_autoenable_gt_powersave) the HW will use that page as both > HWSP and PPHWSP. Currently we're

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/edp: Be less aggressive about changing link config on eDP

On Tue, Jul 11, 2017 at 03:19:56PM -0700, Jim Bride wrote: > This set of changes has some history to them. There were several attempts > to add what was called "fast link training" to i915, which actually wasn't > fast link training as per the DP spec. These changes were > > 5fa836a9d859

Re: [Intel-gfx] [PATCH 01/12] drm/i915/psr: Remove vlv_is_active function.

On Wed, Jul 12, 2017 at 12:56 PM, Chris Wilson wrote: > Quoting Rodrigo Vivi (2017-07-12 20:20:31) >> Let's start the clean-up and re-org of VLV PSR functions by >> removing an useless one. >> >> Cc: Dhinakaran Pandiyan >> Cc: Jim Bride

Re: [Intel-gfx] [PATCH] tools/null_state_gen: Add GEN10 golden context batch buffer creation

On Wed, Jul 12, 2017 at 1:42 PM, Oscar Mateo wrote: > > > On 07/05/2017 05:50 PM, Rodrigo Vivi wrote: >> >> Hi Oscar, > > > Hey! > >> I had missed this patch here, but noticed now that I was refreshing >> and testing more cnl tests before re-submitting them. >> >> First of

Re: [Intel-gfx] [PATCH v2 7/7] igt/kms_fbc_crc.c : Add Y-tile tests

Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu: > Now that we have support for Y-tiled buffers, add another > iteration of tests for Y-tiled buffers. Have you tested this on platforms that don't support Y-tiled buffers? I don't see a check for that, so I wonder if we'll just fail some

Re: [Intel-gfx] [PATCH] tools/null_state_gen: Add GEN10 golden context batch buffer creation

On 07/05/2017 05:50 PM, Rodrigo Vivi wrote: Hi Oscar, Hey! I had missed this patch here, but noticed now that I was refreshing and testing more cnl tests before re-submitting them. First of all I believe we need to remove the A0 w/a. I don't believe we will ever see one. So I'm removing

Re: [Intel-gfx] [PATCH v2 6/7] igt/kms_frontbuffer_tracking: Add Y-tiling support

Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu: > Allow tests to create Y-tiled bufferes using a separate > argument to the test without increasing the number of > subtests. > > v2: Changed tiling option to string (Paulo) I had some minor nitpicks for this patch: reshuffling

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't make assumptions while getting the lrca offset

On 12/07/17 12:49, Chris Wilson wrote: Quoting Michel Thierry (2017-07-12 20:30:32) Using the HWSP ggtt_offset to get the lrca offset is only correct if the HWSP happens to be before it (when we reuse the PPHWSP of the kernel context as the engine HWSP). Instead of making this assumption, get

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.

On Wed, Jul 12, 2017 at 12:27:33AM +0100, Chris Wilson wrote: > Quoting Jim Bride (2017-07-11 23:19:55) > > @@ -5869,13 +5891,14 @@ static bool intel_edp_init_connector(struct > > intel_dp *intel_dp, > > } > > intel_connector->edid = edid; > > > > - /* prefer fixed mode

Re: [Intel-gfx] [PATCH 01/12] drm/i915/psr: Remove vlv_is_active function.

Quoting Rodrigo Vivi (2017-07-12 20:20:31) > Let's start the clean-up and re-org of VLV PSR functions by > removing an useless one. > > Cc: Dhinakaran Pandiyan > Cc: Jim Bride > Cc: Vathsala NAgaraju >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/lrc: Clarify the format of the context image

== Series Details == Series: series starting with [1/2] drm/i915/lrc: Clarify the format of the context image URL : https://patchwork.freedesktop.org/series/27196/ State : success == Summary == Series 27196v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't make assumptions while getting the lrca offset

Quoting Michel Thierry (2017-07-12 20:30:32) > Using the HWSP ggtt_offset to get the lrca offset is only correct if the > HWSP happens to be before it (when we reuse the PPHWSP of the kernel > context as the engine HWSP). Instead of making this assumption, get the > lrca offset from the

Re: [Intel-gfx] [PATCH 1/2] drm/i915/lrc: Clarify the format of the context image

Quoting Michel Thierry (2017-07-12 20:30:31) > Not only the context image consist of two parts (the PPHWSP, and the > logical context state), but we also allocate a header at the start of > for sharing data with GuC. Thus every lrc looks like this: > > | [guc] | [hwsp] [logical state]

[Intel-gfx] ✗ Fi.CI.BAT: warning for PSR clean-up, new vfuncs and more use of HW tracking.

== Series Details == Series: PSR clean-up, new vfuncs and more use of HW tracking. URL : https://patchwork.freedesktop.org/series/27194/ State : warning == Summary == Series 27194v1 PSR clean-up, new vfuncs and more use of HW tracking.

[Intel-gfx] [PATCH 1/2] drm/i915/lrc: Clarify the format of the context image

Not only the context image consist of two parts (the PPHWSP, and the logical context state), but we also allocate a header at the start of for sharing data with GuC. Thus every lrc looks like this: | [guc] | [hwsp] [logical state] | |<- our header ->|<- context image ->| So

[Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't make assumptions while getting the lrca offset

Using the HWSP ggtt_offset to get the lrca offset is only correct if the HWSP happens to be before it (when we reuse the PPHWSP of the kernel context as the engine HWSP). Instead of making this assumption, get the lrca offset from the kernel_context engine state. And while looking at this part of

[Intel-gfx] [PATCH 05/12] drm/i915/psr: Add activate vfunc.

Continue on VLV PSR split with vfunc, let's move activate function there. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan Cc: Jim Bride Cc: Vathsala NAgaraju Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH 12/12] drm/i915/psr: Use more PSR HW tracking.

So far we are using frontbuffer tracking for everything and ignoring that PSR has a HW capable HW tracking for many modern usages of GPU on Core platforms and newer Atom ones. One reason for that is that we were trying to keep same infrastructure in place for VLV/CHV than the rest of platforms.

[Intel-gfx] [PATCH 04/12] drm/i915/psr: hsw_psr_activate.

Oh HSW the real activate of PSR is decided by the source after certain amount of configured idle frames. However for the driver perspective where we track psr.active variable this function here is the actual activate one. So let's rename it before moving to vfunc with that. Cc: Dhinakaran

[Intel-gfx] [PATCH 06/12] drm/i915/psr: Unify VSC setup functions.

VSC package is decided per eDP spec for psr1 or psr2, and not per platform, so let's unify it and kill "skl" func. Cc: Dhinakaran Pandiyan Cc: Jim Bride Cc: Vathsala NAgaraju Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH 02/12] drm/i915/psr: Avoid any PSR stuff on platforms without support.

We really don't want to setup vfuncs and lock mutexes on platforms that has no support to PSR. Also we know what platforms they are so let's do it quietly. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan Cc: Jim Bride

[Intel-gfx] [PATCH 08/12] drm/i915/psr: Re-org Activate after enable

Let's move the activation calls together after enable is done. No real functional change should be expected here. Just an attempt to get it clear when we are really activating PSR after enabling it. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan

[Intel-gfx] [PATCH 11/12] drm/i915/psr: Add enable_source vfunc.

Continue on VPV PSR split with vfunc, let's also create one for enabling source. Also since we are touching *_enable_source functions let's fix a comment with wrong name for vlv's one. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan Cc: Jim

[Intel-gfx] [PATCH 03/12] drm/i915/psr: vfunc for disabling source.

VLV/CHV has a total different PSR implementation than the other platforms, so let's start moving that to vfuncs. Let's start with disable_src one. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan Cc: Jim Bride Cc:

[Intel-gfx] [PATCH 09/12] drm/i915/psr: Add setup VSC vfunc.

Continue on VLV PSR split with vfunc, let's also create one for setting up VSC. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan Cc: Jim Bride Cc: Vathsala NAgaraju Signed-off-by: Rodrigo

[Intel-gfx] [PATCH 01/12] drm/i915/psr: Remove vlv_is_active function.

Let's start the clean-up and re-org of VLV PSR functions by removing an useless one. Cc: Dhinakaran Pandiyan Cc: Jim Bride Cc: Vathsala NAgaraju Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 00/12] PSR clean-up, new vfuncs and more use of HW tracking.

Most of patches on this series is only a clean up with no functional changes. The goal is to allow split VLV PSR implementation better. In a way that would get more cleaner when we use or not the hw tracking. The ones with actual functional changes are:

[Intel-gfx] [PATCH 07/12] drm/i915/psr: Re-create a hsw_psr_enable_source.

This sequence is part of enable source anyways, but they only need to be executed once and not on every activation, So let's re-create hsw_enable_source. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan Cc: Jim Bride

[Intel-gfx] [PATCH 10/12] drm/i915/psr: Add enable_sink vfunc.

Continue on VPV PSR split with vfunc, let's also create one for enabling sink. Cc: Daniel Vetter Cc: Dhinakaran Pandiyan Cc: Jim Bride Cc: Vathsala NAgaraju Signed-off-by: Rodrigo

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

On Wed, Jul 12, 2017 at 08:26:02PM +0530, Ramalingam C wrote: > Daniel, > > Thank you for reviewing the patch in short time. My views are below. > > > On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote: > > On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote: > > > DRM connector

Re: [Intel-gfx] [PATCH IGT 03/11] tests/kms_frontbuffer_tracking: Remove unneeded HSW work-around.

Em Ter, 2017-07-11 às 15:48 -0700, Jim Bride escreveu: > This work-around actually causes issues on HSW now.  Without this > code in-place I'm seeing good results on HSW. Which issues? > > Cc: Rodrigo Vivi > Cc: Paulo Zanoni > Signed-off-by:

Re: [Intel-gfx] [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote: > LSPCON chips can't pick the HDMI AVI infoframes from direct link. > In order to pass AVI infoframes from display controller to LSPCON, > we have to write infoframe packets into vendor specified AUX address. > > Also, LSPCON

Re: [Intel-gfx] [PATCH 06/20] drm: add helper to validate YCBCR420 modes

On Mon, Jul 10, 2017 at 04:48:34PM +0530, Shashank Sharma wrote: > YCBCR420 modes are supported only on HDMI 2.0 capable sources. > This patch adds: > - A drm helper to validate YCBCR420-only mode on a particular > connector. This function will help pruning the YCBCR420-only > modes from the

Re: [Intel-gfx] [PATCH 02/20] drm/edid: complete CEA modedb(VIC 1-107)

On Mon, Jul 10, 2017 at 04:48:30PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH 07/20] drm/edid: parse ycbcr 420 deep color information

On Mon, Jul 10, 2017 at 04:48:35PM +0530, Shashank Sharma wrote: > CEA-861-F spec adds ycbcr420 deep color support information > in hf-vsdb block. This patch extends the existing hf-vsdb parsing > function by adding parsing of ycbcr420 deep color support from the > EDID and adding it into display

Re: [Intel-gfx] [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

On Mon, Jul 10, 2017 at 04:48:38PM +0530, Shashank Sharma wrote: > This patch checks encoder level support for YCBCR420 outputs. > The logic goes as simple as this: > If the input mode is YCBCR420-only mode: prepare HDMI for > YCBCR420 output, else continue with RGB output mode. > > It checks if

Re: [Intel-gfx] [PATCH 11/20] drm/i915: prepare scaler for YCBCR420 modeset

On Mon, Jul 10, 2017 at 04:48:39PM +0530, Shashank Sharma wrote: > To get a YCBCR420 output from intel platforms, we need one > scaler to scale down YCBCR444 samples to YCBCR420 samples. > > This patch: > - Does scaler allocation for HDMI ycbcr420 outputs. > - Programs PIPE_MISC register for

Re: [Intel-gfx] [PATCH 09/20] drm: add helper functions for YCBCR420 handling

On Mon, Jul 10, 2017 at 04:48:37PM +0530, Shashank Sharma wrote: > This patch adds helper functions for YCBCR 420 handling. > These functions do: > - check if a given video mode is YCBCR 420 only mode. > - check if a given video mode is YCBCR 420 also mode. > > V2: Added YCBCR functions as

Re: [Intel-gfx] [PATCH 13/20] drm/i915: prepare csc unit for YCBCR420 output

On Mon, Jul 10, 2017 at 04:48:41PM +0530, Shashank Sharma wrote: > To support ycbcr output, we need a pipe CSC block to do > RGB->YCBCR conversion. > > Current Intel platforms have only one pipe CSC unit, so > we can either do color correction using it, or we can perform > RGB->YCBCR conversion.

Re: [Intel-gfx] [PATCH 08/20] drm: set output colorspace in AVI infoframe

On Mon, Jul 10, 2017 at 04:48:36PM +0530, Shashank Sharma wrote: > A source must set output colorspace information in AVI > infoframes, so that the sink can decode upcoming frames > accordingly. > > This patch adds a function to add the output colorspace > information in the AVI infoframes. > >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev9)

On Wed, Jul 12, 2017 at 04:17:08PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev9) > URL : https://patchwork.freedesktop.org/series/26922/ > State : failure > > == Summary == > > Series 26922v9 drm/i915: Unify the HSW/BDW

Re: [Intel-gfx] [PATCH 18/20] drm/i915: YCBCR 420 support for LSPCON

On Mon, Jul 10, 2017 at 04:48:46PM +0530, Shashank Sharma wrote: > LSPCON chips support YCBCR420 outputs. To be able to get > YCBCR420 output from LSPCON chip, the source should: > - Generate YCBCR444 HDMI output > - Set AVI infoframes for a YCBCR420 output. > > LSPCON FW gets the information

Re: [Intel-gfx] [PATCH 19/20] drm/i915: Move AVI infoframe function to DDI layer

On Mon, Jul 10, 2017 at 04:48:47PM +0530, Shashank Sharma wrote: > We have an existing function to prepare AVI infoframes for HDMI, > this patch moves that function from HDMI layer, to DDI layer, so > that we can reuse the function for DP(LSPCON) displays too. > > This patch: > - Moves the

Re: [Intel-gfx] [PATCH 16/20] drm: add function to read vendor OUI

On Mon, Jul 10, 2017 at 04:48:44PM +0530, Shashank Sharma wrote: > This patch adds a helper function in DP dual mode layer to > read the vendor's IEEE OUI signature from a Dual mode adapter. > This will be used to differentiate between different LSPCON > vendors, to address their custom

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev9)

== Series Details == Series: drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev9) URL : https://patchwork.freedesktop.org/series/26922/ State : failure == Summary == Series 26922v9 drm/i915: Unify the HSW/BDW and GEN9+ power well code

[Intel-gfx] [PATCH v3 13/18] drm/i915/hsw, bdw: Add irq_pipe_mask, has_vga power well attributes

The pattern of a power well backing a set of pipe IRQ or VGA functionality applies to all HSW+ platforms. Using power well attributes instead of platform checks to decide whether to init/reset pipe IRQs and VGA correspondingly is cleaner and it allows us to unify the HSW/BDW and GEN9+ power well

Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE

On Wed, Jul 12, 2017 at 2:54 PM, Bartlomiej Zolnierkiewicz wrote: > On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: >> On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz wrote: >> > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote:

[Intel-gfx] [PATCH i-g-t v2] tests/chamelium: Detect analogue bridges and handle EDID accordingly

Nowadays, many VGA connectors are not actually native VGA but use a discrete bridge to a digital connector. These bridges usually enforce their own EDID instead of the one supplied by the chamelium. Thus, the EDID read test for VGA is not relevant in that case and should be skipped. Reported

[Intel-gfx] [PATCH i-g-t v2 0/1] tests/chamelium: Detect analogue bridges and handle EDID accordingly

Changes since v1: * Rebased on top of the new revisions of the series this depends on ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2 1/2] lib/igt_frame: Add support for analogue frame comparison testing

This adds support for analogue frame comparison check, as used in VGA. Since VGA uses a DAC-ADC chain, its data cannot be expected to be pixel perfect. Thus, it is impossible to uses a CRC check and full frames have to be analyzed instead. Such an analysis is implemented, based on both an absolute

[Intel-gfx] [PATCH i-g-t v2 2/2] chamelium: Add support for VGA frame comparison testing

This adds support for VGA frame comparison testing with the reference generated from cairo. The retrieved frame from the chamelium is first cropped, as it contains the blanking intervals, through a dedicated helper. Another helper function asserts that the analogue frame matches or dump it to png

[Intel-gfx] [PATCH i-g-t v2 0/2] Analogue/VGA frame comparison support

Changes since v1: * Split analogue frame comparison to igt_frame, using cairo surfaces * Added a chamelium helper for analogue frame checking and frame dumping There's nothing holding off this series on my side anymore, so it can now be merged as-is.

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

Daniel, Thank you for reviewing the patch in short time. My views are below. On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote: On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote: DRM connector property is created as bitmask to receive HDCP enable/disable request along with

Re: [Intel-gfx] [PATCH i-g-t v4 0/7] CRC testing with Chamelium improvements

On Wed, 2017-07-12 at 17:50 +0300, Paul Kocialkowski wrote: > Changes since v3: > * Renamed structure used by async crc calculation for more clarity > * Used const qualifier for untouched buffer when hashing > * Split actual calculation to a dedicated function > * Reworked async functions names

[Intel-gfx] [PATCH i-g-t v4 6/7] chamelium: Dump captured and reference frames to png on crc error

This adds support for dumping both the frame capture from the chamelium and the reference frame generated by cairo when the captured crc does not match the crc calculated from the reference, using common helpers. Getting a dump of the frames is quite useful in order to compare them.

[Intel-gfx] [PATCH i-g-t v4 5/7] lib/igt_debugfs: Add extended helper to format crc to string

This introduces a igt_crc_to_string_extended helper that allows formatting a crc to a string with a given delimiter and size to print per crc word. Signed-off-by: Paul Kocialkowski --- lib/igt_debugfs.c | 28 lib/igt_debugfs.h | 1

[Intel-gfx] [PATCH i-g-t v4 7/7] tests/chamelium: Merge the crc testing functions into one

This merges the two test_display_crc_single and test_display_crc_multiple functions into one, with a variable number of frames to capture. This reduces code duplication. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 72

[Intel-gfx] [PATCH i-g-t v4 3/7] lib/igt_debugfs: Introduce CRC check function, with logic made common

This introduces an igt_check_crc_equal function in addition to igt_assert_crc_equal and makes the CRC comparison logic from the latter common. In particular, an igt_find_crc_mismatch function indicates whether there is a mistmatch and at what index, so that the calling functions can print the

[Intel-gfx] [PATCH i-g-t v4 0/7] CRC testing with Chamelium improvements

Changes since v3: * Renamed structure used by async crc calculation for more clarity * Used const qualifier for untouched buffer when hashing * Split actual calculation to a dedicated function * Reworked async functions names for more clarity * Reworked descriptions for better accuracy * Exported

[Intel-gfx] [PATCH i-g-t v4 2/7] chamelium: Calculate CRC from framebuffer instead of hardcoding it

This introduces CRC calculation for reference frames, instead of using hardcoded values for them. The rendering of reference frames may differ from machine to machine, especially due to font rendering, and the frame itself may change with subsequent IGT changes. These differences would cause the

[Intel-gfx] [PATCH i-g-t v4 4/7] Introduce common frame dumping configuration and helpers

This introduces a common FrameDumpPath configuration field, as well as helper functions in dedicated igt_frame for writing cairo surfaces to png files. Signed-off-by: Paul Kocialkowski --- lib/Makefile.sources | 2 + lib/igt.h| 1 +

[Intel-gfx] [PATCH i-g-t v4 1/7] lib/igt_fb: Export the cairo surface instead of writing to a png

This removes the igt_write_fb_to_png function (that was unused thus far) and exports the igt_get_cairo_surface function to grab the matching cairo surface. Writing to a png is now handled by the common frame handling code in lib/igt_frame. This also fixes how the surface is retreived in chamelium

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: push more stuff down to encoders on crtc enable/disable

== Series Details == Series: drm/i915: push more stuff down to encoders on crtc enable/disable URL : https://patchwork.freedesktop.org/series/27186/ State : success == Summary == Series 27186v1 drm/i915: push more stuff down to encoders on crtc enable/disable

[Intel-gfx] [RFC PATCH 2/4] drm/i915: push DDI CRT underrun reporting on disable to encoder

Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_crt.c | 14 ++ drivers/gpu/drm/i915/intel_display.c | 8 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c

[Intel-gfx] [RFC PATCH 0/4] drm/i915: push more stuff down to encoders on crtc enable/disable

Some initial patches for comments and CI. The idea is to move more of the encoder specific stuff from crtc enable/disable paths down to the encoder hooks. Because they're encoder specific. This is the easy start, let's see how it flies. The commit messages are, uh, a little bit on the terse side.

[Intel-gfx] [RFC PATCH 4/4] drm/i915: push DDI FDI link training on enable to CRT encoder

Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_crt.c | 2 ++ drivers/gpu/drm/i915/intel_display.c | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index

[Intel-gfx] [RFC PATCH 3/4] drm/i915: push DDI underrun reporting on enable to encoder

Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_ddi.c | 8 drivers/gpu/drm/i915/intel_display.c | 5 + 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index

[Intel-gfx] [RFC PATCH 1/4] drm/i915: push DDI CRT underrun reporting on enable to encoder

Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_crt.c | 44 drivers/gpu/drm/i915/intel_display.c | 16 + 2 files changed, 45 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

Hey Gerd, Sorry, I missed this mail earlier. On 6/21/2017 12:52 PM, Gerd Hoffmann wrote: > Hi, > >> We don't support cursor for console vnc. Ideally console vnc should >> be >> used by admin for configuration or during maintenance, which refresh >> primary surface at low refresh rate, 10 fps.

Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE

On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote: > > > Instead check info->ops->owner, which amounts to the same. > > > > > > Spotted because I

Re: [Intel-gfx] [PATCH v10] vfio: ABI for mdev display dma-buf operation

On 7/12/2017 1:10 PM, Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 02:31:40AM +, Zhang, Tina wrote: >> >> >>> -Original Message- >>> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On >>> Behalf Of Daniel Vetter >>> Sent: Tuesday, July 11, 2017 5:13 PM >>>

  1   2   3   >