Re: [PATCH 14/17] drm/msm: add atomic support

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote:
> On Tue, May 27, 2014 at 3:26 PM, Daniel Vetter <daniel@ffwll.ch> wrote:

[snip]

> Well, there was the NONBLOCK atomic flag.. I'm not entirely sure if we
> should hang so much off of that one flag.

Yeah, a separate VBLANK_SYNCED might be useful. Apparently people also
want non-blocking modesets.

[snip]

> > I think one excellent use-case we get for free (almost) without the ioctl
> > would be fbcon. It very much wants to do an atomic update, so converting
> > that over to the atomic interface would be good imo.
> 
> Yes, iirc the remaining non-atomic paths are fbcon related.  In
> principle it should be a simple matter to increment the refcnt on
> fbcon state object and re-apply it.  Although at the moment we keep
> track of *how* to apply the state (ie. page_flip vs set_config, etc)
> as the state object is built up.. which isn't very conducive to
> re-committing an existing state object.  Which is part of the reason I
> wanted to deprecate the various existing
> ->page_flip/->update_plane/->set_config/etc and introduce per object
> ->commit()'s.  (Which could either be called by helpers, or called
> internally by driver or completely ignored by driver)

Yeah, I think the approach in here with a few helpers to bend atomic
->commit to the old hooks (somewhat-ish) is good. And with the crtc
helpers we should be able to move most drivers away from the old hooks
quickly. The exception will be pageflips/cursors, but that requires a lot
of driver-specific work, and probably first a full conversion to universal
planes (which atm don't support everything even for the primary plane due
to the arbitrary restriction to rgbx8888).

> I've been a bit reluctant so far to do too much additional refactoring
> on top of atomic, since I'm about at the limit of what I have time to
> repeatedly rebase each kernel version.  This is why I'm a bit anxious
> to start merging some of atomic, even if it doesn't do absolutely
> everything yet.

I understand that, which is why I suggested a bunch of things to split out
already so we can get them in.

On top of that I think with the split-up mode_config.mutex like I've just
proposed in an RFC we have a clear path for the locking issues, too. So
could go ahead an merge the w/w conversion, too.

That leaves the set_prop refactoring which is still under discussion.
Those three pieces hopefully help a lot with reducing rebasing pain.

On top of that I think we should look at cutting away functional pieces of
the conversion, e.g. ignore planes at first and only look at atomic
modeset. Or ignore atomic modesets and only look at plane updates,
rejecting anything that changes connectors or crtcs. By cutting out slices
we should be able to get patches into shape step-by-step.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch