From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
Subject: Re: [PATCH] drm/radeon: Remove deprecated
 create_singlethread_workqueue
Date: Thu, 7 Jul 2016 09:43:26 +0200
Message-ID: <577E081E.8030701@amd.com>
References: <20160702110350.GA3601@Karyakshetra>
 <20160702134614.GB17431@htj.duckdns.org>
 <9e69b1fd-eb93-1fee-15af-c905ee3a202f@daenzer.net>
 <20160705210644.GB25394@htj.duckdns.org>
 <936c5bae-b8e6-bf64-8be2-d27608814fac@daenzer.net>
 <20160706134532.GF3262@mtj.duckdns.org>
 <85449fbd-45ba-7eea-8520-d0c19b8af001@daenzer.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <85449fbd-45ba-7eea-8520-d0c19b8af001@daenzer.net>
Sender: linux-kernel-owner@vger.kernel.org
To: =?UTF-8?Q?Michel_D=c3=a4nzer?= <michel@daenzer.net>, Tejun Heo <tj@kernel.org>
Cc: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>, Alex Deucher <alexander.deucher@amd.com>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
List-Id: dri-devel@lists.freedesktop.org

Am 07.07.2016 um 05:32 schrieb Michel D=C3=A4nzer:
> On 06.07.2016 22:45, Tejun Heo wrote:
>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel D=C3=A4nzer wrote:
>>
>>> Not being very familiar with the workqueue APIs, I'll describe how =
it's
>>> supposed to work from a driver POV, which will hopefully help you g=
uys
>>> decide on the most appropriate alloc_workqueue parameters.
>>>
>>> There is one flip work queue for each hardware CRTC. At most one
>>> radeon_flip_work_func item can be queued for any of them at any tim=
e.
>>> When a radeon_flip_work_func item is queued, it should be executed =
ASAP
>>> (so WQ_HIGHPRI might be appropriate?).
>> Hmmm... the only time WQ_HIGHPRI should be used is when it'd otherwi=
se
>> require a kthread w/ nice value at -20.  Would that be the case here=
?
>> What are the consequences of the work item getting delayed?
> A page flip may be delayed to a later display refresh cycle.
>
>
>> Also, what kind of delays matter here?  Is it millisec range or micr=
o?
> It can be the latter in theory, but normally rather the former.

Well to be precise with a typical 1920x1080@60 resolution you have abou=
t=20
2.16ms time under ideal conditions for the flip.

So using the high priority queue still sounds like a good idea to me.

Regards,
Christian.