Message ID | 20240221-rb3gen2-dp-connector-v1-3-dc0964ef7d96@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-75647-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp1353667dyc; Wed, 21 Feb 2024 15:22:27 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVsCbHe7xS6d+HXhnjWdQ7ywlGGWDRZSwD22I7Hn1DdH4MM6cZQb7u4Xf73HZoK1F4oy+XVpYVYqxApjnqfe0KJ+kNU2A== X-Google-Smtp-Source: AGHT+IF5gZ7RtV9XAvmLDF4FnBSUIBnfb7Gv/8M1cQHFbB/cbKm+kRdyb1Il1EPqFuTOuK+5J2g5 X-Received: by 2002:a17:906:b154:b0:a3e:cb72:b6fd with SMTP id bt20-20020a170906b15400b00a3ecb72b6fdmr5800310ejb.23.1708557747011; Wed, 21 Feb 2024 15:22:27 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708557747; cv=pass; d=google.com; s=arc-20160816; b=OrKQPKKlPZSCWqQhD7RTss3CvCqklYIvvUf3XavHxwZQrXjR/iFmTMEnq2yKYzUm0y vafWqrqZ4JZemphoToPB5kK2CvJuSdJ6ZNjH00OIpcMuwiasHLR98brryCfPQce0YF6Z niKd/86uBpcudV6QQvF2Lb6XE3oODBD2TaypBZlwu5An3F2SMMw+LNfaDTq6xa36Vqbo LMMxeNAbQeC4lJwqwgFC33Msc03n9xpElHf/B4Fyu+T2f8BHnNIM1KRRO9Zyv//pUq6q o/0iaWZYba4FvZF1QeW6Tr9ovQ2GZ83309MlV0hKZhPBRwtCSyRfM0nZz1tSWrg9ZuCI LM5g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=eicjotqJSX3Vn/q7yvGI9f0Q6Wk1DQ3G27dFMziKxn0=; fh=Ph3D4iPhMs0qfrBSt7uGZnxnp3Fv4RZ3r2ELq4z6NQk=; b=Q8PqxqJ8hdPnJLqFi4Azxohe5IdY4vhaT+0jIiidfoRNK/0hq+2Xozc58b8brVx9DX uObbC/dypiRu9NtYLOzNzg0O/vSVzeG4S4m6mOr/hHGOh5wXgKCHAT7lSkoXBYLkuBIu qeiOf+f7G6fAKfXkvtYmKzIxw1CSLUyVi2ohtLGmDM2BBN3FbSrdWg03IM5GwB/ls/Yf u5D+zUPF3XQhQ5b+hQ1d65oTgvAUc4hHbjVTqYU8XXKTCxftAadfemqo3KZkn+urgAb2 mhebPM1Yq7QbfYBCwMrRlbSFzjJRR1scwTkqFk5hystDVmgMHJo/DJytu8Ntr/uzeE1/ QnDA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=PpWfroAc; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-75647-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75647-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id q10-20020a17090622ca00b00a3f801882a7si43029eja.257.2024.02.21.15.22.26 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 15:22:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-75647-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=PpWfroAc; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-75647-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75647-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 964BB1F22240 for <ouuuleilei@gmail.com>; Wed, 21 Feb 2024 23:22:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 05A0513A245; Wed, 21 Feb 2024 23:19:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="PpWfroAc" Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5640A35; Wed, 21 Feb 2024 23:19:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708557569; cv=none; b=sC0Z8h99Z8IivdiQZCCe7XN2YNigfkBUJIu2fBg9d5DykDEDm9FG7mN+/tZtAyeHGIE3Hq3oBttbs+zgsbgYCaiNBxkMH4jY9je1flIVmW8ni6DKMG1NGDCfr95hzXqOdXT/6gSErvQaUVgSEy6Jq3AeNa6Qk1ZTHrEwXnPyTco= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708557569; c=relaxed/simple; bh=TzgXSNqdw1xftuAst6wUaXVUR3Uyud3mYme9WvyGVV4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-ID:References: In-Reply-To:To:CC; b=szT9bdgAW2LoiVqxM2E8Vl538h3e3TAL9VnoVPlE/0k3q8GaBQQy6RmdoK9RJl1dyWpSafrcxDGw4wt3HlyLj7aepyaslKVEIsA3c9FZEaOT4YPIPFuXppKXGvHNgDpAOVpG1b3yxZeWCEoszyAydOjh0TwzIwXzikU5Ecc4Pw0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=PpWfroAc; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 41LMcmGk003186; Wed, 21 Feb 2024 23:19:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= from:date:subject:mime-version:content-type :content-transfer-encoding:message-id:references:in-reply-to:to :cc; s=qcppdkim1; bh=eicjotqJSX3Vn/q7yvGI9f0Q6Wk1DQ3G27dFMziKxn0 =; b=PpWfroAcgvPImN6kSdCjKOJZDHUpc7e4WcTHFwNVAPiVVf+mbXKghcUxtP7 gneJfwZQR5Ddmor56LmxLXv14xC7Mvzn4biHeI4DzzvoxhcKE3GrQgD8EQ+qsA35 Z9bRZPQl23iHtZoPmcQ29morO1CSbQWM4LQCHd9nEHVzuf0OZ2MAA5glQO6pG086 7QreIV5aKPd+dS3WOR/I4+UmSXXN6b09Mn4f7o61V/Zxq2r5F6/9khhLhDDIccfh 2kcII0I5xSFcXBnZ9ACLOK6fDMHwbVl28nyLsyGvaHUTCUzR8iL7hcOXz4BJV+2k tLyeOI7X6e9jePawFEn3x+KEZwg== Received: from nalasppmta05.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3wdgge1jwn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Feb 2024 23:19:15 +0000 (GMT) Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA05.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 41LNJE7Q013459 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Feb 2024 23:19:14 GMT Received: from [169.254.0.1] (10.49.16.6) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Wed, 21 Feb 2024 15:19:14 -0800 From: Bjorn Andersson <quic_bjorande@quicinc.com> Date: Wed, 21 Feb 2024 15:19:11 -0800 Subject: [PATCH 3/9] arm64: dts: qcom: sc7280: Enable MDP turbo mode Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <20240221-rb3gen2-dp-connector-v1-3-dc0964ef7d96@quicinc.com> References: <20240221-rb3gen2-dp-connector-v1-0-dc0964ef7d96@quicinc.com> In-Reply-To: <20240221-rb3gen2-dp-connector-v1-0-dc0964ef7d96@quicinc.com> To: Rob Clark <robdclark@gmail.com>, Abhinav Kumar <quic_abhinavk@quicinc.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Sean Paul <sean@poorly.run>, Marijn Suijten <marijn.suijten@somainline.org>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, <cros-qcom-dts-watchers@chromium.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> CC: <linux-arm-msm@vger.kernel.org>, <dri-devel@lists.freedesktop.org>, <freedreno@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, Bjorn Andersson <quic_bjorande@quicinc.com> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=ed25519-sha256; t=1708557553; l=884; i=quic_bjorande@quicinc.com; s=20230915; h=from:subject:message-id; bh=TzgXSNqdw1xftuAst6wUaXVUR3Uyud3mYme9WvyGVV4=; b=UhzzoDerfTeKx+51HM0Flkb9dOiLD0Pis8KPZAWdRsrKjFN1c/9aVPnDpxyCZvo1poA4/57f4 hdc9XXmdewtBk+r7qNOMavk1t3HeKoJAmAxeu/vkzj3ScVOG2P4ULfD X-Developer-Key: i=quic_bjorande@quicinc.com; a=ed25519; pk=VkhObtljigy9k0ZUIE1Mvr0Y+E1dgBEH9WoLQnUtbIM= X-ClientProxiedBy: nalasex01c.na.qualcomm.com (10.47.97.35) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: ckDOjuBzP1iExCre3YPqDjIkzYFZ14mr X-Proofpoint-ORIG-GUID: ckDOjuBzP1iExCre3YPqDjIkzYFZ14mr X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-21_09,2024-02-21_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 clxscore=1015 spamscore=0 malwarescore=0 suspectscore=0 impostorscore=0 mlxscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 mlxlogscore=987 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2402120000 definitions=main-2402210184 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791552647979844371 X-GMAIL-MSGID: 1791552647979844371 |
Series |
arm64: dts: qcom: qcs6490-rb3gen2: Enable two displays
|
|
Commit Message
Bjorn Andersson
Feb. 21, 2024, 11:19 p.m. UTC
The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60 display, resulting in constant underrun.
Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to
fix this.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > The max frequency listed in the DPU opp-table is 506MHz, this is not > sufficient to drive a 4k@60 display, resulting in constant underrun. > > Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > fix this. I think we might want to keep this disabled for ChromeOS devices. Doug? > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > arch/arm64/boot/dts/qcom/sc7280.dtsi | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > index a19c278ebec9..a2a6717c6c87 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > @@ -4417,6 +4417,11 @@ opp-506666667 { > opp-hz = /bits/ 64 <506666667>; > required-opps = <&rpmhpd_opp_nom>; > }; > + > + opp-608000000 { > + opp-hz = /bits/ 64 <608000000>; > + required-opps = <&rpmhpd_opp_turbo>; > + }; > }; > }; > > > -- > 2.25.1 >
On 2/22/24 00:19, Bjorn Andersson wrote: > The max frequency listed in the DPU opp-table is 506MHz, this is not > sufficient to drive a 4k@60 display, resulting in constant underrun. > > Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > fix this. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Konrad
On 2/22/24 00:41, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >> >> The max frequency listed in the DPU opp-table is 506MHz, this is not >> sufficient to drive a 4k@60 display, resulting in constant underrun. >> >> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >> fix this. > > I think we might want to keep this disabled for ChromeOS devices. Doug? ChromeOS devices don't get a special SoC Konrad
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > On 2/22/24 00:41, Dmitry Baryshkov wrote: > > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > >> > >> The max frequency listed in the DPU opp-table is 506MHz, this is not > >> sufficient to drive a 4k@60 display, resulting in constant underrun. > >> > >> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > >> fix this. > > > > I think we might want to keep this disabled for ChromeOS devices. Doug? > > ChromeOS devices don't get a special SoC But they have the sc7280-chrome-common.dtsi, which might contain a corresponding /delete-node/ .
On 2/22/24 10:04, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 2/22/24 00:41, Dmitry Baryshkov wrote: >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >>>> >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. >>>> >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >>>> fix this. >>> >>> I think we might want to keep this disabled for ChromeOS devices. Doug? >> >> ChromeOS devices don't get a special SoC > > But they have the sc7280-chrome-common.dtsi, which might contain a > corresponding /delete-node/ . What does that change? The clock rates are bound to the SoC and the effective values are limited by link-frequencies or the panel driver. Konrad
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > >> > >> > >> > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > >>>> > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > >>>> > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > >>>> fix this. > >>> > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > >> > >> ChromeOS devices don't get a special SoC > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > corresponding /delete-node/ . > > What does that change? The clock rates are bound to the > SoC and the effective values are limited by link-frequencies > or the panel driver. Preventing the DPU from overheating? Or spending too much power?
On 2/22/24 10:46, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 2/22/24 10:04, Dmitry Baryshkov wrote: >>> On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >>>> >>>> >>>> >>>> On 2/22/24 00:41, Dmitry Baryshkov wrote: >>>>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >>>>>> >>>>>> The max frequency listed in the DPU opp-table is 506MHz, this is not >>>>>> sufficient to drive a 4k@60 display, resulting in constant underrun. >>>>>> >>>>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >>>>>> fix this. >>>>> >>>>> I think we might want to keep this disabled for ChromeOS devices. Doug? >>>> >>>> ChromeOS devices don't get a special SoC >>> >>> But they have the sc7280-chrome-common.dtsi, which might contain a >>> corresponding /delete-node/ . >> >> What does that change? The clock rates are bound to the >> SoC and the effective values are limited by link-frequencies >> or the panel driver. > > Preventing the DPU from overheating? ????????????? > Or spending too much power? Would it not concern non-Chrome SC7280s too, then? Konrad
On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > >> > > >> > > >> > > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > >>>> > > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > > >>>> > > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > > >>>> fix this. > > >>> > > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > > >> > > >> ChromeOS devices don't get a special SoC > > > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > > corresponding /delete-node/ . > > > > What does that change? The clock rates are bound to the > > SoC and the effective values are limited by link-frequencies > > or the panel driver. > > Preventing the DPU from overheating? Or spending too much power? > Perhaps I'm misunderstanding the implementation then, are we always running at the max opp? I thought the opp was selected based on the current need for performance? Regards, Bjorn > -- > With best wishes > Dmitry
On Thu, 22 Feb 2024 at 17:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote: > > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > >> > > > >> > > > >> > > > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > > > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > > >>>> > > > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > > > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > > > >>>> > > > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > > > >>>> fix this. > > > >>> > > > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > > > >> > > > >> ChromeOS devices don't get a special SoC > > > > > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > > > corresponding /delete-node/ . > > > > > > What does that change? The clock rates are bound to the > > > SoC and the effective values are limited by link-frequencies > > > or the panel driver. > > > > Preventing the DPU from overheating? Or spending too much power? > > > > Perhaps I'm misunderstanding the implementation then, are we always > running at the max opp? I thought the opp was selected based on the > current need for performance? Yes. My concern was whether the Chrome people purposely skipped this top/turbo freq for any reason. In such a case, surprising them by adding it to all platforms might be not the best idea. I hope Doug can comment here.
On 2/22/2024 1:46 AM, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 2/22/24 10:04, Dmitry Baryshkov wrote: >>> On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >>>> >>>> >>>> >>>> On 2/22/24 00:41, Dmitry Baryshkov wrote: >>>>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >>>>>> >>>>>> The max frequency listed in the DPU opp-table is 506MHz, this is not >>>>>> sufficient to drive a 4k@60 display, resulting in constant underrun. >>>>>> >>>>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >>>>>> fix this. >>>>> >>>>> I think we might want to keep this disabled for ChromeOS devices. Doug? >>>> >>>> ChromeOS devices don't get a special SoC >>> >>> But they have the sc7280-chrome-common.dtsi, which might contain a >>> corresponding /delete-node/ . >> >> What does that change? The clock rates are bound to the >> SoC and the effective values are limited by link-frequencies >> or the panel driver. > > Preventing the DPU from overheating? Or spending too much power? > Running DPU clock in turbo is a requirement to support 4k@60 otherwise the pixel rate that high cannot be supported. sc7280 chrome devices already limit to HBR2 https://lore.kernel.org/all/20230329233416.27152-1-quic_abhinavk@quicinc.com/ So the DPU will not vote more than nominal. And like others wrote, limiting SOC frequencies is not the way and we should filter out required frequencies using link-frequencies. Hence fwiw, I am fine with this change. Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Hi, On Thu, Feb 22, 2024 at 9:32 AM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Thu, 22 Feb 2024 at 17:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > > > On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote: > > > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > > > > > > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > > > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaroorg> wrote: > > > > >> > > > > >> > > > > >> > > > > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > > > > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > > > >>>> > > > > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > > > > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > > > > >>>> > > > > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > > > > >>>> fix this. > > > > >>> > > > > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > > > > >> > > > > >> ChromeOS devices don't get a special SoC > > > > > > > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > > > > corresponding /delete-node/ . > > > > > > > > What does that change? The clock rates are bound to the > > > > SoC and the effective values are limited by link-frequencies > > > > or the panel driver. > > > > > > Preventing the DPU from overheating? Or spending too much power? > > > > > > > Perhaps I'm misunderstanding the implementation then, are we always > > running at the max opp? I thought the opp was selected based on the > > current need for performance? > > Yes. My concern was whether the Chrome people purposely skipped this > top/turbo freq for any reason. In such a case, surprising them by > adding it to all platforms might be not the best idea. I hope Doug can > comment here. Thanks for thinking of us! In this case, I think the only users left of the sc7280 Chrome devices are folks like Rob and then a few folks on Qualcomm's display team (like Abhinav), so if they're happy with the change then I have no objections. In any case, I'm not aware of any reason why this would have been skipped for Chrome. The Chrome devices were always intended to support 4K so I assume this was an oversight and nothing more. ...of course, as Abhinav points out Chrome devices are currently limited to HBR2 + 2 lanes DP so they can't go 4K60 anyway. In any case, in case it matters, feel free to have: Acked-by: Douglas Anderson <dianders@chromium.org>
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index a19c278ebec9..a2a6717c6c87 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -4417,6 +4417,11 @@ opp-506666667 { opp-hz = /bits/ 64 <506666667>; required-opps = <&rpmhpd_opp_nom>; }; + + opp-608000000 { + opp-hz = /bits/ 64 <608000000>; + required-opps = <&rpmhpd_opp_turbo>; + }; }; };