Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1441628 > unrolled thread

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] drm/radeon: Remove deprecated  create_singlethread_workqueue Tejun Heo <tj@kernel.org> - 2016-07-12 20:00 +0200
    [PATCH v2] drm/radeon: Remove deprecated  create_singlethread_workqueue Bhaktipriya Shridhar <bhaktipriya96@gmail.com> - 2016-07-16 13:40 +0200
      Re: [PATCH v2] drm/radeon: Remove deprecated  create_singlethread_workqueue Tejun Heo <tj@kernel.org> - 2016-07-19 02:50 +0200

#1441628 — Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

Hello,

On Fri, Jul 08, 2016 at 02:52:30PM +0900, Michel Dänzer wrote:
> On 07.07.2016 16:43, Christian König wrote:
> >>> Also, what kind of delays matter here?  Is it millisec range or micro?
> >> It can be the latter in theory, but normally rather the former.
> > 
> > Well to be precise with a typical 1920x1080@60 resolution you have about
> > 2.16ms time under ideal conditions for the flip.
> > 
> > So using the high priority queue still sounds like a good idea to me.
> 
> How did you arrive at 2.16ms?
> 
> Userspace can call the ioctl up to one full refresh cycle ahead of time,
> which is ~16ms at 60 Hz. On the other hand userspace can also call the
> ioctl arbitrarily close to the vertical blank period, in which case even
> a delay of just 1ms (or even significantly less) may cause the flip to
> be delayed by one refresh cycle.

If there's too long a delay, the outcome is missing the refresh cycle,
right?  Hmmm... yeah, WQ_HIGHPRI probably is the right answer here.
Bhaktipriya, can you please update the patch to use a dedicated
workqueue with WQ_HIGHPRI?

Thanks.

-- 
tejun

[toc] | [next] | [standalone]

#1444819 — [PATCH v2] drm/radeon: Remove deprecated create_singlethread_workqueue

alloc_workqueue replaces deprecated create_singlethread_workqueue().

Each hardware CRTC has a single flip work queue.
When a radeon_flip_work_func item is queued, it needs to be executed
ASAP because even a slight delay may cause the flip to be delayed by
one refresh cycle.

Hence, a dedicated workqueue with WQ_HIGHPRI set, has been used here
since a delay can cause the outcome to miss the refresh cycle.

Since there are only a fixed number of work items, explicit concurrency
limit is unnecessary here.

Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
---
 Changes in v2:
	-Used a dedicated work queue with WQ_HIGHPRI

 drivers/gpu/drm/radeon/radeon_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 6a41b49..64b246e 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -711,7 +711,7 @@ static void radeon_crtc_init(struct drm_device *dev, int index)

 	drm_mode_crtc_set_gamma_size(&radeon_crtc->base, 256);
 	radeon_crtc->crtc_id = index;
-	radeon_crtc->flip_queue = create_singlethread_workqueue("radeon-crtc");
+	radeon_crtc->flip_queue = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
 	rdev->mode_info.crtcs[index] = radeon_crtc;

 	if (rdev->family >= CHIP_BONAIRE) {
--
2.1.4

[toc] | [prev] | [next] | [standalone]

#1445962 — Re: [PATCH v2] drm/radeon: Remove deprecated create_singlethread_workqueue

On Sat, Jul 16, 2016 at 05:00:44PM +0530, Bhaktipriya Shridhar wrote:
> 
> alloc_workqueue replaces deprecated create_singlethread_workqueue().
> 
> Each hardware CRTC has a single flip work queue.
> When a radeon_flip_work_func item is queued, it needs to be executed
> ASAP because even a slight delay may cause the flip to be delayed by
> one refresh cycle.
> 
> Hence, a dedicated workqueue with WQ_HIGHPRI set, has been used here
> since a delay can cause the outcome to miss the refresh cycle.
> 
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary here.
> 
> Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>

Acked-by: Tejun Heo <tj@kernel.org>

Thanks.

-- 
tejun

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web