[Intel-gfx] [PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths

[Daniel Vetter]

On Thu, Jun 29, 2017 at 12:22 PM, Maarten Lankhorst
<maarten.lankhorst at 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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch