On 4/9/24 20:31, Dmitry Baryshkov wrote:
On Tue, 9 Apr 2024 at 21:27, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx>
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
