[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF6AEGs0sUfdER+GuygnupituPpVygms-Sc4hw1nYUFwCXC_=Q@mail.gmail.com>
Date: Thu, 22 May 2025 10:33:04 -0700
From: Rob Clark <robdclark@...il.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Akhil P Oommen <quic_akhilpo@...cinc.com>, neil.armstrong@...aro.org,
Konrad Dybcio <konradybcio@...nel.org>, Sean Paul <sean@...rly.run>,
Abhinav Kumar <quic_abhinavk@...cinc.com>, Dmitry Baryshkov <lumag@...nel.org>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Marijn Suijten <marijn.suijten@...ainline.org>, linux-arm-msm@...r.kernel.org,
dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
Konrad Dybcio <konrad.dybcio@...aro.org>
Subject: Re: [PATCH RFT v6 2/5] drm/msm/adreno: Add speedbin data for SM8550 / A740
On Thu, May 22, 2025 at 9:03 AM Konrad Dybcio
<konrad.dybcio@....qualcomm.com> wrote:
>
> On 5/11/25 11:51 AM, Akhil P Oommen wrote:
> > On 5/1/2025 9:23 PM, Konrad Dybcio wrote:
> >> On 5/1/25 11:29 AM, Akhil P Oommen wrote:
> >>> On 4/30/2025 10:26 PM, neil.armstrong@...aro.org wrote:
> >>>> On 30/04/2025 18:39, Konrad Dybcio wrote:
> >>>>> On 4/30/25 6:19 PM, neil.armstrong@...aro.org wrote:
> >>>>>> On 30/04/2025 17:36, Konrad Dybcio wrote:
> >>>>>>> On 4/30/25 4:49 PM, neil.armstrong@...aro.org wrote:
> >>>>>>>> On 30/04/2025 15:09, Konrad Dybcio wrote:
> >>>>>>>>> On 4/30/25 2:49 PM, neil.armstrong@...aro.org wrote:
> >>>>>>>>>> On 30/04/2025 14:35, Konrad Dybcio wrote:
> >>>>>>>>>>> On 4/30/25 2:26 PM, neil.armstrong@...aro.org wrote:
> >>
> >> [...]
> >>
> >>>> This behaves exactly as I said, so please fix it.
> >>
> >> Eh, I was so sure I tested things correctly..
> >>
> >>>
> >>> Konrad,
> >>>
> >>> iirc, we discussed this in one of the earlier revision. There is a
> >>> circular dependency between the driver change for SKU support and the dt
> >>> change that adds supported_hw bitmask in opp-table. Only scenario it
> >>> works is when you add these to the initial patches series of a new GPU.
> >>>
> >>> It will be very useful if we can break this circular dependency.
> >>
> >> Right. Let's start with getting that in order
> >
> > Another complication with the socinfo is that the value is unique for a
> > chipset, not for a GPU. So, it won't work if we keep this data in GPU
> > list in the driver.
> >
> > Downstream solved this problem by keeping the PCODE/FCODE mappings in
> > the devicetree.
>
> Hmm.. that actually does not sound very bad.. it would allow for e.g.
> new bins to appear without having to replace the kernel.. great for
> backwards/forwards compat
>
> Rob, WDYT?
Not against having it in dt if the dt maintainers can be convinced..
Alternatively, there is the optional machine string in adreno_info.
We've used that in a few other places where speedbin mappings are
different for multiple SoCs using the same gpu.
BR,
-R
Powered by blists - more mailing lists