Re: [Intel-gfx] [PATCH v5 4/5] drm: Connector helper function to release resources

On Thu, 2017-03-30 at 12:36 +0200, Maarten Lankhorst wrote: > Op 30-03-17 om 10:42 schreef Dhinakaran Pandiyan: > > From: "Pandiyan, Dhinakaran" <dhinakaran.pandi...@intel.com> > > > > Having an ->atomic_release callback is useful to release

Re: [Intel-gfx] [PATCH] Revert unrelated part of "drm: simplify the locking in the GETCRTC ioctl"

On Thu, 2017-03-30 at 09:36 +0200, Maarten Lankhorst wrote: > Op 28-03-17 om 09:01 schreef Daniel Vetter: > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 68cded453882..43dbad62786e 100644 > > ---

Re: [Intel-gfx] [PATCH v5 4/8] drm: Add driver-private objects to atomic state

9PM -0700, Dhinakaran Pandiyan wrote: > >>>> From: "Pandiyan, Dhinakaran" <dhinakaran.pandi...@intel.com> > >>>> > >>>> It is necessary to track states for objects other than connector, crtc > >>>> and plane for atomic modesets.

Re: [Intel-gfx] [PATCH v4 8/8] drm/dp: Track MST link bandwidth

On Wed, 2017-03-22 at 13:30 +0100, Maarten Lankhorst wrote: > Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan: > > From: "Pandiyan, Dhinakaran" <dhinakaran.pandi...@intel.com> > > > > Use the added helpers to track MST link bandwidth for ato

Re: [Intel-gfx] [PATCH v4 4/8] drm: Add driver-private objects to atomic state

On Wed, 2017-03-22 at 11:00 +0100, Maarten Lankhorst wrote: > Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan: > > From: "Pandiyan, Dhinakaran" <dhinakaran.pandi...@intel.com> > > > > It is necessary to track states for objects other than connector, c

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

IRC acked by Harry Wentland " dhnkrn, the patch for driver-private atomic state object makes sense to me. Didn't realize that's the same one from early February. Feel free to add my Acked-by" -DK On Wed, 2017-02-08 at 22:38 -0800, Dhinakaran Pandiyan wrote: > It is necessary to track states

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote: > On Wed, Feb 22, 2017 at 12:01:12AM +0000, Pandiyan, Dhinakaran wrote: > > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: > > > > > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: > > >

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Thu, 2017-02-16 at 09:09 +, Lankhorst, Maarten wrote: > Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]: > > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran > > <dhinakaran.pandi...@intel.com> wrote: > > > On Mon, 2017-02-13 at 09:05 +

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

On Wed, 2017-02-22 at 09:59 +0530, Archit Taneja wrote: > > On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote: > > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: > >> > >> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: > >>> On Wed, 2017

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: > > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: > >> Hi, > >> > >> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote: > >>>

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: > Hi, > > On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote: > > It is necessary to track states for objects other than connector, crtc > > and plane for atomic modesets. But adding objects like DP MST link > > bandwidth to drm_atomic_state

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Tue, 2017-02-14 at 20:51 +0100, Daniel Vetter wrote: > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran > <dhinakaran.pandi...@intel.com> wrote: > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: > >> Pandiyan, Dhinakaran schreef op do

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]: > > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote: > > > > > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-080

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Mon, 2017-02-13 at 21:26 +, Pandiyan, Dhinakaran wrote: > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: > > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]: > > > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote: > > > >

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote: > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]: > > Having a ->atomic_release callback is useful to release shared > > resources > > that get allocated in compute_config(). This function is expected to > > be > > called

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

On Thu, 2017-02-09 at 08:08 +, Chris Wilson wrote: > On Wed, Feb 08, 2017 at 10:38:07PM -0800, Dhinakaran Pandiyan wrote: > > +#define for_each_private_obj(__state, obj_funcs, obj, obj_state, __i, > > __funcs) \ > > + for ((__i) = 0; \ > >

Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

On Wed, 2017-02-01 at 18:14 +0530, Shashank Sharma wrote: > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > than 340Mhz. This patch adds few new functions in drm layer for > core drivers to enable/disable scrambling. > > This patch adds: > - A function to detect scrambling

Re: [Intel-gfx] [PATCH v2 7/9] drm: Connector helper function to release atomic state

On Wed, 2017-01-25 at 07:18 +0100, Daniel Vetter wrote: > On Tue, Jan 24, 2017 at 03:49:35PM -0800, Dhinakaran Pandiyan wrote: > > Having a ->atomic_release callback is useful to release shared resources > > that get allocated in compute_config(). > > > > Suggested-by: Daniel Vetter

Re: [Intel-gfx] [PATCH v2 2/9] drm/dp: Kill unused MST vcpi slot availability tracking

On Wed, 2017-01-25 at 06:43 +0100, Daniel Vetter wrote: > On Tue, Jan 24, 2017 at 03:49:30PM -0800, Dhinakaran Pandiyan wrote: > > The avail_slots member in the MST topology manager is never updated to > > reflect the available vcpi slots. The check is effectively against > > total_slots. So,

Re: [Intel-gfx] [PATCH v2 7/9] drm: Connector helper function to release atomic state

On Wed, 2017-01-25 at 07:18 +0100, Daniel Vetter wrote: > On Tue, Jan 24, 2017 at 03:49:35PM -0800, Dhinakaran Pandiyan wrote: > > Having a ->atomic_release callback is useful to release shared resources > > that get allocated in compute_config(). > > > > Suggested-by: Daniel Vetter

Re: [Intel-gfx] [PATCH v2 9/9] drm/dp: Track MST link bandwidth

On Wed, 2017-01-25 at 07:15 +0100, Daniel Vetter wrote: > On Tue, Jan 24, 2017 at 03:49:37PM -0800, Dhinakaran Pandiyan wrote: > > Use the added helpers to track MST link bandwidth for atomic modesets. > > Link bw is acquired in the ->atomic_check() phase when CRTCs are being > > enabled with

Re: [Intel-gfx] [PATCH v2 8/9] drm/dp: Release DP MST shared link bandwidth

On Wed, 2017-01-25 at 07:16 +0100, Daniel Vetter wrote: > On Tue, Jan 24, 2017 at 03:49:36PM -0800, Dhinakaran Pandiyan wrote: > > Implement the ->atomic_release() callback to release the shared link > > bandwidth that was originally acquired during compute_config() > > > > Signed-off-by:

Re: [Intel-gfx] [PATCH v2 4/9] drm: Add driver private objects to atomic state

On Wed, 2017-01-25 at 06:59 +0100, Daniel Vetter wrote: > On Tue, Jan 24, 2017 at 03:49:32PM -0800, Dhinakaran Pandiyan wrote: > > It is necessary to track states for objects other than connector, crtc > > and plane for atomic modesets. But adding objects like DP MST link > > bandwidth to

Re: [Intel-gfx] [PATCH v2 3/9] drm/dp: Split drm_dp_mst_allocate_vcpi

On Wed, 2017-01-25 at 10:31 +1000, Dave Airlie wrote: > On 25 January 2017 at 09:49, Dhinakaran Pandiyan > wrote: > > drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure, > > also finds if there are enough slots available. This check is a duplicate >

[Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

On Wed, 2017-01-04 at 19:20 +, Pandiyan, Dhinakaran wrote: > On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote: > > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote: > > > Link bandwidth is shared between multiple display streams in DP MST > >

[Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote: > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote: > > Link bandwidth is shared between multiple display streams in DP MST > > configurations. The DP MST topology manager structure maintains the shared > > link bandwidth

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

Done, hope I got it right this time. -DK -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, December 22, 2016 12:52 AM To: Ander Conselvan De Oliveira Cc: Pandiyan, Dhinakaran ; intel-gfx at lists.freedesktop.org; Daniel

[Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling

On Sun, 2016-12-18 at 14:43 +0100, Daniel Vetter wrote: > On Sat, Dec 17, 2016 at 05:47:56AM +0000, Pandiyan, Dhinakaran wrote: > > On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote: > > > On Fri, 16 Dec 2016, Daniel Vetter wrote: > > > > On Fri, Dec 16, 2016 at

[Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling

On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote: > On Fri, 16 Dec 2016, Daniel Vetter wrote: > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote: > >> The two remaining patches from [1], rebased. > >> > >> BR, > >> Jani. > >> > >> > >> [1] > >>

[Intel-gfx] [PATCH 2/3] drm/dp/mst: Calculate total link bandwidth instead of hardcoding it

On Tue, 2016-11-29 at 22:58 +0200, Ville Syrjälä wrote: > On Thu, Nov 17, 2016 at 06:03:47PM -0800, Dhinakaran Pandiyan wrote: > > The total or the nominal link bandwidth, which we save in terms of PBN, is > > a factor of link rate and lane count. But, currently we hardcode it to > > 2560 PBN.

[Intel-gfx] [PATCH 2/3] drm/dp/mst: Calculate total link bandwidth instead of hardcoding it

This patch along with https://patchwork.freedesktop.org/series/15305/ will fix https://bugs.freedesktop.org/show_bug.cgi?id=98141. I'd like this to be reviewed independently since the other two patches in this series require rework for atomic support. -DK On Thu, 2016-11-17 at 18:03 -0800,

[Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

On Fri, 2016-11-18 at 06:57 +, Chris Wilson wrote: > On Thu, Nov 17, 2016 at 06:03:48PM -0800, Dhinakaran Pandiyan wrote: > > static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr, > > struct drm_dp_vcpi *vcpi, int pbn) > > { > > - int num_slots; > > +

[Intel-gfx] [PATCH 1/3] drm/i915/dp: Fail DP MST config when there are not enough vcpi slots

On Fri, 2016-11-18 at 09:43 +0100, Daniel Vetter wrote: > On Thu, Nov 17, 2016 at 06:03:46PM -0800, Dhinakaran Pandiyan wrote: > > drm_dp_find_vcpi_slots() returns an error when there is not enough > > available bandwidth on a link to support a mode. This error should make > > compute_config() to

[Intel-gfx] [PATCH v2] drm/dp: Make space for null terminator in the DP device ID char array

Adding Cc's. On Mon, 2016-11-07 at 15:22 -0800, Dhinakaran Pandiyan wrote: > The DP device identification string read from the DPCD registers is 6 > characters long at max. and we store it in a char array of the same length > without space for the NULL terminator. Fix this by increasing the

[Intel-gfx] [PATCH] drm/dp: Make space for null terminator in the DP device ID char array

Mika, Can you take a look at this? -DK On Fri, 2016-11-04 at 14:06 -0700, Dhinakaran Pandiyan wrote: > The DP device identification string read from the DPCD registers is 6 > characters long at max. and we store it in a char array of the same length > without space for the NULL terminator. Fix

[Intel-gfx] [PATCH 2/5] drm: Define a work struct for scheduling a uevent for modeset retry

On Mon, 2016-10-24 at 23:28 -0700, Manasi Navare wrote: > On Sat, Oct 22, 2016 at 10:48:13AM +0200, Daniel Vetter wrote: > > On Fri, Oct 21, 2016 at 04:45:40PM -0700, Manasi Navare wrote: > > > This work struct will be used to schedule a uevent on a separate > > > thread. This will be scheduled

[Intel-gfx] [PATCH RFC 2/8] drm: Define a work struct for scheduling a uevent for modeset retry

On Wed, 2016-10-19 at 14:46 -0700, Manasi Navare wrote: > This work struct will be used to schedule a uevent on a separate > thread. This will be scheduled after a link train failure during modeset > to indicate a modeset retry request. It will get executed after the > current modeset is complete

[2/9] drm/doc: Polish kerneldoc for encoders

I guess it's too late for review now. But, I want to send this anyway. On Mon, 2016-08-29 at 10:27 +0200, Daniel Vetter wrote: > - Move missing bits into struct drm_encoder docs. > - Explain that encoders are 95% internal and only 5% uapi, and that in > general the uapi part is broken. > -

[Intel-gfx] [PATCH 1/2] A Helper function that returns available link bandwidth

On Thu, 2016-08-11 at 16:41 -0700, Anusha Srivatsa wrote: > drm/dp/mst > > Signed-off-by: Anusha Srivatsa > > Add a function that returns the available link bandwidth for > MST port so that we can accurately determine whether a new > mode is valid for the link or not. > The Signed-off line

[Intel-gfx] [PATCH 1/4] drm/i915/dp: Add debug messages to print DP link training pattern

On Thu, 2016-08-04 at 04:07 +0100, Chris Wilson wrote: > On Wed, Aug 03, 2016 at 08:07:38PM -0700, Dhinakaran Pandiyan wrote: > > @@ -2588,7 +2592,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp, > > *DP |= DP_LINK_TRAIN_PAT_2_CPT; > > break; > >

[Intel-gfx] [PATCH 3/4] drm/dp: Clarify clock recovery and channel equalization failures

On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote: > On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote: > > The causes of clock recovery and channel equalization failures are not > > explicitly printed in debug messages. Help debugging link training > > failures by printing

[Intel-gfx] [PATCH 4/4] drm/i915/dp: Dump DP link status when link training stages fails

On Thu, 2016-08-04 at 10:46 +0300, Jani Nikula wrote: > On Thu, 04 Aug 2016, Dhinakaran Pandiyan > wrote: > > A full dump of link status can be handy in debugging link training > > failures. Let's add that to the debug messages when link training fails. > > > > Signed-off-by: Dhinakaran Pandiyan

<    1   2