[Intel-gfx] [PATCH v2 00/19] Remove depencies on staged config for atomic transition

[Daniel Vetter]

On Wed, Mar 18, 2015 at 11:57:19PM +0000, Konduru, Chandra wrote:
> 
> 
> > -----Original Message-----
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx at lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH v2 00/19] Remove depencies on staged config for atomic
> > transition
> > 
> > Here's v2 with most of the comments from Daniel addressed. I didn't change the
> > zeroing of the crtc_state to the duplicate state function, since it causes
> > problems when we add the state of a crtc that isn't going through a modeset.
> > Specifically, this would cause the code that decides whether pipes B and C can
> > be enabled at the same time to fail, since the number of fdi lanes would be zero.
> > 
> > The other concerns I raised with v1 are also addressed. I tested this on
> > IVYBRIDGE using pipes B & C, and the load detect code path using Daniel's patch
> > that adds the i915.load_detect_test parameter.
> 
> Had a chat with Ander to get an overview of his patches. It is helping to 
> review the patches. There are still couple questions, so will ask for
> clarifications as I go through the changes. 
> 
> Also got clarified that this patch series is moving in direction for atomic_crtc
> but more work needs to be done to separate out check path, swap states
> then commit path. And hook these check and commit paths into 
> intel_atomic_check/commit functions.
> 
> Also any resources involved in doing internally induced set_mode, 
> update_plane needs to be added to incoming nuclear/atomic transaction.
> I think this is one of the major todo. In that process need find way to
> avoid nested atomic transactions. Also complications can arise if the 
> transaction already has crtc state to do a mode change, and requires 
> another set mode to do load detect. In these type of scenarios, suspend
> calling nuclear transaction and start a freshone? Or do both at same time.
> It is not clear how this can be done. Probably Daniel has some ideas
> to overcome these.
> 
> Current nightly has .update_plane pointing to helper upate instead of 
> atomic_helper_update to avoid nested atomic.

Yeah nested atomic is no-go, so we need to rework that code. Ville has a
few patches in-flight already. Atm we don't have nested atomic sessions,
so this shouldn't be a concern.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch