Tobias Jakobi wrote: > The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke > operation of the G2D. After this commit the following > happens. > - exynos_g2d_exec_ioctl() prepares a runqueue node and > calls g2d_exec_runqueue() > - g2d_exec_runqueue() calls g2d_dma_start() which gets > runtime PM sync > - runtime PM calls g2d_runtime_resume() > - g2d_runtime_resume() calls g2d_exec_runqueue() > > Luckily for us this doesn't really loop, but creates a > mutex lockup, which the kernel even predicts. > > Anyway, we fix this by reintroducing dedicated sleep > operations again, and only letting runtime PM control > the gate clock. > > This is not enough to fix the issue though. > - We switch runtime PM to autosuspend. Currently clocks get > disabled, and then re-enabled again in the runqueue worker > when a node is completed and the next is started. > With the upcoming introduction of IOMMU runtime PM this > situations gets worse, since now also the IOMMU goes > through a disable/enable cycle before the next node is > started. > - We consolidate all runtime PM management to the runqueue > worker. > - We introduce g2d_wait_finish() which waits until the currently > processed runqueue node is finished. > If this takes too long, the engine is forcibly reset. This > is necessary to properly close the driver in case the engine > should hang with read/write access to some area of memory. > In this situation we can't properly unmap GEM/userptr > objects, since this might create a pagefault. > - Sleep suspend issues a suspend of the runqueue and then calls > g2d_wait_finished(), which returns the engine in the idle state. This should read 'g2d_wait_finish()'. > The current runqueue node gets completed, all other queued > nodes stay in the queue. There is no hardware state that > needs to be retained. > - Sleep resume just pokes the runqueue worker, which, should > something be in queue, continues its work, or just exits. > > Signed-off-by: Tobias Jakobi <tjakobi@xxxxxxxxxxxxxxxxxxxxx> <snip> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
