From: Konrad Dybcio <konradybcio@kernel.org>
To: Akhil P Oommen <quic_akhilpo@quicinc.com>
Cc: Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
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,
Elliot Berman <quic_eberman@quicinc.com>
Subject: Re: [PATCH v5 1/5] drm/msm/adreno: Implement SMEM-based speed bin
Date: Mon, 29 Jul 2024 14:40:30 +0200 [thread overview]
Message-ID: <aaf74e25-ba24-454c-8bc1-c2b079d549e3@kernel.org> (raw)
In-Reply-To: <87607d2c-a4b1-4923-ba9f-9cfc56a0aa38@kernel.org>
On 29.07.2024 2:13 PM, Konrad Dybcio wrote:
> On 16.07.2024 1:56 PM, Konrad Dybcio wrote:
>> On 15.07.2024 10:04 PM, Akhil P Oommen wrote:
>>> On Tue, Jul 09, 2024 at 12:45:29PM +0200, Konrad Dybcio wrote:
>>>> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
>>>> abstracted through SMEM, instead of being directly available in a fuse.
>>>>
>>>> Add support for SMEM-based speed binning, which includes getting
>>>> "feature code" and "product code" from said source and parsing them
>>>> to form something that lets us match OPPs against.
>>>>
>>>> Due to the product code being ignored in the context of Adreno on
>>>> production parts (as of SM8650), hardcode it to SOCINFO_PC_UNKNOWN.
>>>>
>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>>> ---
>> [...]
>>
>>>>
>>>> - if (adreno_read_speedbin(dev, &speedbin) || !speedbin)
>>>> + if (adreno_read_speedbin(adreno_gpu, dev, &speedbin) || !speedbin)
>>>> speedbin = 0xffff;
>>>> - adreno_gpu->speedbin = (uint16_t) (0xffff & speedbin);
>>>> + adreno_gpu->speedbin = speedbin;
>>> There are some chipsets which uses both Speedbin and Socinfo data for
>>> SKU detection [1].
>> 0_0
>>
>>
>>> We don't need to worry about that logic for now. But
>>> I am worried about mixing Speedbin and SKU_ID in the UABI with this patch.
>>> It will be difficult when we have to expose both to userspace.
>>>
>>> I think we can use a separate bitfield to expose FCODE/PCODE. Currently,
>>> the lower 32 bit is reserved for chipid and 33-48 is reserved for speedbin,
>>> so I think we can use the rest of the 16 bits for SKU_ID. And within that
>>> 16bits, 12 bits should be sufficient for FCODE and the rest 8 bits
>>> reserved for future PCODE.
>> Right, sounds reasonable. Hopefully nothing overflows..
> +CC Elliot
>
> Would you know whether these sizes ^ are going to be sufficient for
> the foreseeable future?
Also Akhil, 12 + 8 > 16.. did you mean 8 bits for both P and FCODE? Or
12 for FCODE and 4 for PCODE?
Konrad
next prev parent reply other threads:[~2024-07-29 12:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 10:45 [PATCH v5 0/5] Add SMEM-based speedbin matching Konrad Dybcio
2024-07-09 10:45 ` [PATCH v5 1/5] drm/msm/adreno: Implement SMEM-based speed bin Konrad Dybcio
2024-07-15 20:04 ` Akhil P Oommen
2024-07-16 11:56 ` Konrad Dybcio
2024-07-29 12:13 ` Konrad Dybcio
2024-07-29 12:40 ` Konrad Dybcio [this message]
2024-07-29 14:40 ` Akhil P Oommen
2025-04-25 9:05 ` Konrad Dybcio
2025-05-01 9:17 ` Akhil P Oommen
2024-07-09 10:45 ` [PATCH v5 2/5] drm/msm/adreno: Add speedbin data for SM8550 / A740 Konrad Dybcio
2024-07-09 10:45 ` [PATCH v5 3/5] drm/msm/adreno: Define A530 speed bins explicitly Konrad Dybcio
2024-07-09 10:45 ` [PATCH v5 4/5] drm/msm/adreno: Redo the speedbin assignment Konrad Dybcio
2024-07-09 10:45 ` [PATCH v5 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=aaf74e25-ba24-454c-8bc1-c2b079d549e3@kernel.org \
--to=konradybcio@kernel.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=quic_abhinavk@quicinc.com \
--cc=quic_akhilpo@quicinc.com \
--cc=quic_eberman@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).