Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3979802pxb; Tue, 25 Jan 2022 00:32:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJyGy7uVbkLIXyoMAn9NxCwfF9ilDEcCuCzhKkdrYWcOwJnwPJMWM4J1cTb2ZaUf+O/kt0XD X-Received: by 2002:a17:903:31c8:b0:149:a463:ad38 with SMTP id v8-20020a17090331c800b00149a463ad38mr17499723ple.76.1643099558321; Tue, 25 Jan 2022 00:32:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643099558; cv=none; d=google.com; s=arc-20160816; b=XlL/kzUAbPSrIxz2ZkFHQMPzCGXt5cV2smz8gocmY8y5VkLBKFQlO+2T8HT2bQUd5N 6tcxErGcZUqVdU8DHzw0+2qCeINDA2mYzVtSF6ONZAYDJczMO32kG1sVGoT7CjMZzQa0 nc9oWHwNLGdtQSiBCeZhLdG2IkzjOSOHvhcjmrP5a4G9AhrA8V3W2BG+5wTQ0LL4qbCT fx8BBk3isfwjHywb3E92vE2lQtyg3xADSHH97u9sf09gyC1KK/BNQakSoxQLrfZHu+10 /2sCQnkkv/e/8aU0WAonwb2QtEwlLioTLqwy2p+ab68R/WKMbDROc1jLCxcPbehRsvC9 DyFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=V0Xy7OiF/nw0y2hNMuwqXxe4miauy48sMbl0B2pVDvI=; b=TyWWRRQ8U3GhXMFfLGqFEeG7afu/CrATPDYB0fB50DJQmJ+YvHwIVaufH6ZqgDt2yb Rw4Wb7LWazcXMDNszj352nB+7PVeSwtnHoog5sWZOcljF8wNKB/1p8Yuqnl58XToPOba HMpDTDwqewBHNI8cLeUp0Zlj3hnTeqUx9WByG8Yk3+qsZ2UaC6EiCbm89HiPoeTaMrOR 7Q9cOtfFvKHXQ25Am4wHRPmYMHdR3/NcrRk2O1vcLHwXTIgvbdOgf7r6u1af7AnPmrvI XFQPbIycqNtjDWlDpGP8YkMh3oCxzLL7ktVFjjllqylx8blUD8813ruNSDQRh77Vtt2w vwsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=E9WZL8K1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w198si13075155pfc.73.2022.01.25.00.32.27; Tue, 25 Jan 2022 00:32:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=E9WZL8K1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1314404AbiAYCuz (ORCPT + 99 others); Mon, 24 Jan 2022 21:50:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1445597AbiAXVE3 (ORCPT ); Mon, 24 Jan 2022 16:04:29 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0CFDC068084; Mon, 24 Jan 2022 12:04:10 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7F1CC6090A; Mon, 24 Jan 2022 20:04:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 600EBC340E5; Mon, 24 Jan 2022 20:04:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643054650; bh=LexXsOHLM2Zyt+r8gcyKj5jMn+0GNWWGVK2D4CaDRiY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E9WZL8K1sM0c2jlFsX+uyUxNWMa1ajeqndE7gI/g5L+Nzesu3d47HHC8RYIcLoXNm t17Mefom4mJd8acMddFZ1nRnbEDD3ubpEnwUs2/s70mHbuqivR+UCnEYWMx80SVl8x gMgtzOSzmS9Q0OMPgWRCPtM1bTltMoksy14CY5xk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zain Wang , Tomasz Figa , Heiko Stuebner , Sean Paul , Brian Norris , Robert Foss Subject: [PATCH 5.10 457/563] drm/bridge: analogix_dp: Make PSR-exit block less Date: Mon, 24 Jan 2022 19:43:42 +0100 Message-Id: <20220124184040.252701251@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124184024.407936072@linuxfoundation.org> References: <20220124184024.407936072@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Brian Norris commit c4c6ef229593366ab593d4d424addc7025b54a76 upstream. Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"), "PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor started using the blocking variant, for a variety of reasons -- quoting Sean Paul's potentially-faulty memory: """ - To avoid racing a subsequent PSR entry (if exit takes a long time) - To avoid racing disable/modeset - We're not displaying new content while exiting PSR anyways, so there is minimal utility in allowing frames to be submitted - We're lying to userspace telling them frames are on the screen when we're just dropping them on the floor """ However, I'm finding that this blocking transition is causing upwards of 60+ ms of unneeded latency on PSR-exit, to the point that initial cursor movements when leaving PSR are unbearably jumpy. It turns out that we need to meet in the middle somewhere: Sean is right that we were "lying to userspace" with a non-blocking PSR-exit, but the new blocking behavior is also waiting too long: According to the eDP specification, the sink device must support PSR entry transitions from both state 4 (ACTIVE_RESYNC) and state 0 (INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must display the incoming active frames from the Source device with no visible glitches and/or artifacts." Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before moving on; we are ready to display video, and subsequent PSR-entry is safe. Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin), where this saves about 60ms of latency, for PSR-exit that used to take about 80ms. Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR") Cc: Cc: Zain Wang Cc: Tomasz Figa Cc: Heiko Stuebner Cc: Sean Paul Signed-off-by: Brian Norris Reviewed-by: Sean Paul Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -1086,11 +1086,21 @@ int analogix_dp_send_psr_spd(struct anal if (!blocking) return 0; + /* + * db[1]!=0: entering PSR, wait for fully active remote frame buffer. + * db[1]==0: exiting PSR, wait for either + * (a) ACTIVE_RESYNC - the sink "must display the + * incoming active frames from the Source device with no visible + * glitches and/or artifacts", even though timings may still be + * re-synchronizing; or + * (b) INACTIVE - the transition is fully complete. + */ ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status, psr_status >= 0 && ((vsc->db[1] && psr_status == DP_PSR_SINK_ACTIVE_RFB) || - (!vsc->db[1] && psr_status == DP_PSR_SINK_INACTIVE)), 1500, - DP_TIMEOUT_PSR_LOOP_MS * 1000); + (!vsc->db[1] && (psr_status == DP_PSR_SINK_ACTIVE_RESYNC || + psr_status == DP_PSR_SINK_INACTIVE))), + 1500, DP_TIMEOUT_PSR_LOOP_MS * 1000); if (ret) { dev_warn(dp->dev, "Failed to apply PSR %d\n", ret); return ret;