Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp4764841rwl; Mon, 3 Apr 2023 09:15:20 -0700 (PDT) X-Google-Smtp-Source: AK7set8QsyH1BIQ3iBWuRYyN2L6Usc//qbxzJS0yEsNmb3j2NT7oT2Q1kmsW56BfaKjogMi0nF/4 X-Received: by 2002:a05:6a20:a82a:b0:db:1b41:704 with SMTP id cb42-20020a056a20a82a00b000db1b410704mr28801811pzb.16.1680538520273; Mon, 03 Apr 2023 09:15:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680538520; cv=none; d=google.com; s=arc-20160816; b=AOPLtaRyKRZ5qzgCsVqukalzCyCzd3IACVCoAFn/W3wELSqnqkprbVzD0mSe/IHq2Q pvm2Gt+UG0uU5WUE4ZjmgIdpmV09hzrS2xc2nya1bNcb5Hujh6E+lAfXBFAN3BcMMkDL ByIgEHXcC5HwHkYiHRDaI9dKz86v/RQnialg4ppSRf0Km1z+o6b27QA58iOOuYwWiuys NDDXQZCP3NwM2Z5c/Mmcz5LfHWO1wTBSu8/EtpQ6ImjVkfANN8c2UXZK4FNdIPc3le53 sAoIJkReAsFigt0m1XMPpHMce1LJYeezdugRqR729C64SRxHXYl0yaFLTOfRcqVXJKpX aW3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ckRoaRfuFXSxICrM929LhPKiHMEGVxGno6xY+TLvhpw=; b=KTNhCR7Rm2ksWdvUdCh/IrBDfMFmkzV1U4x/uTHb6JQoK8CJi9fQeYcO5XrZu9hC+A hHwV4D+uvPv6DAW5nrbbxJVZTY8NBnUnJvDeH9ONz7n1uVl7jf5LLXeXGVF1D/YNp6qz +Y0yFtfJN5h5x0H3QHLIsro8Dqevdtq83/womiWc/qbsjk2SVKJ8Cs6rnNWXiWXn1kiy G7f/vIEcSoVV0uoGHLpEY9qqnTeqjc1PswLBtdKRufpAJS3zae7MBGDVX3LBefgoHqtc jsTBp+K4TkjQMutnwqs7CMUgQ+Mxcm2q6iMyync7W48uhr+Eip4fqKsAaKewz9r5rDZD UDoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="FVhe/9/B"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r9-20020aa79889000000b00625dc9792a6si8475478pfl.300.2023.04.03.09.15.07; Mon, 03 Apr 2023 09:15:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="FVhe/9/B"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229498AbjDCQMN (ORCPT + 99 others); Mon, 3 Apr 2023 12:12:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232011AbjDCQML (ORCPT ); Mon, 3 Apr 2023 12:12:11 -0400 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E53D123 for ; Mon, 3 Apr 2023 09:12:10 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id e65so35380979ybh.10 for ; Mon, 03 Apr 2023 09:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680538329; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ckRoaRfuFXSxICrM929LhPKiHMEGVxGno6xY+TLvhpw=; b=FVhe/9/B5nnJIV+P+o3lR0MP8LctNsUM8vqI6LLpp5pOt9jJiOh9UHqSCQPsQ9Idbx PveyIETXxV9OXgvwdBG8WHQZiqo1///a8v4eJZzdQOnew15zDxUkUg3g1+3GN1V8WWm5 UBIW3hmoHELoAQHoaOrQRZJL3C91NcfwFDS2CXp3wVnxQBOEPfPcYFkZJUszKf4znOGi EoY3CoyLXyg21b0tp9g3XgeYo2tzFUjtWPCLP9jRuuwzs9VJLXxFHbjX7r2UUsb9Ovqq KCEszdUu1e8jBQ2HJel2Fc9oVXahuP33s6Mr9oxYSXXYoq9e3T2GHwJre1EWKGo6zRmU bbcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680538329; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ckRoaRfuFXSxICrM929LhPKiHMEGVxGno6xY+TLvhpw=; b=trALKL2A4IS2H4GSikknfkUfkGotncPPwmtdTGA5vi113nGONlGRtrLI74+2E2mjTV zA33Z0dH3McBKVJiwAodjtC/o9Ho9hdD4fgcvH3gYng/yRGTLEBiOVJQuICFt19p3Bw1 2Vo8cGTgFjgJ29ByvN775d2LKamdoC1bpDBobxrRjcYnd1F10CkbrGybnDGAI0bS9xZm lTmN2gU1tABFIvt3IDl0STySTdG8d1VmyWcfFVnfJj+L3tGT64w3HdlaiWfPvugDemrN 5MWlCQ0R0wiy9CDOreINY5/nUwNQvTZGnCHS2uxAtcMD46nGYuFMJM31BEGAb5w3Fp5a 4GXg== X-Gm-Message-State: AAQBX9fqofqaG5FntRDIGnRZE4dKoqkLIiYYs/1193Nnx9Vo+3/7u/59 7ZnMUK7jIjy9OHHr5EhKlwNeqfMgQSAw/EjM6UWHow== X-Received: by 2002:a05:6902:168d:b0:b6c:2d28:b3e7 with SMTP id bx13-20020a056902168d00b00b6c2d28b3e7mr23000047ybb.9.1680538329177; Mon, 03 Apr 2023 09:12:09 -0700 (PDT) MIME-Version: 1.0 References: <1680271114-1534-1-git-send-email-quic_vpolimer@quicinc.com> <1680271114-1534-4-git-send-email-quic_vpolimer@quicinc.com> In-Reply-To: From: Dmitry Baryshkov Date: Mon, 3 Apr 2023 19:11:58 +0300 Message-ID: Subject: Re: [PATCH v1 3/3] msm: skip the atomic commit of self refresh while PSR running To: Vinod Polimera Cc: "Vinod Polimera (QUIC)" , "dri-devel@lists.freedesktop.org" , "linux-arm-msm@vger.kernel.org" , "freedreno@lists.freedesktop.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "robdclark@gmail.com" , "dianders@chromium.org" , "swboyd@chromium.org" , "Kalyan Thota (QUIC)" , "Kuogee Hsieh (QUIC)" , "Vishnuvardhan Prodduturi (QUIC)" , "Bjorn Andersson (QUIC)" , "Abhinav Kumar (QUIC)" , "Sankeerth Billakanti (QUIC)" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Apr 2023 at 15:01, Vinod Polimera wrote: > > > On Fri, 31 Mar 2023 at 16:59, Vinod Polimera > > wrote: > > > > > > In certain CPU stress conditions, there can be a delay in scheduling commit > > > work and it was observed that PSR commit from a different work queue > > was > > > scheduled. Avoid these commits as display is already in PSR mode. > > > > > > Signed-off-by: Vinod Polimera > > > --- > > > drivers/gpu/drm/msm/msm_atomic.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c > > b/drivers/gpu/drm/msm/msm_atomic.c > > > index 645fe53..f8141bb 100644 > > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > > @@ -192,6 +192,9 @@ int msm_atomic_check(struct drm_device *dev, > > struct drm_atomic_state *state) > > > new_crtc_state->mode_changed = true; > > > state->allow_modeset = true; > > > } > > > + > > > + if (old_crtc_state->self_refresh_active && new_crtc_state- > > >self_refresh_active) > > > + return -EINVAL; > > > > EINVAL here means that atomic_check will fail if both old and new > > states are in SR mode. For example, there might be a mode set for > > another CRTC (while keeping this one in SR mode). I don't think this > > is correct. We should skip/shortcut the commit, that's true. But I > > doubt that returning an error here is a proper way to do this. Please > > correct me if I'm wrong. > > If there is a modeset on same crtc with a different connector. The new_crtc_state will not have self_refresh_active set. > Self_refresh_active is set from the helper library, which will duplicate the old_state and just adds self_refresh_active to true and active to false. > so we can be confident that if we are checking for self_refresh_active status then it should be coming from the library call. > > Also the EINVAL is returned to the self_refresh library API and the function will be retired. Maybe I misunderstand you here. However, in this way EINVAL is returned to drm_atomic_check_only() and not to the SR code. > And self_refresh_active is cleared on every commit : https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/drm_atomic_state_helper.c#n158 And this means that this check will not trigger at all, if I'm not mistaken. You've added code to msm_atomic_check(), so drm_self_refresh_helper_alter_state() was not called (yet) and thus new_crtc_state->self_refresh_active is set to false, fresh after crtc's duplicate_state. -- With best wishes Dmitry