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

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 > > > > > > Shash

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

On Fri, 2017-06-30 at 17:47 +0530, Sharma, Shashank wrote: > 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 identifi

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

13 too if the refactor I proposed are separate prep patches. But anyway, you can use Reviewed-by: Ander Conselvan de Oliveira <conselv...@gmail.com> on those if you want. > --- > drivers/gpu/drm/i915/intel_hdmi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/

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

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 output from intel platforms,

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

On Fri, 2017-06-30 at 11:33 +0530, Sharma, Shashank wrote: > 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

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

ase > V3: Rebase > V4: Rebase > > Cc: Ville Syrjala <ville.syrj...@linux.intel.com> > Cc: Daniel Vetter <daniel.vet...@intel.com> > Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com> > Signed-off-by: Sha

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

ister for ycbcr420 output. > - Adds a new scaler user "HDMI output" to plug-into existing > scaler framework. This output type is identified using bit > 30 of the scaler users bitmap. > > V2: rebase > V3: rebase > V4: rebase > > Cc: Ville Syrjala <ville.

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

On Wed, 2017-06-21 at 21:19 +0530, Sharma, Shashank wrote: > 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

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

com> > Cc: Daniel Vetter <daniel.vet...@intel.com> > Cc: Ander Conselvan De Oliveira <ander.conselvan.de.olive...@intel.com> > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com> > --- > drivers/gpu/drm/i915/intel_display.c | 1 + > drivers/gpu/dr

Re: [Intel-gfx] [PATCH v3] drm: Add DPCD definitions for DP 1.4 DSC feature

On Tue, 2017-03-14 at 13:01 -0700, Manasi Navare wrote: > From: "Navare, Manasi D" > > Display stream compression is supported on DP 1.4 DP > devices. This patch adds the corersponding DPCD > register definitions for DSC. > > v3: > * Add some SHIFTS and MASKS for

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote: > > 從我的 iPad 傳送 > > > Ville Syrjälä 於 2017年3月7日 上午2:34 寫道： > > > > > On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote: > > > > > > > > > 從我的 iPad 傳送 > > > > > > > > Ville Syrjälä

Re: [Intel-gfx] [PATCH v10 5/6] drm/i915: enable scrambling

> - Pass the scrambling state variables as bool input to the sink_scrambling >function and let the disable call be unconditional. > - Fix alignments in function calls and debug messages. > - Add kernel doc for function intel_hdmi_handle_sink_scrambling > > V10: Reba

Re: [PATCH v8 5/6] drm/i915: enable scrambling

On Wed, 2017-03-08 at 19:07 +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the

Re: [PATCH v7 5/6] drm/i915: enable scrambling

On Fri, 2017-03-03 at 21:58 +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the monitor

Re: [Intel-gfx] [PATCH v6 5/6] drm/i915: enable scrambling

On Fri, 2017-03-03 at 17:33 +0530, Sharma, Shashank wrote: > Thanks for the review Ander. My comments inline. > > Shashank > > On 3/3/2017 3:22 PM, Ander Conselvan De Oliveira wrote: > > On Fri, 2017-03-03 at 11:59 +0530, Shashank Sharma wrote: > > > Geminilake pla

Re: [Intel-gfx] [PATCH v6 5/6] drm/i915: enable scrambling

On Fri, 2017-03-03 at 11:59 +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the monitor

Re: [Intel-gfx] [PATCH v5 5/6] drm/i915: enable scrambling

On Thu, 2017-03-02 at 08:25 +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/1/2017 8:41 PM, Ville Syrjälä wrote: > > On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote: > > > Geminilake platform sports a native HDMI 2.0 controller, and is > > > capable of driving

Re: [PATCH v4 5/6] drm/i915: enable scrambling

On Thu, 2017-02-23 at 16:33 +0530, Sharma, Shashank wrote: > Thanks for the review Ander, my comments, inline. > > > Regards > > Shashank > > > On 2/23/2017 1:33 PM, Ander Conselvan De Oliveira wrote: > > On Thu, 2017-02-23 at 10:01 +0530, Shar

Re: [PATCH v4 5/6] drm/i915: enable scrambling

On Thu, 2017-02-23 at 10:01 +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 2/22/2017 10:59 PM, Ville Syrjälä wrote: > > On Wed, Feb 22, 2017 at 06:48:30PM +0530, Shashank Sharma wrote: > > > Geminilake platform sports a native HDMI 2.0 controller, and is > > > capable of driving

[PATCH] drm: Add name for DRM_DP_DUAL_MODE_LSPCON

.org> Cc: David Airlie <airl...@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com> --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 2 ++ 1 file changed, 2 insertions(+)

Re: [Intel-gfx] [PATCH v3 6/6] drm/i915: allow HDMI 2.0 clock rates

On Fri, 2017-02-10 at 21:59 +0530, Shashank Sharma wrote: > Geminilake has a native HDMI 2.0 controller, which is capable of > driving clocks upto 594Mhz. This patch updates the max tmds clock > limit for the same. > > V2: rebase > V3: rebase > > Cc: And

[Intel-gfx] [PATCH v2 1/2] drm: Wrap the check for atomic_commit implementation

On Wed, 2016-12-21 at 12:12 -0800, Dhinakaran Pandiyan wrote: > This check is useful for drivers that do not have DRIVER_ATOMIC set but > have atomic modesetting internally implemented. Wrap the check into a > function since this is used in many places and as a bonus, the function > name helps to

[PATCH 10/10] drm/i915: Account for sink max TMDS clock when checking the port clock

sink's max TMDS clock > into account before we go and decide that a particular mode can > be used with 12bpc. Reviewed-by: Ander Conselvan de Oliveira > > Signed-off-by: Ville Syrjälä > --- >  drivers/gpu/drm/i915/intel_hdmi.c | 9 - >  1 file changed, 8 insertio

[PATCH 09/10] drm/i915: Replace a bunch of connector->base.display_info with a local variable

On Wed, 2016-09-28 at 16:51 +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Reduce the eyesore with a local variable. > > Signed-off-by: Ville Syrjälä Reviewed-by: Ander Conselvan de Oliveira > --- >  drivers/gpu/drm/i915/intel_display.c |

[PATCH v2 02/11] drm/i915: Remove stallcheck special handling.

On Mon, 2016-04-18 at 07:31 +0200, Maarten Lankhorst wrote: > Op 15-04-16 om 09:07 schreef Ander Conselvan De Oliveira: > > On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote: > > > Re-use unpin_work->pending, but also set vblank count before > > > intel_ma

[PATCH v2 05/11] drm/i915: Allow mmio updates on all platforms, v2.

On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote: > Rename intel_unpin_work to intel_flip_work and use it for mmio flips > and unpinning. I think the rename should be a separate patch. Ander > Use flip_queued_req to hold the wait request in the > mmio case and allow the vblank

[PATCH v2 03/11] drm/i915: Remove intel_prepare_page_flip.

On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote: > Do it in 1 step instead, use atomic_read since INTEL_FLIP_COMPLETE > is no longer useful. What's the deal with "use atomic_read"? I couldn't find where that is different from the old code. > > Signed-off-by: Maarten Lankhorst > ---

[PATCH v2 02/11] drm/i915: Remove stallcheck special handling.

On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote: > Re-use unpin_work->pending, but also set vblank count before > intel_mark_page_flip_active to be sure. Be sure of what? > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/i915_debugfs.c | 11 ++- >

[PATCH] drm/dp: add eDP DPCD backlight control bit definitions

GHT_FREQ_PWM_PIN_PASSTHRU_ENABLE (1 << 2) > +# define DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE(1 << 3) > +# define DP_EDP_DYNAMIC_BACKLIGHT_ENABLE (1 << 4) > +# define DP_EDP_REGIONAL_BACKLIGHT_ENABLE(1 << 5) Doesn't DP_EDP_REGIONAL_BACKLIGHT_ENABLE need a /* eDP 1.4 */ comment too? Anyway, it all matches the spec so, Reviewed-by: Ander Conselvan de Oliveira > +# define DP_EDP_UPDATE_REGION_BRIGHTNESS (1 << 6) /* eDP 1.4 > */ > > #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722 > #define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723

[PATCH] drm: Repurpose reserved field of drm_event_vlank to crtc_id

drm_vblank_event is repurposed to include the crtc_id which the event is for. The DRM_CAP_CRTC_IN_VBLANK_EVENT is added to allow userspace to query if the crtc field will be set properly. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/drm_atomic.c | 7 +-- drivers/gpu/drm/drm_crtc.c

[PATCH libdrm] xf86drmMode: Handle the crtc_id field of drm_event_vblank

Signed-off-by: Ander Conselvan de Oliveira --- include/drm/drm.h | 2 +- xf86drm.h | 9 - xf86drmMode.c | 26 +- 3 files changed, 26 insertions(+), 11 deletions(-) diff --git a/include/drm/drm.h b/include/drm/drm.h index 167b7b8..81f8af1 100644

[PATCH] drm: Repurpose reserved field of drm_event_vlank to crtc_id

drm_vblank_event is repurposed to include the crtc_id which the event is for. The DRM_CAP_CRTC_IN_VBLANK_EVENT is added to allow userspace to query if the crtc field will be set properly. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/drm_atomic.c | 7 +-- drivers/gpu/drm/drm_crtc.c

[RFC] Repurpose reserved field in vblank event to crtc_id

Hi, Right now, if an atomic commit sends multiple vblank events it is not possible to distiguish for each crtc each event is for in userspace. This series changes that be repurposing the reserved field in struct drm_event_vblank. Would this be a sane thing to do? Thanks, Ander

[Intel-gfx] [PATCH 4/4] drm/atomic-helpers: Make encoder picking more robust

For the series: Reviewed-by: Ander Conselvan de Oliveira On Mon, 2015-08-03 at 17:24 +0200, Daniel Vetter wrote: > We've had a few issues with atomic where subtle bugs in the encoder > picking logic lead to accidental self-stealing of the encoder, > resulting in a NULL connector_st

[PATCH 2/6] drm/atomic: pass old crtc state to atomic_begin/flush.

Reviewed-by: Ander Conselvan de Oliveira On Tue, 2015-07-21 at 13:28 +0200, Maarten Lankhorst wrote: > In intel it's useful to keep track of some state changes with old > crtc state vs new state, for example to disable initial planes or > when a modeset's prevented during fastboot. >

[PATCH 1/6] drm/atomic: add connectors_changed to separate it from mode_changed, v2

> Changes since v1: > - Update kerneldocs slightly. > > Cc: dri-devel at lists.freedesktop.org > Signed-off-by: Maarten Lankhorst I have a couple of nits below, but anyway, Reviewed-by: Ander Conselvan de Oliveira > --- > dr

[Intel-gfx] [PATCH] drm/i915: Clear pipe's pll hw state in hsw_dp_set_ddi_pll_sel()

On Tue, 2015-06-30 at 18:41 +0300, Jani Nikula wrote: > On Tue, 30 Jun 2015, Daniel Vetter wrote: > > On Tue, Jun 30, 2015 at 04:47:06PM +0300, Jani Nikula wrote: > >> On Tue, 30 Jun 2015, Ander Conselvan de Oliveira > >> wrote: > >> > Similarly to what i

[PATCH] drm/i915: Clear pipe's pll hw state in hsw_dp_set_ddi_pll_sel()

]() pipe state doesn't match! This regression was indroduced in commit dd3cd74acf12723045a64f1f2c6298ac7b34a5d5 Author: Ander Conselvan de Oliveira Date: Fri May 15 13:34:29 2015 +0300 drm/i915: Don't overwrite (e)DP PLL selection on SKL Signed-off-by: Ander Conselvan de Oliveira

[git pull] drm tree for 4.2

On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote: > On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote: > > > > This is the main drm pull request for v4.2. > > It seems to work ok for me, but it causes quite a few new warnings on > my Sony VAIO Pro laptop. It's (once more) a regular

[PULL] drm-intel-next-fixes

There is commit bd4b4827acdc00bf9e71f939d160102021d10d4f Author: Ander Conselvan de Oliveira Date: Fri May 29 14:28:09 2015 +0300 drm/i915: Silence compiler warning in -nightly to fix that same issue. I didn't realize this was also needed in -next-fixes. Ander On Fri, 2015-06-19 at 17

[Fwd: Re: [PATCH] drm/i915: Properly initialize SDVO analog connectors]

Thanks for testing. Forwarded Message From: Stefan Lippers-Hollmann <s@gmx.de> To: Ander Conselvan de Oliveira Subject: Re: [PATCH] drm/i915: Properly initialize SDVO analog connectors Date: Mon, 8 Jun 2015 12:16:04 +0200 Hi On 2015-06-08, Ander Conselvan de Ol

git pull] drm for v4.1-rc1

On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote: > On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote: > > Hi > > > > On 2015-06-07, Ville Syrjälä wrote: > > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lipp

[PATCH] drm/i915: Properly initialize SDVO analog connectors

In the commit below, I missed the connector allocation in the function intel_sdvo_analog_init(), leading to those connectors to have a NULL state pointer. commit 08d9bc920d465d762cac9383249c19bf69a2 Author: Ander Conselvan de Oliveira Date: Fri Apr 10 10:59:10 2015 +0300 drm/i915

git pull] drm for v4.1-rc1

-04-19 > > > > 14:31:41 -0700) > > > > > > > > are available in the git repository at: > > > > > > > > git://people.freedesktop.org/~airlied/linux drm-next-merged > > > > > > > > for you to fetch changes up to 2c33ce009ca2389

[PATCH] drm/atomic: Don't try to free a NULL state

Consistently with other free functions, handle the NULL case without oopsing. Cc: dri-devel at lists.freedesktop.org Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/drm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm

[PATCH] drm/atomic: Clear crtcs, connectors and planes when clearing state

but leave the pointer to the object still set. This fixes a NULL pointer dereference in i915 caused by the use of drm_atomic_state_clear(). Cc: dri-devel at lists.freedesktop.org Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/drm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH] drm/atomic: Fix potential use of state after free

The atomic helpers rely on drm_atomic_state_clear() to reset an atomic state if a retry is needed due to the w/w mutexes. The subsequent calls to drm_atomic_get_{crtc,plane,...}_state() would then return the stale pointers in state->{crtc,plane,...}_states. Signed-off-by: Ander Conselvan

[Intel-gfx] [PATCH 1/9] drm: add helper to get crtc timings (v4)

On 11/24/2014 09:52 PM, Matt Roper wrote: > From: Gustavo Padovan > > We need to get hdisplay and vdisplay in a few places so create a > helper to make our job easier. > > v2 (by Matt): Use new stereo doubling function (suggested by Ville) > > v3 (by Matt): > - Add missing kerneldoc (Daniel) >

[PATCH] drm: Global atomic state handling

On 11/05/2014 12:07 AM, Daniel Vetter wrote: > /** > + * struct struct drm_atomic_state - the global state object for atomic > updates > + * @dev: parent DRM device > + * @flags: state flags like async update > + * @planes: pointer to array of plane pointers > + * @plane_states: pointer to

[PATCH libdrm] libkms: fix the name of the intel driver in linux_sysfs_create

Ping? On 09/05/2012 02:30 PM, Ander Conselvan de Oliveira wrote: > From: Ander Conselvan de Oliveira > > linux_sysfs_create() checked for a driver named "intel" while the intel > driver is called "i915". This went unnoticed because in kernels 2.6.39 > and aft

Re: [PATCH libdrm] libkms: fix the name of the intel driver in linux_sysfs_create

Ping? On 09/05/2012 02:30 PM, Ander Conselvan de Oliveira wrote: From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com linux_sysfs_create() checked for a driver named intel while the intel driver is called i915. This went unnoticed because in kernels 2.6.39 and after

[PATCH libdrm] libkms: fix the name of the intel driver in linux_sysfs_create

From: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com> linux_sysfs_create() checked for a driver named "intel" while the intel driver is called "i915". This went unnoticed because in kernels 2.6.39 and after this code path was never reached because of

[PATCH libdrm] libkms: fix the name of the intel driver in linux_sysfs_create

From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com linux_sysfs_create() checked for a driver named intel while the intel driver is called i915. This went unnoticed because in kernels 2.6.39 and after this code path was never reached because of the dumb buffer interface