From: Akhil P Oommen <akhilpo@oss.qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Rob Clark <robin.clark@oss.qualcomm.com>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Sean Paul <sean@poorly.run>, Dmitry Baryshkov <lumag@kernel.org>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Jessica Zhang <jesszhan0024@gmail.com>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Jonathan Marek <jonathan@marek.ca>,
Jordan Crouse <jordan@cosmicpenguin.net>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Connor Abbott <cwabbott0@gmail.com>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 17/21] drm/msm/a8xx: Add support for Adreno X2-85 GPU
Date: Thu, 13 Nov 2025 02:37:37 +0530 [thread overview]
Message-ID: <7ece2feb-79ab-478e-936b-607cfda22707@oss.qualcomm.com> (raw)
In-Reply-To: <f9aafd73-fe4a-4399-a0c8-0da1c109283a@oss.qualcomm.com>
On 11/12/2025 8:11 PM, Konrad Dybcio wrote:
> On 11/10/25 5:37 PM, Akhil P Oommen wrote:
>> Adreno X2-85 GPU is found in the next generation of Qualcomm's compute
>> series chipset called Snapdragon X2 Elite (a.k.a Glymur). It is based
>> on the new A8x slice architecture and features up to 4 slices. Due to
>> the wider 12 channel DDR support, there is higher DDR bandwidth available
>> than previous generation to improve performance.
>>
>> Add a new entry in the catalog along with the necessary register
>> configurations to enable support for it.
>>
>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>> ---
>
> [...]
>
>> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 131 ++++++++++++++++++++++++++++++
>> drivers/gpu/drm/msm/adreno/a8xx_gpu.c | 3 +
>> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 ++
>> 3 files changed, 139 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
>> index fa3ae725f389..2e5b0573c212 100644
>> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
>> @@ -1625,6 +1625,108 @@ static const struct adreno_info a7xx_gpus[] = {
>> };
>> DECLARE_ADRENO_GPULIST(a7xx);
>>
>> +static const struct adreno_reglist_pipe x285_nonctxt_regs[] = {
>
> It's certainly not the same silicon, but a830 sets a bunch more regs
> here and has a lot more comments in kgsl. Could you check if any of
> these settings are required/beneficial?
This list will see more updates.
>
>
>> +static const u32 x285_protect_regs[] = {
>> + A6XX_PROTECT_RDONLY(0x00008, 0x039b),
>
> In case anyone asks, there are simply no registers before 0x8<<2
>
>> + A6XX_PROTECT_RDONLY(0x003b4, 0x008b),
>> + A6XX_PROTECT_NORDWR(0x00440, 0x001f),
>> + A6XX_PROTECT_RDONLY(0x00580, 0x005f),
>> + A6XX_PROTECT_NORDWR(0x005e0, 0x011f),
>> + A6XX_PROTECT_RDONLY(0x0074a, 0x0005),
>> + A6XX_PROTECT_RDONLY(0x00759, 0x0026),
>> + A6XX_PROTECT_RDONLY(0x00789, 0x0000),
>> + A6XX_PROTECT_RDONLY(0x0078c, 0x0013),
>> + A6XX_PROTECT_NORDWR(0x00800, 0x0029),
>> + A6XX_PROTECT_NORDWR(0x0082c, 0x0000),
>> + A6XX_PROTECT_NORDWR(0x00837, 0x00af),
>> + A6XX_PROTECT_RDONLY(0x008e7, 0x00c9),
>> + A6XX_PROTECT_NORDWR(0x008ec, 0x00c3),
>> + A6XX_PROTECT_NORDWR(0x009b1, 0x0250),
>> + A6XX_PROTECT_RDONLY(0x00ce0, 0x0001),
>> + A6XX_PROTECT_RDONLY(0x00df0, 0x0000),
>> + A6XX_PROTECT_NORDWR(0x00df1, 0x0000),
>> + A6XX_PROTECT_NORDWR(0x00e01, 0x0000),
>> + A6XX_PROTECT_NORDWR(0x00e03, 0x1fff),
>> + A6XX_PROTECT_NORDWR(0x03c00, 0x00c5),
>> + A6XX_PROTECT_RDONLY(0x03cc6, 0x0039),
>
> 830 has start=0x03cc6 len=0x1fff but that must be a bug unless a lot of
> registers have shifted from there.. I see there's perf counters so perhaps
> perfetto-proofing?
>
>> + A6XX_PROTECT_NORDWR(0x03d00, 0x1fff),
>> + A6XX_PROTECT_NORDWR(0x08600, 0x01ff),
>> + A6XX_PROTECT_NORDWR(0x08e00, 0x00ff),
>> + A6XX_PROTECT_RDONLY(0x08f00, 0x0000),
>> + A6XX_PROTECT_NORDWR(0x08f01, 0x01be),
>> + A6XX_PROTECT_NORDWR(0x09600, 0x01ff),
>> + A6XX_PROTECT_RDONLY(0x0981a, 0x02e5),
>> + A6XX_PROTECT_NORDWR(0x09e00, 0x01ff),
>> + A6XX_PROTECT_NORDWR(0x0a600, 0x01ff),
>> + A6XX_PROTECT_NORDWR(0x0a82e, 0x0000),
>> + A6XX_PROTECT_NORDWR(0x0ae00, 0x0006),
>
> 830 has len=4 here, with len=6 you can't write to GEN8_SP_NC_MODE_CNTL_2
> which I think may be useful for UMD
On A8x, all non-ctxt register configurations are moved to KMD.
>
>> + A6XX_PROTECT_NORDWR(0x0ae08, 0x0006),
>> + A6XX_PROTECT_NORDWR(0x0ae10, 0x00bf),
>> + A6XX_PROTECT_RDONLY(0x0aed0, 0x002f),
>> + A6XX_PROTECT_NORDWR(0x0af00, 0x027f),
>> + A6XX_PROTECT_NORDWR(0x0b600, 0x1fff),
>
> This carveout differs slightly vs 830 but I think that's mandated
>
>> + A6XX_PROTECT_NORDWR(0x0dc00, 0x1fff),
>> + A6XX_PROTECT_RDONLY(0x0fc00, 0x1fff),
>> + A6XX_PROTECT_NORDWR(0x18400, 0x003f),
>> + A6XX_PROTECT_RDONLY(0x18440, 0x013f),
>> + A6XX_PROTECT_NORDWR(0x18580, 0x1fff),
>> + A6XX_PROTECT_NORDWR(0x1b400, 0x1fff),
>> + A6XX_PROTECT_NORDWR(0x1f400, 0x0477),
>> + A6XX_PROTECT_RDONLY(0x1f878, 0x0507),
>
> This differs vs a830 but it's kgsl that has a harmless? logic bug:
>
> { GEN8_CP_PROTECT_REG_GLOBAL + 40, 0x1f400, 0x1f877, 1 },
> { GEN8_CP_PROTECT_REG_GLOBAL + 41, 0x1f878, 0x1ffff, 0 },
> { GEN8_CP_PROTECT_REG_GLOBAL + 42, 0x1f930, 0x1fc59, 1 },
>
> (0x1f930 is overwritten)
I think this overlay is intentional to save a protect register.
Otherwise, we need to use 3 Protect registers to describe this range.
>
>> + A6XX_PROTECT_NORDWR(0x1f930, 0x0329),
>> + A6XX_PROTECT_NORDWR(0x1fd80, 0x1fff),
>> + A6XX_PROTECT_NORDWR(0x27800, 0x007f),
>> + A6XX_PROTECT_RDONLY(0x27880, 0x0385),
>> + A6XX_PROTECT_NORDWR(0x27882, 0x000a),
>
> These 2 seem to have been changed vs 830 for counters (all good)
We are not opening up the perfcounters to UMD for A8x at the moment. We
should think about the UABI for perfcounter before that.
>
>> + A6XX_PROTECT_NORDWR(0x27c06, 0x0000),
>> +};
>> +
>> +DECLARE_ADRENO_PROTECT(x285_protect, 64);
>> +
>> static const uint32_t a840_pwrup_reglist_regs[] = {
>> REG_A7XX_SP_HLSQ_TIMEOUT_THRESHOLD_DP,
>> REG_A7XX_SP_READ_SEL,
>> @@ -1809,6 +1911,35 @@ static const struct adreno_reglist a840_gbif[] = {
>>
>> static const struct adreno_info a8xx_gpus[] = {
>> {
>> + .chip_ids = ADRENO_CHIP_IDS(0x44070041),
>> + .family = ADRENO_8XX_GEN1,
>> + .fw = {
>> + [ADRENO_FW_SQE] = "gen80100_sqe.fw",
>> + [ADRENO_FW_GMU] = "gen80100_gmu.bin",
>> + },
>> + .gmem = 21 * SZ_1M,
>> + .inactive_period = DRM_MSM_INACTIVE_PERIOD,
>> + .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
>> + ADRENO_QUIRK_HAS_HW_APRIV,
>
> No preemption and IFPC - I supopose the smart thing to do before we
> know things are stable
Right.
>
>> + .funcs = &a8xx_gpu_funcs,
>> + .a6xx = &(const struct a6xx_info) {
>> + .protect = &x285_protect,
>> + .nonctxt_reglist = x285_nonctxt_regs,
>> + .gbif_cx = a840_gbif,
>> + .gmu_chipid = 0x8010100,
>
> Is this the chip id for the final revision silicon?
Yes. For v2.
>
> [...]
>
>> diff --git a/drivers/gpu/drm/msm/adreno/a8xx_gpu.c b/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
>> index ad140b0d641d..d283d0b55623 100644
>> --- a/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
>> @@ -175,6 +175,9 @@ static void a8xx_set_hwcg(struct msm_gpu *gpu, bool state)
>> struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
>> u32 val;
>>
>> + if (adreno_is_x285(adreno_gpu))
>> + gpu_write(gpu, REG_A8XX_RBBM_CGC_0_PC, 0x00000702);
>
> kgsl sets this only when turning on hwcg (bool state in this func) and
> on a830 family - should we turn this into an A8XX_GEN1 check?
X285 is not strictly Gen1 or Gen2. HW development is not really linear.
I might update it to GEN2 in future when we add more a8x features. Not sure.
We can revisit this when we add A830 GPU.
-Akhil.
>
> Konrad
next prev parent reply other threads:[~2025-11-12 21:08 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 16:37 [PATCH v2 00/21] drm/msm/adreno: Introduce Adreno 8xx family support Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 01/21] drm/msm/a6xx: Flush LRZ cache before PT switch Akhil P Oommen
2025-11-12 10:07 ` Konrad Dybcio
2025-11-10 16:37 ` [PATCH v2 02/21] drm/msm/a6xx: Fix the gemnoc workaround Akhil P Oommen
2025-11-12 10:18 ` Konrad Dybcio
2025-11-12 22:09 ` Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 04/21] drm/msm/adreno: Create adreno_func->submit_flush() Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 05/21] drm/msm/adreno: Move adreno_gpu_func to catalogue Akhil P Oommen
2025-11-12 10:22 ` Konrad Dybcio
2025-11-12 22:02 ` Akhil P Oommen
2025-11-13 3:38 ` Dmitry Baryshkov
2025-11-13 9:27 ` Konrad Dybcio
2025-11-13 12:22 ` Dmitry Baryshkov
2025-11-13 13:10 ` Konrad Dybcio
2025-11-10 16:37 ` [PATCH v2 06/21] drm/msm/adreno: Move gbif_halt() to adreno_gpu_func Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 07/21] drm/msm/adreno: Add MMU fault handler " Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 09/21] drm/msm/a6xx: Rebase GMU register offsets Akhil P Oommen
2025-11-12 10:56 ` Konrad Dybcio
2025-11-10 16:37 ` [PATCH v2 10/21] drm/msm/a8xx: Add support for A8x GMU Akhil P Oommen
2025-11-13 13:10 ` Konrad Dybcio
2025-11-13 20:00 ` Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 11/21] drm/msm/a6xx: Improve MX rail fallback in RPMH vote init Akhil P Oommen
2025-11-12 10:59 ` Konrad Dybcio
2025-11-14 11:26 ` Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 12/21] drm/msm/a6xx: Share dependency vote table with GMU Akhil P Oommen
2025-11-13 9:42 ` Konrad Dybcio
2025-11-10 16:37 ` [PATCH v2 13/21] drm/msm/adreno: Introduce A8x GPU Support Akhil P Oommen
2025-11-13 10:15 ` Konrad Dybcio
2025-11-13 20:09 ` Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 14/21] drm/msm/adreno: Support AQE engine Akhil P Oommen
2025-11-12 11:07 ` Konrad Dybcio
2025-11-12 21:16 ` Akhil P Oommen
2025-11-13 9:29 ` Konrad Dybcio
2025-11-10 16:37 ` [PATCH v2 15/21] drm/msm/a8xx: Add support for Adreno 840 GPU Akhil P Oommen
2025-11-13 10:58 ` Konrad Dybcio
2025-11-10 16:37 ` [PATCH v2 16/21] drm/msm/adreno: Do CX GBIF config before GMU start Akhil P Oommen
2025-11-12 10:37 ` Konrad Dybcio
2025-11-12 21:34 ` Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 17/21] drm/msm/a8xx: Add support for Adreno X2-85 GPU Akhil P Oommen
2025-11-12 14:41 ` Konrad Dybcio
2025-11-12 21:07 ` Akhil P Oommen [this message]
2025-11-10 16:37 ` [PATCH v2 18/21] dt-bindings: arm-smmu: Add Kaanapali GPU SMMU Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 19/21] dt-bindings: display/msm/gmu: Add Adreno 840 GMU Akhil P Oommen
2025-11-10 16:37 ` [PATCH v2 20/21] dt-bindings: display/msm/gmu: Add Adreno X2-85 GMU Akhil P Oommen
2025-11-11 7:49 ` Krzysztof Kozlowski
2025-11-11 14:25 ` Akhil P Oommen
2025-11-13 8:14 ` Krzysztof Kozlowski
2025-11-13 8:21 ` Krzysztof Kozlowski
2025-11-10 16:37 ` [PATCH v2 21/21] dt-bindings: arm-smmu: Add Glymur GPU SMMU Akhil P Oommen
2025-11-11 7:50 ` Krzysztof Kozlowski
2025-11-11 14:27 ` Akhil P Oommen
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=7ece2feb-79ab-478e-936b-607cfda22707@oss.qualcomm.com \
--to=akhilpo@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cwabbott0@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=jesszhan0024@gmail.com \
--cc=jonathan@marek.ca \
--cc=jordan@cosmicpenguin.net \
--cc=joro@8bytes.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=will@kernel.org \
/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