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.