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@xxxxxxxxxxxxxxxxxxxxx > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
