All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Simon Ser <contact@emersion.fr>
Cc: Jason Ekstrand <jason@jlekstrand.net>,
	James Jones <jajones@nvidia.com>,
	wayland-devel@lists.freedesktop.org,
	Pekka Paalanen <ppaalanen@gmail.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline
Date: Wed, 12 Oct 2022 13:00:51 +0200	[thread overview]
Message-ID: <4d058402-5379-8eaa-7f71-8bdc73685e58@amd.com> (raw)
In-Reply-To: <WVB2bcT7aLthDz-fKpP-_--tlos1G_EAuXbA2g5qnlTcZ4BK0z595RaTDjhaC8kK6R4P6dqvYOlgBf-ef8eAV7KMSZ_-v8HAztLFv0-_lA8=@emersion.fr>

Am 12.10.22 um 12:25 schrieb Simon Ser:
> On Tuesday, October 11th, 2022 at 14:10, Christian König <christian.koenig@amd.com> wrote:
>
>> Am 10.10.22 um 11:13 schrieb Simon Ser:
>>> On Sunday, October 9th, 2022 at 20:00, Christian König <christian.koenig@amd.com> wrote:
>>>
>>>> Am 09.10.22 um 16:40 schrieb Simon Ser:
>>>>
>>>>> Introduce a new DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD IOCTL
>>>>> which signals an eventfd when a timeline point completes.
>>>> I was entertaining the same though for quite a while, but I would even
>>>> go a step further and actually always base the wait before signal
>>>> functionality of the drm_syncobj and the eventfd functionality. That
>>>> would save us quite a bit of complexity I think.
>>> Hm what do you mean exactly? I'm not sure I'm following.
>> Essentially we have the syncobj_wait_entry structure which is added to
>> the list whenever somebody starts to wait for a sequence which hasn't
>> materialized yet.
>>
>> Instead of extending this maybe just completely nuke the
>> syncobj_wait_entry handling and replace it with your implementation here.
> Hm, no sure I understand how that would work. We don't have an eventfd in the
> WAIT IOCTL...
>
> We could merge the two structs and figure out which callback to invoke based
> on which fields are filled, but I figured two separate structs would be make
> for a cleaner split.

In this case feel free to go ahead with this approach.

Just make sure that you always add the eventfd structure to the right 
list. For example the list_add in drm_syncobj_add_eventfd() doesn't seem 
to be correct of hand.

Regards,
Christian.

  reply	other threads:[~2022-10-12 11:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-09 14:40 [RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline Simon Ser
2022-10-09 18:00 ` Christian König
2022-10-10  9:13   ` Simon Ser
2022-10-11 12:10     ` Christian König
2022-10-12 10:25       ` Simon Ser
2022-10-12 11:00         ` Christian König [this message]
2022-10-10  8:19 ` Pekka Paalanen
2022-10-10  9:20   ` Simon Ser

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=4d058402-5379-8eaa-7f71-8bdc73685e58@amd.com \
    --to=christian.koenig@amd.com \
    --cc=contact@emersion.fr \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jajones@nvidia.com \
    --cc=jason@jlekstrand.net \
    --cc=ppaalanen@gmail.com \
    --cc=wayland-devel@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.