All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Lyude Paul <lyude@redhat.com>
Cc: "Daniel Vetter" <daniel@ffwll.ch>,
	nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@linux.ie>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/9] drm/vblank: Add vblank works
Date: Tue, 14 Apr 2020 14:17:11 -0400	[thread overview]
Message-ID: <20200414181711.GO60335@mtj.duckdns.org> (raw)
In-Reply-To: <a2d9da054ace3f0ff59373c5a6252f25e1c3df4b.camel@redhat.com>

Hello,

On Tue, Apr 14, 2020 at 12:52:51PM -0400, Lyude Paul wrote:
> Hi, thanks for the response! And yes-I think this would actually be perfect
> for what we need, I guess one question I might as well ask since I've got you
> here: would patches to expose an unlocked version of kthread_queue_worker() be
> accepted? With something like that I should be able to just reuse the
> delayed_work_list and spinlocks that come with kthread_worker which would make
> the vblank works implementation a bit easier

Difficult to tell w/o looking at the code but if technically reasonable and
justified, I don't see a reason why something like that couldn't be accepted.
That said, whatever gain coming from sharing an inner lock like that usually
is miniscule and API and logic simplicity often easily outweighs.

Thanks.

-- 
tejun

WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "David Airlie" <airlied-cv59FeDIM0c@public.gmane.org>,
	nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Maarten Lankhorst"
	<maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Maxime Ripard" <mripard-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Daniel Vetter" <daniel-/w4YWyX8dFk@public.gmane.org>,
	"Ville Syrjälä"
	<ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Subject: Re: [PATCH 1/9] drm/vblank: Add vblank works
Date: Tue, 14 Apr 2020 14:17:11 -0400	[thread overview]
Message-ID: <20200414181711.GO60335@mtj.duckdns.org> (raw)
In-Reply-To: <a2d9da054ace3f0ff59373c5a6252f25e1c3df4b.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hello,

On Tue, Apr 14, 2020 at 12:52:51PM -0400, Lyude Paul wrote:
> Hi, thanks for the response! And yes-I think this would actually be perfect
> for what we need, I guess one question I might as well ask since I've got you
> here: would patches to expose an unlocked version of kthread_queue_worker() be
> accepted? With something like that I should be able to just reuse the
> delayed_work_list and spinlocks that come with kthread_worker which would make
> the vblank works implementation a bit easier

Difficult to tell w/o looking at the code but if technically reasonable and
justified, I don't see a reason why something like that couldn't be accepted.
That said, whatever gain coming from sharing an inner lock like that usually
is miniscule and API and logic simplicity often easily outweighs.

Thanks.

-- 
tejun

WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Lyude Paul <lyude@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/9] drm/vblank: Add vblank works
Date: Tue, 14 Apr 2020 14:17:11 -0400	[thread overview]
Message-ID: <20200414181711.GO60335@mtj.duckdns.org> (raw)
In-Reply-To: <a2d9da054ace3f0ff59373c5a6252f25e1c3df4b.camel@redhat.com>

Hello,

On Tue, Apr 14, 2020 at 12:52:51PM -0400, Lyude Paul wrote:
> Hi, thanks for the response! And yes-I think this would actually be perfect
> for what we need, I guess one question I might as well ask since I've got you
> here: would patches to expose an unlocked version of kthread_queue_worker() be
> accepted? With something like that I should be able to just reuse the
> delayed_work_list and spinlocks that come with kthread_worker which would make
> the vblank works implementation a bit easier

Difficult to tell w/o looking at the code but if technically reasonable and
justified, I don't see a reason why something like that couldn't be accepted.
That said, whatever gain coming from sharing an inner lock like that usually
is miniscule and API and logic simplicity often easily outweighs.

Thanks.

-- 
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-14 18:17 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18  0:40 [PATCH 0/9] drm/nouveau: Introduce CRC support for gf119+ Lyude Paul
2020-03-18  0:40 ` Lyude Paul
2020-03-18  0:40 ` Lyude Paul
2020-03-18  0:40 ` [PATCH 1/9] drm/vblank: Add vblank works Lyude Paul
2020-03-18  0:40   ` Lyude Paul
2020-03-18  0:40   ` Lyude Paul
2020-03-18 13:46   ` Daniel Vetter
2020-03-18 13:46     ` Daniel Vetter
2020-03-18 13:46     ` Daniel Vetter
2020-03-19 20:12     ` Lyude Paul
2020-03-19 20:12       ` Lyude Paul
2020-03-27 20:29     ` Lyude Paul
2020-03-27 20:29       ` Lyude Paul
2020-03-27 20:38       ` Lyude Paul
2020-03-27 20:38         ` Lyude Paul
2020-04-13 20:18         ` Lyude Paul
2020-04-13 20:18           ` Lyude Paul
2020-04-13 20:18           ` Lyude Paul
2020-04-13 20:42           ` Tejun Heo
2020-04-13 20:42             ` Tejun Heo
2020-04-13 20:42             ` Tejun Heo
2020-04-13 21:07             ` Sam Ravnborg
2020-04-13 21:07               ` Sam Ravnborg
2020-04-14 16:52             ` Lyude Paul
2020-04-14 16:52               ` Lyude Paul
2020-04-14 16:52               ` Lyude Paul
2020-04-14 18:17               ` Tejun Heo [this message]
2020-04-14 18:17                 ` Tejun Heo
2020-04-14 18:17                 ` Tejun Heo
2020-05-07 18:57     ` Lyude Paul
2020-05-07 18:57       ` Lyude Paul
2020-03-18  0:40 ` [PATCH 2/9] drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create() Lyude Paul
2020-03-18  0:40   ` Lyude Paul
2020-03-18  0:41 ` [PATCH 3/9] drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  0:41 ` [PATCH 4/9] drm/nouveau/kms/nv50-: Fix disabling dithering Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  0:41 ` [PATCH 5/9] drm/nouveau/kms/nv50-: s/harm/armh/g Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  0:41 ` [PATCH 6/9] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  0:41 ` [PATCH 7/9] drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  0:41 ` [PATCH 8/9] drm/nouveau/kms/nv50-: Move hard-coded object handles into header Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  0:41 ` [PATCH 9/9] drm/nouveau/kms/nvd9-: Add CRC support Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  0:41   ` Lyude Paul
2020-03-18  1:09   ` [PATCH v2] " Lyude Paul
2020-03-18  1:09     ` Lyude Paul
2020-03-18  1:09     ` Lyude Paul
2020-03-18  6:02   ` [PATCH 9/9] " Greg Kroah-Hartman
2020-03-18  6:02     ` Greg Kroah-Hartman

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=20200414181711.GO60335@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=tzimmermann@suse.de \
    --cc=ville.syrjala@linux.intel.com \
    /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.