Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 10 Apr 2024 13:47:00 +0200 | Subject | Re: [PATCH 3/6] drm/msm/adreno: Allow specifying default speedbin value | From | Konrad Dybcio <> |
| |
On 4/9/24 20:31, Dmitry Baryshkov wrote: > On Tue, 9 Apr 2024 at 21:27, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 4/9/24 20:15, Dmitry Baryshkov wrote: >>> On Tue, Apr 09, 2024 at 08:07:56PM +0200, Konrad Dybcio wrote: >>>> >>>> >>>> On 4/9/24 20:04, Dmitry Baryshkov wrote: >>>>> On Tue, Apr 09, 2024 at 10:12:00AM -0700, Rob Clark wrote: >>>>>> On Tue, Apr 9, 2024 at 8:23 AM Dmitry Baryshkov >>>>>> <dmitry.baryshkov@linaro.org> wrote: >>>>>>> >>>>>>> On Tue, Apr 09, 2024 at 05:12:46PM +0200, Konrad Dybcio wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 4/6/24 04:56, Dmitry Baryshkov wrote: >>>>>>>>> On Fri, Apr 05, 2024 at 10:41:31AM +0200, Konrad Dybcio wrote: >>>>>>>>>> From: Neil Armstrong <neil.armstrong@linaro.org> >>>>>>>>>> >>>>>>>>>> Usually, speedbin 0 is the "super SKU", a.k.a the one which can clock >>>>>>>>>> the highest. Falling back to it when things go wrong is largely >>>>>>>>>> suboptimal, as more often than not, the top frequencies are not >>>>>>>>>> supposed to work on other bins. >>>>>>>>> >>>>>>>>> Isn't it better to just return an error here instead of trying to guess >>>>>>>>> which speedbin to use? >>>>>>>> >>>>>>>> Not sure. I'd rather better compatibility for e.g. booting up a new >>>>>>>> laptop with just dt. >>>>>>> >>>>>>> New speedbin can have lower max speed, so by attempting to run it at >>>>>>> higher freq you might be breaking it. >>>>>> >>>>>> Usually there are some OPPs in common to all speedbins, so picking a >>>>>> freq from that set would seem like the safe thing to do >>>>> >>>>> Well, the issue is about an uknown speed bin. So in theory we know >>>>> nothing about the set of speeds itsupports. My point is that we should >>>>> simplfy fail in such case. >>>> >>>> Or we could allow e.g. the lowest frequency (or 2) which if often shared >>>> across the board to work, giving a compromise between OOBE and sanity >>> >>> That's also an option. But we should not be using existing speed table for >>> the unknown bin. >> >> I derived this logic from msm-5.15 where it's "intended behavior".. I >> suppose we can do better as you said though >> >> There have been cases in the past where the default speed bin ended up >> having a higher max freq than subsequent ones, and I don't think I can >> trust this product/feature code approach to guarantee this never >> happening again. >> >> So. I think sticking to a single lowest freq and printing a big red line >> in dmesg makes sense here > > Make 0x80 the default supported-hw, make sure that the lowest freq has > 0xff. Plus big-red-line. > And hope that we'll never see 16 speed bins for the hardware.
opp-supported-hw is a u32 bitmask fwiw
I was thinking, either 0xffffffff or some driver-side hackery (dev_pm_opp_enable).
Perhaps I'd be more in favor of the latter, as putting meaningless gobblygoo in dt is not good
Konrad
| ![\](/images/icornerr.gif) |