On Thu, Jun 29, 2017 at 12:22 PM, Maarten Lankhorst maarten.lankhorst@linux.intel.com wrote:
+static void dpms_atomic(struct drm_fb_helper *fb_helper, int dpms_mode) +{
struct drm_device *dev = fb_helper->dev;struct drm_atomic_state *state;int i, ret;struct drm_modeset_acquire_ctx ctx;drm_modeset_acquire_init(&ctx, 0);state = drm_atomic_state_alloc(dev);if (!state) {ret = -ENOMEM;goto out_ctx;}state->acquire_ctx = &ctx;+retry:
for (i = 0; i < fb_helper->crtc_count; i++) {struct drm_crtc_state *crtc_state;struct drm_crtc *crtc;if (!fb_helper->crtc_info[i].mode_set.mode)continue;crtc = fb_helper->crtc_info[i].mode_set.crtc;crtc_state = drm_atomic_get_crtc_state(state, crtc);if (IS_ERR(crtc_state)) {ret = PTR_ERR(crtc_state);goto out_state;}Hm, maybe remove the early continue, and change this to if (crtc_state->enable) crtc_state->active = ...; ?
I don't know if it matters in practice, but it might be more resilient when crtc state does not match our expected state, similar to how DPMS on is ignored without CRTC.
I just blindly smashed the old fbdev code in with the helper and moved the locking out. Not sure what would be better here, since the continue is in a way just part of a non-existent drm_fb_helper_for_each_active_crtc loop iterator. Not sure it's worth it to overpolish this code to such an extent :-) -Daniel