linux-kernel - Re: [RFC 0/6] drm/fences: add in-fences to DRM

Open Source and information security mailing list archives

Date:	Mon, 04 Apr 2016 09:14:12 +0900
From:	Inki Dae <inki.dae@...sung.com>
To:	Rob Clark <robdclark@...il.com>, Inki Dae <daeinki@...il.com>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	Arve Hjønnevåg 
	<arve@...roid.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Riley Andrews <riandrews@...roid.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM

2016년 03월 31일 23:10에 Rob Clark 이(가) 쓴 글:
> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae <daeinki@...il.com> wrote:
>> Hi Daniel,
>>
>> 2016-03-31 19:56 GMT+09:00 Daniel Stone <daniel@...ishbar.org>:
>>> Hi Inki,
>>>
>>> On 31 March 2016 at 11:05, Inki Dae <inki.dae@...sung.com> wrote:
>>>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>>>> On 31 March 2016 at 08:45, Inki Dae <inki.dae@...sung.com> wrote:
>>>>>> As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.
>>>>>
>>>>> Drivers would have to opt in to explicit fencing support, and part of
>>>>> that would be ensuring that the driver does not wait on implicit
>>>>> fences when the user has requested explicit fencing be used.
>>>>>
>>>>
>>>> Then, existing drivers would need additional works for explicit fencing support. This wouldn't be really what the drivers have to but should be handled with this patch series because this would affect exising device drivers which use implicit fencing.
>>>
>>> Well, yes. Anyone implementing their own atomic commit would need to
>>> ensure that the commit works properly for fences. The helpers could
>>> also add it, but the helpers are not mandatory, and you are not
>>> required to use every part of the helper to use one part of the
>>> helper. There is no magic wand you can wave that instantly makes it
>>> work for every driver
>>
>> I meant there are already several DRM drivers which work properly for
>> implicit fence. So if atomic helper framework of DRM core is
>> considered only for the explicit fence, then fencing operation would
>> affect the existing DRM drivers. So I hope this trying could consider
>> existing implicit fence users.
>>
> 
> Note that there would be a new flag on the atomic ioctl to request

What is the new flag? And Where I could find the new flag?

> explicit fencing, and with an old kernel or a driver that does not
> support it, the ioctl would be rejected and an error returned.  The
> atomic/kms framework would of course continue to support implicit

I couldn't find where such exceptions are considered.
And as of now, I think implicit fence is implemented by drivers so hided from drm core framework. So how atomic/kms framework knows whether explicit or implicit fence is supported by driver?
Otherwise, you mean such things are TODO in the future?

There may be some logic I don't understand yet.

Thanks,
Inki Dae

> fencing.   And an explicit-fencing userspace would require a
> sufficiently new kernel and possibly some minor driver support (above
> and beyond 'struct fence' conversion).
> 
> BR,
> -R
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives