16:13 <macc24> can anyone test if scarlet boots up on 5.16?

16:13 <macc24> 5.17*

16:13 <macc24> with display

16:13 <alyssa> is there an elseif?

16:17 <broonie> alyssa: Looks like people are writing it out with else: \n if: but I could be missing something.

16:17 <alyssa> broonie: alright, thanks. that's going to get messy.

16:17 <broonie> robher: ^^^ is the expert though.

16:17 <alyssa> Why does MediaTek have to vary the number of power domains every time they make a new chip? who knows

16:17 <alyssa> because they like making kernel developers suffer, I guess

16:18 <broonie> s/suffer/stay employed/

16:18 <macc24> alyssa: A wise man once said "Write good code and they'll only need you once, write garbage unreadable code and they'll need you forever"

16:19 <alyssa> macc24: being able to retire someday sounds nice

16:19 <macc24> alyssa: 2 weeks notices are a thing

16:19 <robher> Maybe because power domains (bindings) are widely abused beyond just power gating islands.

16:19 <macc24> or just inexplicably disappear

16:19 <alyssa> robher: yeah, guess so

16:20 <alyssa> this binding file is going to get messy if we keep adding mediatek malis.

16:20 <macc24> alyssa: LETS BOMB MTK HQ

16:20 <broonie> Power gating is also the sort of thing that gets tweaked a lot in the hardware.

16:20 <alyssa> on the other hand the power-domain-names are completely boring (core%d)

16:20 <broonie> Lots of tradeoffs to play with.

16:20 <robher> alyssa: no elseif or elif in json-schema

16:20 <alyssa> so maybe the binding shouldn't be validating th enumber of power domains?

16:20 <alyssa> ack

16:20 <alyssa> (It just will end up with a lot of copypaste)

16:22 <alyssa> we don't validate # of clocks, maybe we shouldn't bother with pm domains for mtk

16:22 <robher> how many if/then schemas is judgement call or a sign to split the schema file.

16:23 <alyssa> I don't have a strong preference except for whatever will get merged so I can get back to userland ;)

16:23 <robher> err, we usually do validate # of clocks

16:24 <alyssa> maybe that was missed when mt8183

16:24 <robher> this is bifrost binding?

16:24 <alyssa> (possibly because only a single clock is described in mainline, but 4 clocks are described downstream... I once made the mistake of asking about the clock topology and quickly regretted that decision)

16:24 <alyssa> yeah

16:27 <alyssa> (I heard there's yet another mt81xx SoC coming with Bifrost and yet another different # of pm domains)

16:27 <alyssa> (so splitting bifrost/valhall-jm isn't really solving anything)

16:28 <robher> I think tried to figure out from the TRM what's the correct number and split for power domains, but it wasn't all that clear.

16:29 <robher> The boundaries should be fixed in the design by Arm.

16:31 <robher> Just as how many clocks there are should be. The problem on clocks is bus clocks get added in.

16:36 <alyssa> /home/alyssa/.src/src/arch/arm64/boot/dts/mediatek/mt8192-evb.dtb: gpu@13000000: 'power-domain-names' does not match any of the regexes: 'pinctrl-[0-9]+'

16:36 <alyssa> *blinks*

16:36 <alyssa> where did pinctrl come from?!

16:39 <broonie> robher: Do the power domain bindings cope nicely with two power domains mapped onto a single user?

16:42 <broonie> (ie, the IP can have domains A and B switched separately but the integration has implemented them as a single domain)

16:42 <robher> alyssa: magic. pinctrl is allowed on any node, so it is automatically added.

16:42 <alyssa> right, ok

16:43 <robher> broonie: Not sure, but I would think so. From a DT perspective that's just like 2 clock inputs have the same clock source.

16:43 <broonie> But I'd expect a lot of things that turn out not to work :(

16:44 <robher> broonie: And we'd have the same problem of some vendors defining just 1 domain for their variant.

16:46 <alyssa> Oh... dtbs_check was failing before any of my changes... delightful....

16:52 <javierm> alyssa: probably you know this already, but when doing DT binding changes I just usually do:

16:52 <javierm> make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml

16:52 <javierm> instead of doing a full make dtbs_check

16:52 <alyssa> Yeah, that's what I'm trying

16:52 <javierm> alyssa: cool

16:52 <alyssa> It doesn't seem to pass on whatever linux-next this tree is based on

16:55 <javierm> alyssa: I see. It passes here with latest next-20220414: https://paste.centos.org/view/raw/1fe931eb

16:56 <alyssa> oops, misread

16:56 <alyssa> dt_binding_check passes, dtbs_check doesn't

16:56 <alyssa> I think

16:56 <alyssa> Honestly I don't know what I'm doing here

16:56 <javierm> alyssa: ah, yeah I usually don't run that since I only care about the DT binding schema I'm working on, rather than all the DTS out there

16:59 <robclark> alyssa: most (all?) of the modern adreno's have two (nested) power domains, gx and cx.. iirc from binding standpoint we handle it as a single power domain and gdsc code is aware of the dependency (according to my understanding of how it works, CosmicPenguin might remember the details better)

17:00 <CosmicPenguin> Yeah, its goofy. The CPU is expected to manage the CX domain and the the built in GMU handles the GX domain

17:02 <CosmicPenguin> But sometimes the GMU loses its mind, and in order to get everything working again, the CPU has to step in and turn off the GX domain on its behalf, so there has to be some knowledge about the GX domain from the CPU side for that one corner case

17:04 <robclark> heh, the naming CX and GX suddenly became apparent