12:43 <tomba> is afd (ever) on this channel?

12:54 <bryanb> tomba: he logs in when he needs to. but he tries to keep the notifications down

14:00 <NishanthMenon> tomba: afd ^^

14:03 <tomba> afd: wanted to ping you about the "arm64: ti: Use syscon for the Control Module" (surprise surprise). any ideas how to proceed? afaiu Krzk and Rob nacked the "let's add a new syscon node for each register" approach.

14:08 <afd> tomba: I'm not suggesting "one node for each register", I'm suggesting one node per logical address space, which is already the rule in DT, if that address space just so happens to be only a handful of registers then so be it.

14:09 <afd> I don't see Rob's NAK on this anywhere, just a question on it, https://lore.kernel.org/all/20260505193538.GA3785056-robh@kernel.org/

14:09 <tomba> yes, that's what I meant. in this case it's a single register.

14:13 <afd> what about "dss-oldi-io-ctrl", or some similar existing node type, could you just re-use that? Sure it might not be *exactly* the same but just using a phandle to one big syscon region doesn't give any hint as to the type of underlying hardware space either, so no harm

14:14 <tomba> hmm, I can't find the other thread right now where this (or something similar) was discussed, and while, I think, there wasn't really a nack there either, the suggestion was to go for a making the ctrl mmr a syscon. but I confess, maybe there hasn't been nacks, but after the patches and additional explanations I have not seen acks either.

14:17 <tomba> the register in question is surrounded by registers for other things. I think on one side the register is controlled by the firmware. I can't recall the other side. but I don't think extending an existing one would be good, as it'll then cover totally unrelated registers. oh, you mean basically using a single node as a generic "syscon container" of sorts? like multiple instances of "dss-ctrl-registers", at different addresses and sizes?

14:20 <afd> Yes, the second one, it basically let's us avoid the DT binding modifications every time we want to add something to our DTS file

14:23 <tomba> that's essentially the same as generic syscon (i.e. only syscon compatible), and that's not allowed. I don't know how strict that rule is, but I assume "dss-ctrl-registers" that can be used for any dss related registers would be stretching the rules...

14:24 <tomba> I would prefer just a generic syscon, though =).

14:35 <tomba> afd: looks like that "other thread" was on irc, between you, bryanb and krzk. I got a copy-paste of that discussion from Devarsh. I can't quite see a clear NACK there either, but Krzk nor Rob seem to be agreeing with a single-register node. he also says "parent should be syscon" which... confuses me.

14:41 <tomba> e.g. here I think Krzk specifically nacks a single register node: https://lore.kernel.org/all/20250409-calculating-hungry-mosquito-f8cfeb@shite/ has that been resolved?

14:45 <afd> I would have liked not having syscon regions of any size at all in DT to be honest, can't find the thread but Rob has expressed similar dissatisfaction with the concept, but can't fix the past. What would have been the way that keeps the "DT feel" would be your main node have a `reg = ` propery with the register you want to use, vs a phandle pointer to a completely different spot in the DTS. Having phandle/syscon makes the hardware description less well

14:45 <afd> contained (everything the DSS needs is defined inside the one DSS node)

14:49 <tomba> we could still do that, for new registers (if I understood you correctly, appending a new reg in the dss's node's reg property). that's also quite annoying, though, handling different reg arrays per SoC. and it rubs me the wrong way, as they are not related to the IP. but all options are bad =)

14:52 <afd> I'm not a huge fan of it either, but the register you need from the control region is the "DSS DPI output control" register right? That seems like it is very much related to the IP and only to the DSS IP, it feels like something that should be in the DSS node reg array

14:52 <afd> (but yes, none of the options are perfect here..)

14:58 <tomba> well, yes, you need it to get output from the SoC's DPI pins. my guess is that the register controls a level shifter enable, re-timing the DSS signals, or something like that. strictly speaking it's outside the DSS IP, and feels almost more like pinmuxing to me. In the earlier SoCs they just took a signal from the DSS IP, and wired that to the external block's enable. But I guess that wire was too expensive...