Received: by 10.213.65.68 with SMTP id h4csp571602imn; Wed, 4 Apr 2018 03:39:09 -0700 (PDT) X-Google-Smtp-Source: AIpwx49xChEAkYrWDFPG480S/g0DVJK/zIqhA6XUQcFRPMlyHCgL+qWRaltDwdfjSsTEKisx8VNj X-Received: by 2002:a17:902:51ee:: with SMTP id y101-v6mr18476174plh.359.1522838349537; Wed, 04 Apr 2018 03:39:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522838349; cv=none; d=google.com; s=arc-20160816; b=QuHC34rqsPaBACP9ZtnhhQQFHnXE1+8uV0wQa3dgDZX6nUtCyw+k4mzp7+GUPJ+g2G 4KxI8KGbOUOwa+AnTOEOoVgx02FD0jj5XuQW1t/havbvGBvi6gudwOW8R/9ehD97pbN7 z4iKTwK8fVBRo0SfMz+G/yRdfefy1A7NWYf2FiOYCOC986uGiX+ycfTZSLEsxUajkpKn YQ8MLXpWN9+WnQXfgCtzorJUKGiK4O3fn2lteUApwyeL86FhdLm0N6rD5j2wDKHxR3D8 +1mUTqnWGXJHzV0Yesnquj+O/p1qipmLEN0UfAQl5ZxwAYR1M2q/hEkXYjDnP9VhB1Fl Q2mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=jPPDLK5/peVIEIiuX+VJwgr3BwWVg8FfE5HO+AqJ0XE=; b=s1Knt+pmQ+ouiTYOvn2/hro5TA6Og/Xsi5NH7cFxGqWhhGxyRQsbCIy7V3DsQYHhRg cH7kk5iSB5kir4rKGwOGjhRbXPYHPx8UmEmks9FNQrX4XH4WJiuk4pjJZkHRQIu0Xm/K 2nlt/PSgvhrZ91vIi1XDs27cZcHJqBIDvX/ptp4y1oUSrSRRQGZhaOaS1qM/6qXlgVDE fJ8Al4zmrH7o0npLF3+XWSsGMd97YeNUsFw3zLnVI6XUCjfzk78/9TIw2tEeCVpyxcF8 KVDKn7jcXjHRRE0O7mTLmYbOrKB0HnkNXJSeMTPOcWv2RwbsLMHSK9Qlm+1j9/N7G6Yf iYmw== ARC-Authentication-Results: i=1; mx.google.com; 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 j12si3808098pfh.3.2018.04.04.03.38.55; Wed, 04 Apr 2018 03:39:09 -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; 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 S1751434AbeDDKgS (ORCPT + 99 others); Wed, 4 Apr 2018 06:36:18 -0400 Received: from mga05.intel.com ([192.55.52.43]:60963 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbeDDKgR (ORCPT ); Wed, 4 Apr 2018 06:36:17 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 03:36:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,405,1517904000"; d="scan'208";a="213823969" Received: from amihaila-mobl.ger.corp.intel.com (HELO [10.252.53.31]) ([10.252.53.31]) by orsmga005.jf.intel.com with ESMTP; 04 Apr 2018 03:36:12 -0700 Subject: Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb To: Rob Clark , dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Thomas Hellstrom , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Lukasz Spintzyk , Deepak Singh Rawat , Gustavo Padovan , Sean Paul , David Airlie , linux-kernel@vger.kernel.org References: <20180403224225.26776-1-robdclark@gmail.com> <20180404100300.GE3881@phenom.ffwll.local> <20180404102108.GF3881@phenom.ffwll.local> From: Maarten Lankhorst Message-ID: <4976c166-32b2-75ef-ee78-7e7893dd4121@linux.intel.com> Date: Wed, 4 Apr 2018 12:36:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180404102108.GF3881@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 04-04-18 om 12:21 schreef Daniel Vetter: > 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. I thought plane_state->fence was used for explicit fences, so its use by drivers would interfere with it? I don't think fencing would work on msm or vc4.. > - 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. > > 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