01:13 <marex> anarsoul: well, success, Lima works on my zynqmp with 5.10.y, except the GALLIUM_HUD is acting funny :)

01:13 <marex> but damn, getting GPU operational in 4 hours compared to 4 days with the blob ... that is just great

04:07 <anarsoul> marex: these are gpu regs, I believe we took them from blob kernel driver which is GPL, so unfortunately there's nothing new for lima

05:32 <marex> anarsoul: maybe at least some extra description/clarification could be found there then

05:32 <marex> anarsoul: btw how would you prefer to go about those funny zynqmp clock, there are no bus clock , but there are three GPU clock (core, pp0, pp1)

05:32 <marex> I can imagine bus clock can be turned into optional ones

05:33 <marex> but the core/pp0/pp1, hmmm, well, I can use clk_bulk I guess

05:34 <marex> request all the clock, enable them all, that kind of thing would even work with the other devices which have bus/core clock

05:35 <anarsoul> marex: no idea

05:36 <anarsoul> looks like zynqmp is quite special, all other SoCs usually have a single clock gate for GPU

05:41 <anarsoul> marex: can you actually change clock rate of core, pp0 and pp1 separately?

07:54 <linkmauve> marex, if you refer to missing text in GALLIUM_HUD (replaced with squares), I can reproduce on Allwinner on 5.11 too.

07:55 <linkmauve> I have yet to investigate that, but GTK has its own HUD so I haven’t priorised it yet. :)

14:54 <marex> anarsoul: separately? No ... it seems there is one single divider, see https://www.xilinx.com/html_docs/registers/ug1087/crf_apb___gpu_ref_ctrl.html

14:55 <marex> linkmauve: it looks like corrupted texture in my case, but I think it's the same issue

14:56 <marex> anarsoul: I would probably need to turn the clock on/off in the correct order (on: core,pp0,pp1, off: the reverse)

14:57 <marex> I just dunno whether to put this into Lima driver, or the zynqmp clock driver (unlikely, since it already exposes those three clock separately)

15:02 <marex> anarsoul: I can imagine the lima driver could do devm_clk_bulk_get() to get all the clock in DT, which would work for both regular platforms and zynqmp ... and then clk_bulk_{enable/disable/etc}

15:11 <anarsoul|c> Handling it in clock driver would be cleaner, check other platforms that have mali utgard

15:17 <marex> anarsoul|c: except that sounds like we would need to introduce some sort of virtual clock

15:18 <marex> that doesn't sound like the right thing to export out of the clock driver and into DT bindings

15:19 <anarsoul|c> If you need to enable them in certain order it's a platform thing and it needs to be abstracted

15:20 <marex> anarsoul|c: shouldn't it be the other way around ? ie driver should know how to correctly handle all the clock, and if the driver currently cannot deal with these clock detail (which are apparently present on the mali400 core), it should be extended to do that ?

15:21 <marex> I mean, I can imagine what xilinx did there is they just had a single clock and then added one clock gate per clock input into the Mali400 IP core

15:21 <marex> other vendors just tied all those clock inputs to single clock gate

15:21 <marex> that's what I think happened

15:23 <anarsoul|c> How is it usually handled in Linux? So far I haven't seen drivers that can control variable number of clocks depending on platform

17:31 <marex> anarsoul|c: well since what you do now is enable bus_clk, enable core_clk , and when stopping the clock you do the reverse, you can very well replace that whole thing with clk_bulk calls :)

17:31 <marex> anarsoul|c: those could the clock in DT node and enable them in that order, then disable them in reverse

17:31 <marex> anarsoul|c: that;s how I think it migth be workable

17:32 <marex> but then there would have to be some magic in the DT binding doc about that

18:32 <anarsoul> marex: I think there were some dvfs patches in flight

18:32 <anarsoul> (if not merged yet)

18:32 <anarsoul> so you'll need to consider that as well

18:55 <marex> anarsoul: ah, I'll take a look