Re: [RFC][PATCH 0/10] Atomic modesetting v2

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Jun 27, 2012 at 09:48:26AM -0700, Jesse Barnes wrote:
> On Wed, 27 Jun 2012 13:24:02 +0300
> ville.syrjala@linux.intel.com wrote:
> 
> > Second version of the atomic mode setting work. Still very much
> > work in progress.
> > 
> > I decided that I can't afford to fight the drm_crtc_helper
> > architecture due to the sheer amount of driver code depending on it.
> > So I changed the code to do things in way that more closely matches
> > drm_crtc_helper.
> 
> :(
> 
> > Next I'll be moving the buffer pinning to happen before any hw state
> > is clobbered. This will avoid having to do actual rollbacks when
> > pinning fails. And a similar treatment needs to be done to the PLL
> > calculations (those should be done before buffer pinning).
> > 
> > I didn't re-post all the i915 specific bits I have in my tree since those
> > didn't really change. I pushed the whole work to the drm_atomic_2 branch
> > at https://gitorious.org/vsyrjala/linux.
> 
> OTOH introducing an atomic alternative to the helper stuff and moving
> drivers over would probably end up looking a lot nicer.  But there's no
> doubt that's a huge chunk of work...

I'm thinking that it should be doable. Well, at least for all the "core"
features, but I'm not quite sure how it would handle all driver specific
properties in a nice way. Basically what I have now in intel_atomic.c
could become the new helper, but then it needs somehow to defer to the
driver for some of the props.

So either the driver needs to collect the state for those somehow, or we
have the core do it the same way as for other objects, ie. overwrite
the object state with the new values as we go on, and then roll back
later if necessary. But then we potentially need to save/restore all
properties in the beginning and end of the operation, or we could try
to do it in some lazy fashion.

> The other thing I'm worried about with atomic mode setting is handling
> the legacy case properly.  We'll still need to handle apps that want to
> change one CRTC at a time without altering the state of other CRTCs.
> In an atomic context, drivers should be able to assume they can shut
> anything off that doesn't come in as part of the atomic state, which
> means when we build a compat atomic setup, we'll need to read the
> current state of any existing objects and pass them in to the driver...

My current code collects the current state in the beginning (or rather
it saves the state of all the objects in the beginning) and starts
to modify the current state of the objects as new values are read in by
the ioctl handler. Anything not part of the atomic modeset is left
untouched.

-- 
Ville Syrjälä
Intel OTC