[PATCH v2] libdrm: add exynos drm support
2012. 5. 13. ?? 12:05 Rob Clark ??: > Ok, I've pushed this with a couple minor cleanups: > > 1) remove .pc file (which is generated from .pc.in file) > 2) below patch to fix a compile error (maybe not seen w/ older gcc?) > 3) remove DRM_IOCTL_EXYNOS_GEM_USERPTR because I think that part is > still being debated on kernel side.. it can be added back in another > patch once there is a conclusion on the kernel side yes, right. I should have removed USERPTR ioctl but I missed it and also thank you for cleanup. Thanks, Inki Dae > > - > diff --git a/exynos/exynos_drmif.h b/exynos/exynos_drmif.h > index 7e8347a..92f613e 100644 > --- a/exynos/exynos_drmif.h > +++ b/exynos/exynos_drmif.h > @@ -66,7 +66,7 @@ void exynos_device_destroy(struct exynos_device *dev); > * buffer-object related functions: > */ > struct exynos_bo * exynos_bo_create(struct exynos_device *dev, > -uint32_t size, uint32_t flags); > +size_t size, uint32_t flags); > int exynos_bo_get_info(struct exynos_device *dev, uint32_t handle, >size_t *size, uint32_t *flags); > void exynos_bo_destroy(struct exynos_bo *bo); > - > > BR, > -R > > On Fri, May 4, 2012 at 5:13 AM, Inki Dae wrote: >> this patch adds libdrm_exynos helper layer that inclues some intefaces >> for exynos specific gem and virtual display driver and also adds exynos >> module name to modtest and vbltest. >> >> Changelog v2: >> - fixed exynos broken ioctl. >> the pointer of uint64_t *edid should be removed. >> - removed unnecessary definitions. >> - added drm prime interfaces. >> this feature is used to share a buffer between drivers or memory managers >> and for this, please, refer to below links: >>http://www.mjmwired.net/kernel/Documentation/dma-buf-sharing.txt >>http://lwn.net/Articles/488664/ >> >> this patch is based on a link below: >>git://anongit.freedesktop.org/mesa/drm >>commit id: d72a44c7c4f5eea9c1e5bb0c36cb9e0224b9ca22 >> >> Reviewed-by: Rob Clark >> Reviewed-by: Alex Deucher >> Signed-off-by: Inki Dae >> Signed-off-by: Kyungmin Park >> --- >> Makefile.am|6 +- >> configure.ac | 13 ++ >> exynos/Makefile.am | 22 +++ >> exynos/exynos_drm.c| 396 >> >> exynos/exynos_drm.h| 149 + >> exynos/exynos_drmif.h | 88 ++ >> exynos/libdrm_exynos.pc| 11 ++ >> exynos/libdrm_exynos.pc.in | 11 ++ >> tests/modetest/modetest.c |2 +- >> tests/vbltest/vbltest.c|2 +- >> 10 files changed, 697 insertions(+), 3 deletions(-) >> create mode 100644 exynos/Makefile.am >> create mode 100644 exynos/exynos_drm.c >> create mode 100644 exynos/exynos_drm.h >> create mode 100644 exynos/exynos_drmif.h >> create mode 100644 exynos/libdrm_exynos.pc >> create mode 100644 exynos/libdrm_exynos.pc.in >> >> diff --git a/Makefile.am b/Makefile.am >> index 4f625a1..256a8cc 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -45,7 +45,11 @@ if HAVE_OMAP >> OMAP_SUBDIR = omap >> endif >> >> -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) >> $(RADEON_SUBDIR) $(OMAP_SUBDIR) tests include >> +if HAVE_EXYNOS >> +EXYNOS_SUBDIR = exynos >> +endif >> + >> +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) >> $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include >> >> libdrm_la_LTLIBRARIES = libdrm.la >> libdrm_ladir = $(libdir) >> diff --git a/configure.ac b/configure.ac >> index 6a1d98e..f832201 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -88,6 +88,11 @@ AC_ARG_ENABLE(omap-experimental-api, >> [Enable support for OMAP's experimental API (default: >> disabled)]), >> [OMAP=$enableval], [OMAP=no]) >> >> +AC_ARG_ENABLE(exynos-experimental-api, >> + AS_HELP_STRING([--enable-exynos-experimental-api], >> + [Enable support for EXYNOS's experimental API (default: >> disabled)]), >> + [EXYNOS=$enableval], [EXYNOS=no]) >> + >> dnl >> === >> dnl check compiler flags >> AC_DEFUN([LIBDRM_CC_TRY_FLAG], [ >> @@ -191,6 +196,11 @@ if test "x$OMAP" = xyes; then >>AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support]) >> fi >> >> +AM_CONDITIONAL(HAVE_EXYNOS, [test "x$EXYNOS" = xyes]) >> +if test "x$EXYNOS" = xyes; then >> + AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support]) >> +fi >> + >> PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no]) >> if test "x$HAVE_CAIRO" = xyes; then >>AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support]) >> @@ -313,6 +323,8 @@ AC_CONFIG_FILES([ >>nouveau/libdrm_nouveau.pc >>omap/Makefile >>omap/libdrm_omap.pc >> + exynos/Makefile >> + exynos/libdrm_exynos.pc >>tests/Makefile >>tests/modeprint/Makefile >>tests/modetest/Makefile >> @@ -333,4 +345,5 @@ echo " vmwgfx
[PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, 2012. 4. 25. ?? 7:15 Dave Airlie ??: > On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: >> this feature could be used to use memory region allocated by malloc() in user >> mode and mmaped memory region allocated by other memory allocators. userptr >> interface can identify memory type through vm_flags value and would get >> pages or page frame numbers to user space appropriately. > > Is there anything to stop the unpriviledged userspace driver locking > all the RAM in the machine inside userptr? > you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Thanks, Inki Dae. > seems like a very bad plan, I know TTM has code to address this sort > of things with limits. > > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats
?? iPad?? ??
2012. 4. 6. ?? 4:43 Ville Syrj?l? ??:
> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
>> Hi Ville,
>>
>>> -Original Message-
>>> From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
>>> Sent: Friday, April 06, 2012 3:14 AM
>>> To: airlied at redhat.com
>>> Cc: inki.dae at samsung.com; kyungmin.park at samsung.com; dri-
>>> devel at lists.freedesktop.org; Seung-Woo Kim
>>> Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to
>>> add multi plane formats
>>>
>>> On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrj?l? wrote:
On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> Multi buffer plane pixel formats are added as like kernel header.
>
> Signed-off-by: Seung-Woo Kim
> ---
> include/drm/drm_fourcc.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 85facb0..7cfd95a 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -107,6 +107,10 @@
> #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /*
>>> 2x1 subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /*
>>> 2x1 subsampled Cb:Cr plane */
>
> +/* 2 non contiguous plane YCbCr */
> +#define DRM_FORMAT_NV12Mfourcc_code('N', 'M', '1', '2') /* 2x2
>>> subsampled Cr:Cb plane */
NAK. DRM_FORMAT_NV12 handles this just fine.
>>>
>>> And I just realized that I was already too late with my NAK since this a
>>> libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
>>> via some backdoor without review. Sigh.
>>>
>>
>> We had already requested review for it. for this you can refer to link
>> below:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
>
> I see. I couldn't find it in my work mailbox for some reason, and I
> don't remember having seen the patch before. I suppose I just missed it
> due to Christmas vacations, and was too blind to see it in my mailbox.
> Also google decicded to filter my search results too much, so I didn't
> spot it via the web archives either. I'm sorry for the false accusation.
>
>>> So they're now in Linus's tree. But looks like format_check() was never
>>> updated to accept them, so there's no way anyone could actually be using
>>> them. So Dave, can we still remove them from the kernel header?
>>>
>>
>> Yes, right. these formats aren't used for any SoCs except Exynos series yet
>> but just we are first. I think they should be added because anyone may use
>> them someday at least possible.
>
> Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
> in adding it (similarly for YUV420M vs. YUV420).
>
but with this way, user and device driver should understand NV12M format and
how gem handles should send to driver and also how the driver should decide
whether these handles mean NV12M or NV12. I think these things are unnecessary
codes. with such theory, maybe current some fourcc formats couldn't be removed
because we can identify desired format if we add some codes for it. as you
mentioned, it's important to avoid such duplicated formats but also to consider
user and device driver. so I think it's not good for user and driver should
understand and decide them. Please give me your opinion.
thanks,
Inki Dae
> --
> Ville Syrj?l?
> syrjala at sci.fi
> http://www.sci.fi/~syrjala/
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: base prime/dma-buf support
Reviewed-by: Inki Dae
2012. 3. 27. ?? 12:02 Dave Airlie ??:
> From: Dave Airlie
>
> This adds the basic drm dma-buf interface layer, called PRIME,
>
> The main APIs exposed to userspace allow translating a 32-bit object handle
> to a file descriptor, and a file descriptor to a 32-bit object handle.
>
> The flags value is currently limited to O_CLOEXEC.
>
> Acknowledgements:
> Daniel Vetter: lots of review
> Rob Clark: cleaned up lots of the internals and did lifetime review.
>
> This is what I intend to send to Linus to form the basis for prime work
> in the drivers.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/Kconfig |1 +
> drivers/gpu/drm/Makefile|2 +-
> drivers/gpu/drm/drm_drv.c |4 +
> drivers/gpu/drm/drm_fops.c |7 +
> drivers/gpu/drm/drm_gem.c |9 ++
> drivers/gpu/drm/drm_prime.c | 281 +++
> include/drm/drm.h | 14 ++-
> include/drm/drmP.h | 61 ++
> 8 files changed, 377 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_prime.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index cc11488..e354bc0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -9,6 +9,7 @@ menuconfig DRM
>depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU
>select I2C
>select I2C_ALGOBIT
> +select DMA_SHARED_BUFFER
>help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> introduced in XFree86 4.0. If you say Y here, you need to select
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a858532..c20da5b 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -12,7 +12,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
> drm_cache.o \
>drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
>drm_crtc.o drm_modes.o drm_edid.o \
>drm_info.o drm_debugfs.o drm_encoder_slave.o \
> -drm_trace_points.o drm_global.o
> +drm_trace_points.o drm_global.o drm_prime.o
>
> drm-$(CONFIG_COMPAT) += drm_ioc32.o
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 0b65fbc..6116e3b 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -136,6 +136,10 @@ static struct drm_ioctl_desc drm_ioctls[] = {
>DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl,
> DRM_AUTH|DRM_UNLOCKED),
>
>DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
> DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> +
> +DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
> drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
> +DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
> drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
> +
>DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
> DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 7348a3d..cdfbf27 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -271,6 +271,9 @@ static int drm_open_helper(struct inode *inode, struct
> file *filp,
>if (dev->driver->driver_features & DRIVER_GEM)
>drm_gem_open(dev, priv);
>
> +if (drm_core_check_feature(dev, DRIVER_PRIME))
> +drm_prime_init_file_private(>prime);
> +
>if (dev->driver->open) {
>ret = dev->driver->open(dev, priv);
>if (ret < 0)
> @@ -571,6 +574,10 @@ int drm_release(struct inode *inode, struct file *filp)
>
>if (dev->driver->postclose)
>dev->driver->postclose(dev, file_priv);
> +
> +if (drm_core_check_feature(dev, DRIVER_PRIME))
> +drm_prime_destroy_file_private(_priv->prime);
> +
>kfree(file_priv);
>
>/*
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 0ef358e..f337497 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
> #include "drmP.h"
>
> /** @file drm_gem.c
> @@ -232,6 +233,10 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
>idr_remove(>object_idr, handle);
>spin_unlock(>table_lock);
>
> +if (obj->import_attach)
> +drm_prime_remove_fd_handle_mapping(>prime,
> +obj->import_attach->dmabuf);
> +
>if (dev->driver->gem_close_object)
>dev->driver->gem_close_object(obj, filp);
>drm_gem_object_handle_unreference_unlocked(obj);
> @@ -527,6 +532,10 @@ drm_gem_object_release_handle(int id, void *ptr, void
> *data)
>struct drm_gem_object *obj = ptr;
>struct drm_device *dev = obj->dev;
>
> +if (obj->import_attach)
> +
