Searched hist:"7 caecdbe" (Results 1 – 1 of 1) sorted by relevance
| /openbmc/linux/drivers/gpu/drm/rockchip/ |
| H A D | rockchip_drm_vop.c | 7caecdbe Wed Sep 14 07:54:56 CDT 2016 Tomasz Figa <tfiga@chromium.org> drm/rockchip: Avoid race with vblank count increment
Since VOP does not have a hardware vblank count register, the ongoing
commit might be racing with a requested vblank interrupt, which would
increment the software vblank counter before the changes being committed
actually happen.
To avoid this, we can extend .atomic_flush(), so after it sets cfg_done
bit, it polls the vblank interrupt bit until it's inactive to make sure
that any old vblank interrupt gets to the handler and then uses
synchronize_irq(vop->irq) to make sure the handler finishes running.
The polling case should happen very rarely, but even if, the total wait
time should be relatively low and in practice almost equal to the vop
hardirq handler running time.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
7caecdbe Wed Sep 14 07:54:56 CDT 2016 Tomasz Figa <tfiga@chromium.org> drm/rockchip: Avoid race with vblank count increment
Since VOP does not have a hardware vblank count register, the ongoing
commit might be racing with a requested vblank interrupt, which would
increment the software vblank counter before the changes being committed
actually happen.
To avoid this, we can extend .atomic_flush(), so after it sets cfg_done
bit, it polls the vblank interrupt bit until it's inactive to make sure
that any old vblank interrupt gets to the handler and then uses
synchronize_irq(vop->irq) to make sure the handler finishes running.
The polling case should happen very rarely, but even if, the total wait
time should be relatively low and in practice almost equal to the vop
hardirq handler running time.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
|