Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Thomas Hellstrom"
	<thomas-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>,
	"David Airlie" <airlied-cv59FeDIM0c@public.gmane.org>,
	linux-arm-msm
	<linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Linux Kernel Mailing List"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"Sean Paul" <seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	"Ville Syrjälä"
	<ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	"Gustavo Padovan"
	<gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org>,
	"Deepak Singh Rawat"
	<drawat-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>,
	freedreno
	<freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"Lukasz Spintzyk"
	<lukasz.spintzyk-mKY92deTM1QHrNJx0XZkJA@public.gmane.org>
Subject: Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb
Date: Wed, 4 Apr 2018 13:49:07 +0200	[thread overview]
Message-ID: <4386c0a5-e8e4-34d7-a977-4136e1dec44f@linux.intel.com> (raw)
In-Reply-To: <CAF6AEGvozzCDtkRjCjMsZ5HtdHXbFiiVM52jZaz=VfshONzqTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Op 04-04-18 om 13:37 schreef Rob Clark:
> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com> wrote:
>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>>>> Add an atomic helper to implement dirtyfb support.  This is needed to
>>>>> support DSI command-mode panels with x11 userspace (ie. when we can't
>>>>> rely on pageflips to trigger a flush to the panel).
>>>>>
>>>>> To signal to the driver that the async atomic update needs to
>>>>> synchronize with fences, even though the fb didn't change, the
>>>>> drm_atomic_state::dirty flag is added.
>>>>>
>>>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>>>> ---
>>>>> Background: there are a number of different folks working on getting
>>>>> upstream kernel working on various different phones/tablets with qcom
>>>>> SoC's.. many of them have command mode panels, so we kind of need a
>>>>> way to support the legacy dirtyfb ioctl for x11 support.
>>>>>
>>>>> I know there is work on a proprer non-legacy atomic property for
>>>>> userspace to communicate dirty-rect(s) to the kernel, so this can
>>>>> be improved from triggering a full-frame flush once that is in
>>>>> place.  But we kinda needa a stop-gap solution.
>>>>>
>>>>> I had considered an in-driver solution for this, but things get a
>>>>> bit tricky if userspace ands up combining dirtyfb ioctls with page-
>>>>> flips, because we need to synchronize setting various CTL.FLUSH bits
>>>>> with setting the CTL.START bit.  (ie. really all we need to do for
>>>>> cmd mode panels is bang CTL.START, but is this ends up racing with
>>>>> pageflips setting FLUSH bits, then bad things.)  The easiest soln
>>>>> is to wrap this up as an atomic commit and rely on the worker to
>>>>> serialize things.  Hence adding an atomic dirtyfb helper.
>>>>>
>>>>> I guess at least the helper, with some small addition to translate
>>>>> and pass-thru the dirty rect(s) is useful to the final atomic dirty-
>>>>> rect property solution.  Depending on how far off that is, a stop-
>>>>> gap solution could be useful.
>>>>>
>>>>>  drivers/gpu/drm/drm_atomic_helper.c | 66 +++++++++++++++++++++++++++++++++++++
>>>>>  drivers/gpu/drm/msm/msm_atomic.c    |  5 ++-
>>>>>  drivers/gpu/drm/msm/msm_fb.c        |  1 +
>>>>>  include/drm/drm_atomic_helper.h     |  4 +++
>>>>>  include/drm/drm_plane.h             |  9 +++++
>>>>>  5 files changed, 84 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
>>>>> index c35654591c12..a578dc681b27 100644
>>>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>>>> @@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>>>>>     if (state->fb)
>>>>>             drm_framebuffer_get(state->fb);
>>>>>
>>>>> +   state->dirty = false;
>>>>>     state->fence = NULL;
>>>>>     state->commit = NULL;
>>>>>  }
>>>>> @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
>>>>>  }
>>>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>>>>>
>>>>> +/**
>>>>> + * drm_atomic_helper_dirtyfb - helper for dirtyfb
>>>>> + *
>>>>> + * A helper to implement drm_framebuffer_funcs::dirty
>>>>> + */
>>>>> +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
>>>>> +                         struct drm_file *file_priv, unsigned flags,
>>>>> +                         unsigned color, struct drm_clip_rect *clips,
>>>>> +                         unsigned num_clips)
>>>>> +{
>>>>> +   struct drm_modeset_acquire_ctx ctx;
>>>>> +   struct drm_atomic_state *state;
>>>>> +   struct drm_plane *plane;
>>>>> +   int ret = 0;
>>>>> +
>>>>> +   /*
>>>>> +    * When called from ioctl, we are interruptable, but not when
>>>>> +    * called internally (ie. defio worker)
>>>>> +    */
>>>>> +   drm_modeset_acquire_init(&ctx,
>>>>> +           file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
>>>>> +
>>>>> +   state = drm_atomic_state_alloc(fb->dev);
>>>>> +   if (!state) {
>>>>> +           ret = -ENOMEM;
>>>>> +           goto out;
>>>>> +   }
>>>>> +   state->acquire_ctx = &ctx;
>>>>> +
>>>>> +retry:
>>>>> +   drm_for_each_plane(plane, fb->dev) {
>>>>> +           struct drm_plane_state *plane_state;
>>>>> +
>>>>> +           if (plane->state->fb != fb)
>>>>> +                   continue;
>>>>> +
>>>>> +           plane_state = drm_atomic_get_plane_state(state, plane);
>>>>> +           if (IS_ERR(plane_state)) {
>>>>> +                   ret = PTR_ERR(plane_state);
>>>>> +                   goto out;
>>>>> +           }
>>>>> +
>>>>> +           plane_state->dirty = true;
>>>>> +   }
>>>>> +
>>>>> +   ret = drm_atomic_nonblocking_commit(state);
>>>>> +
>>>>> +out:
>>>>> +   if (ret == -EDEADLK) {
>>>>> +           drm_atomic_state_clear(state);
>>>>> +           ret = drm_modeset_backoff(&ctx);
>>>>> +           if (!ret)
>>>>> +                   goto retry;
>>>>> +   }
>>>>> +
>>>>> +   drm_atomic_state_put(state);
>>>>> +
>>>>> +   drm_modeset_drop_locks(&ctx);
>>>>> +   drm_modeset_acquire_fini(&ctx);
>>>>> +
>>>>> +   return ret;
>>>>> +
>>>>> +}
>>>>> +EXPORT_SYMBOL(drm_atomic_helper_dirtyfb);
>>>>> +
>>>>>  /**
>>>>>   * __drm_atomic_helper_private_duplicate_state - copy atomic private state
>>>>>   * @obj: CRTC object
>>>>> diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
>>>>> index bf5f8c39f34d..bb55a048e98b 100644
>>>>> --- a/drivers/gpu/drm/msm/msm_atomic.c
>>>>> +++ b/drivers/gpu/drm/msm/msm_atomic.c
>>>>> @@ -201,7 +201,10 @@ int msm_atomic_commit(struct drm_device *dev,
>>>>>      * Figure out what fence to wait for:
>>>>>      */
>>>>>     for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
>>>>> -           if ((new_plane_state->fb != old_plane_state->fb) && new_plane_state->fb) {
>>>>> +           bool sync_fb = new_plane_state->fb &&
>>>>> +                   ((new_plane_state->fb != old_plane_state->fb) ||
>>>>> +                    new_plane_state->dirty);
>>>> Why do you have this optimization even here? Imo flipping to the same fb
>>>> should result in the fb getting fully uploaded, whether you're doing a
>>>> legacy page_flip, and atomic one or just a plane update.
>>>>
>>>> Iirc some userspace does use that as essentially a full-plane frontbuffer
>>>> rendering flush already. IOW I don't think we need your
>>>> plane_state->dirty, it's implied to always be true - why would userspace
>>>> do a flip otherwise?
>>>>
>>>> The helper itself to map dirtyfb to a nonblocking atomic commit looks
>>>> reasonable, but misses a bunch of the trickery discussed with Noralf and
>>>> others I think.
>>> Ok, I've done some history digging:
>>>
>>> - i915 and nouveau unconditionally wait for fences, even for same-fb
>>>   flips.
>>> - no idea what amdgpu and vmwgfx are doing, they're not using
>>>   plane_state->fence for implicit fences.
>> I thought plane_state->fence was used for explicit fences, so its use by drivers
>> would interfere with it? I don't think fencing would work on msm or vc4..
> for implicit fencing we fish out the implicit fence and stuff it in
> plane_state->fence..
What happens when userspace passes a fence fd to in_fence_fd?
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

  parent reply	other threads:[~2018-04-04 11:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-03 22:42 [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb Rob Clark
2018-04-04  6:58 ` Daniel Vetter
2018-04-04  8:22   ` Thomas Hellstrom
     [not found]     ` <307adb15-412a-1fe2-f116-27fe5b4a657d-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>
2018-04-04  8:43       ` Daniel Vetter
2018-04-04  9:10         ` Thomas Hellstrom
2018-04-04  9:56           ` Daniel Vetter
2018-04-04 10:28             ` Thomas Hellstrom
     [not found]               ` <9b731e33-32fd-e7e7-952f-75b87ff26f8a-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>
2018-04-04 11:46                 ` Thomas Hellstrom
     [not found]                   ` <61931c2e-4c81-0d94-fd45-f4f7dd91cb13-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>
2018-04-04 12:13                     ` Daniel Vetter
     [not found]             ` <20180404095604.GD3881-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-04-04 11:40               ` Rob Clark
     [not found]                 ` <CAF6AEGs4BdOUQQH6N8_ywTA=8uraJNm8FGc1ZL8Pm9tqymy3Nw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-04 12:16                   ` Daniel Vetter
2018-04-04 13:24                     ` Rob Clark
     [not found]                       ` <CAF6AEGv2yfBzSbcAdKqZ0wJT5XoF9uqZKKJT297aib10O88=xQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-04 13:28                         ` Daniel Vetter
2018-04-05 13:30               ` Thomas Hellstrom
2018-04-05 13:35                 ` Daniel Vetter
2018-04-06  0:19                   ` Deepak Singh Rawat
     [not found]                 ` <7616bf87-bd2e-5003-af35-bc95f0e2a912-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>
2018-04-06  0:36                   ` Rob Clark
     [not found] ` <20180403224225.26776-1-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-04-04 10:03   ` Daniel Vetter
     [not found]     ` <20180404100300.GE3881-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-04-04 10:21       ` Daniel Vetter
     [not found]         ` <20180404102108.GF3881-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-04-04 10:36           ` Maarten Lankhorst
     [not found]             ` <4976c166-32b2-75ef-ee78-7e7893dd4121-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-04-04 11:37               ` Rob Clark
     [not found]                 ` <CAF6AEGvozzCDtkRjCjMsZ5HtdHXbFiiVM52jZaz=VfshONzqTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-04 11:49                   ` Maarten Lankhorst [this message]
     [not found]                     ` <4386c0a5-e8e4-34d7-a977-4136e1dec44f-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-04-04 12:05                       ` Rob Clark
2018-04-04 12:23                         ` Maarten Lankhorst
2018-04-04 12:26                         ` Daniel Vetter
     [not found]                           ` <CAKMK7uEMsUOFDWishv6L0519Z7eiz+7LcHMpQAZu1bO7i2dVDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-04 12:28                             ` Maarten Lankhorst
2018-04-04 13:26                             ` Rob Clark
2018-04-04 11:35           ` Rob Clark
     [not found]             ` <CAF6AEGtowtdQmUxNF_F3B3Yow+PDB43Eb0VJ_ZqGKpVw1iZBzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-04 12:18               ` Daniel Vetter
2018-04-04 17:41   ` Noralf Trønnes
     [not found]     ` <4dac69b7-b0e6-a014-1c36-1a9934f14120-L59+Z2yzLopAfugRpC6u6w@public.gmane.org>
2018-04-04 17:56       ` Daniel Vetter
     [not found]         ` <CAKMK7uFvjQF-SxPkx_G5Y_o1AHkbms=Dhkie9de3s4JyepyH1g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-04 18:52           ` Noralf Trønnes
2018-04-04 19:19       ` Rob Clark

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=4386c0a5-e8e4-34d7-a977-4136e1dec44f@linux.intel.com \
    --to=maarten.lankhorst-vuqaysv1563yd54fqh9/ca@public.gmane.org \
    --cc=airlied-cv59FeDIM0c@public.gmane.org \
    --cc=drawat-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lukasz.spintzyk-mKY92deTM1QHrNJx0XZkJA@public.gmane.org \
    --cc=robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=thomas-4+hqylr40dJg9hUCZPvPmw@public.gmane.org \
    --cc=ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.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