ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at and - Contact ARM for binary driver support!
<marex> anarsoul: well, success, Lima works on my zynqmp with 5.10.y, except the GALLIUM_HUD is acting funny :)
<marex> but damn, getting GPU operational in 4 hours compared to 4 days with the blob ... that is just great
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #lima
bhoj- has quit [Ping timeout: 264 seconds]
bhoj has joined #lima
bhoj has quit [Read error: Connection reset by peer]
bhoj has joined #lima
bhoj has quit [Client Quit]
bhoj has joined #lima
<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
<marex> anarsoul: maybe at least some extra description/clarification could be found there then
<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)
<marex> I can imagine bus clock can be turned into optional ones
<marex> but the core/pp0/pp1, hmmm, well, I can use clk_bulk I guess
<marex> request all the clock, enable them all, that kind of thing would even work with the other devices which have bus/core clock
<anarsoul> marex: no idea
<anarsoul> looks like zynqmp is quite special, all other SoCs usually have a single clock gate for GPU
<anarsoul> marex: can you actually change clock rate of core, pp0 and pp1 separately?
<linkmauve> marex, if you refer to missing text in GALLIUM_HUD (replaced with squares), I can reproduce on Allwinner on 5.11 too.
<linkmauve> I have yet to investigate that, but GTK has its own HUD so I haven’t priorised it yet. :)
putti_ is now known as Putti
MoeIcenowy has quit [Ping timeout: 240 seconds]
Moe_Icenowy has joined #lima
Moe_Icenowy is now known as MoeIcenowy
lvrp16 has quit [Ping timeout: 240 seconds]
tlwoerner has quit [Ping timeout: 256 seconds]
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #lima
<marex> anarsoul: separately? No ... it seems there is one single divider, see
<marex> linkmauve: it looks like corrupted texture in my case, but I think it's the same issue
<marex> anarsoul: I would probably need to turn the clock on/off in the correct order (on: core,pp0,pp1, off: the reverse)
<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)
<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}
<anarsoul|c> Handling it in clock driver would be cleaner, check other platforms that have mali utgard
<marex> anarsoul|c: except that sounds like we would need to introduce some sort of virtual clock
<marex> that doesn't sound like the right thing to export out of the clock driver and into DT bindings
<anarsoul|c> If you need to enable them in certain order it's a platform thing and it needs to be abstracted
<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 ?
<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
<marex> other vendors just tied all those clock inputs to single clock gate
<marex> that's what I think happened
<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
<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 :)
<marex> anarsoul|c: those could the clock in DT node and enable them in that order, then disable them in reverse
<marex> anarsoul|c: that;s how I think it migth be workable
<marex> but then there would have to be some magic in the DT binding doc about that
dev1990 has quit [Read error: Connection reset by peer]
dev1990 has joined #lima
Elpaulo has joined #lima
<anarsoul> marex: I think there were some dvfs patches in flight
<anarsoul> (if not merged yet)
<anarsoul> so you'll need to consider that as well
<marex> anarsoul: ah, I'll take a look
dev1990 has quit [Excess Flood]
dev1990 has joined #lima
tlwoerner has joined #lima
warpme_ has quit [Quit: Connection closed for inactivity]