Received-SPF: pass (google.com: domain of linux-kernel+bounces-196742-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <673dcf47596e7bc8ba065034e339bb1bbf9cdcb0.1716948159.git.dsimic@manjaro.org>
 <CABjd4YxD41DEkBCZfkznLboEY9ZVOfTCLcj4S_kkcsVswbANyQ@mail.gmail.com>
 <8f8623e29a479c4108141302e708dc3b@manjaro.org> <CABjd4Yy4RMg+6-4ygV0MSwJj5LReY-ymbctq4PPfVZ6L+c1tsw@mail.gmail.com>
 <166cc4e46f31644a50306625b2ab18a6@manjaro.org> <CABjd4YzDNQa45=KC_t0xnTDrH+g-oUrcpgP55oOj7JcAuu7uFw@mail.gmail.com>
 <82db817a908b761d8c3d73ea04714314@manjaro.org> <607f4da8-99b2-4379-9567-4bfd2744eab3@kwiboo.se>
In-Reply-To: <607f4da8-99b2-4379-9567-4bfd2744eab3@kwiboo.se>
From: Alexey Charkov <alchark@gmail.com>
Date: Fri, 31 May 2024 15:44:17 +0400
Message-ID: <CABjd4YxdM+cM+z7ou3=DF2SrFM0235DSTZ45o0NsKBwGrgW8Bg@mail.gmail.com>
Subject: Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for
 per-RK3588-variant OPPs
To: Jonas Karlman <jonas@kwiboo.se>
Cc: Dragan Simic <dsimic@manjaro.org>, linux-rockchip@lists.infradead.org, heiko@sntech.de, 
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, 
	robh+dt@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, 
	linux-kernel@vger.kernel.org, quentin.schulz@cherry.de, wens@kernel.org, 
	daniel.lezcano@linaro.org, didi.debian@cknow.org, 
	krzysztof.kozlowski+dt@linaro.org, viresh.kumar@linaro.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jonas,

On Fri, May 31, 2024 at 3:27=E2=80=AFPM Jonas Karlman <jonas@kwiboo.se> wro=
te:
>
> Hi Alexey and Dragan,
>
> On 2024-05-30 21:31, Dragan Simic wrote:
> > Hello Alexey,
> >
>
> [snip]
>
> >>>>> That way we'll have no roadblocks if, at some point, we end up with
> >>>>> having
> >>>>> different OPPs defined for the RK3588 and the RK3588S variants.  Or
> >>>>> maybe
> >>>>> even for the RK3582, which we don't know much about yet.
> >>>>
> >>>> Guess we'll deal with that one once we stumble upon an actual RK3582
> >>>> board out in the wild and heading to the mainline kernel tree :)
> >>>
> >>> Of course, that was just an example for the future use.
> >>
> >> In fact, I've just discovered that Radxa has recently released Rock 5C
> >> Lite which is based on RK3582, and starts at just $29 for the 1GB
> >> version, making it interesting for tinkering. Especially given that
> >> its GPU, one of the big-core clusters and one of the VPU cores seem to
> >> be disabled in software (u-boot) rather than in hardware, which means
> >> there is some chance that a particular SoC specimen would actually
> >> have them in a working condition and possible to re-enable at no cost.
> >> Ordered myself one to investigate :)
> >
> > Yes, I also saw the RK3582-based ROCK 5C Lite a couple of days ago. :)
> > It seems that the disabled IP blocks are detected as defective during
> > the manufacturing, which means that they might work correctly, or might
> > actually misbehave.  It seems similar to the way old three-core AMD
> > Phenom II CPUs could sometimes be made quad-core.
> >
>
> I can confirm that the RK3582 include ip-state in OTP indicating
> unusable cores, any unusable cpu core cannot be taken online and stalls
> Linux kernel a few extra seconds during boot.
>
> Started working on a patch for U-Boot to remove any broken cpu core
> and/or cluster nodes, similar to what vendor U-Boot does, adopted to
> work with a mainline DT for RK3588.

Superb - it's great to have a patch for it already, thank you for working o=
n it!

> On one of my ROCK 5C Lite board one of the cpu cores is unusable, U-Boot
> removes the related cpu cluster nodes. On another ROCK 5C Lite board one
> rkvdec core is only marked unusable and all cpu cores can be taken
> online, U-Boot does nothing in this case. Guessing we should apply
> similar policy as vendor U-Boot and disable cores anyway.

Is there any misbehavior / instability if you just keep all the
unmarked cores online?

I think from an end-user perspective it would be better to just enable
everything that works, as the reason to unconditionally disable some
IP blocks even when they are "good" is quite likely not a technical
one but rather a marketing one. It's hard to justify selling chips
with different sets of working IP blocks under the same label and the
same price, making it easier to just trim them all to a lowest common
denominator. On the other hand, once a person has already bought a
device where some IP blocks work even if they are not supposed to, why
not make use of them? It costs nothing, hurts noone...

Best regards,
Alexey