From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35A61C77B7A for ; Wed, 19 Apr 2023 19:49:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231376AbjDSTtB (ORCPT ); Wed, 19 Apr 2023 15:49:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230237AbjDSTs7 (ORCPT ); Wed, 19 Apr 2023 15:48:59 -0400 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3577444AE for ; Wed, 19 Apr 2023 12:48:57 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2a8ad872ea5so409011fa.2 for ; Wed, 19 Apr 2023 12:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1681933735; x=1684525735; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZTyNKupNsXf2g+91PrPeU2a11PGoDFN20zA7SNUiqa0=; b=MMVV0oI5iZoLMSWrFHuxhrPHwJWEwWo9NDFSTsUMvnDuxZ+ftMo4+2t6pSqxU/9zmJ mJUFGHmFF2pV4n4Id8zA4IIb3ilQOlhiHMhX4mMxPIQyKQaeGNNvWKtP4PurPzpIhTkn oGTsuccZQM1EF0j7uvUbWVrUbGLhXq+13He/orOkcSzXMNoCNX4xK1SIjK2NMhusK+Na JuMFlyaJAEtG1hhtBW4em31/vbbQoD8sJTaRcZd9vMMXPU90sQBJ0HmV2B5gsod0c75t O9WgpZXhUexEQm42tyn8FN+8KiCi6gKXsDTSA+f7JNwh6Cks81lze41j4B8dxyWx5E1/ J5qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681933735; x=1684525735; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZTyNKupNsXf2g+91PrPeU2a11PGoDFN20zA7SNUiqa0=; b=AGOlmi4sbZZI4R/NCtOcBTwk9W3Gk+0VAEVf2LxQFlRbhsFlV2mfRWqcsCrI/dym/S 00NqOmyG4VT8a7ripYAfzqUlAa7aU4VjKr306RoDRyTx9c9L7poexN15pqyfM69UMuGa CUYv3uGBox1+1tNZLSW3ltWge0oM35vOewoAqVWT3pXCx9zH3iu6tHboVXEix+Rk5LbB 4VprEOxoQoXMm41KbmHBSmOuMws80Q5mHWF1ALwgZWRnIR150Ngx877PmRt5j9SQNxL+ u6QFd2/jQ9W+eU5BwugbJiOIsfmO0X7TkGrbyDu3o6zHkuWSfl1MazFm2wQLxZZPSOAU PZ1A== X-Gm-Message-State: AAQBX9cnJswo0iQOQMzJUDPKnNtgnc95tFaK0K86hDjNuRczv2w7GJmt DvoHJWMz/nxrxcu254OAD9tEnA== X-Google-Smtp-Source: AKy350YKG23tnDYXxO75yYLkS8XJe3vIMC1X4eB1eASmgz1L1is/D1f87aLJjfvgYP27+NZxb0G9wg== X-Received: by 2002:a19:740a:0:b0:4ec:92e4:e0c3 with SMTP id v10-20020a19740a000000b004ec92e4e0c3mr4073568lfe.62.1681933735325; Wed, 19 Apr 2023 12:48:55 -0700 (PDT) Received: from [192.168.1.101] (abyj144.neoplus.adsl.tpnet.pl. [83.9.29.144]) by smtp.gmail.com with ESMTPSA id 7-20020ac25687000000b004edc2a023ffsm1351395lfr.36.2023.04.19.12.48.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Apr 2023 12:48:54 -0700 (PDT) Message-ID: Date: Wed, 19 Apr 2023 21:48:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [Freedreno] [PATCH 5/5] drm/msm/dpu1: Handle the reg bus ICC path Content-Language: en-US To: Jeykumar Sankaran , Rob Clark , Abhinav Kumar , Dmitry Baryshkov , Sean Paul , David Airlie , Daniel Vetter , Rob Herring , Krzysztof Kozlowski , Krishna Manikandan Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Marijn Suijten , freedreno@lists.freedesktop.org References: <20230417-topic-dpu_regbus-v1-0-06fbdc1643c0@linaro.org> <20230417-topic-dpu_regbus-v1-5-06fbdc1643c0@linaro.org> <11c72462-b256-d0db-a666-9615da4420f6@quicinc.com> From: Konrad Dybcio In-Reply-To: <11c72462-b256-d0db-a666-9615da4420f6@quicinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 19.04.2023 21:06, Jeykumar Sankaran wrote: > > > On 4/17/2023 8:30 AM, Konrad Dybcio wrote: >> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's >> another path that needs to be handled to ensure MDSS functions properly, >> namely the "reg bus", a.k.a the CPU-MDSS interconnect. >> >> Gating that path may have a variety of effects.. from none to otherwise >> inexplicable DSI timeouts.. >> >> On the DPU side, we need to keep the bus alive. The vendor driver >> kickstarts it to max (300Mbps) throughput on first commit, but in >> exchange for some battery life in rare DPU-enabled-panel-disabled >> usecases, we can request it at DPU init and gate it at suspend. >> >> Signed-off-by: Konrad Dybcio >> --- >>   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 22 ++++++++++++++++++++-- >>   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |  1 + >>   2 files changed, 21 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c >> index dd6c1c40ab9e..d1f77faebbc0 100644 >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c >> @@ -384,15 +384,17 @@ static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms) >>       return 0; >>   } >>   -static int dpu_kms_parse_data_bus_icc_path(struct dpu_kms *dpu_kms) >> +static int dpu_kms_parse_icc_paths(struct dpu_kms *dpu_kms) >>   { >>       struct icc_path *path0; >>       struct icc_path *path1; >> +    struct icc_path *reg_bus_path; >>       struct drm_device *dev = dpu_kms->dev; >>       struct device *dpu_dev = dev->dev; >>         path0 = msm_icc_get(dpu_dev, "mdp0-mem"); >>       path1 = msm_icc_get(dpu_dev, "mdp1-mem"); >> +    reg_bus_path = msm_icc_get(dpu_dev, "cpu-cfg"); >>         if (IS_ERR_OR_NULL(path0)) >>           return PTR_ERR_OR_ZERO(path0); >> @@ -404,6 +406,10 @@ static int dpu_kms_parse_data_bus_icc_path(struct dpu_kms *dpu_kms) >>           dpu_kms->mdp_path[1] = path1; >>           dpu_kms->num_mdp_paths++; >>       } >> + >> +    if (!IS_ERR_OR_NULL(reg_bus_path)) >> +        dpu_kms->reg_bus_path = reg_bus_path; >> + >>       return 0; >>   } >>   @@ -1039,7 +1045,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms) >>           DPU_DEBUG("REG_DMA is not defined"); >>       } >>   -    dpu_kms_parse_data_bus_icc_path(dpu_kms); >> +    dpu_kms_parse_icc_paths(dpu_kms); >>         rc = pm_runtime_resume_and_get(&dpu_kms->pdev->dev); >>       if (rc < 0) >> @@ -1241,6 +1247,9 @@ static int __maybe_unused dpu_runtime_suspend(struct device *dev) >>       for (i = 0; i < dpu_kms->num_mdp_paths; i++) >>           icc_set_bw(dpu_kms->mdp_path[i], 0, 0); >>   +    if (dpu_kms->reg_bus_path) >> +        icc_set_bw(dpu_kms->reg_bus_path, 0, 0); >> + >>       return 0; >>   } >>   @@ -1261,6 +1270,15 @@ static int __maybe_unused dpu_runtime_resume(struct device *dev) >>           return rc; >>       } >>   +    /* >> +     * The vendor driver supports setting 76.8 / 150 / 300 Mbps on this > How do you arrive at these distint BW values? Are they provided by the ICC fwk for the given path? They're hardcoded in the SDE driver. Konrad >> +     * path, but it seems to go for the highest level when display output >> +     * is enabled and zero otherwise. For simplicity, we can assume that >> +     * DPU being enabled and running implies that. >> +     */ >> +    if (dpu_kms->reg_bus_path) >> +        icc_set_bw(dpu_kms->reg_bus_path, 0, MBps_to_icc(300)); >> + >>       dpu_vbif_init_memtypes(dpu_kms); >>         drm_for_each_encoder(encoder, ddev) >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h >> index d5d9bec90705..c332381d58c4 100644 >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h >> @@ -111,6 +111,7 @@ struct dpu_kms { >>       atomic_t bandwidth_ref; >>       struct icc_path *mdp_path[2]; >>       u32 num_mdp_paths; >> +    struct icc_path *reg_bus_path; >>   }; >>     struct vsync_info { >>