Re: [PATCH v2 09/20] drm/i915: Fill in more crtc state, v2.

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Jul 13, 2015 at 11:32:09AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 12:28 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:20AM +0200, Maarten Lankhorst wrote:
> >> Perform a full readout of the state by making sure the mode is set
> >> up correctly atomically.
> >>
> >> Also there was a small memory leak by doing the memset, fix this
> >> by calling __drm_atomic_helper_crtc_destroy_state first.
> >>
> >> Changes since v1:
> >> - Moved after reworking primary plane and updating mode members.
> >> - Force a modeset calculation by changing mode->type from what the
> >>   final mode will be.
> >>
> >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > tbh I don't really like mode_from_pipe_config since it goes in reverse.
> > With the adjust mode of config_compare we can compare different final hw
> > states and make a call whether they match enough for modeset avoidance or
> > not. mode_from_pipe_config otoh is a lie on panels where we can do
> > upscaling, hence I'd like to remove it to avoid confusion.
> What do you want the initial mode to be then?
> 
> You need to fill in some mode to satisfy drm_atomic_crtc_check.

All zeros? That would make it clear that we have a mode, and that we also
have no idea really what it is ...

Otoh I think you've convinced me now that we indeed do need a real mode
object here to avoid other troubles (i.e. the entire discussion around
initial fbcon modesets). Given that I'd guess even the slightly wrong
fill_in_modes here with the change to set DRIVER_MODE would be ok. As long
as we can guarantee that we'll get a full modeset eventually we should be
fine I hope.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx