Received: by 10.213.65.68 with SMTP id h4csp666143imn; Wed, 4 Apr 2018 05:20:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+0iQFSw28tqiiX20eDguxS/w8443Dg0nEiAKy3QrWfgmYDFS+vWgkuc/P4VpEqQRf5tXY5 X-Received: by 10.98.35.202 with SMTP id q71mr13780431pfj.9.1522844422813; Wed, 04 Apr 2018 05:20:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522844422; cv=none; d=google.com; s=arc-20160816; b=M6WACjDTdBLLNztyRZFqwkIBT6udvXNeD7dwGMEj+iTwmJRDK+CkufJzo+0HZ7TpSa WSXAk6/hOiydkun3AnDSM+jKuG4GyKlyicQFwfK95SDDSf28ZvJeQGXvu+K2Hk1W3hSL Y9ZBAvNRbaud/2AHIlRGkpWR+3JyOyQV+AgghyvVpMd1jNuSmIwz2e6Q25mEFR+Rz807 F3LSKBPNX+0pspUD4YXdj267BPCwLi73fhEPrus6Qdrz8jDtlubzx3PWh/jIt46L4bcu c+BU8MexOEqzAWT/6bP9UvvEwewHztHEAQhIjYfp2OnF1GMAvoytMcim7H5ciw6NlnPk r++g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=ehh+7JB3bwlw9+3AOMJ6UtZDJjcrR4K4yMT+36h2Xkk=; b=vTnhmNgHVTIlm7cvouT3McZB0HCgbe6gpNq3D9as8IrA/T1JnbFl5QNDdCyRemv0E/ BLf53AcHKf3J4F4yg6918LKR0dPNhfxOhHx/SIhq5PQFfShm/HApUbDqK8bLKDjSOMX3 e0DdRupRoyHZjmoPL52OiLk1Z8/Gp1hm9UQi99AqX2WMRAJrLRsOXybrq0yv8kRZOt2I Xb9bkSvmuHuzvqltA7u8lO5HGzD88ZU8zVKw7lcm3C16qD6kDTbRTr7+JCCnXbmEHEtw ayiYHQcSLzLc/XH5WyclyJfdyYTUcecnEVSqmpiKNZJAc95/6JkCQiDqCv9aEoqMfWQ3 5C1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=jrPR7vnw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m10si1269718pgs.797.2018.04.04.05.20.08; Wed, 04 Apr 2018 05:20:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=jrPR7vnw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751265AbeDDMSt (ORCPT + 99 others); Wed, 4 Apr 2018 08:18:49 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:37501 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751117AbeDDMSr (ORCPT ); Wed, 4 Apr 2018 08:18:47 -0400 Received: by mail-wm0-f68.google.com with SMTP id r131so41897833wmb.2 for ; Wed, 04 Apr 2018 05:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=ehh+7JB3bwlw9+3AOMJ6UtZDJjcrR4K4yMT+36h2Xkk=; b=jrPR7vnwo7HyRVgVQuRPnpKz7JbRZjIQ384rwO97AtpvpkX11eyvcnp8fd1mQvt5MT KI8N0U8L29nmDbrB6ljXJmhb44pIzvHU5wV5JGRrYxpSiFlcTGT3pO4Tbb7LuO2GvcbO BP9gUvyvE9eqol/EClKVAqZHdpDuF46g25x4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=ehh+7JB3bwlw9+3AOMJ6UtZDJjcrR4K4yMT+36h2Xkk=; b=NRI7PocnY0v4w9RiJfAsOnUVCyQ/TKrCXRA4l+rdzRev1GO0emJyO1GQLd6Fx0xVBi M0w8smTAELd4WW0+oyqBLRzhnwz2fmOVOcALZ4xATfbSKVWH5kV6lz7+gl/ByIb5sHT4 o79eUlf85dyJ51WcWd5V9yLfjgg0ad7ePLVlUtidAeKTK2KueUHURP8yOlmiqHJH8E8I MLLVfh4xIyXPHVfDioFyt+BaTe0yrQYqyQzNX3y6ahkk/4uaZK6hCY/e15ebDgY2+EMW dWOP98yeuu3WSTjB9N4gfRFyZZ+ji8DDg5wA4ChIv+jq610yKqpOBGmcqPrVMMOdBRX+ wkgA== X-Gm-Message-State: AElRT7HeLgx8h0YlglyoEOGtKs4KKKaL9PaUQeetY6sSSYG3WmGX2RPq DgstKf1/ygQsvsPRfDWoTsJXtw== X-Received: by 10.80.190.13 with SMTP id a13mr16375896edi.153.1522844326333; Wed, 04 Apr 2018 05:18:46 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by smtp.gmail.com with ESMTPSA id 4sm3322166edx.8.2018.04.04.05.18.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Apr 2018 05:18:45 -0700 (PDT) Date: Wed, 4 Apr 2018 14:18:43 +0200 From: Daniel Vetter To: Rob Clark Cc: dri-devel , freedreno , linux-arm-msm , Thomas Hellstrom , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Lukasz Spintzyk , Deepak Singh Rawat , Gustavo Padovan , Maarten Lankhorst , Sean Paul , David Airlie , Linux Kernel Mailing List , Daniel Vetter Subject: Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb Message-ID: <20180404121843.GL3881@phenom.ffwll.local> Mail-Followup-To: Rob Clark , dri-devel , freedreno , linux-arm-msm , Thomas Hellstrom , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Lukasz Spintzyk , Deepak Singh Rawat , Gustavo Padovan , Maarten Lankhorst , Sean Paul , David Airlie , Linux Kernel Mailing List References: <20180403224225.26776-1-robdclark@gmail.com> <20180404100300.GE3881@phenom.ffwll.local> <20180404102108.GF3881@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.15.0-1-amd64 User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 04, 2018 at 07:35:58AM -0400, Rob Clark wrote: > On Wed, Apr 4, 2018 at 6:21 AM, Daniel Vetter wrote: > > On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: > >> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote: > >> > Add an atomic helper to implement dirtyfb support. This is needed to > >> > support DSI command-mode panels with x11 userspace (ie. when we can't > >> > rely on pageflips to trigger a flush to the panel). > >> > > >> > To signal to the driver that the async atomic update needs to > >> > synchronize with fences, even though the fb didn't change, the > >> > drm_atomic_state::dirty flag is added. > >> > > >> > Signed-off-by: Rob Clark > >> > --- > >> > Background: there are a number of different folks working on getting > >> > upstream kernel working on various different phones/tablets with qcom > >> > SoC's.. many of them have command mode panels, so we kind of need a > >> > way to support the legacy dirtyfb ioctl for x11 support. > >> > > >> > I know there is work on a proprer non-legacy atomic property for > >> > userspace to communicate dirty-rect(s) to the kernel, so this can > >> > be improved from triggering a full-frame flush once that is in > >> > place. But we kinda needa a stop-gap solution. > >> > > >> > I had considered an in-driver solution for this, but things get a > >> > bit tricky if userspace ands up combining dirtyfb ioctls with page- > >> > flips, because we need to synchronize setting various CTL.FLUSH bits > >> > with setting the CTL.START bit. (ie. really all we need to do for > >> > cmd mode panels is bang CTL.START, but is this ends up racing with > >> > pageflips setting FLUSH bits, then bad things.) The easiest soln > >> > is to wrap this up as an atomic commit and rely on the worker to > >> > serialize things. Hence adding an atomic dirtyfb helper. > >> > > >> > I guess at least the helper, with some small addition to translate > >> > and pass-thru the dirty rect(s) is useful to the final atomic dirty- > >> > rect property solution. Depending on how far off that is, a stop- > >> > gap solution could be useful. > >> > > >> > drivers/gpu/drm/drm_atomic_helper.c | 66 +++++++++++++++++++++++++++++++++++++ > >> > drivers/gpu/drm/msm/msm_atomic.c | 5 ++- > >> > drivers/gpu/drm/msm/msm_fb.c | 1 + > >> > include/drm/drm_atomic_helper.h | 4 +++ > >> > include/drm/drm_plane.h | 9 +++++ > >> > 5 files changed, 84 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > >> > index c35654591c12..a578dc681b27 100644 > >> > --- a/drivers/gpu/drm/drm_atomic_helper.c > >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c > >> > @@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane, > >> > if (state->fb) > >> > drm_framebuffer_get(state->fb); > >> > > >> > + state->dirty = false; > >> > state->fence = NULL; > >> > state->commit = NULL; > >> > } > >> > @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc, > >> > } > >> > EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set); > >> > > >> > +/** > >> > + * drm_atomic_helper_dirtyfb - helper for dirtyfb > >> > + * > >> > + * A helper to implement drm_framebuffer_funcs::dirty > >> > + */ > >> > +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb, > >> > + struct drm_file *file_priv, unsigned flags, > >> > + unsigned color, struct drm_clip_rect *clips, > >> > + unsigned num_clips) > >> > +{ > >> > + struct drm_modeset_acquire_ctx ctx; > >> > + struct drm_atomic_state *state; > >> > + struct drm_plane *plane; > >> > + int ret = 0; > >> > + > >> > + /* > >> > + * When called from ioctl, we are interruptable, but not when > >> > + * called internally (ie. defio worker) > >> > + */ > >> > + drm_modeset_acquire_init(&ctx, > >> > + file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0); > >> > + > >> > + state = drm_atomic_state_alloc(fb->dev); > >> > + if (!state) { > >> > + ret = -ENOMEM; > >> > + goto out; > >> > + } > >> > + state->acquire_ctx = &ctx; > >> > + > >> > +retry: > >> > + drm_for_each_plane(plane, fb->dev) { > >> > + struct drm_plane_state *plane_state; > >> > + > >> > + if (plane->state->fb != fb) > >> > + continue; > >> > + > >> > + plane_state = drm_atomic_get_plane_state(state, plane); > >> > + if (IS_ERR(plane_state)) { > >> > + ret = PTR_ERR(plane_state); > >> > + goto out; > >> > + } > >> > + > >> > + plane_state->dirty = true; > >> > + } > >> > + > >> > + ret = drm_atomic_nonblocking_commit(state); > >> > + > >> > +out: > >> > + if (ret == -EDEADLK) { > >> > + drm_atomic_state_clear(state); > >> > + ret = drm_modeset_backoff(&ctx); > >> > + if (!ret) > >> > + goto retry; > >> > + } > >> > + > >> > + drm_atomic_state_put(state); > >> > + > >> > + drm_modeset_drop_locks(&ctx); > >> > + drm_modeset_acquire_fini(&ctx); > >> > + > >> > + return ret; > >> > + > >> > +} > >> > +EXPORT_SYMBOL(drm_atomic_helper_dirtyfb); > >> > + > >> > /** > >> > * __drm_atomic_helper_private_duplicate_state - copy atomic private state > >> > * @obj: CRTC object > >> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c > >> > index bf5f8c39f34d..bb55a048e98b 100644 > >> > --- a/drivers/gpu/drm/msm/msm_atomic.c > >> > +++ b/drivers/gpu/drm/msm/msm_atomic.c > >> > @@ -201,7 +201,10 @@ int msm_atomic_commit(struct drm_device *dev, > >> > * Figure out what fence to wait for: > >> > */ > >> > for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) { > >> > - if ((new_plane_state->fb != old_plane_state->fb) && new_plane_state->fb) { > >> > + bool sync_fb = new_plane_state->fb && > >> > + ((new_plane_state->fb != old_plane_state->fb) || > >> > + new_plane_state->dirty); > >> > >> Why do you have this optimization even here? Imo flipping to the same fb > >> should result in the fb getting fully uploaded, whether you're doing a > >> legacy page_flip, and atomic one or just a plane update. > >> > >> Iirc some userspace does use that as essentially a full-plane frontbuffer > >> rendering flush already. IOW I don't think we need your > >> plane_state->dirty, it's implied to always be true - why would userspace > >> do a flip otherwise? > >> > >> The helper itself to map dirtyfb to a nonblocking atomic commit looks > >> reasonable, but misses a bunch of the trickery discussed with Noralf and > >> others I think. > > > > Ok, I've done some history digging: > > > > - i915 and nouveau unconditionally wait for fences, even for same-fb > > flips. > > - no idea what amdgpu and vmwgfx are doing, they're not using > > plane_state->fence for implicit fences. > > - most arm-soc drivers do have this "optimization" in their code, and it > > even managed to get into the new drm_gem_fb_prepare_fb helper (which I > > reviewed, or well claimed to have ... oops). Afaict it goes back to the > > original msm atomic code, and was then dutifully copypasted all over the > > place. > > > > If folks are ok I'll do a patch series to align drivers with i915/nouveau. > > Well, any driver using reservation_object_get_excl_rcu + > > drm_atomic_set_fence_for_plane combo, since amdgpu and vmwgfx don't I have > > no idea what they're doing or whether they might have the same bug. > > if you do a patch series, I think do it the other way around and align > to msm ;-) The problem is that this would break i915 userspace afaik, which I think is using a frontbuffer page flip to flush out uploads (and re-enable self refresh and stuff like that). So that we can't do easily. > I think otherwise we could end up stalling while x11 does front buffer > rendering for something unrelated (maybe I was hitting that with > cursor updates?) Why would you stall on something unrelated if we unconditionally fish out the fence? Especially cursor rendering isn't done through the gpu at all afaik. -Daniel > > BR, > -R > > > From looking at at least the various prepare_fb callbacks I don't see any > > other drivers doing funny stuff around implicit fences. > > -Daniel > > > >> > + if (sync_fb) { > >> > struct drm_gem_object *obj = msm_framebuffer_bo(new_plane_state->fb, 0); > >> > struct msm_gem_object *msm_obj = to_msm_bo(obj); > >> > struct dma_fence *fence = reservation_object_get_excl_rcu(msm_obj->resv); > >> > diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c > >> > index 0e0c87252ab0..a5d882a34a33 100644 > >> > --- a/drivers/gpu/drm/msm/msm_fb.c > >> > +++ b/drivers/gpu/drm/msm/msm_fb.c > >> > @@ -62,6 +62,7 @@ static void msm_framebuffer_destroy(struct drm_framebuffer *fb) > >> > static const struct drm_framebuffer_funcs msm_framebuffer_funcs = { > >> > .create_handle = msm_framebuffer_create_handle, > >> > .destroy = msm_framebuffer_destroy, > >> > + .dirty = drm_atomic_helper_dirtyfb, > >> > }; > >> > > >> > #ifdef CONFIG_DEBUG_FS > >> > diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h > >> > index 26aaba58d6ce..9b7a95c2643d 100644 > >> > --- a/include/drm/drm_atomic_helper.h > >> > +++ b/include/drm/drm_atomic_helper.h > >> > @@ -183,6 +183,10 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc, > >> > u16 *red, u16 *green, u16 *blue, > >> > uint32_t size, > >> > struct drm_modeset_acquire_ctx *ctx); > >> > +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb, > >> > + struct drm_file *file_priv, unsigned flags, > >> > + unsigned color, struct drm_clip_rect *clips, > >> > + unsigned num_clips); > >> > void __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj, > >> > struct drm_private_state *state); > >> > > >> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h > >> > index f7bf4a48b1c3..296fa22bda7a 100644 > >> > --- a/include/drm/drm_plane.h > >> > +++ b/include/drm/drm_plane.h > >> > @@ -76,6 +76,15 @@ struct drm_plane_state { > >> > */ > >> > struct drm_framebuffer *fb; > >> > > >> > + /** > >> > + * @dirty: > >> > + * > >> > + * Flag that indicates the fb contents have changed even though the > >> > + * fb has not. This is mostly a stop-gap solution until we have > >> > + * atomic dirty-rect(s) property. > >> > + */ > >> > + bool dirty; > >> > + > >> > /** > >> > * @fence: > >> > * > >> > -- > >> > 2.14.3 > >> > > >> > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> http://blog.ffwll.ch > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch