<jernej>
loki666: just for my understanding - does this issue happen at first GPU use or only after you re-load driver?
evgeny_boger has quit [Ping timeout: 480 seconds]
szemzoa has quit [Remote host closed the connection]
<apritzel>
jernej: what I have seen is that when panfrost probes at boot, it activates the pd, then goes back "to sleep" quickly, which deactivates the PD. This part works, it's apparently the next pd activate that hangs
<apritzel>
so very similar to the CPU behaviour on the A523
szemzoa has joined #linux-sunxi
<jernej>
ah, yes, I didn't know that sleep also manages pd
<jernej>
I guess in worst case, quirk needs to be implemented in GPU driver
<jernej>
which would hold pd enabled whole time
colinsane1 has quit []
colinsane has joined #linux-sunxi
<loki666>
jernej: first GPU usage
<apritzel>
with GPU driver you mean my GPU PD driver? If yes: indeed that is one hack already floating around. If we can prove that this is an AW integration issue, we could justify this hack to be upstreamed
<apritzel>
jernej: and I don't know if "sleep" is the right term here, my observation was: the driver probes and registers, but at this point there is nothing to do (yet), and that triggers the PD deactivate
colinsane1 has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
massoud has quit [Remote host closed the connection]
massoud has joined #linux-sunxi
rtp has quit [Remote host closed the connection]
rtp has joined #linux-sunxi
<jernej>
apritzel: I meant panfrost, but I guess PD driver would make more sense
colinsane11 has joined #linux-sunxi
<loki666>
But why is it working the first time, is it a lucky left over from u-boot ?
<loki666>
Or is it disabling PD while clock/reset is enabled ?
<loki666>
That break the thing and crash on next pd enable ?
<jernej>
loki666: I see that in bifrost platform driver there is power_on_callback and power_off_callback which enable and disable PD respectively. Have you tried re-loading it? This should cycle PD and show if this combination is broken there too.
colinsane1 has quit [Ping timeout: 480 seconds]
<loki666>
On first GPU usage it's the enabling of PD that hangs the system
<jernej>
if you compile driver as a module, load it, use it, rmmod it, modprobe it and use it again
<jernej>
I wonder if it shows same issue
<loki666>
Ok I'll try as a module...
<loki666>
jernej: the difference with bifrost platform driver is that pd is disabled after clock and reset, where with panfrost, pd is disabled while clock is still enabled and reset deasserted
<loki666>
but I'll try the module load/unload
<jernej>
loki666: panfrost can always be updated, but if I'm not mistaken, you already tried switching order in panfrost without success?
warpme has joined #linux-sunxi
<loki666>
jernej: yes, but it doesn't matter really, as panfrost doesn't go though its _fini function
<loki666>
well I guess it will if I unload it
<loki666>
I still think we need a hook in the PD driver, if the GPU PD can only be enabled in certain conditions, I guess it's up to the sunxi PD driver to ensure that, not panfrost
<jernej>
but panfrost has weird ordering which is imo wrong
<loki666>
indeed, but the issue seems to be that the PD is disabled, just after probing (while clock and reset are still enabled)
<apritzel>
... which sounds like a bug in panfrost, so it indeed should be fixed there
ftg has joined #linux-sunxi
<apritzel>
I wonder if other platforms do not give a proper power domain, like only something that covers parts of the GPU, but not the whole of it, including the register interface
warpme has quit []
<jernej>
"Single domain is handled by the core"
<jernej>
so this is not completely fault of panfrost
<jernej>
according to loki666's trace, PD is already enabled before PD code in panfrost driver is even reached
<loki666>
indeed
<loki666>
so with the panfrost compiled as a module, pd is not enabled on boot (before panfrost is loaded)
<loki666>
mmh crap... panfrost is not compiled at all... let me check
<jernej>
it seems that by default, clocks are not disabled during suspend, only PD
<jernej>
so this panfrost_compatible data explicitly states that clocks should be disabled too
<jernej>
now I hope it's done in proper order
<loki666>
I think I tested that already....
<loki666>
but maybe not with the correct order
<jernej>
loki666: please also remove generic compatible from DT, so we're sure it takes proper data
<loki666>
ah maybe that was that... I'll test
<apritzel>
jernej: nice find, but shouldn't this be a generic fix, and not AW specific? I mean turning off the power domain sounds indeed like the last thing you want to do, regardless of the SoC implementation
<jernej>
apritzel: not sure what do you mean. power domain handling won't change with my suggested fix
<jernej>
it will only make sure clocks are disabled too
<jernej>
if that's not enough, we can add reset too
<apritzel>
ah, I see
apritzel has quit [Ping timeout: 480 seconds]
hazardchem has quit [Read error: Connection reset by peer]
<loki666>
jernej: so I added your patch and changed the order of init to match biforst support code, but it doesn't changes nothing...
<loki666>
driver doesn't go in panfrost_device_resume/suspend (where the GPU_PM_CLK_DIS flag is tested)
<loki666>
rmmod the driver also crash, as this enable back the GPU pd
<loki666>
what is enabling/disabling the GPU pd, it doesn't seems to be the panfrost, since panfrost_pm_domain_init() return early because there is only one PD