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

[Jesse Barnes]

On Wed, 27 Jun 2012 13:24:02 +0300
ville.syrjala at 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...

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...

-- 
Jesse Barnes, Intel Open Source Technology Center