The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Tomasz Figa <tfiga@chromium.org>
Cc: "Enric Balletbo i Serra" <enric.balletbo@collabora.com>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"David Airlie" <airlied@linux.ie>,
	"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,"
	<linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Gustavo Padovan" <gustavo.padovan@collabora.com>,
	"Sean Paul" <seanpaul@google.com>,
	kernel@collabora.com, "Stéphane Marchesin" <marcheu@google.com>
Subject: Re: [PATCH] drm/rockchip: update cursors asynchronously through atomic.
Date: Mon, 13 Aug 2018 09:26:08 +0200	[thread overview]
Message-ID: <1889320.MtRaPYoaVN@phil> (raw)
In-Reply-To: <CAAFQd5CGhkfTRzSdTqtFh4zuQuFH0H5SVyKWtk98Ceh_izo4=A@mail.gmail.com>

Am Montag, 13. August 2018, 09:11:07 CEST schrieb Tomasz Figa:
> Hi Enric,
> 
> On Tue, Aug 7, 2018 at 12:53 AM Enric Balletbo i Serra
> <enric.balletbo@collabora.com> wrote:
> >
> > Add support to async updates of cursors by using the new atomic
> > interface for that.
> >
> > Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > ---
> > Hi,
> >
> > This first version is slightly different from the RFC, note that I did
> > not maintain the Sean reviewed tag for that reason. With this version I
> > don't touch the atomic_update function and all is implemented in the
> > async_check/update functions. See the changelog for a list of changes.
> >
> > The patch was tested on a Samsung Chromebook Plus in two ways.
> >
> >  1. Running all igt kms_cursor_legacy and kms_atomic@plane_cursor_legacy
> >     tests and see that there is no regression after the patch.
> >
> >  2. Running weston using the atomic API.
> 
> Thanks for the patch. This feature might look like a really minor
> thing, but we really had hard time dealing with users complaints, so
> having this in upstream would be a really useful thing.
> 
> Let me post some comments inline.
> 
> >
> > Best regards,
> >   Enric
> >
> > Changes in v1:
> > - Rebased on top of drm-misc
> > - In async_check call drm_atomic_helper_check_plane_state to check that
> >   the desired plane is valid and update various bits of derived state
> >   (clipped coordinates etc.)
> > - In async_check allow to configure new scaling in the fast path.
> > - In async_update force to flush all registered PSR encoders.
> > - In async_update call atomic_update directly.
> > - In async_update call vop_cfg_done needed to set the vop registers and take effect.
> >
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 53 +++++++++++++++++++++
> >  1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index e9f91278137d..dab70056ee73 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -811,10 +811,63 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
> >         spin_unlock(&vop->reg_lock);
> >  }
> >
> > +static int vop_plane_atomic_async_check(struct drm_plane *plane,
> > +                                       struct drm_plane_state *state)
> > +{
> > +       struct vop_win *vop_win = to_vop_win(plane);
> > +       const struct vop_win_data *win = vop_win->data;
> > +       int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
> > +                                       DRM_PLANE_HELPER_NO_SCALING;
> > +       int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
> > +                                       DRM_PLANE_HELPER_NO_SCALING;
> > +       int ret;
> > +
> > +       if (plane != state->crtc->cursor)
> > +               return -EINVAL;
> > +
> > +       if (!plane->state)
> > +               return -EINVAL;
> > +
> > +       if (!plane->state->fb ||
> > +           plane->state->fb != state->fb)
> > +               return -EINVAL;
> 
> While it covers for quite a big part of cursor movements, you may
> still expect jumpy cursor when hoovering text boxes or hyperlinks,
> since it changes the cursor image. Our downstream patch [1] actually
> took care of changing the framebuffer as well, although with the added
> complexity of referencing the old buffer at update time and releasing
> it in a flip work.
> 
> [1] https://chromium.git.corp.google.com/chromiumos/third_party/kernel/+/1ad887e1a1349991c9e137b48cb32086e65347fc%5E%21/

[1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/394492
for non-google people ;-)


Heiko

> > +
> > +       ret = drm_atomic_helper_check_plane_state(plane->state,
> > +                                                 plane->crtc->state,
> > +                                                 min_scale, max_scale,
> > +                                                 true, true);
> > +       return ret;
> > +}
> > +
> > +static void vop_plane_atomic_async_update(struct drm_plane *plane,
> > +                                         struct drm_plane_state *new_state)
> > +{
> > +       struct vop *vop = to_vop(plane->state->crtc);
> > +
> > +       plane->state->crtc_x = new_state->crtc_x;
> > +       plane->state->crtc_y = new_state->crtc_y;
> > +       plane->state->crtc_h = new_state->crtc_h;
> > +       plane->state->crtc_w = new_state->crtc_w;
> > +       plane->state->src_x = new_state->src_x;
> > +       plane->state->src_y = new_state->src_y;
> > +       plane->state->src_h = new_state->src_h;
> > +       plane->state->src_w = new_state->src_w;
> > +
> > +       if (vop->is_enabled) {
> > +               rockchip_drm_psr_flush_all(plane->dev);
> 
> We should use the inhibit mechanism when accessing VOP hardware. While
> the flush is expected to keep the PSR disabled for at least 100 ms,
> we're not in any atomic (pun not intended) context here and might get
> preempted for some unspecified time in very high load conditions.
> 
> Best regards,
> Tomasz
> 





  reply	other threads:[~2018-08-13  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06 15:53 [PATCH] drm/rockchip: update cursors asynchronously through atomic Enric Balletbo i Serra
2018-08-13  7:11 ` Tomasz Figa
2018-08-13  7:26   ` Heiko Stuebner [this message]
2018-08-13  7:29     ` Tomasz Figa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1889320.MtRaPYoaVN@phil \
    --to=heiko@sntech.de \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=enric.balletbo@collabora.com \
    --cc=gustavo.padovan@collabora.com \
    --cc=hjc@rock-chips.com \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=marcheu@google.com \
    --cc=seanpaul@google.com \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox