]> git.baikalelectronics.ru Git - kernel.git/commit
drm/msm: dpu: Untangle frame_done timeout units
authorSean Paul <seanpaul@chromium.org>
Mon, 28 Jan 2019 20:42:50 +0000 (15:42 -0500)
committerRob Clark <robdclark@chromium.org>
Thu, 18 Apr 2019 17:04:10 +0000 (10:04 -0700)
commit4f70f29a378651764379fbafbb9dc6963ba7ff62
tree9718f160ea90d65a1c78438266008685b8d64ee9
parent89d7ab395e966dc8c2f160dcf1ad27e3fca51df8
drm/msm: dpu: Untangle frame_done timeout units

There exists a bunch of confusion as to what the actual units of
frame_done is:

- The definition states it's in # of frames
- CRTC treats it like it's ms
- frame_done_timeout comment thinks it's Hz, but it stores ms
- frame_done timer is setup such that it _should_ be in frames, but the
  timeout is super long

So this patch tries to interpret what the driver really wants. I've
de-centralized the #define since the consumers are expecting different
units.

For crtc, we just use 60ms since that's what it was doing before.
Perhaps we could get fancy and scale with vrefresh, but that's for
another time.

For encoder, fix the comments and rename frame_done_timeout so it's
obvious what the units are. In practice, frame_done_timeout is really
just checked against 0 || !0, which I guess is why the units being wrong
didn't matter. I've also dropped the timeout from the previous 60 frames
to 5. That seems like more than enough time to give up on a frame, and
my guess is that no one intended for the timeout to _actually_ be 60
frames.

Reviewed-by: Fritz Koenig <frkoenig@google.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-3-sean@poorly.run
Signed-off-by: Rob Clark <robdclark@chromium.org>
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h