Hi Stefan, On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote: > 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? My understanding of usleep_range was that you can still overshoot, even though it's backed by an HR timer so the resolution is not a jiffy. Are we certain that we're going to be in that range? Maxime
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
