Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1660202pxa; Thu, 6 Aug 2020 12:43:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyShJ3Fp4NbzjtQVhc+V6Odkjb1MB2av/tfow00+3fJo8/eOhtH0WKH9i0NpVsb81tn2OTa X-Received: by 2002:a17:906:32ce:: with SMTP id k14mr6228822ejk.412.1596742987745; Thu, 06 Aug 2020 12:43:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596742987; cv=none; d=google.com; s=arc-20160816; b=CF0MY+OjsabDjF7cIvJz37wFwSExnMCvil8+YWSng7gh6K0gf7xmxlPO4c6nNglxlo /kC6AcT3GcEEBQ0DDxK4Zf4OncCHop/AWD5okLAYNaUSvd5xojX18SXNAhNTmDYcapst n7S0vUsWapAJd50bBOwg9ariB/Oe5Us/iOvtGi4dXNco75Qf4HFrQ8QtH+0d4aKMZ12Q LO+oOedeLGwWZzeZBgfMS0JAoGWHD3VCeRGtTykCXSsawAJu8caw1Py1khvWDnilkHFY umuDaeZS03+Qbyy/+h5tdSCcJx/LyvUFSLXf5lBbKP0qWZn2RGVUjDi4blrq19P0cPCv BaUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=ZYadisCTQSXaXKPrEzfTRnoXgPlBsKm1tiWBuOzw0mE=; b=jZXAZV7HvzH8I3hc1USwHWMEijyTlCN7DIwSp5qSgDxBgYbrCElGU7Hgv+3JDCmX4w oi+xjv1I/lfeglh6vPDWyDwvXIdZhCijvZiR93/F3gC/tyLNL09i88lG8POGb6KLeM16 JF0E2iFFLvGrodYeY0P+J90ziLTmzQjh4YyzdRtFs3ybUQAou2VEdBfif+ZW0nS0kQqv Z6BMxsLIlEDpWCkhozbwhtp0X7QIbJoJ4FviVz25bJtS8+hv24/5dA32KA9MMWIjLq3r mdO/1D9GQzLo2YLiM11ZiLpNjttLHcPReW9W/0x2JpUBUpuDuI4PaFvcD+jw2Zpa6wah lY0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=cslBfxQP; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e15si3828237edy.357.2020.08.06.12.42.43; Thu, 06 Aug 2020 12:43:07 -0700 (PDT) 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=fail header.i=@mg.codeaurora.org header.s=smtp header.b=cslBfxQP; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726005AbgHFTl6 (ORCPT + 99 others); Thu, 6 Aug 2020 15:41:58 -0400 Received: from m43-7.mailgun.net ([69.72.43.7]:46408 "EHLO m43-7.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725272AbgHFTl6 (ORCPT ); Thu, 6 Aug 2020 15:41:58 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1596742917; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=ZYadisCTQSXaXKPrEzfTRnoXgPlBsKm1tiWBuOzw0mE=; b=cslBfxQPUGdIYJmjMOIOusCRZibKBW4ylkRqOiOg4btck5l5e8bdDcOaoDVDd/sVH2TJ/aEY qbDE0UNNlfl7voYznoXm7TPZQQLeJ7rreuWonfea4vwAfnmittrs3qfxiSnmiP11/V5RG3w+ rUp/5qGxHVDDCFqlPCJNETJ2htg= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n12.prod.us-west-2.postgun.com with SMTP id 5f2c17a04c787f237b7af23c (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 06 Aug 2020 14:45:52 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 8F2FEC43391; Thu, 6 Aug 2020 14:45:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kalyan_t) by smtp.codeaurora.org (Postfix) with ESMTPSA id BFEC3C433C9; Thu, 6 Aug 2020 14:45:51 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Aug 2020 20:15:51 +0530 From: kalyan_t@codeaurora.org To: Rob Clark Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Krishna Manikandan , linux-arm-msm , Raviteja Tamatam , Linux Kernel Mailing List , dri-devel , Douglas Anderson , nganji@codeaurora.org, Sean Paul , Abhinav Kumar , Drew Davenport , "Kristian H. Kristensen" , Stephen Boyd , freedreno Subject: Re: [Freedreno] [v1] drm/msm/dpu: Fix reservation failures in modeset In-Reply-To: References: <1596634446-1413-1-git-send-email-kalyan_t@codeaurora.org> Message-ID: <1101abba0c8082da196f36636ef07a84@codeaurora.org> X-Sender: kalyan_t@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-08-05 21:18, Rob Clark wrote: > On Wed, Aug 5, 2020 at 6:34 AM Kalyan Thota > wrote: >> >> In TEST_ONLY commit, rm global_state will duplicate the >> object and request for new reservations, once they pass >> then the new state will be swapped with the old and will >> be available for the Atomic Commit. >> >> This patch fixes some of missing links in the resource >> reservation sequence mentioned above. >> >> 1) Creation of a duplicate state in test_only commit (Rob) >> 2) Allow resource release only during crtc_active false. >> >> For #2 >> In a modeset operation, swap state happens well before disable. >> Hence clearing reservations in disable will cause failures >> in modeset enable. >> >> Sequence: >> Swap state --> old, new >> modeset disables --> virt disable >> modeset enable --> virt modeset >> >> Allow reservations to be cleared only when crtc active is false >> as in that case there wont be any modeset enable after disable. >> >> Signed-off-by: Kalyan Thota >> --- >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c >> index 63976dc..b85a576 100644 >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c >> @@ -582,7 +582,7 @@ static int dpu_encoder_virt_atomic_check( >> dpu_kms = to_dpu_kms(priv->kms); >> mode = &crtc_state->mode; >> adj_mode = &crtc_state->adjusted_mode; >> - global_state = dpu_kms_get_existing_global_state(dpu_kms); >> + global_state = dpu_kms_get_global_state(crtc_state->state); >> trace_dpu_enc_atomic_check(DRMID(drm_enc)); >> >> /* >> @@ -1172,6 +1172,7 @@ static void dpu_encoder_virt_disable(struct >> drm_encoder *drm_enc) >> struct msm_drm_private *priv; >> struct dpu_kms *dpu_kms; >> struct dpu_global_state *global_state; >> + struct drm_crtc_state *crtc_state; >> int i = 0; >> >> if (!drm_enc) { >> @@ -1191,6 +1192,7 @@ static void dpu_encoder_virt_disable(struct >> drm_encoder *drm_enc) >> priv = drm_enc->dev->dev_private; >> dpu_kms = to_dpu_kms(priv->kms); >> global_state = dpu_kms_get_existing_global_state(dpu_kms); >> + crtc_state = drm_enc->crtc->state; >> >> trace_dpu_enc_disable(DRMID(drm_enc)); >> >> @@ -1220,7 +1222,8 @@ static void dpu_encoder_virt_disable(struct >> drm_encoder *drm_enc) >> >> DPU_DEBUG_ENC(dpu_enc, "encoder disabled\n"); >> >> - dpu_rm_release(global_state, drm_enc); >> + if (crtc_state->active_changed && !crtc_state->active) >> + dpu_rm_release(global_state, drm_enc); > > I still think releasing the state in the atomic_commit() path is the > wrong thing to do. In the commit path, the various state objects > should be immutable.. ie. in the atomic_test() path you derive the new > hw state (including assignment/release of resources), and > atomic_commit() is simply pushing the state down to the hw. > > Otherwise, this looks better than v1. > > BR, > -R > okay. Should we avoid reservation all together if active=0 on that crtc and trigger rm_release on the enc during atomic_check ? how do you see the approach ? -Kalyan >> >> mutex_unlock(&dpu_enc->enc_lock); >> } >> -- >> 1.9.1 >> > _______________________________________________ > Freedreno mailing list > Freedreno@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/freedreno