[Intel-gfx] [PATCH v2 00/20] Convert to atomic, part 4.

[Daniel Vetter]

On Tue, Jul 07, 2015 at 09:08:11AM +0200, Maarten Lankhorst wrote:
> This patch series requires
> [PATCH] drm/atomic: pass old crtc state to atomic_begin/flush.
> and highly recommends, but optional:
> [PATCH 2/2] drm/atomic: Cleanup on error properly in the atomic ioctl.
> 
> This series adds full atomic ioctl support, allows for decreased boot
> times by inheriting the boot state, adds support for atomic
> suspend/resume and will skip modesets if there's no need for it.
> 
> Maarten Lankhorst (20):
>   drm/atomic: add connectors_changed to separate it from mode_changed
>   drm: Don't update plane properties for atomic planes if it stays the
>     same
>   drm/i915: Fix noatomic crtc disabling.
>   drm/i915: Do not update pfit state when toggling crtc enabled.
>   drm/i915: Do not use plane_config in intel_fbdev.c
>   drm/i915: Allow fuzzy matching in pipe_config_compare.
>   drm/i915: Rework primary plane stuff slightly.
>   drm/i915: fill in more mode members
>   drm/i915: Fill in more crtc state, v2.
>   drm/i915: Convert suspend/resume to atomic.
>   drm/i915: Update power domains on readout.
>   drm/i915: skip modeset if compatible, and enable fastboot for
>     everyone, v2.
>   drm/i915: Always reset in intel_crtc_restore_mode
>   drm/i915: Make intel_display_suspend atomic, try 2.
>   drm/i915: Use full atomic modeset.
>   drm/i915: Call plane update functions directly from
>     intel_atomic_commit.
>   drm/i915: always disable irqs in intel_pipe_update_start
>   drm/i915: Only commit planes on crtc's that have changed planes.
>   drm/i915: Remove use of runtime pm in atomic commit functions
>   drm/i915: Skip modeset checks when modeset is prevented.

Ok went through the patches an made comments. My main concern is really
about the fastboot work, that has the risk of introducing another pile of
issues. Hence I'd like to get just the atomic modeset in and rolled out
every. For that the missing bit seems to be rolling out
drm_atomic_helper_dpms to all connectors (and a bit more garbage
collecting of dead code afterwards). Once that's in and stabilized a bit
we can look at fastboot.

But I'd really like not to pull in fastboot and full-blown atomic at the
same time, I fear that would destabilize the driver a bit too much. This
would affect patches 8&9, parts of patch 12 (the one split-out I
commented about should land) and probably also patch 19&20.

Overall looks good I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch