drm/exynos: add render node support

[Daniel Vetter]

On Mon, Aug 31, 2015 at 07:30:23PM +0100, Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae  wrote:
> > Hi Emil,
> >
> > On 2015년 08월 31일 20:58, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On 18 August 2015 at 08:01, Inki Dae  wrote:
> >>> From: Joonyoung Shim 
> >>>
> >>> This patch allows clients who want to use render node to access
> >>> rendering relevant ioctls - g2d, post processor and gem allocation.
> >>>
> >> I seem to recall Dave and others saying that we must have users of
> >> these interfaces prior to merging them into the kernel. Then again I
> >> cannot find any open-source userspace using the post-processor. Can
> >> anyone kingly share a link ?
> >
> > You can refer to the user-space below,
> > https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e
> >
> Nice one thanks !
> Did those patch(es) ever made it to the list ? Mind giving them a tiny
> bit of cleanup (move tests to exynos, drop duplication, C99
> initializers) and sending them over ?

This is stretching the open-source userspace requirements quite a bit
since it's just a simple testcase and not really real-world userspace
(like a gstreamer module, X driver or whatever). Dave Airlie recently
clarified for the atomic series that just a bunch of test apps
(specifically for atomic glplanes) isn't good enough, and he wants the
real thing.

Where is that?

Also adding Dave.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

drm/exynos: add render node support

[Inki Dae]

On 2015년 09월 01일 03:30, Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae  wrote:
>> Hi Emil,
>>
>> On 2015년 08월 31일 20:58, Emil Velikov wrote:
>>> Hi all,
>>>
>>> On 18 August 2015 at 08:01, Inki Dae  wrote:
 From: Joonyoung Shim 

 This patch allows clients who want to use render node to access
 rendering relevant ioctls - g2d, post processor and gem allocation.

>>> I seem to recall Dave and others saying that we must have users of
>>> these interfaces prior to merging them into the kernel. Then again I
>>> cannot find any open-source userspace using the post-processor. Can
>>> anyone kingly share a link ?
>>
>> You can refer to the user-space below,
>> https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e
>>
> Nice one thanks !
> Did those patch(es) ever made it to the list ? Mind giving them a tiny
> bit of cleanup (move tests to exynos, drop duplication, C99
> initializers) and sending them over ?
> 
> On a mildly related note:
> The tizen people like excessive rebasing :( Another alternative would
> be to send fixes upstream and keep their changes within ./packaging,
> which will allow clean merges.

I just shared the patch for you and someone who want to know the
user-space of the post processor. The patch should be more __really__
cleaned up and refactored. After that, we'd like to post it to mainline
in the near future. Currently, we are working on this in kernel and
user-space side.

> 
>>>
>>> On the g2d front, can you guys take a look at the work Tobias has been
>>> doing ? He seems to be the only one that cares about it :'(
>>
>> I'd like to say really sorry about that to you and Tobias. Will review
>> it soon.
>>
> Great. Tobias sent a few more drm/exynos and libdrm (g2d utilities)
> patches that've been around for a while :(
> 
> Perhaps he can re-spin then and/or send a list with outstanding ones ?

Ok, I will check it.

Thanks,
Inki Dae

> 
> Cheers,
> Emil
> 

drm/exynos: add render node support

[Inki Dae]

Hi Emil,

On 2015년 08월 31일 20:58, Emil Velikov wrote:
> Hi all,
> 
> On 18 August 2015 at 08:01, Inki Dae  wrote:
>> From: Joonyoung Shim 
>>
>> This patch allows clients who want to use render node to access
>> rendering relevant ioctls - g2d, post processor and gem allocation.
>>
> I seem to recall Dave and others saying that we must have users of
> these interfaces prior to merging them into the kernel. Then again I
> cannot find any open-source userspace using the post-processor. Can
> anyone kingly share a link ?

You can refer to the user-space below,
https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e

> 
> On the g2d front, can you guys take a look at the work Tobias has been
> doing ? He seems to be the only one that cares about it :'(

I'd like to say really sorry about that to you and Tobias. Will review
it soon.

Thanks,
Inki Dae

> 
> Thanks
> Emil
> 

drm/exynos: add render node support

[Tobias Jakobi]

Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae  wrote:
>> Hi Emil,
>>
>> On 2015년 08월 31일 20:58, Emil Velikov wrote:
>>> Hi all,
>>>
>>> On 18 August 2015 at 08:01, Inki Dae  wrote:
 From: Joonyoung Shim 

 This patch allows clients who want to use render node to access
 rendering relevant ioctls - g2d, post processor and gem allocation.

>>> I seem to recall Dave and others saying that we must have users of
>>> these interfaces prior to merging them into the kernel. Then again I
>>> cannot find any open-source userspace using the post-processor. Can
>>> anyone kingly share a link ?
>>
>> You can refer to the user-space below,
>> https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e
>>
> Nice one thanks !
> Did those patch(es) ever made it to the list ? Mind giving them a tiny
> bit of cleanup (move tests to exynos, drop duplication, C99
> initializers) and sending them over ?
> 
> On a mildly related note:
> The tizen people like excessive rebasing :( Another alternative would
> be to send fixes upstream and keep their changes within ./packaging,
> which will allow clean merges.
> 
>>>
>>> On the g2d front, can you guys take a look at the work Tobias has been
>>> doing ? He seems to be the only one that cares about it :'(
>>
>> I'd like to say really sorry about that to you and Tobias. Will review
>> it soon.
>>
> Great. Tobias sent a few more drm/exynos and libdrm (g2d utilities)
> patches that've been around for a while :(
Thanks, the size two patches for the kernel (size check) are kinda
important. Currently userspace can easily trigger a pagefault due to
this being wrong. So maybe it's also a candidate for stable (but I don't
know too much about how stable backports work).

With best wishes,
Tobias

P.S.: I also might've some patches ready in 2 weeks or so which should
resolve the g2d/userptr issues.


> 
> Perhaps he can re-spin then and/or send a list with outstanding ones ?
> 
> Cheers,
> Emil
> 

drm/exynos: add render node support

[Emil Velikov]

On 31 August 2015 at 13:36, Inki Dae  wrote:
> Hi Emil,
>
> On 2015년 08월 31일 20:58, Emil Velikov wrote:
>> Hi all,
>>
>> On 18 August 2015 at 08:01, Inki Dae  wrote:
>>> From: Joonyoung Shim 
>>>
>>> This patch allows clients who want to use render node to access
>>> rendering relevant ioctls - g2d, post processor and gem allocation.
>>>
>> I seem to recall Dave and others saying that we must have users of
>> these interfaces prior to merging them into the kernel. Then again I
>> cannot find any open-source userspace using the post-processor. Can
>> anyone kingly share a link ?
>
> You can refer to the user-space below,
> https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e
>
Nice one thanks !
Did those patch(es) ever made it to the list ? Mind giving them a tiny
bit of cleanup (move tests to exynos, drop duplication, C99
initializers) and sending them over ?

On a mildly related note:
The tizen people like excessive rebasing :( Another alternative would
be to send fixes upstream and keep their changes within ./packaging,
which will allow clean merges.

>>
>> On the g2d front, can you guys take a look at the work Tobias has been
>> doing ? He seems to be the only one that cares about it :'(
>
> I'd like to say really sorry about that to you and Tobias. Will review
> it soon.
>
Great. Tobias sent a few more drm/exynos and libdrm (g2d utilities)
patches that've been around for a while :(

Perhaps he can re-spin then and/or send a list with outstanding ones ?

Cheers,
Emil

drm/exynos: add render node support

[Emil Velikov]

Hi all,

On 18 August 2015 at 08:01, Inki Dae  wrote:
> From: Joonyoung Shim 
>
> This patch allows clients who want to use render node to access
> rendering relevant ioctls - g2d, post processor and gem allocation.
>
I seem to recall Dave and others saying that we must have users of
these interfaces prior to merging them into the kernel. Then again I
cannot find any open-source userspace using the post-processor. Can
anyone kingly share a link ?

On the g2d front, can you guys take a look at the work Tobias has been
doing ? He seems to be the only one that cares about it :'(

Thanks
Emil

drm/exynos: add render node support

[Inki Dae]

From: Joonyoung Shim 

This patch allows clients who want to use render node to access
rendering relevant ioctls - g2d, post processor and gem allocation.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 39 +
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7c65819..20800b3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -275,25 +275,25 @@ static const struct vm_operations_struct 
exynos_drm_gem_vm_ops = {

 static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
+   DRM_UNLOCKED | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
-   exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
-   vidi_connection_ioctl, DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
-   exynos_g2d_get_ver_ioctl, DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_SET_CMDLIST,
-   exynos_g2d_set_cmdlist_ioctl, DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC,
-   exynos_g2d_exec_ioctl, DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY,
-   exynos_drm_ipp_get_property, DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY,
-   exynos_drm_ipp_set_property, DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF,
-   exynos_drm_ipp_queue_buf, DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL,
-   exynos_drm_ipp_cmd_ctrl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER, exynos_g2d_get_ver_ioctl,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_SET_CMDLIST, exynos_g2d_set_cmdlist_ioctl,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY, exynos_drm_ipp_get_property,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY, exynos_drm_ipp_set_property,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF, exynos_drm_ipp_queue_buf,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL, exynos_drm_ipp_cmd_ctrl,
+   DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
 };

 static const struct file_operations exynos_drm_driver_fops = {
@@ -310,7 +310,8 @@ static const struct file_operations exynos_drm_driver_fops 
= {
 };

 static struct drm_driver exynos_drm_driver = {
-   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
+   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
+   DRIVER_RENDER,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
.suspend= exynos_drm_suspend,
-- 
1.9.1