On 2024-09-05 14:42, Andre Przywara wrote:
On Thu, 05 Sep 2024 14:38:53 +0200
Dragan Simic <dsimic@xxxxxxxxxxx> wrote:
Hello Andre,
On 2024-09-05 14:34, Andre Przywara wrote:
> On Thu, 5 Sep 2024 20:26:15 +0800
> Chen-Yu Tsai <wens@xxxxxxxx> wrote:
>
>> Hi,
>>
>> On Thu, Sep 5, 2024 at 8:17 PM Dragan Simic <dsimic@xxxxxxxxxxx>
>> wrote:
>> >
>> > Hello,
>> >
>> > Just checking, any further thoughts about this patch?
>>
>> Sorry, but I feel like it's not really worth the churn. There's not
>> really a problem to be solved here. What you are arguing for is more
>> about aesthetics, and we could argue that having them separate makes
>> it easier to read and turn on/off.
>
> Yeah, I agree. If a board wants to support OPPs, they just have to
> include
> a single file and define the CPU regulator, and that's a nice opt-in,
> IMHO.
> But having this patch would make it quite hard to opt out, I believe.
> For
> Linux there are probably ways to disable DVFS nevertheless, but I am
> not
> sure this is true in an OS agnostic pure-DT-only way.
Thanks for your response. The only thing that still makes me wonder
is why would a board want to opt out of DVFS? Frankly, I'd consider
the design of the boards that must keep DVFS disabled broken.
Yes! Among the boards using Allwinner SoCs there are some, say
less-optimal
designs ;-)
I see, but such boards could simply disable the "cpu0_opp_table" node in
their dts(i) files, for the encapsulated CPU OPPs scenario, and
everything
would still work and be defined in a clean(er) way.
I mean, if there are some suboptimal designs, perhaps the defaults
should
be tailored towards the good designs, and the suboptimal designs should
be
some kind of exceptions.
> This could probably be solved, but same as Chen-Yu I don't see any good
> enough reason for this patch in the first place.
>
>> And even though the GPU OPPs are in the dtsi, it's just one OPP acting
>> as a default clock rate.
