09:32 <bbrezillon> dliviu, stepri01: Regarding the panthor_irq discussion we had yesterday, should I just kill the drm_dev_enter/exit() section there, and keep using _irq_supend() in the _unplug() path?

09:33 <bbrezillon> I don't really see a case where these helpers can be called after the device has been unplugged, but maybe I'm missing something

10:09 <dliviu> bbrezillon: yeah, I think we should rename _suspend() into _unplug() and move the drm_dev_enter()/exit() to the calling places where it makes sense.

10:29 <dliviu> bbrezillon: I don't care about the name of the function, I was just trying to be in the spirit of "_unplug() doesn't care about drm_dev_enter()/exit()". You can keep the name or choose another, I don't mind.

10:30 <dliviu> I think we're on the same page, make _suspend() look like your _unplug() and (where appropriate) add the drm_dev_enter()/exit() at the calling site.

10:37 <bbrezillon> I don't think we ever need dev_enter/exit(), that's my point

10:41 <dliviu> I don't disagree.

10:41 <bbrezillon> ok :-)

10:41 <bbrezillon> are you happy with the re-ordering in _irq_suspend()?

10:42 <bbrezillon> (and the argument that comes with it: we don't care about lost events at that point)

10:43 <dliviu> yes. Like you've said, when perf dumping comes along we sort out the synchronisation then

10:44 <bbrezillon> cool, I'll respin the last 2 patches then

16:45 <dliviu> bbrezillon: where is panthor (going to be) tested by freedesktop CI? What tests will be run?

17:20 <bbrezillon> dliviu: mesa-CI, and possibly igt if we develop tests for panthor

17:20 <bbrezillon> (not sure where igt test are run these days)

17:21 <dliviu> is mesa-CI including panthor atm? Or will in the future, and when?

17:21 <bbrezillon> for mesa-CI, we plan to have GLES[2-3.1] tested

17:22 <bbrezillon> it's not including panthor yet, but there's an effort to enable that, through the rock5b boards we have in our LAVA lab

17:22 <dliviu> how can I get notified of failures once that is started?

17:22 <bbrezillon> not that testing kernel drivers is not the primary goal of mesa-CI

17:23 <bbrezillon> *note

17:23 <dliviu> sure, but I'm interested in panfrost Mesa driver too

17:24 <bbrezillon> sure, just pointing that out to make it clear that the kernel driver used in mesa-CI is unlikely to be the one in drm-misc-next, that's all

17:31 <bbrezillon> dliviu: we will probably enable only manual testing first, then nightly runs, and finally, when we have enough boards, pre-merge testing

17:38 <bbrezillon> as for notifications, I don't know how you can receive panfrost CI failures only. You can get notified on all MRs touching panfrost/panvk though