JohnnyonFlame has quit [Ping timeout: 246 seconds]
JohnnyonFlame has joined #etnaviv
lynxeye has joined #etnaviv
<marex>
the MX8MM GPCv2 can fail because if the gpu2d exits imx_gpc_pu_pgc_sw_pxx_req() in one thread and is just before pm_runtime_put() , and gpu3d enters imx_gpc_pu_pgc_sw_pxx_req() and is just before pm_runtime_get_sync(), then depending on the order, the gpumix might just be enabled and disabled right away, followed by gpu3d PU enabling, which obviously fails
<marex>
so PD nesting might need some locking work
<marex>
lynxeye: ^
<lynxeye>
marex: I don't quite understand the failure case. If one GPU domain puts the mix domain before the other has reached get_sync() the mix domain will be powered down, but then get powered up again when the thread reaches the get_sync()
<lynxeye>
Is this a problem?
<lynxeye>
If one thread already passed the get_sync() the mix domain should not be powered down, even when the other GPU domain executes the put()
<marex>
lynxeye: the problem is if one GPU powers down gpu2d and the other powers up gpu3d ; the first thread can power down the mix domain right after it was powered up by gpu3d thread
<marex>
unless there is proper synchronization
<lynxeye>
Huh? How do you get the mix domain to power down after one GPU executed the get_sync()? The mix domain power state is reference counted through the genpd code, no?
<marex>
lynxeye: so there should be two references at that point ?
<marex>
lynxeye: are you sure that works if the parent device of all the gpcv2 PDs is the same parent device ?
<lynxeye>
Yes, there should be two references. But it's worth validating this assumption ;)
<marex>
lynxeye: btw did you ever use the SMC-based power managed to start the GPU, did that work ?
<marex>
iirc it was flaky for me too
<lynxeye>
I haven't used that at all.
<marex>
lynxeye: ha, ok, well, I'll keep digging
<marex>
lynxeye: well, duh ... imx_gpc_pu_pgc_sw_pxx_req() calls pm_runtime_get_sync(domain->dev); and pm_runtime_put(domain->dev);
<marex>
lynxeye: so if gpu3d thread calls the former, gets rescheduled ... then gpu2d thread calls the later, gets rescheduled ... then gpu3d tries to enable GPU3D, it must fail
<marex>
yes ?
<marex>
notice the domain->dev
<marex>
that's the same device for all of the PDs
<marex>
so nope, it's all bolted down with mutexes now, and it still fails
pcercuei has joined #etnaviv
berton has joined #etnaviv
T_UNIX has joined #etnaviv
lynxeye has quit [Quit: Leaving.]
hanzelpeter has joined #etnaviv
<marex>
so ok, the weirdness is some gpumix+gpu2d interaction
<marex>
yep, seems that SRC reset of the GPU is needed and fixes the gpu2d misbehavior
<marex>
that means the three gpu PDs on MX8MM are basically unusable because the GPUs share one reset
<marex>
sigh
T_UNIX has quit [Quit: Connection closed for inactivity]
<mntmn>
marex: do they need to be reset all the time or what?
<marex>
mntmn: dunno
<marex>
mntmn: TFA does it every time the PD is brought up
<marex>
I wonder whether if I bring the PD up, reset the GPUs, and then suspend it again, whether that would be reliable
<marex>
but obv they should've connected reset to each GPU ... sigh
_daniel_ has joined #etnaviv
<marex>
so nope, toggling the GPU reset in TFA doesn't help
<marex>
that basically means that to bring up either GPU, you either bring up the whole cluster or nothing, sigh
<marex>
so three power domains are useless I guess
hanzelpeter has quit [Quit: leaving]
_daniel_ has quit [Quit: Leaving.]
berton has quit [Remote host closed the connection]