On Thu, Jun 29, 2017 at 12:58 PM, Maarten Lankhorst
<maarten.lankhorst@xxxxxxxxxxxxxxx> wrote:
> Op 29-06-17 om 12:31 schreef Daniel Vetter:
>> 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
>
> Well checking for crtc_state->enable instead of mode_set.mode probably means we're at least bug for bug
> compatible vs legacy. It might be better to add a bool active to restore_fbdev_mode_atomic.
>
> What about something like this? The less atomic commits the better. :)
Hm yeah, that sounds like a useful simplification. I don't think we
should do too much into extremes in fbdev and only have 1 atomic
commit, because fbdev fundamentally isn't atomic. But merging them
where it makes sense is reasonable.
-Daniel
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e49bae10f0ee..2c401fe8531c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -378,7 +378,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> }
> EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>
> -static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper)
> +static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool active)
> {
> struct drm_device *dev = fb_helper->dev;
> struct drm_plane *plane;
> @@ -427,6 +427,17 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper)
> ret = __drm_atomic_helper_set_config(mode_set, state);
> if (ret != 0)
> goto out_state;
> +
> + /*
> + * __drm_atomic_helper_set_config() sets active when a
> + * mode is set, unconditionally clear it if we force DPMS off
> + */
> + if (!active) {
> + struct drm_crtc *crtc = mode_set->crtc;
> + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +
> + crtc_state->active = false;
> + }
> }
>
> ret = drm_atomic_commit(state);
> @@ -497,7 +508,7 @@ static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> struct drm_device *dev = fb_helper->dev;
>
> if (drm_drv_uses_atomic_modeset(dev))
> - return restore_fbdev_mode_atomic(fb_helper);
> + return restore_fbdev_mode_atomic(fb_helper, true);
> else
> return restore_fbdev_mode_legacy(fb_helper);
> }
> @@ -714,7 +669,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
> }
>
> if (drm_drv_uses_atomic_modeset(fb_helper->dev))
> - dpms_atomic(fb_helper, dpms_mode);
> + restore_fbdev_mode_atomic(fb_helper, dpms_mode == DRM_MODE_DPMS_ON);
> else
> dpms_legacy(fb_helper, dpms_mode);
> mutex_unlock(&fb_helper->lock);
>
--
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
