Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Rob Clark <robdclark@gmail.com>
To:     dri-devel@lists.freedesktop.org
Cc:     Rob Clark <robdclark@chromium.org>,
        Abhinav Kumar <abhinavk@codeaurora.org>,
        Bernard <bernard@vivo.com>,
        freedreno@lists.freedesktop.org (open list:DRM DRIVER FOR MSM ADRENO
        GPU), Hongbo Yao <yaohongbo@huawei.com>,
        Kalyan Thota <kalyan_t@codeaurora.org>,
        linux-arm-msm@vger.kernel.org (open list:DRM DRIVER FOR MSM ADRENO GPU),
        linux-kernel@vger.kernel.org (open list),
        Maxime Ripard <maxime@cerno.tech>,
        Qinglang Miao <miaoqinglang@huawei.com>,
        Stephen Boyd <swboyd@chromium.org>
Subject: [PATCH 0/2] drm: Fix atomic helper dirtyfb stalls
Date:   Sat,  8 May 2021 12:56:37 -0700
Message-Id: <20210508195641.397198-1-robdclark@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

From: Rob Clark <robdclark@chromium.org>

Someone on IRC once asked an innocent enough sounding question:  Why
with xf86-video-modesetting is es2gears limited at 120fps.

So I broke out the perfetto tracing mesa MR and took a look.  It turns
out the problem was drm_atomic_helper_dirtyfb(), which would end up
waiting for vblank.. es2gears would rapidly push two frames to Xorg,
which would blit them to screen and in idle hook (I assume) call the
DIRTYFB ioctl.  Which in turn would do an atomic update to flush the
dirty rects, which would stall until the next vblank.  And then the
whole process would repeat.

But this is a bit silly, we only need dirtyfb for command mode DSI
panels.  So lets just skip it otherwise.

Rob Clark (2):
  drm: Fix dirtyfb stalls
  drm/msm/dpu: Wire up needs_dirtyfb

 drivers/gpu/drm/drm_damage_helper.c      |  8 ++++++++
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 14 ++++++++++++++
 include/drm/drm_modeset_helper_vtables.h | 14 ++++++++++++++
 3 files changed, 36 insertions(+)

-- 
2.30.2