Re: [Intel-gfx] [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested workaround is to keep sending the in

Re: [Intel-gfx] [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

Regards Shashank On 11/13/2017 10:34 PM, Ville Syrjala wrote: From: Ville Syrjälä HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to transmit the VIC or stereo information)

Re: [Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

I am still waiting for the dmesg logs, Rodrigo :P I am pretty sure that you would have picked up if there is a general problem, wit the modeset or HDMI. I just want to check what is following from the mode and monitor combination during blankout: - is the mode YCBCR420 ? - is scrambling en

Re: [Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

Regards Shashank On 11/11/2017 3:56 AM, Rodrigo Vivi wrote: Starting on GLK we support HDMI 2.0. So this patch only extend the work Shashank has made to GLK to CNL. Cc: Paulo Zanoni Cc: Shashank Sharma Cc: Manasi Navare Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_hdmi.c |

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

Regards Shashank On 11/1/2017 3:18 PM, Ville Syrjälä wrote: On Wed, Nov 01, 2017 at 10:27:23AM +0100, Maarten Lankhorst wrote: Op 09-08-17 om 08:46 schreef Shashank Sharma: To pass AVI infoframes from display controller to LSPCON, we have to write infoframe packets into vendor specified AUX

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

Regards Shashank On 11/1/2017 2:57 PM, Maarten Lankhorst wrote: Op 09-08-17 om 08:46 schreef Shashank Sharma: To pass AVI infoframes from display controller to LSPCON, we have to write infoframe packets into vendor specified AUX address, in vendor specified way. Also, LSPCON vendors provide

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

Regards Shashank On 11/1/2017 3:02 PM, Maarten Lankhorst wrote: Op 09-08-17 om 08:46 schreef Shashank Sharma: 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 outpu

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: check LSPCON vendor OUI

Thanks for the review, Maarten. My comments, inline. Regards Shashank On 10/31/2017 2:30 PM, Maarten Lankhorst wrote: Hey, Op 09-08-17 om 08:46 schreef Shashank Sharma: Intel LSPCON chip is provided by 2 vendors: - Megachips America (MCA) - Parade technologies (Parade tech) Its important to

Re: [Intel-gfx] [PATCH v3 0/3] Various retries for LSPCON

Regards Shashank On 10/10/2017 3:42 PM, Saarinen, Jani wrote: Hi, -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Shashank Sharma Sent: tiistai 10. lokakuuta 2017 13.08 To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v3

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make i9xx_load_ycbcr_conversion_matrix() static

On 9/1/2017 8:01 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Make i9xx_load_ycbcr_conversion_matrix() static to appease sparse: intel_color.c:110:6: warning: symbol 'i9xx_load_ycbcr_conversion_matrix' was not declared. Should it be static? Cc: Shashank Sharma Fixes: 25edf915

Re: [Intel-gfx] [PATCH v3 1/2] drm: Add retries for dp dual mode read

Regards Shashank On 8/24/2017 7:38 PM, Ville Syrjälä wrote: On Thu, Aug 24, 2017 at 06:53:43PM +0530, Shashank Sharma wrote: >From the CI builds, its been observed that during a driver reload/insert, dp dual mode read function sometimes fails to read from dual mode devices (like LSPCON) over

Re: [Intel-gfx] [PATCH v2 1/2] drm: Add retries for dp dual mode read

Regards Shashank On 8/24/2017 5:49 PM, Imre Deak wrote: On Thu, Aug 24, 2017 at 05:40:32PM +0530, Sharma, Shashank wrote: Regards Shashank On 8/24/2017 5:19 PM, Imre Deak wrote: On Wed, Aug 23, 2017 at 06:12:51PM +0530, Shashank Sharma wrote: From the CI builds, its been observed that

Re: [Intel-gfx] [PATCH v2 1/2] drm: Add retries for dp dual mode read

Regards Shashank On 8/24/2017 5:19 PM, Imre Deak wrote: On Wed, Aug 23, 2017 at 06:12:51PM +0530, Shashank Sharma wrote: From the CI builds, its been observed that during a driver reload/insert, dp dual mode read function sometimes fails to read from dual mode devices (like LSPCON) over i2c-

Re: [Intel-gfx] [PATCH 1/3] drm: Add retries for lspcon status check

Regards Shashank On 8/22/2017 8:57 PM, Jani Nikula wrote: On Tue, 22 Aug 2017, Shashank Sharma wrote: It's an observation during some CI tests that few LSPCON chips respond slow while system is under load, and need some delay while reading current mode status using i2c-over-aux channel. Thi

Re: [Intel-gfx] [PATCH 1/3] drm: Add retries for lspcon status check

Regards Shashank On 8/22/2017 8:24 PM, Imre Deak wrote: On Tue, Aug 22, 2017 at 08:23:49PM +0530, Shashank Sharma wrote: It's an observation during some CI tests that few LSPCON chips respond slow while system is under load, and need some delay while reading current mode status using i2c-over

Re: [Intel-gfx] [PATCH 1/2] drm: add retries for lspcon status check

Regards Shashank On 8/16/2017 9:42 PM, Imre Deak wrote: On Wed, Aug 16, 2017 at 09:18:58PM +0530, Sharma, Shashank wrote: Thanks for the review, Imre. My comments, inline. Regards Shashank On 8/16/2017 7:35 PM, Imre Deak wrote: On Fri, Aug 11, 2017 at 06:58:26PM +0530, Shashank Sharma

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't give up waiting on INVALID_MODE

Regards Shashank On 8/15/2017 5:51 AM, Pandiyan, Dhinakaran wrote: On Fri, 2017-08-11 at 18:58 +0530, Shashank Sharma wrote: Our current logic to read LSPCON's current mode, stops retries and breaks wait-loop, if it gets LSPCON_MODE_INVALID as return from the core function. This doesn't allow

Re: [Intel-gfx] [PATCH 1/2] drm: add retries for lspcon status check

Thanks for the review, Imre. My comments, inline. Regards Shashank On 8/16/2017 7:35 PM, Imre Deak wrote: On Fri, Aug 11, 2017 at 06:58:26PM +0530, Shashank Sharma wrote: It's an observation during some CI tests that few LSPCON chips respond slow while system is under load, and need some delay

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix LSPCON support.

There is probably one more place where we want this change, but I will try to cover that in my 4:2:0 for lspcon patch set. Meanwhile, please feel free to use: Reviewed-by: Shashank Sharma Regards Shashank On 8/16/2017 8:34 AM, Rodrigo Vivi wrote: When LSPCON support was extended to CNL one

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for YCBCR 4:2:0 support for LSPCON

shank -Original Message- From: Patchwork [mailto:patchw...@emeril.freedesktop.org] Sent: Wednesday, August 9, 2017 12:35 PM To: Sharma, Shashank Cc: intel-gfx@lists.freedesktop.org Subject: ✗ Fi.CI.BAT: warning for YCBCR 4:2:0 support for LSPCON == Series Details == Series: YCBCR 4:2:0 suppor

Re: [Intel-gfx] [PATCH v5 3/6] drm/i915: prepare pipe for YCBCR420 output

Regards Shashank On 7/22/2017 12:34 AM, Imre Deak wrote: On Fri, Jul 21, 2017 at 08:55:06PM +0530, Shashank Sharma wrote: To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in full

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout

Acked-by: Shashank Sharma Regards Shashank On 7/20/2017 4:20 AM, Imre Deak wrote: The scaler allocation code depends on a non-zero default value for the crtc scaler_id, so make sure we initialize the scaler state accordingly even if the crtc is off. This fixes at least an initial YUV420 modeset

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

Regards Shashank On 7/18/2017 11:42 PM, Imre Deak wrote: On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote: To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in full

Re: [Intel-gfx] [PATCH v2 00/14] YCBCR 4:2:0 handling in DRM layer

Regards Shashank On 7/15/2017 12:32 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote: Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, which is currently supported on HDMI 2.0 sources/sinks. Due to lower chroma sub-sampling rate, YCB

Re: [Intel-gfx] [PATCH v2 12/14] drm/i915: prepare csc unit for YCBCR420 output

Regards Shashank On 7/15/2017 12:06 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:18PM +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 correcti

Re: [Intel-gfx] [PATCH v2 11/14] drm/i915: prepare pipe for YCBCR420 output

Regards Shashank On 7/15/2017 12:03 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote: To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in

Re: [Intel-gfx] [PATCH v2 10/14] drm/i915: prepare scaler for YCBCR420 modeset

Regards Shahank On 7/15/2017 12:00 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:16PM +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 ycb

Re: [Intel-gfx] [PATCH v2 09/14] drm/i915: add config function for YCBCR420 outputs

Regards Shashank On 7/15/2017 12:00 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:15PM +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 outp

Re: [Intel-gfx] [PATCH v2 06/14] drm/edid: parse YCBCR420 videomodes from EDID

Regards Shashank On 7/13/2017 9:51 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:12PM +0530, Shashank Sharma wrote: HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 o

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

On 7/13/2017 7:40 PM, Ville Syrjälä wrote: What I mean is for_each() { ... + if (420) { + if (!420_dc) + return false; + } else { if (!444_dc) return false; + } } Got it, Thanks !

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

On 7/13/2017 6:56 PM, Ville Syrjälä wrote: We don't want breaks in the loop. It's meant to go through all the connectors for the crtc. Granted on modern platforms there can only be one, but IMO assuming that just makes the whole thing look confusing. It's much clearer IMO if we do if (420) {

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

On 7/13/2017 6:49 PM, Ville Syrjälä wrote: Yeah something like this perhaps: "We send 4:4:4 data to LSPCON which performs the 4:4:4->4:2:0 downsampling or us, hence we don't need a pipe scaler." Seems good ! Will add this. - Shashank ___ Intel-gfx m

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

On 7/13/2017 6:43 PM, Ville Syrjälä wrote: We don't use those clocks with DP. You've just added them here because the function call requires them as parameters. Also the function call is actually doing the wrong thing for DP by halving port_clock. Ah, missed that part. Thanks for letting me kno

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

On 7/13/2017 6:33 PM, Ville Syrjälä wrote: If the mode requires pixel repeat to meet the minimum clock requirement, then we can't just not do pixel repeat. That would violate the spec in other ways, and IIRC we couldn't even generate a low enough clock for it. The YCBCR420 modes I am seeing on s

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

On 7/13/2017 6:30 PM, Ville Syrjälä wrote: I guess then you just need to add the bitmap already in the validation patch. An alternative would be just squash the patches, but that seems a bit drastic, and probably would mix up too many things in one patch. Ok then, I will introduce this bitmap i

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

Regards Shashank On 7/13/2017 6:25 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 06:09:53PM +0530, Sharma, Shashank wrote: Regards Shashank On 7/13/2017 5:57 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 11:11:53AM +0530, Sharma, Shashank wrote: Regards Shashank On 7/12/2017 10

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

Regards Shashank On 7/13/2017 6:23 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 10:56:06AM +0530, Sharma, Shashank wrote: 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

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

Regards Shashank On 7/13/2017 6:22 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 10:51:04AM +0530, Sharma, Shashank wrote: 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

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

Regards Shashank On 7/13/2017 6:20 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 10:44:51AM +0530, Sharma, Shashank wrote: 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

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

Regards Shashank On 7/13/2017 6:07 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 10:34:26AM +0530, Sharma, Shashank wrote: 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

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

Regards Shashank On 7/13/2017 6:05 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 10:37:53AM +0530, Sharma, Shashank wrote: 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

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

Regards Shashank On 7/13/2017 6:01 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 11:02:18AM +0530, Sharma, Shashank wrote: 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

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

Regards Shashank On 7/13/2017 5:57 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 11:11:53AM +0530, Sharma, Shashank wrote: 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

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 packets

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 m

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 de

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 functi

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 YCB

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 outp

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 yc

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 correcti

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 outp

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 dif

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 D

Re: [Intel-gfx] [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

Regards Shashank On 7/5/2017 3:46 PM, Ville Syrjälä wrote: On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote: Regards Shashank On 7/4/2017 9:26 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote: YCBCR420 modes are supported only on

Re: [Intel-gfx] [PATCH v5 09/17] drm: create hdmi output property

Regards Shashank On 7/5/2017 12:01 PM, Daniel Vetter wrote: On Wed, Jul 05, 2017 at 11:39:30AM +0530, Sharma, Shashank wrote: Regards Shashank On 7/4/2017 9:06 PM, Daniel Vetter wrote: On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote: HDMI displays can support various

Re: [Intel-gfx] [PATCH v5 09/17] drm: create hdmi output property

Regards Shashank On 7/4/2017 9:06 PM, Daniel Vetter wrote: On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB - YCBCR 4

Re: [Intel-gfx] [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

Regards Shashank On 7/4/2017 9:26 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:51PM +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

Re: [Intel-gfx] [PATCH v5 02/17] drm: add YCBCR 420 capability identifier

Regards Shashank On 7/4/2017 9:25 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote: This patch adds a bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is c

Re: [Intel-gfx] [PATCH v3] drm/edid: rename macro for CEA extended-tag

Regards Shashank On 7/3/2017 9:14 PM, David Weinehall wrote: On Mon, Jul 03, 2017 at 08:41:53PM +0530, Shashank Sharma wrote: CEA-861-F introduces extended tag codes for EDID extension blocks, which indicates the actual type of the data block. The code for using exteded tag is 0x7, whereas in

Re: [Intel-gfx] [PATCH v3] drm/edid: rename macro for CEA extended-tag

Please ignore this version, sent premature. Actual one on the way. -Original Message- From: Sharma, Shashank Sent: Monday, July 3, 2017 8:39 PM To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org Cc: Sharma, Shashank ; Ville Syrjala Subject: [PATCH v3] drm/edid

Re: [Intel-gfx] [RESEND-CI v4 01/15] drm: add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 7/3/2017 3:27 PM, Ville Syrjälä wrote: On Mon, Jul 03, 2017 at 02:36:58PM +0530, Sharma, Shashank wrote: Regards Shashank On 6/30/2017 5:24 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes

Re: [Intel-gfx] [RESEND-CI v4 01/15] drm: add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 6/30/2017 5:24 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:03:59PM +0530, 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 vid

Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

Regards Shashank On 6/30/2017 7:45 PM, Ander Conselvan De Oliveira wrote: On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote: Regards Shashank On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote: On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote: Regards Shashank

Re: [Intel-gfx] [RESEND-CI v4 15/15] drm/i915/glk: set HDMI 2.0 identifier

Regards Shashank On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote: On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote: This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID hand

Re: [Intel-gfx] [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID

Regards Shashank On 6/30/2017 5:28 PM, Ville Syrjälä wrote: On Fri, Jun 30, 2017 at 10:47:48AM +0530, Sharma, Shashank wrote: Regards Shashank On 6/27/2017 5:22 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote: HDMI 2.0 spec adds support for

Re: [Intel-gfx] [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks

Regards Shashank On 6/30/2017 5:16 PM, Ville Syrjälä wrote: On Fri, Jun 30, 2017 at 10:52:54AM +0530, Sharma, Shashank wrote: Regards Shashank On 6/27/2017 5:25 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote: CEA-861-F adds ycbcr capability map

Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

Regards Shashank On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote: On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote: Regards Shashank On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote: On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote: To get a YCBCR420

Re: [Intel-gfx] [RESEND-CI v4 13/15] drm/i915: prepare csc unit for YCBCR HDMI output

Regards Shashank On 6/29/2017 5:38 PM, Ander Conselvan De Oliveira wrote: On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote: To support ycbcr HDMI output, we need a pipe CSC block to do the RGB->YCBCR conversion, as the blender output is in RGB. Current Intel platforms have only one p

Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

Regards Shashank On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote: On Wed, 2017-06-21 at 16:04 +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 H

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

Regards Shashank On 6/27/2017 5:44 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB - YCBCR

Re: [Intel-gfx] [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks

Regards Shashank On 6/27/2017 5:25 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote: CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid mult

Re: [Intel-gfx] [RESEND-CI v4 05/15] drm/edid: parse ycbcr 420 deep color information

Regards Shashank On 6/27/2017 5:23 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:03PM +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 dee

Re: [Intel-gfx] [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID

Regards Shashank On 6/27/2017 5:22 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote: HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 o

Re: [Intel-gfx] [RESEND-CI v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)

Regards Shashank On 6/27/2017 5:02 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:01PM +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 mo

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

Regards Shashank On 6/23/2017 2:50 PM, Daniel Vetter wrote: On Thu, Jun 22, 2017 at 10:33 AM, Sharma, Shashank wrote: - The property values should be limited to what the driver can support, I guess that would mean limiting the available ycbcr modes? Or does all our hw support all

Re: [Intel-gfx] [RESEND-CI v4 09/15] drm: add helper functions for YCBCR output handling

Regards Shashank On 6/23/2017 2:42 PM, Daniel Vetter wrote: On Thu, Jun 22, 2017 at 11:42 AM, Sharma, Shashank wrote: You should explain in 1-2 sentences what exactly this function does, and when a driver should use it. Just documenting the input/output stuff doesn't make the kerneldo

Re: [Intel-gfx] [RESEND-CI v4 09/15] drm: add helper functions for YCBCR output handling

Regards Shashank On 6/22/2017 12:35 PM, Daniel Vetter wrote: On Wed, Jun 21, 2017 at 04:04:06PM +0530, Shashank Sharma wrote: This patch adds set of helper functions for YCBCR HDMI output handling. These functions provide functionality like: - check if a given video mode is YCBCR 420 only mod

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

Thanks for the review, Daniel. My comments inline. Regards Shashank On 6/22/2017 12:44 PM, Daniel Vetter wrote: On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs f

Re: [Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs

Regards Shashank On 6/20/2017 7:50 PM, Ander Conselvan De Oliveira wrote: On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote: This patch checks encoder level support for HDMI YCBCR outputs. HDMI output mode is a connector property, this patch checks if source and sink can support the HD

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

Regards Shashank On 6/20/2017 8:04 PM, Ville Syrjälä wrote: On Tue, Jun 20, 2017 at 07:27:54PM +0530, Sharma, Shashank wrote: Regards Shashank On 6/20/2017 7:02 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Turns out the VLV/CHV fixed function sprite CSC expects full range

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

Regards Shashank On 6/20/2017 7:02 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color c

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add support for the YCbCr COLOR_ENCODING property

R-B: Shashank Sharma > Regards Shashank On 6/20/2017 7:03 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

while typing these examples :-). Ok then, I will add a flag which sounds more like ycbcr_420_supported or so. Regards Shashank On 6/15/2017 10:29 PM, Ville Syrjälä wrote: On Thu, Jun 15, 2017 at 10:18:40PM +0530, Sharma, Shashank wrote: Regards Shashank On 6/15/2017 9:42 PM, Ville Syrjälä wrote

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

Regards Shashank On 6/15/2017 9:42 PM, Ville Syrjälä wrote: On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote: Regards Shashank On 6/15/2017 8:13 PM, Ville Syrjälä wrote: On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote: HDMI 2.0 spec adds support for

Re: [Intel-gfx] [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

Regards Shashank On 6/15/2017 8:13 PM, Ville Syrjälä wrote: On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote: HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 o

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add support for the YCbCr COLOR_RANGE property

Reviewed-by: Shashank Sharma Regards Shashank On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Add support for the COLOR_RANGE property on planes. This property selects whether the input YCbCr data is to treated as limited range or full range. On most platforms

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Change the COLOR_ENCODING prop default value to BT.709

ACK: Shashank Sharma Regards Shashank On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Bring us forward from the stone age and switch our default YCbCr->RGB conversion matrix to BT.709 from BT.601. I would expect most matrial to be BT.709 these days. Cc: Jyri Sar

Re: [Intel-gfx] [PATCH v3 02/14] drm/edid: Complete CEA modedb(VIC 1-107)

Regards Shashank On 6/15/2017 6:59 PM, Ville Syrjälä wrote: On Wed, Jun 14, 2017 at 11:17:33PM +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 mo

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fix plane YCbCr->RGB conversion for GLK

Regards Shashank On 6/15/2017 6:12 PM, Ville Syrjälä wrote: On Thu, Jun 15, 2017 at 05:57:21PM +0530, Sharma, Shashank wrote: Regards Shashank On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä On GLK the plane CSC controls moved into the COLOR_CTL register

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Add support for the YCbCr COLOR_ENCODING property

Regards Shashank On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can generally handle BT.601 and BT.709. CHV pipe B sprites

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

Regards Shashank On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fix plane YCbCr->RGB conversion for GLK

Regards Shashank On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä On GLK the plane CSC controls moved into the COLOR_CTL register. Update the code to progam the YCbCr->RGB CSC mode correctly when faced with an YCbCr framebuffer. The spec is rather confusing as it

Re: [Intel-gfx] [PATCH v3 01/14] drm: add HDMI 2.0 VIC support for AVI info-frames

Hello Thierry, Thanks for the comments. In fact, that was the plan earlier, but the problem is, this function is being called from several drivers, and not all of them have the drm_connector readily available with their caller function. For few drivers, I might have to go up two to three level

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev3)

This is just missing the EXPORT_SYMBOL(drm_find_hdmi_output_type); Will handle this. Regards Shashank -Original Message- From: Patchwork [mailto:patchw...@emeril.freedesktop.org] Sent: Wednesday, June 14, 2017 11:22 PM To: Sharma, Shashank Cc: intel-gfx@lists.freedesktop.org Subject

Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 5/31/2017 6:11 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 10:00:12PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/30/2017 9:43 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote: HDMI 1.4b support the CEA video

Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

Regards Shashank On 5/31/2017 6:09 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 09:56:56PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/30/2017 9:48 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote: CEA-861-F specs defines new video

Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property

Regards Shashank On 5/31/2017 6:16 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 10:18:19PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/30/2017 10:06 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote: HDMI displays can support various

Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property

Regards Shashank On 5/30/2017 10:06 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB - YCBCR

<    1   2   3   4   5   6   7   >