diff mbox

drm/exynos: add render node support

Message ID 1439881270-29206-1-git-send-email-inki.dae@samsung.com (mailing list archive)
State New, archived
Headers show

Commit Message

Inki Dae Aug. 18, 2015, 7:01 a.m. UTC 
From: Joonyoung Shim <jy0922.shim@samsung.com>

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 <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 39 +++++++++++++++++----------------
 1 file changed, 20 insertions(+), 19 deletions(-)

Comments

Emil Velikov Aug. 31, 2015, 11:58 a.m. UTC | #1 
Hi all,

On 18 August 2015 at 08:01, Inki Dae <inki.dae@samsung.com> wrote:
> From: Joonyoung Shim <jy0922.shim@samsung.com>
>
> 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
Inki Dae Aug. 31, 2015, 12:36 p.m. UTC | #2 
Hi Emil,

On 2015? 08? 31? 20:58, Emil Velikov wrote:
> Hi all,
> 
> On 18 August 2015 at 08:01, Inki Dae <inki.dae@samsung.com> wrote:
>> From: Joonyoung Shim <jy0922.shim@samsung.com>
>>
>> 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
>
Emil Velikov Aug. 31, 2015, 6:30 p.m. UTC | #3 
On 31 August 2015 at 13:36, Inki Dae <inki.dae@samsung.com> wrote:
> Hi Emil,
>
> On 2015? 08? 31? 20:58, Emil Velikov wrote:
>> Hi all,
>>
>> On 18 August 2015 at 08:01, Inki Dae <inki.dae@samsung.com> wrote:
>>> From: Joonyoung Shim <jy0922.shim@samsung.com>
>>>
>>> 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
Tobias Jakobi Aug. 31, 2015, 7:35 p.m. UTC | #4 
Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae <inki.dae@samsung.com> wrote:
>> Hi Emil,
>>
>> On 2015? 08? 31? 20:58, Emil Velikov wrote:
>>> Hi all,
>>>
>>> On 18 August 2015 at 08:01, Inki Dae <inki.dae@samsung.com> wrote:
>>>> From: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>
>>>> 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
>
Inki Dae Sept. 1, 2015, 12:34 a.m. UTC | #5 
On 2015? 09? 01? 03:30, Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae <inki.dae@samsung.com> wrote:
>> Hi Emil,
>>
>> On 2015? 08? 31? 20:58, Emil Velikov wrote:
>>> Hi all,
>>>
>>> On 18 August 2015 at 08:01, Inki Dae <inki.dae@samsung.com> wrote:
>>>> From: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>
>>>> 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
>
Daniel Vetter Sept. 1, 2015, 8:34 a.m. UTC | #6 
On Mon, Aug 31, 2015 at 07:30:23PM +0100, Emil Velikov wrote:
> On 31 August 2015 at 13:36, Inki Dae <inki.dae@samsung.com> wrote:
> > Hi Emil,
> >
> > On 2015? 08? 31? 20:58, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On 18 August 2015 at 08:01, Inki Dae <inki.dae@samsung.com> wrote:
> >>> From: Joonyoung Shim <jy0922.shim@samsung.com>
> >>>
> >>> 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
diff mbox

Patch

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,