07:39 <apritzel> warpme: can you do me a favour and run: "sunxi-fel readl 0x3000024" on your two H313 boxes? According to this TF-A patch you mentioned bits[7:0] should tell the difference between the T507 and H616 CPU cluster control block

07:43 <warpme> sure. give me sec...

07:53 <warpme> here it is: https://controlc.com/b0758310

08:00 <apritzel> warpme: great, thanks! but are you sure that's not the other way around? (mainline TF-A chip ends with 00)

08:08 <warpme> argh: my mistake. I have both boxes now with closed cases and....i will put stickers with desc. here is correct (i hope) outputs: https://controlc.com/d0d7c106

08:09 <apritzel> warpme: many thanks, that matches now what I was hoping for!

08:12 <apritzel> warpme: so the plan would be to have two distinct DTs for both box versions, we will need this for the different PMICs

08:12 <warpme> btw: do you know from somwhere correct cpu opp for h313? I was looking on vendor dts and obviously see traditional Chinise style: 1416MHz opp has higher voltage than 1520MHz (for the same bin)

08:14 <apritzel> and ideally put both DTs in one U-Boot image and let the SPL pick the right one, depending on those bits from 0x3000024

08:14 <apritzel> warpme: I don't know about any "correct" OPPs

08:16 <warpme> re dt: yes i think 2 dts will be a must (and for me work really well (https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.2/files/0636-arm64-dts-allwinner-h313-add-x96q-TVbox.patch and https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.2/files/0639-arm64-dts-allwinner-h313-add-x96q-lpddr3-TVbox.patch)

08:19 <warpme> also - due different cpu opp for h616 and h313 probably good will be to have one sun50i-hx1x.dtsi (without cpu opp) and then sun50i-h616.dtsi and sun50i-h313.dtsi with dedicated cpu opps

08:25 <apritzel> we typically include CPU OPPs .dtsi's into the *board* .dts files, so that would not be needed

08:26 <apritzel> because technically the OPPs are per-board data, since cooling and board layout would affect the settings

08:38 <mripard> apritzel: in practice (for the pre-A64 SoCs at least), OPPs were always the same from one board to another

08:38 <mripard> and cooling would affect how long you can run with a particular OPP (so, thermal throttling), not the OPP itself

08:38 <MoeIcenowy> yes, opp is just a voltage-frequency pair

08:39 <apritzel> I see, and in practice I agree, but for the later SoCs we seem to include them per SoC

08:39 <MoeIcenowy> yes

08:39 <apritzel> sorry, per board

08:39 <MoeIcenowy> the major reason is to disable DVFS for some boards

08:39 <MoeIcenowy> that do not have its cpu-supply ready

08:41 <apritzel> I was scratching my head about this already: even when the kernel cannot adjust the voltage, it still seems to increase the frequency?

08:42 <apritzel> which sounds like it should be fixed somewhere in the kernel: only enabled DVFS if we have control over both voltage and frequency?

08:44 <MoeIcenowy> well a DT having no cpu-supply but DVFS table is technically wrong, I think

08:46 <mripard> apritzel: yeah, indeed

08:46 <mripard> it always felt wrong to me too

08:47 <mripard> but I guess the argument is that you could have a fixed regulator that outputs at the maximum voltage required

08:47 <mripard> and that would work

08:47 <mripard> (still seems wrong to me)

08:49 <mripard> I agree with MoeIcenowy, that's easy enough to fix by requiring cpu-supply and providing a fixed-regulator in such a case

08:49 <mripard> but that ship has probably sailed a long time ago, and fixing it now without breaking DT compat is not going to be easy to do

08:50 <apritzel> I agree, and indeed it does not seem to be a biggie to explicitly announce DVFS by including the opp.dtsi

08:52 <apritzel> ah yeah, I was wrong: cooling does not affect the OPPs, the temp sensor would (ideally) limit this automatically

09:00 <MoeIcenowy> mripard: I think some H3 boards really have a fixed regulator on HW

09:01 <MoeIcenowy> and then the DT just models it so

09:01 <gamiee> MoeIcenowy: Banana Pi M2+ have this kind of regulator, it can switch between two voltages.

09:01 <MoeIcenowy> gamiee: then it's not so fixed

09:02 <MoeIcenowy> but I think the original M2+ is totally fixed

09:02 <MoeIcenowy> in DT M2+ 1.2 regulator is a "gpio-regulator"

09:02 <MoeIcenowy> which can have its voltage toggled by toggling a GPIO

09:02 <gamiee> ah yes, you are right. Older revision is totally fixed. But I didn't seen the old version for a very long time.

09:03 <MoeIcenowy> gamiee: well I have one ;-)

09:45 <warpme> apritzel: re cpu opp in h3131/h616: i personally prefer when inheritance/overwrites of dtsi/dts follows hw specifics. IMHO cpu dvfs sets are SoC specific. Thermal safe OPP set/subset + cpu-vdd realisation is board specific. So imho soc difference should be covered by: sun50i-hx1x.dtsi (without cpu opp) and then sun50i-h616.dtsi and sun50i-h313.dtsi with dedicated cpu opp set covering all bins and allowable opps. Then board specific

09:45 <warpme> dts should (potentially) remove some unsafe oops (due thermal design) + address vdd-cpu regulator specifics. just my 0.02$

09:48 <apritzel> warpme: but isn't much easier to keep the one existing h616.dtsi (since they are the same die), add two separate sun50i-h{616,313}-cpu-opp.dtsi files (with just the OPPs), and then include the respective one from the board .dts?

09:50 <warpme> apritzel : this is exactly what i implemented currently :-p

09:50 <warpme> https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.2/files/0638-arm64-dts-allwinner-h313-add-dedicated-cpu-opp-and-use-in-x96q-TVbox.patch

09:52 <apritzel> ah, but you put both OPP sets in one file

09:54 <warpme> yeah. that why i fell baaaad with this ;-p

10:00 <warpme> basically - recently working on rk3588 - i like approach: base is waker soc (3588s) then richer 3588 inherits 3588s then boards are including one of such dtsi. I'm not sure is this applicable to h313 vs h616 as in don't know fuctionjal relation between them: a)subset/superset of b)functional the same with implementation difference

10:03 <warpme> probably it is not worth to touch already mainlined h616.dtsi... so that why i was lazy and went with multiple soc opp.dtsi include

10:18 <apritzel> from all we know the H313 is just a weaker bin of the H616, that's why that wouldn't justify a separate h313.dtsi

10:19 <apritzel> there were rumours that some video codecs were limited/fused off on the H313, but I don't know if this really happened

10:22 <warpme> apritzel : small Q: if i want to add wifi LPO 32k clock in h616 box DT - will this be ok: https://github.com/warpme/minimyth2/blob/d2089198a30d6052fbd4a6bd4c9b9c96b811b48b/script/kernel/linux-6.2/files/0633-arm64-dts-allwinner-h616-add-Tanix-TX6s-TVbox.patch#L93 ?

10:25 <warpme> re h313 vs h616 video caps: my v.basic tests showing no difference (https://github.com/warpme/minimyth2/blob/master/video-test-summary.txt)

10:25 <warpme>

10:25 <MoeIcenowy> I rememberthe RK world

10:25 <MoeIcenowy> have a rk3399-opp and op1-opp

10:26 <MoeIcenowy> ah it's rk3399-op1-opp https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi

10:26 <MoeIcenowy> and OP1 devices include rk3399-op1-opp.dtsi, e.g. https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi#L10

10:27 <MoeIcenowy> ordinary rk3399 devices include rk3399-opp.dtsi, e.g. https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts#L15

10:28 <apritzel> warpme: if the WiFi chip uses that clock pin, that should be good

10:29 <warpme> apritzel : "if the WiFi chip uses that clock pin" - do you mean this soc gpio pin is wired to lpo pin of wifi module?

10:42 <warpme> in android dt is see following: https://controlc.com/8f61ad67

10:44 <warpme> pincontrol-0 points to https://controlc.com/bc691bd5

10:45 <warpme> so it looks wifi lpo is wired to PG10?

10:45 <apritzel> warpme: without a schematic I guess it's the best we can hope for. Take those Allwinner Android DTs with a grain of salt though.

10:48 <apritzel> looks like it: if you program PG10 to use mux 3, it will spit out the 32KHz clock on that pin, so you can use that where ever you need a 32KHz clock

10:57 <warpme> indeed: in android dt i see "allwinner,muxsel = <0x03>;" Can i use such entry also in mainline 6.2 dts?

10:59 <apritzel> no, not directly, but you can use something equivalent

11:01 <apritzel> we describe mux 3 for PG10 as "clock", so you describe that pin in a child of the pinctrl node (like all the other pins), and say: function = "clock";

11:02 <apritzel> and then reference this in your .dts, in the respective pinctrl-0 property

11:03 <apritzel> that should be in the wifi device's node, not in the mmc1 node, but I am not 100% sure that works

11:07 <warpme> so for pindef: will this be ok: https://pastebin.com/4eSuDYRL line380 ?

11:12 <warpme> and for dts: https://pastebin.com/37tUnZu9 line186?

11:13 <apritzel> yes, that's what I meant

14:39 <LordKalma> did someone make any progress on the misterious chips that don't boot with gcc 12-built u-boot?

14:39 <LordKalma> just out of curiosity

19:44 <warpme> apritzel : pre your request i'm updating axp313a to v10 for testing and v10 not applies cleanly on 6.2.9 for me. Do i miss something?

20:14 <apritzel> warpme: maybe this patch? https://lore.kernel.org/lkml/20230325114353.50293-1-krzysztof.kozlowski@linaro.org/

20:15 <apritzel> that got already queued, so I based my post on top of it

20:17 <warpme> oh - it fails for me on axp20x_power_off hunk in drivers/mfd/axp20x.c

20:17 <warpme> v8 applies clean....

20:18 <apritzel> there series is based on 6.3-rc4-something

20:20 <apritzel> probably this patch then: https://lore.kernel.org/lkml/20221228162752.14204-1-samuel@sholland.org/

20:22 <apritzel> warpme: btw: I am almost done with a proper TF-A series to support the "T507-style" SoCs

20:30 <warpme> apritzel : sill no go in the same hunk. don't waste your time on this. i'll sort this tommorow!. Re: ATF perfect. Give me msg here - i'll test asap