Received: by 10.213.65.68 with SMTP id h4csp623548imn; Wed, 4 Apr 2018 04:37:39 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+WHUQmP9obPI7Mnab9F0UN43ZnONbDOLjZCiTY1CmdsXz3DQGEmZiPWJ78DOrMdUpX7KFF X-Received: by 10.101.65.4 with SMTP id w4mr10037438pgp.68.1522841859677; Wed, 04 Apr 2018 04:37:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522841859; cv=none; d=google.com; s=arc-20160816; b=s7xYRZ59U6O/B6ck0iCtNUveQgUKF4Ptn/Npo/9s9NFWdBCaT0MG3YcP8jRluID9LL KXd+zjhiZGxNqmNXFdMp1/urFq4KY8xv6cBZa0y2rrqstqdUDI16BJ5UBpOyH0t+4iYM aER9tp1i1IJu5GjVKmWk7vJh0mbg/i5Y9WyFJPrlrLQ3Q0QeHY75ii2SgUaNkznRnGkI j1vCeb1+VQON0a68uR3ikfER9Em/JCOOfLulQILaKMApfAo1kbXHpA+ZpZEbK8MRwXuZ 1Ik2DcDMBp9IRfremQxfkyv5IBaJ+5ElsgXSg01XLY4Hr3YMhCXFdb0E2uNvsdyPOQL+ pBHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=MTSyIJxcXjqnQR+j1HM08FCAryZ1zUi0PrYkOlOLec8=; b=LT9LZj4Qr+RjIP46i1/xgbEhreLmDkeS1xrVi5NFUd9+UAOaDE7R1Hs2W+ktsHlvcx cuZtRJN0663ZV64RUHBNEslGeMD/tPAPqSsbM2IqMsBCtsSMjNHp30WIJoQ/4gQFAMz8 90nU+jjLCMKD9lEjVewYdP3ExS+h6b7o0HWstj+NOx6qVpHYAJkEpaHOTDX5WN89YwEX VuqIEKivqx9bx4YTz8cXOzQzcnHHT/e8TAeTVyQSDUmM4uAEYiDxmVSihzBBLprw/e9L u/xHR3GDgE0akdVKHW/f7aRevgpMw1j5+E6jKBWgt58iEHVhzOqMrIp+cOFvqfHL3R/5 NUXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KfXCyPjg; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j15si2128167pfn.389.2018.04.04.04.37.25; Wed, 04 Apr 2018 04:37:39 -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=pass header.i=@gmail.com header.s=20161025 header.b=KfXCyPjg; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751535AbeDDLgB (ORCPT + 99 others); Wed, 4 Apr 2018 07:36:01 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:42728 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbeDDLf7 (ORCPT ); Wed, 4 Apr 2018 07:35:59 -0400 Received: by mail-io0-f196.google.com with SMTP id d5so25923840iob.9; Wed, 04 Apr 2018 04:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MTSyIJxcXjqnQR+j1HM08FCAryZ1zUi0PrYkOlOLec8=; b=KfXCyPjgunJLddu/aVwW7Ui+wsIAIqk0lS4fsQcjsBFz4gXU+UHpD40WUEGT6Sj4DD BckJ6dCD0uzq52ut4cVtHI38kelmua5co8p0kDlQ6RvQJf+jdiWDfEvYl7r2gtHA2f5S yE10d+7PcKL5hOTIkt3/amUcu8Qut5JY0klYkcQL8vvmJrTEc63U69nYpv1YIUSiwyC9 9a368ZOpYUI5bLXn0s7VZlslsRa4oBN9E4D/dIUIenzEbtBJq7Q9IVaBJgJEluGZNciS 4PG9uHJxBDbtmsVe5BKGkeX8c3CNq2QRZEw0O0hH48funPalGrPt9BKjzsso0oIig8f7 xL7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MTSyIJxcXjqnQR+j1HM08FCAryZ1zUi0PrYkOlOLec8=; b=IiQfmx4Cv/JEiZBudqkwDKVOUjH9OnjDY2S/UXdwQSv5KNnT/2p8elY5/bdnsuf1R0 1F9kLayPiyFoEfaAXsDbwptS6gCOqtF0biuuaOQ0f7BYJGPDkz02UJSnChtlTUKSAjgZ 8G5kGBHMgqv1xqJUZ4PVek4gKIlxe5qx35Som2rVKKIKj7Dop8coNQt1iJerZQRh48R4 7/O7hYaiRmd/rkhb4UNfUwA7R4jBYRXaHrk5vdg91FsJpYy54xbTeolwU7mvEKiLYVCf ddHJajquskLgj16e1pakamftGquw2OGhl/PvrUN0/OxRA5LCkMpYi/W4+1bgfXRNsJsr HFgQ== X-Gm-Message-State: ALQs6tCawlvwsyJSF1UeVUfZou2csC+au/bR2Ts0ECn66Ab9SKToj4t6 d8uC46zJaaVJ6xVuUVtt7378QqG4ZGgsqynFtSE= X-Received: by 10.107.83.9 with SMTP id h9mr14916010iob.225.1522841758879; Wed, 04 Apr 2018 04:35:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.85.204 with HTTP; Wed, 4 Apr 2018 04:35:58 -0700 (PDT) In-Reply-To: <20180404102108.GF3881@phenom.ffwll.local> References: <20180403224225.26776-1-robdclark@gmail.com> <20180404100300.GE3881@phenom.ffwll.local> <20180404102108.GF3881@phenom.ffwll.local> From: Rob Clark Date: Wed, 4 Apr 2018 07:35:58 -0400 Message-ID: Subject: Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb To: Rob Clark , dri-devel , freedreno , linux-arm-msm , Thomas Hellstrom , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Lukasz Spintzyk , Deepak Singh Rawat , Gustavo Padovan , Maarten Lankhorst , Sean Paul , David Airlie , Linux Kernel Mailing List Cc: Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ;-) 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?) 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