13:22 <CounterPillow> robmur01: do you happen to know if anyone is working on the NIU stuff for Rockchip? Related to https://lore.kernel.org/linux-rockchip/CAMdYzYoWAjRQPCy_cuYH5VpMfnVR2_H+1-MNSKv0w6j-NpbORw@mail.gmail.com/ (Peter Geis told me you made the statement that the clock structure needs to be updated for this)

13:25 <CounterPillow> Apparently that was https://lore.kernel.org/dri-devel/8b902216-fd82-fb2c-1849-d613caa0a763@arm.com/

13:28 <robmur01> I believe in most cases the NIU clocks are just regular "bus" clocks that simply need to be kept ungated whenever the device is in use - it's only those few specific ones with weird internal cross-dependencies that need more fiddly clock API work

13:28 <robmur01> but no, I'm not aware of anyone doing anything in that area

13:29 <CounterPillow> Alright, thanks

13:29 <CounterPillow> I assume the Collabora people working on the SoC are gonna run into this head first, since they're now at a point where quite a few of these weirder clocks will come into play

13:33 <CounterPillow> I have negative infinity experience with the clock subsystem but since (according to rockchip) the NIU path and clock tree are completely independent, their suggestion of adding another device tree property to model this doesn't sound too outlandish

13:35 <CounterPillow> or turn clocks into a DAG with the graph schema but I am ready to get absolutely blasted for that idea

13:35 <robmur01> yeah, I guess it might potentially be possible to model with the interconnect API, if that can somehow be aware of all the clocks required for a given path.

13:37 <robmur01> However AFAIK there's no means to make the interconnect stuff automatic without consumer drivers having to explicitly request it

13:37 <CounterPillow> Yeah that's not the greatest

13:42 <CounterPillow> I take it that ideally the SoC's CRU just implicitly does the NIU stuff when a driver prepare-enables a clock that needs it

14:03 <lag> Anyone know where to find Jiri Kosina?

14:12 <broonie> lag: he's jikos when he's on IRC.

14:16 <lag> broonie: Lovely, thanks Mark

14:30 <robmur01> CounterPillow: perhaps my view should be that ideally people use Arm Ltd. interconnects, which don't have such absurdly fine-grained clock gating anyway :D

14:33 <robmur01> but as I alluded to previously, if you know that the only reason to enable clock A is to access the bus, which you know will also require clock B, then it seems most pragmatic to just hide that knowledge in the clock driver, even if it's not a "real" clock tree dependency

14:33 <CounterPillow> Alright

14:33 <CounterPillow> so in other words, properly implement the GATE_LINK define that clk-rk3588.c just defines to GATE right now :)

14:34 <robmur01> indeed, on the face of it that sounds promising :)

14:40 <CounterPillow> Looks like right now the linked clocks are marked as critical, so any issues I ran into with touching usb regs locking up the SoC probably weren't related to NIU not being implemented, unless there's a bug in the CRU regs it writes to