From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: neil.armstrong@linaro.org,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Konrad Dybcio <konradybcio@kernel.org>,
Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Dmitry Baryshkov <lumag@kernel.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: Marijn Suijten <marijn.suijten@somainline.org>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org,
Konrad Dybcio <konrad.dybcio@linaro.org>
Subject: Re: [PATCH RFT v6 2/5] drm/msm/adreno: Add speedbin data for SM8550 / A740
Date: Wed, 30 Apr 2025 17:36:42 +0200 [thread overview]
Message-ID: <281ab1b6-498e-4b29-9e15-19b5aae25342@oss.qualcomm.com> (raw)
In-Reply-To: <a26213ec-808f-4edf-bb0d-ab469ee0a884@linaro.org>
On 4/30/25 4:49 PM, neil.armstrong@linaro.org wrote:
> On 30/04/2025 15:09, Konrad Dybcio wrote:
>> On 4/30/25 2:49 PM, neil.armstrong@linaro.org wrote:
>>> On 30/04/2025 14:35, Konrad Dybcio wrote:
>>>> On 4/30/25 2:26 PM, neil.armstrong@linaro.org wrote:
>>>>> Hi,
>>>>>
>>>>> On 30/04/2025 13:34, Konrad Dybcio wrote:
>>>>>> From: Konrad Dybcio <konrad.dybcio@linaro.org>
>>>>>>
>>>>>> Add speebin data for A740, as found on SM8550 and derivative SoCs.
>>>>>>
>>>>>> For non-development SoCs it seems that "everything except FC_AC, FC_AF
>>>>>> should be speedbin 1", but what the values are for said "everything" are
>>>>>> not known, so that's an exercise left to the user..
>>>>>>
>>>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>>>>> ---
>>>>>> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 8 ++++++++
>>>>>> 1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
>>>>>> index 53e2ff4406d8f0afe474aaafbf0e459ef8f4577d..61daa331567925e529deae5e25d6fb63a8ba8375 100644
>>>>>> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
>>>>>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
>>>>>> @@ -11,6 +11,9 @@
>>>>>> #include "a6xx.xml.h"
>>>>>> #include "a6xx_gmu.xml.h"
>>>>>> +#include <linux/soc/qcom/smem.h>
>>>>>> +#include <linux/soc/qcom/socinfo.h>
>>>>>> +
>>>>>> static const struct adreno_reglist a612_hwcg[] = {
>>>>>> {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x22222222},
>>>>>> {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x02222220},
>>>>>> @@ -1431,6 +1434,11 @@ static const struct adreno_info a7xx_gpus[] = {
>>>>>> },
>>>>>> .address_space_size = SZ_16G,
>>>>>> .preempt_record_size = 4192 * SZ_1K,
>>>>>> + .speedbins = ADRENO_SPEEDBINS(
>>>>>> + { ADRENO_SKU_ID(SOCINFO_FC_AC), 0 },
>>>>>> + { ADRENO_SKU_ID(SOCINFO_FC_AF), 0 },
>>>>>> + /* Other feature codes (on prod SoCs) should match to speedbin 1 */
>>>>>
>>>>> I'm trying to understand this sentence. because reading patch 4, when there's no match
>>>>> devm_pm_opp_set_supported_hw() is simply never called so how can it match speedbin 1 ?
>>>>
>>>> What I'm saying is that all other entries that happen to be possibly
>>>> added down the line are expected to be speedbin 1 (i.e. BIT(1))
>>>>
>>>>> Before this change the fallback was speedbin = BIT(0), but this disappeared.
>>>>
>>>> No, the default was to allow speedbin mask ~(0U)
>>>
>>> Hmm no:
>>>
>>> supp_hw = fuse_to_supp_hw(info, speedbin);
>>>
>>> if (supp_hw == UINT_MAX) {
>>> DRM_DEV_ERROR(dev,
>>> "missing support for speed-bin: %u. Some OPPs may not be supported by hardware\n",
>>> speedbin);
>>> supp_hw = BIT(0); /* Default */
>>> }
>>>
>>> ret = devm_pm_opp_set_supported_hw(dev, &supp_hw, 1);
>>> if (ret)
>>> return ret;
>>
>> Right, that's my own code even..
>>
>> in any case, the kernel can't know about the speed bins that aren't
>> defined and here we only define bin0, which doesn't break things
>>
>> the kernel isn't aware about hw with bin1 with or without this change
>> so it effectively doesn't matter
>
> But it's regression for the other platforms, where before an unknown SKU
> mapped to supp_hw=BIT(0)
>
> Not calling devm_pm_opp_set_supported_hw() is a major regression,
> if the opp-supported-hw is present, the OPP will be rejected:
A comment in patch 4 explains that. We can either be forwards or backwards
compatible (i.e. accept a limited amount of
speedbin_in_driver x speedbin_in_dt combinations)
Konrad
next prev parent reply other threads:[~2025-04-30 15:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 11:34 [RFT PATCH v6 0/5] Add SMEM-based speedbin matching Konrad Dybcio
2025-04-30 11:34 ` [PATCH RFT v6 1/5] drm/msm/adreno: Implement SMEM-based speed bin Konrad Dybcio
2025-04-30 16:20 ` neil.armstrong
2025-04-30 16:25 ` Konrad Dybcio
2025-04-30 11:34 ` [PATCH RFT v6 2/5] drm/msm/adreno: Add speedbin data for SM8550 / A740 Konrad Dybcio
2025-04-30 12:26 ` neil.armstrong
2025-04-30 12:35 ` Konrad Dybcio
2025-04-30 12:49 ` neil.armstrong
2025-04-30 13:09 ` Konrad Dybcio
2025-04-30 14:49 ` neil.armstrong
2025-04-30 15:36 ` Konrad Dybcio [this message]
2025-04-30 16:19 ` neil.armstrong
2025-04-30 16:39 ` Konrad Dybcio
2025-04-30 16:56 ` neil.armstrong
2025-05-01 9:29 ` Akhil P Oommen
2025-05-01 15:53 ` Konrad Dybcio
2025-05-11 9:51 ` Akhil P Oommen
2025-05-22 16:02 ` Konrad Dybcio
2025-05-22 17:33 ` Rob Clark
2025-04-30 11:34 ` [PATCH RFT v6 3/5] drm/msm/adreno: Define A530 speed bins explicitly Konrad Dybcio
2025-04-30 11:34 ` [PATCH RFT v6 4/5] drm/msm/adreno: Redo the speedbin assignment Konrad Dybcio
2025-04-30 11:34 ` [PATCH RFT v6 5/5] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs Konrad Dybcio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=281ab1b6-498e-4b29-9e15-19b5aae25342@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=konrad.dybcio@linaro.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=robh@kernel.org \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®