From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
Rob Clark <robdclark@gmail.com>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
devicetree@vger.kernel.org,
Neil Armstrong <neil.armstrong@linaro.org>
Subject: Re: [PATCH v2 2/7] soc: qcom: smem: Add a feature code getter
Date: Thu, 18 Apr 2024 11:53:31 +0200 [thread overview]
Message-ID: <89eccb1f-c527-4820-a084-7fc4ad3f0ab4@linaro.org> (raw)
In-Reply-To: <mg6ojmzl3snj3k6fuyi6opkbdovs7xna6sn65pjh52ii4yy7u6@ny2spvjjbfpu>
On 18.04.2024 1:39 AM, Dmitry Baryshkov wrote:
> On Wed, Apr 17, 2024 at 10:02:54PM +0200, Konrad Dybcio wrote:
>> Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely
>> identifying the specific SKU and the precise speed bin (in the general
>> meaning of this word, anyway): a pair of values called Product Code
>> and Feature Code.
>>
>> Based on this information, we can deduce the available frequencies for
>> things such as Adreno. In the case of Adreno specifically, Pcode is
>> useless for non-prototype SoCs.
>>
>> Introduce a getter for the feature code and export it.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
[...]
>> +/* Internal feature codes */
>> +/* Valid values: 0 <= n <= 0xf */
>> +#define SOCINFO_FC_Yn(n) (0xf1 + n)
>> +#define SOCINFO_FC_INT_MAX SOCINFO_FC_Yn(0x10)
>
> This is 0x101 rather than 0x100 or 0xff. Is that expected?
Yes, this is "the first invalid one", similar to ENUMNAME_NUM
>
>> +
>> +/* Product codes */
>> +#define SOCINFO_PC_UNKNOWN 0
>> +#define SOCINFO_PCn(n) (n + 1)
>> +#define SOCINFO_PC_RESERVE (BIT(31) - 1)
>
> This patch works on fcodes, why do we have PCode defines here?
I decided they're useful to keep.. Didn't want to split them to a separate
patch for no reason.
Konrad
next prev parent reply other threads:[~2024-04-18 9:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 20:02 [PATCH v2 0/7] Add SMEM-based speedbin matching Konrad Dybcio
2024-04-17 20:02 ` [PATCH v2 1/7] soc: qcom: Move some socinfo defines to the header Konrad Dybcio
2024-04-17 20:02 ` [PATCH v2 2/7] soc: qcom: smem: Add a feature code getter Konrad Dybcio
2024-04-17 23:39 ` Dmitry Baryshkov
2024-04-18 9:53 ` Konrad Dybcio [this message]
2024-04-18 11:06 ` Dmitry Baryshkov
2024-05-28 21:06 ` Bjorn Andersson
2024-04-17 20:02 ` [PATCH v2 3/7] drm/msm/adreno: Implement SMEM-based speed bin Konrad Dybcio
2024-04-17 23:43 ` Dmitry Baryshkov
2024-04-18 9:51 ` Konrad Dybcio
2024-04-18 11:07 ` Dmitry Baryshkov
2024-04-18 11:31 ` Konrad Dybcio
2024-04-18 11:48 ` Dmitry Baryshkov
2024-04-17 20:02 ` [PATCH v2 4/7] drm/msm/adreno: Add speedbin data for SM8550 / A740 Konrad Dybcio
2024-04-17 23:44 ` Dmitry Baryshkov
2024-04-17 20:02 ` [PATCH v2 5/7] drm/msm/adreno: Define A530 speed bins explicitly Konrad Dybcio
2024-04-17 23:44 ` Dmitry Baryshkov
2024-04-17 20:02 ` [PATCH v2 6/7] drm/msm/adreno: Redo the speedbin assignment Konrad Dybcio
2024-04-17 23:49 ` Dmitry Baryshkov
2024-04-18 9:57 ` Konrad Dybcio
2024-04-18 11:29 ` Dmitry Baryshkov
2024-04-17 20:02 ` [PATCH v2 7/7] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs Konrad Dybcio
2024-04-17 23:49 ` Dmitry Baryshkov
-- strict thread matches above, loose matches on Subject: below --
2024-06-05 20:10 [PATCH v2 0/7] Add SMEM-based speedbin matching Konrad Dybcio
2024-06-05 20:10 ` [PATCH v2 2/7] soc: qcom: smem: Add a feature code getter 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=89eccb1f-c527-4820-a084-7fc4ad3f0ab4@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.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 \
/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;
as well as URLs for NNTP newsgroup(s).