Hi Maxime, Am 29.07.20 um 16:42 schrieb Maxime Ripard: > Hi, > > On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: >> On Wed, 8 Jul 2020 at 18:43, Maxime Ripard <maxime@xxxxxxxxxx> wrote: >>> In order to avoid pixels getting stuck in the (unflushable) FIFO between >>> the HVS and the PV, we need to add some delay after disabling the PV output >>> and before disabling the HDMI controller. 20ms seems to be good enough so >>> let's use that. >>> >>> Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx> >>> --- >>> drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c >>> index d0b326e1df0a..7b178d67187f 100644 >>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c >>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c >>> @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc, >>> ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1); >>> WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); >>> >>> + mdelay(20); >> mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we >> not msleep instead? > Since the timing was fairly critical, sleeping didn't seem like a good > solution since there's definitely some chance you overshoot and end up > with a higher time than the one you targeted. usleep_range(min, max) isn't a solution? Stefan > > Maxime > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
