From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC 1/9] drm: add atomic fxns Date: Wed, 12 Sep 2012 21:03:19 +0300 Message-ID: <20120912180319.GH9227@intel.com> References: <1347246202-24249-1-git-send-email-rob.clark@linaro.org> <1347246202-24249-2-git-send-email-rob.clark@linaro.org> <20120912095720.495bf1ff@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 614299E830 for ; Wed, 12 Sep 2012 11:03:23 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Rob Clark Cc: daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org, patches@linaro.org List-Id: dri-devel@lists.freedesktop.org On Wed, Sep 12, 2012 at 12:35:01PM -0500, Rob Clark wrote: > On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes = wrote: > > On Sun, 9 Sep 2012 22:03:14 -0500 > > Rob Clark wrote: > > > >> From: Rob Clark > >> > >> The 'atomic' mechanism allows for multiple properties to be updated, > >> checked, and commited atomically. This will be the basis of atomic- > >> modeset and nuclear-pageflip. > >> > >> The basic flow is: > >> > >> state =3D dev->atomic_begin(); > >> for (... one or more ...) > >> obj->set_property(obj, state, prop, value); > >> if (dev->atomic_check(state)) > >> dev->atomic_commit(state, event); > >> dev->atomic_end(state); > > > > I think the above is more suited to drm_crtc_helper code. I think the > > top level callback should contain the arrays and be a single "multi > > flip" hook (or maybe a check then set double callback). For some > > drivers that'll end up being a lot simpler, rather than sprinkling > > atomic handling code in all the set_property callbacks. > = > well, there are a few other places in drm_crtc.c where I want to use > the new API, to avoid drivers having to support both atomic API and > old set_plane/page_flip stuff.. the transactional API makes that a bit > easier, I think.. or at least I don't have to construct an array on > the stack. Usually you would need to build up the full state anyway before you can tell if it's good or bad. I don't see what some big array would buy here. > > Having a transactional API just seems a little messier with both the > > atomic state and per-property state to track and rollback in the case > > of failure. > = > For the rollback, I think I'm just going to move the array of property > values into drm_{crtc,plane,etc}_state. That way, userspace doesn't > see updated property values if they are not committed. It makes the > property value rollback automatic. This was my original idea as well. Separate the current and future states cleanly. At the moment it's all mixed up inside the objects somewhere. I sort of abandoned the idea so that I could avoid touching too much driver code while prototyping the atomic modesetting, but that's certainly the way I would design the system. -- = Ville Syrj=E4l=E4 Intel OTC