On Thu, Jun 29, 2017 at 12:22 PM, Maarten Lankhorst
<maarten.lankhorst@xxxxxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
