From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/7] drm: add atomic fxns Date: Wed, 23 Jul 2014 23:38:20 +0200 Message-ID: <20140723213820.GG15237@phenom.ffwll.local> References: <1406144300-4995-1-git-send-email-robdclark@gmail.com> <1406144300-4995-2-git-send-email-robdclark@gmail.com> <20140723213400.GF15237@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by gabe.freedesktop.org (Postfix) with ESMTP id 3906989A34 for ; Wed, 23 Jul 2014 14:38:12 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so2961931wib.5 for ; Wed, 23 Jul 2014 14:38:11 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140723213400.GF15237@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Clark Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Wed, Jul 23, 2014 at 11:34:00PM +0200, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 03:38:14PM -0400, Rob Clark wrote: > > 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 = dev->atomic_begin(); > > for (... one or more ...) > > obj->set_property(obj, state, prop, value); > > if (dev->atomic_check(state)) > > dev->atomic_commit(state); > > dev->atomic_end(state); > > > > The split of check and commit steps is to allow for ioctls with a > > test-only flag (which would skip the commit step). > > > > Signed-off-by: Rob Clark > > [snip] > > + if (flags & DRM_MODE_ATOMIC_NOLOCK) > > + acquire_flags |= DRM_MODESET_ACQUIRE_NOLOCK; > > + if (flags & DRM_MODE_ATOMIC_NONBLOCK) > > + acquire_flags |= DRM_MODESET_ACQUIRE_NONBLOCK; > > Just a very quick reply. Can you please remove the code which does the > NOLOCK/NONBLOCK stuff here? It's not really part of the property > conversion and I'm still not sold on those concepts. > > At least I want to review them once we add them, maybe at the very end > where everything else is clear. Afaics nothing in this series actually > uses this. Self-correct: NOLOCK is used for the fbdev restore code. Imo we should drop the modeset_lock_all this one uses and switch to using the atomic locking scheme like everywhere. That way fbdev modeset changes work exactly like any other modeset change. fbdev state itself can be protected with dev->mode_config.mutex, which wraps around all the ww_mutex dancing. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch