> -----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. > > Thanks, > Ander > > Ander Conselvan de Oliveira (19): > drm/i915: Add intel_atomic_get_crtc_state() helper function > drm/i915: Pass acquire ctx also to intel_release_load_detect_pipe() > drm/i915: Allocate a drm_atomic_state for the legacy modeset code > drm/i915: Allocate a crtc_state also when the crtc is being disabled > drm/i915: Update dummy connector atomic state with current config > drm/i915: Implement connector state duplication > drm/i915: Copy the staged connector config to the legacy atomic state > drm/i915: Don't use encoder->new_crtc in intel_modeset_pipe_config() > drm/i915: Don't use encoder->new_crtc in compute_baseline_pipe_bpp() > drm/i915: Don't depend on encoder->new_crtc in > intel_dp_compute_config() > drm/i915: Don't depend on encoder->new_crtc in > intel_hdmi_compute_config > drm/i915: Use atomic state in intel_ddi_crtc_get_new_encoder() > drm/i915: Don't use staged config in intel_dp_mst_compute_config() > drm/i915: Don't use encoder->new_crtc in intel_lvds_compute_config() > drm/i915: Pass an atomic state to modeset_global_resources() functions > drm/i915: Check lane sharing between pipes B & C using atomic state > drm/i915: Convert intel_pipe_will_have_type() to using atomic state > drm/i915: Don't look at staged config crtc when changing DRRS state > drm/i915: Remove usage of encoder->new_crtc from clock computations > > drivers/gpu/drm/i915/i915_drv.h | 4 +- > drivers/gpu/drm/i915/intel_crt.c | 3 +- > drivers/gpu/drm/i915/intel_ddi.c | 24 +- > drivers/gpu/drm/i915/intel_display.c | 544 ++++++++++++++++++++++++++----- > ---- > drivers/gpu/drm/i915/intel_dp.c | 5 +- > drivers/gpu/drm/i915/intel_dp_mst.c | 18 +- > drivers/gpu/drm/i915/intel_drv.h | 16 +- > drivers/gpu/drm/i915/intel_dsi.c | 1 + > drivers/gpu/drm/i915/intel_dvo.c | 1 + > drivers/gpu/drm/i915/intel_hdmi.c | 22 +- > drivers/gpu/drm/i915/intel_lvds.c | 3 +- > drivers/gpu/drm/i915/intel_sdvo.c | 1 + > drivers/gpu/drm/i915/intel_tv.c | 3 +- > 13 files changed, 484 insertions(+), 161 deletions(-) > > -- > 2.1.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
