12:09 <marex> lynxeye: you're still missing the locking in your GPCv2 mx8mm stuff at least

12:10 <marex> lynxeye: consider both GPU2D and GPU3D are accessing the PWRHSK register

12:11 <marex> austriancoder: did you run glmark2 on mx6dl recently ? seems the RGB10A2 format is picked by default, and then glmark fails

12:12 <marex> it is again this 64c7cdcae51 ("etnaviv: add missing formats")

12:12 <marex> flto: ^

12:12 <marex> its likely the same problem I had with clutter

12:30 <lynxeye> marex: I don't see the issue? read-modify-write cycles on registers are locked in the regmap

12:32 <marex> lynxeye: and that whole PGC power up/down thing doesn't need to be atomic ?

12:50 <lynxeye> marex: at least as far as I understand the GPCv2 you can trigger power sequencing for multiple domains at the same time

12:51 <marex> lynxeye: and those shared registers are OK with it ? PWRHSK and I think there is one more ...

12:51 <lynxeye> so the only thing you need to take care of is not corrupting the state of shared registers (which regmap does for us)

12:52 <lynxeye> and obviously you need to synchronize power up of parent domains, but that is done via the rpm framework

12:52 <marex> lynxeye: would that work for the VPU domain too ? if you enable e.g. G1 and G2 , which both need to enable VPUMIX

12:52 <marex> lynxeye: I have a feeling you will hit some synchronization issue there

12:53 <marex> and with dispmix maybe too

12:53 <marex> lynxeye: btw did you try the DSI yet ?

12:53 <lynxeye> Nope that's the same thing with multiple devices in a domain

12:54 <lynxeye> first one to use the domain triggers the power up, other wait until power up done in the _sync variants of the rpm calls

12:54 <marex> lynxeye: well, submit the stuff, CC me and I will possibly complain if I hit some sync issue

12:55 <lynxeye> marex: one of my colleagues is working on DSI, but for proper power management we need the same BLKCTRL drivers as with the VPUs

12:55 <marex> lynxeye: it sure is a pity NXP didn't upstream things properly

12:55 <marex> lynxeye: oh, right ... I noticed that we also dont bring the CPU cores via Linux GPCv2 driver, but via PSCI call, yuck

12:56 <lynxeye> i.e. it doesn't suffice to enable the reset clocks in the CCM, but you need to enable them in the BLKCTRL, same with the VPU/DSI resets

12:56 <marex> which then does GPCv2 work anyway in TFA

12:57 <marex> lynxeye: I didn't get that far with the DSI, so thanks for the heads up

13:00 <flto> marex: is that with glmark-drm? if so, freedreno has the same problem (it doesn't try to pick a config that it can actually scanout), its a problem with glmark, you can run with "--visual-config r=8"

13:01 <marex> flto: well yes, --visual-config red=8 seems like a workaround, no ?

13:01 <flto> but its a problem with glmark-drm, not mesa, it even does the same on my desktop

13:05 <marex> flto: shouldn't mesa somehow help glmark to select the right format, e.g. by not offering RGB10A2 if that's what the scanout engine cannot handle ?

13:05 <marex> flto: or reduce the priority of RGB10A2 ?