Message-ID: <1f96a267-f5c6-498e-a2c4-7a47a73ea7e7@canonical.com>
Date: Wed, 19 Nov 2025 08:04:41 +0100
From: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
To: Conor Dooley <conor@...nel.org>, Hal Feng <hal.feng@...rfivetech.com>
Cc: E Shattow <e@...eshell.de>,
 Emil Renner Berthing <emil.renner.berthing@...onical.com>,
 Albert Ou <aou@...s.berkeley.edu>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Krzysztof Wilczyński
 <kwilczynski@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Manivannan Sadhasivam <mani@...nel.org>, Palmer Dabbelt
 <palmer@...belt.com>, Paul Walmsley <pjw@...nel.org>,
 "Rafael J . Wysocki" <rafael@...nel.org>, Rob Herring <robh@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/8] Add support for StarFive VisionFive 2 Lite board

On 11/19/25 00:10, Conor Dooley wrote:
> On Tue, Nov 18, 2025 at 02:12:58AM +0000, Hal Feng wrote:
>>> All,
>>>
>>> I repeat that the suggestion was made months ago (by Hal) to split out the
>>> OPP tables per-board from the period of time when I was complaining about
>>> 1.5GHz JH-7110 operation pushing TDP into over-temperature thermal limit
>>> on Milk-V Mars CM SoM.
>>>
>>> Whether or not JH7110S is a new compatible should follow precedence in
>>> Linux development. JH-7110S is evidently the same tape-out as JH-7110 and
>>> however you deal with that in Linux is the appropriate way to deal with that
>>> here. Selection of OPP table for correct operation will be determined by
>>> bootloader, where, it is demonstrated by patch series sent to U-Boot
>>> upstream to be selected ** per-board ** based on EEPROM content as if it
>>> was any other JH-7110 board deciding dts based on EEPROM content. Given
>>> that it is the same tape-out I do not find a valid justification for a new
>>> compatible in the stack of adjacent software besides going along with some
>>> kind of marketing-driven answer about whether or not this is a new SoC.
>>>
>>> What I care about now is that the VisionFive 2 Lite series is in good enough
>>> shape and there's a possibility to act on this months-old suggestion to split out
>>> the OPP tables which as we have confirmed the JH7110S is the same SoC as
>>> JH7110 it makes a lot of sense to do.
>>>
>>> How is it supposed to work for binned silicon in Linux?
>>
>> Hi, Conor,  Emil,
>>
>> What do you think about this? Hope to hear from you.
> 
> Can someone just give me a yes/no question out of this thread? I'm not
> really immediately sure what's being asked of me. What exactly do you
> want to do with the opp-tables? "Split out" isn't super clear. Does that
> mean into board files? I am guessing it does, since you're saying that a
> particular board cannot support the 1.5 GHz mode. It's not unusual
> though to use delete node for unsupported opp-table entries, could that
> be done instead?
> 
> FWIW, this weekend is -rc7, so I won't be applying any new material
> after that.
> 

There was agreement that the JH7110 and JH7110S need different operating 
points. This is realized via the different includes for the VisionFive 2 
Lite boards and the other boards.

Support for the new compatible string "starfive,jh7110s" used by the 
VisionFive 2 Lite is already implemented in OpenSBI where it is needed 
for platform support (specifically reboot). It is also used in tag 
next-20251119 in drivers/cpufreq/cpufreq-dt-platdev.c. There is no 
technical need to role this back.

The changes in OpenSBI and the cpu frequency driver could have been 
avoided by using

compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s", 
"starfive,jh7110"

to indicate that JH7110s is just a variety of JH7110. This also would 
match the best practice example in Documentation/devicetree/usage-model.rst:

     compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";

I guess we could add that third compatible value in a later patch.

As U-Boot uses the Linux device-trees too, I have built U-Boot with the 
updated device-trees and had no problem to boot all supported JH7110 and 
JH7110S devices including the StarFive VisionFive 2 Lite.

A bootph-pre-ram property for booting from SD-card that was already 
missing before the series can be added via a separate patch.

I think we should go ahead as is.

Best regards

Heinrich

Powered by blists - more mailing lists