14:09 <gerddie> Hi, I've started looking at a way to implement the PPU flop reset in the kernel, and now I'm wondering a bit what would be the best way: I could write some code that would basically create the buffers and replay them like mesa does, i.e. going through the IOCTL interface. For me, as someone who is not familiar with the kernel code this seems like

14:09 <gerddie> the best option. However, in this case it could also make sense to just implement a user space program that talks directly to DRM and does the same job. It would could be run during boot, e.g. triggered by udev when the rendernode becomes available, or from a startup script, and also during resume. Or do you have any other suggestions how this

14:09 <gerddie> could go into the kernel module?

14:19 <austriancoder> gerddie: if this PPU flop reset needs to be done every time after a PM resume, do it in the kernel without any user space program.

14:31 <austriancoder> gerddie: from a very quick look, the PPU flow reset is used for PM in the vivante kernel driver: viv_dev_system_suspend(..) -> gckHARDWARE_SetPowerState() -> gckHARDWARE_InitializeHardware(..) -> ... -> PPU flop reset

14:32 <austriancoder> s/viv_dev_system_suspend/viv_dev_system_resume

20:44 <gerddie> austriancoder: from what I can see it's actually gckHARDWARE_SetPowerState() -> _PmSetPowerOnDirection -> gckHARDWARE_InitializeHardware(..) ..., so the flop reset is called when it moves from either OFF or SUSPEND to IDLE or ON. My interpretation of this is that the flop reset is not used _for_ PM, it's just used to properly reset some

20:44 <gerddie> states/registers after the GPU comes back from OFF or SUSPEND. From that point of view it should not be relevant whether the flop reset is triggered from user space of from the kernel, the only problem is that it should be the first program to be run after turning the GPU on. I guess it is way easier to ensure this from kernel space.

20:46 <austriancoder> if I was unclear, it is not used FOR pm, needed to reset the GPU. Like its done for e.g. the 3d core.

20:47 <austriancoder> I think, goining kernel space is the only way to solve this

20:48 <gerddie> My question is now what is the best way to implement this in the kernel module: Call the IOCTL callbacks to mimic a user space program, or go deeper and try to use the internal interfaces? The first one seems easy enough for someone who has never touched this code, the second approach will require a lot of learning.

20:59 <austriancoder> looked at your RFC mesa MR. so you need two bo's (shader and image data) and a cmd stream. I think, you could put the command stream directly in to ring-buffer - see etnaviv_buffer.c, which safes you form using the submit ioctl callback. The bo's look small too .. maybe also put them into the ring-buffer

21:00 <austriancoder> and your "entry-point" would be etnaviv_gpu_hw_init(..)

21:05 <austriancoder> after your ppu flop reset the command buffer must have the wait-link combo as done by etnaviv_buffer_init(..) or by etnaviv_buffer_queue(..)

21:08 <austriancoder> or maybe you could extend etnaviv_buffer_init(..) - not sure which is nicer