Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2804774imm; Mon, 13 Aug 2018 00:17:35 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxpIYT8qEfOmUbSLOzowGNDGWQYdA2JHoPdNmxo82Y+cHo7JtlOcEJXBzSd45CxWPrswNXt X-Received: by 2002:aa7:82c3:: with SMTP id f3-v6mr17762046pfn.136.1534144655135; Mon, 13 Aug 2018 00:17:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534144655; cv=none; d=google.com; s=arc-20160816; b=RGfR3wkORODdHGBNk4urEf2TuzK49cenVBHpuAsEamfC+I5VRCn2cJ03NZz1a4s5hZ Pb7pPpTE/6ptgWuriMQG7jqKY7qLrTkS47/T1TmPyTaUH43tNjhZ4gMz05g1Jqe3Url8 DjTXDzjNb95n/MmIk/eULuDIrkh2h0BXQsRAJkTq/zBDZfV7x1aktiZ3V00UrzJlh7tn xmyLrJ51lCRggjHbOlhO8CxHZYnpGLOnLbIvAurNsQ59ypKCxPNXgS6edbJs9cx1dQDI QgWFjr8FTwfTtWT8bnYs8xB6YOQFsTnoC+WbNSx6u91X1+TSzDTfmgvpE/oDwE7t/OSi IfQA== 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 :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=5pCo+BFgJOTsIvnxxdnozrefLH4vLCu7jOheTHlHAWg=; b=QvbHSCTNY0V6RM82Nir1wFj/uRyA66uPMyh3sLaOUFWD5jvY71IhNCEMgTF5Izi5AI qFbokYLh0BNLbxHicwDX/Or1xd7FVn2Wljsghj60wA/W3f0E9ZvnDoksQNKkQgGzsmHt 3KZL43H4FcAUqEvQ/nxEKhnUFFJGbk6JTLdlEV2osPpXcpEUTC8QWYZeMZCDdyAlnkXR 55E/LXc/71mufOc2NLXqDT15QOoIo/eJx0P5zhqQbYc8EMPTlG1O7Bbo9AatKsflQHE5 G8f2TxRW1cs+6b8R1ri9w6TNiWglYt4kBdEkgThoeZPUCjp0UJNVtPhYZNtJJKD8GMa/ Zs1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Ntc3csj0; 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=REJECT sp=REJECT dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o81-v6si17634408pfj.350.2018.08.13.00.17.20; Mon, 13 Aug 2018 00:17:35 -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=@chromium.org header.s=google header.b=Ntc3csj0; 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=REJECT sp=REJECT dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728443AbeHMJwU (ORCPT + 99 others); Mon, 13 Aug 2018 05:52:20 -0400 Received: from mail-yw1-f66.google.com ([209.85.161.66]:33575 "EHLO mail-yw1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728237AbeHMJwU (ORCPT ); Mon, 13 Aug 2018 05:52:20 -0400 Received: by mail-yw1-f66.google.com with SMTP id c135-v6so12898041ywa.0 for ; Mon, 13 Aug 2018 00:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5pCo+BFgJOTsIvnxxdnozrefLH4vLCu7jOheTHlHAWg=; b=Ntc3csj0JwIDangHGSFsgd4gOgBDdzT3oKdzfh0bRAhp5g9kkq2CfierECLlO3B9sC CLnumCk+C8ansE0q1MsI7HYEUts6fQZSz99bfK06tMJunLeTO2e7AM0u63JUVqvyHmYE NgUpBXCTG580zHhj1sCfaZpAvz11/hJxcYFME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5pCo+BFgJOTsIvnxxdnozrefLH4vLCu7jOheTHlHAWg=; b=UUrqa8KqOzpPgYP5qvB2z/fCrExGJs54ipexND8LjYOCfvw2oYM8paMJ1WLS+iRvKi R7ZhNQQi70hoADJmzatVSrffb9WMO4gL/oltlyA8c68Zv3BFl4x0RPpgkiZgu+0YkCSP x1gn+BJisB4kf6ROUmg8aZjkQOZ3GfeVusPYpSX/MLXrald+cwjMWbcp9e/Z92UkpmGD jG3hO+aPiIfb9XhTZchH/mVmwEf29rkGTvc0RdtUW8mVdC6e8QGxTujEYJp7BDS1Eb5g vUwXGwpxacc1gqYhwQ29VlaY8LIXD4bWbetxdQUIre6NXR5F8HKYSaA0sBCBoH4u9w6l ne6w== X-Gm-Message-State: AOUpUlGOLPCUWMVhUW8Irz2WGNes+8zrJ4ntZvhMeP7fmzXJYFdfkke2 NM6aWa4/z+ZmSHTs1cCwW69lsAAoTUo= X-Received: by 2002:a81:150d:: with SMTP id 13-v6mr9252284ywv.319.1534144282134; Mon, 13 Aug 2018 00:11:22 -0700 (PDT) Received: from mail-yw1-f50.google.com (mail-yw1-f50.google.com. [209.85.161.50]) by smtp.gmail.com with ESMTPSA id g203-v6sm9091470ywb.69.2018.08.13.00.11.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 00:11:19 -0700 (PDT) Received: by mail-yw1-f50.google.com with SMTP id l9-v6so12875352ywc.11 for ; Mon, 13 Aug 2018 00:11:18 -0700 (PDT) X-Received: by 2002:a0d:e7c1:: with SMTP id q184-v6mr8421932ywe.435.1534144278167; Mon, 13 Aug 2018 00:11:18 -0700 (PDT) MIME-Version: 1.0 References: <20180806155339.9473-1-enric.balletbo@collabora.com> In-Reply-To: <20180806155339.9473-1-enric.balletbo@collabora.com> From: Tomasz Figa Date: Mon, 13 Aug 2018 16:11:07 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] drm/rockchip: update cursors asynchronously through atomic. To: Enric Balletbo i Serra Cc: Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , David Airlie , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Linux Kernel Mailing List , dri-devel , "open list:ARM/Rockchip SoC..." , Gustavo Padovan , Sean Paul , kernel@collabora.com, =?UTF-8?Q?St=C3=A9phane_Marchesin?= 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 Hi Enric, On Tue, Aug 7, 2018 at 12:53 AM Enric Balletbo i Serra wrote: > > Add support to async updates of cursors by using the new atomic > interface for that. > > Signed-off-by: Enric Balletbo i Serra > --- > Hi, > > This first version is slightly different from the RFC, note that I did > not maintain the Sean reviewed tag for that reason. With this version I > don't touch the atomic_update function and all is implemented in the > async_check/update functions. See the changelog for a list of changes. > > The patch was tested on a Samsung Chromebook Plus in two ways. > > 1. Running all igt kms_cursor_legacy and kms_atomic@plane_cursor_legacy > tests and see that there is no regression after the patch. > > 2. Running weston using the atomic API. Thanks for the patch. This feature might look like a really minor thing, but we really had hard time dealing with users complaints, so having this in upstream would be a really useful thing. Let me post some comments inline. > > Best regards, > Enric > > Changes in v1: > - Rebased on top of drm-misc > - In async_check call drm_atomic_helper_check_plane_state to check that > the desired plane is valid and update various bits of derived state > (clipped coordinates etc.) > - In async_check allow to configure new scaling in the fast path. > - In async_update force to flush all registered PSR encoders. > - In async_update call atomic_update directly. > - In async_update call vop_cfg_done needed to set the vop registers and take effect. > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 53 +++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > index e9f91278137d..dab70056ee73 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -811,10 +811,63 @@ static void vop_plane_atomic_update(struct drm_plane *plane, > spin_unlock(&vop->reg_lock); > } > > +static int vop_plane_atomic_async_check(struct drm_plane *plane, > + struct drm_plane_state *state) > +{ > + struct vop_win *vop_win = to_vop_win(plane); > + const struct vop_win_data *win = vop_win->data; > + int min_scale = win->phy->scl ? FRAC_16_16(1, 8) : > + DRM_PLANE_HELPER_NO_SCALING; > + int max_scale = win->phy->scl ? FRAC_16_16(8, 1) : > + DRM_PLANE_HELPER_NO_SCALING; > + int ret; > + > + if (plane != state->crtc->cursor) > + return -EINVAL; > + > + if (!plane->state) > + return -EINVAL; > + > + if (!plane->state->fb || > + plane->state->fb != state->fb) > + return -EINVAL; While it covers for quite a big part of cursor movements, you may still expect jumpy cursor when hoovering text boxes or hyperlinks, since it changes the cursor image. Our downstream patch [1] actually took care of changing the framebuffer as well, although with the added complexity of referencing the old buffer at update time and releasing it in a flip work. [1] https://chromium.git.corp.google.com/chromiumos/third_party/kernel/+/1ad887e1a1349991c9e137b48cb32086e65347fc%5E%21/ > + > + ret = drm_atomic_helper_check_plane_state(plane->state, > + plane->crtc->state, > + min_scale, max_scale, > + true, true); > + return ret; > +} > + > +static void vop_plane_atomic_async_update(struct drm_plane *plane, > + struct drm_plane_state *new_state) > +{ > + struct vop *vop = to_vop(plane->state->crtc); > + > + plane->state->crtc_x = new_state->crtc_x; > + plane->state->crtc_y = new_state->crtc_y; > + plane->state->crtc_h = new_state->crtc_h; > + plane->state->crtc_w = new_state->crtc_w; > + plane->state->src_x = new_state->src_x; > + plane->state->src_y = new_state->src_y; > + plane->state->src_h = new_state->src_h; > + plane->state->src_w = new_state->src_w; > + > + if (vop->is_enabled) { > + rockchip_drm_psr_flush_all(plane->dev); We should use the inhibit mechanism when accessing VOP hardware. While the flush is expected to keep the PSR disabled for at least 100 ms, we're not in any atomic (pun not intended) context here and might get preempted for some unspecified time in very high load conditions. Best regards, Tomasz