[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF6AEGsBNafYjfC-05XBG2QT+vxU-jB=wTmu9gOVe-wLTXFgzQ@mail.gmail.com>
Date: Mon, 17 Jan 2022 10:52:07 -0800
From: Rob Clark <robdclark@...il.com>
To: Akhil P Oommen <quic_akhilpo@...cinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
freedreno <freedreno@...ts.freedesktop.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
<devicetree@...r.kernel.org>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Christian König <christian.koenig@....com>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>,
Jonathan Marek <jonathan@...ek.ca>,
Jordan Crouse <jordan@...micpenguin.net>,
Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
Sean Paul <sean@...rly.run>,
Stephen Boyd <swboyd@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/4] drm/msm/adreno: Expose speedbin to userspace
On Mon, Jan 17, 2022 at 6:38 AM Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
>
> On 1/13/2022 12:43 PM, Dmitry Baryshkov wrote:
> > On Thu, 13 Jan 2022 at 00:19, Rob Clark <robdclark@...il.com> wrote:
> >> On Tue, Jan 11, 2022 at 1:31 PM Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
> >>> Expose speedbin through MSM_PARAM_CHIP_ID parameter to help userspace
> >>> identify the sku.
> >>>
> >>> Signed-off-by: Akhil P Oommen <quic_akhilpo@...cinc.com>
> >>> ---
> >>>
> >>> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +++++----
> >>> 1 file changed, 5 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>> index f33cfa4..e970e6a 100644
> >>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>> @@ -242,10 +242,11 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value)
> >>> *value = !adreno_is_a650_family(adreno_gpu) ? 0x100000 : 0;
> >>> return 0;
> >>> case MSM_PARAM_CHIP_ID:
> >>> - *value = adreno_gpu->rev.patchid |
> >>> - (adreno_gpu->rev.minor << 8) |
> >>> - (adreno_gpu->rev.major << 16) |
> >>> - (adreno_gpu->rev.core << 24);
> >>> + *value = (uint64_t) adreno_gpu->rev.patchid |
> >>> + (uint64_t) (adreno_gpu->rev.minor << 8) |
> >>> + (uint64_t) (adreno_gpu->rev.major << 16) |
> >>> + (uint64_t) (adreno_gpu->rev.core << 24) |
> >>> + (((uint64_t) adreno_gpu->rev.sku) << 32);
> >> How about this instead, so we are only changing the behavior for
> >> new/unreleased devices:
>
> I thought this property was only used for new devices whereas the
> existing devices rely on REVN.
>
> -Akhil.
>
> >>
> >> *value = adreno_gpu->rev.patchid |
> >> (adreno_gpu->rev.minor << 8) |
> >> (adreno_gpu->rev.major << 16) |
> >> (adreno_gpu->rev.core << 24);
> >> if (!adreno_gpu->info->revn)
> >> *value |= (((uint64_t) adreno_gpu->rev.sku) << 32);
> >>
> >> (sorry about the butchered indentation.. somehow gmail has become
> >> antagonistic about pasting code)
> > I assume that you would like to keep userspace compat for older chips.
> > thus the if.
> > Maybe we should introduce MSM_PARAM_CHIP_ID_SKU instead (and gradually
> > make userspace switch to it)?
> >
Existing userspace tools do query CHIP_ID, but match based on GPU_ID
(falling back to CHIP_ID only if GPU_ID==0).. still, out of an
abundance of caution, we should probably not change the behavior for
existing GPUs. But so far the only thing with GPU_ID==0 does not
exist in the wild yet, so I think we can get away without having to
introduce a new param if we only set the upper bits of CHIP_ID when
GPU_ID==0.
BR,
-R
Powered by blists - more mailing lists