[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <o55el5zduao57uomzm6zeqslxjg7rtzfbttk7gq6gvsatapktx@5lflwspish24>
Date: Thu, 2 Oct 2025 04:08:12 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Akhil P Oommen <akhilpo@....qualcomm.com>
Cc: Connor Abbott <cwabbott0@...il.com>, rob.clark@....qualcomm.com,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Sean Paul <sean@...rly.run>,
Dmitry Baryshkov <lumag@...nel.org>,
Abhinav Kumar <abhinav.kumar@...ux.dev>,
Jessica Zhang <jessica.zhang@....qualcomm.com>,
Marijn Suijten <marijn.suijten@...ainline.org>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Jonathan Marek <jonathan@...ek.ca>,
Jordan Crouse <jordan@...micpenguin.net>,
Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
Joerg Roedel <joro@...tes.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
freedreno@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux.dev, devicetree@...r.kernel.org
Subject: Re: [PATCH 12/17] drm/msm/adreno: Introduce A8x GPU Support
On Thu, Oct 02, 2025 at 02:32:21AM +0530, Akhil P Oommen wrote:
> On 9/30/2025 2:11 PM, Connor Abbott wrote:
> > On Tue, Sep 30, 2025 at 10:08 AM Rob Clark <rob.clark@....qualcomm.com> wrote:
> > >
> > > On Tue, Sep 30, 2025 at 12:43 AM Dmitry Baryshkov
> > > <dmitry.baryshkov@....qualcomm.com> wrote:
> > > >
> > > > On Tue, Sep 30, 2025 at 11:18:17AM +0530, Akhil P Oommen wrote:
> > > > > A8x is the next generation of Adreno GPUs, featuring a significant
> > > > > hardware design change. A major update to the design is the introduction
> > > > > of Slice architecture. Slices are sort of mini-GPUs within the GPU which
> > > > > are more independent in processing Graphics and compute workloads. Also,
> > > > > in addition to the BV and BR pipe we saw in A7x, CP has more concurrency
> > > > > with additional pipes.
> > > > >
> > > > > From a software interface perspective, these changes have a significant
> > > > > impact on the KMD side. First, the GPU register space has been extensively
> > > > > reorganized. Second, to avoid a register space explosion caused by the
> > > > > new slice architecture and additional pipes, many registers are now
> > > > > virtualized, instead of duplicated as in A7x. KMD must configure an
> > > > > aperture register with the appropriate slice and pipe ID before accessing
> > > > > these virtualized registers.
> > > > >
> > > > > This patch adds only a skeleton support for the A8x family. An A8x GPU
> > > > > support will be added in an upcoming patch.
> > > >
> > > > Consider this lands in a commit message. What would it mean in the Git
> > > > history?
>
> Commit text is not just for git history. This sentence is for a reviewer who
> is going through the patches one by one.
You can put this in the commit message (in the git tree) under three
dashes:
----- CUT ----
drm: subject
Foo bar baz.
SoB: you
---
All the notes and details that will be ignored by git-am.
----- CUT ----
> > > > > @@ -2561,10 +2583,8 @@ static struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> > > > > adreno_gpu->base.hw_apriv =
> > > > > !!(config->info->quirks & ADRENO_QUIRK_HAS_HW_APRIV);
> > > > >
> > > > > - /* gpu->info only gets assigned in adreno_gpu_init() */
> > > > > - is_a7xx = config->info->family == ADRENO_7XX_GEN1 ||
> > > > > - config->info->family == ADRENO_7XX_GEN2 ||
> > > > > - config->info->family == ADRENO_7XX_GEN3;
> > > > > + /* gpu->info only gets assigned in adreno_gpu_init(). A8x is included intentionally */
> > > > > + is_a7xx = config->info->family >= ADRENO_7XX_GEN1;
> > > >
> > > > Is A8xx also a part of is_a7xx? What about the A9XX which will come at
> > > > some point in future?
>
> I think this is okay for now. I have a separate patch which reworks the
> cx_mem initialization. That will completely remove the above ugliness.
Ack.
--
With best wishes
Dmitry
Powered by blists - more mailing lists