Re: [PATCH v2] libdrm: add exynos drm support
and cache attribute types.
+ * @fd: file descriptor exported into dmabuf.
+ * @size: size to the buffer created.
+ * @vaddr: user space address to a gem buffer mmaped.
+ * @name: a gem global handle from flink request.
+ */
+struct exynos_bo {
+ struct exynos_device*dev;
+ uint32_thandle;
+ uint32_tflags;
+ int fd;
+ size_t size;
+ void*vaddr;
+ uint32_tname;
+};
+
+/*
+ * device related functions:
+ */
+struct exynos_device * exynos_device_create(int fd);
+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);
+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);
+struct exynos_bo * exynos_bo_from_name(struct exynos_device *dev, uint32_t
name);
+int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name);
+uint32_t exynos_bo_handle(struct exynos_bo *bo);
+void * exynos_bo_map(struct exynos_bo *bo);
+int exynos_prime_handle_to_fd(struct exynos_device *dev, uint32_t handle,
+ int *fd);
+int exynos_prime_fd_to_handle(struct exynos_device *dev, int fd,
+ uint32_t *handle);
+
+/*
+ * Virtual Display related functions:
+ */
+int exynos_vidi_connection(struct exynos_device *dev, uint32_t connect,
+ uint32_t ext, void *edid);
+
+#endif /* EXYNOS_DRMIF_H_ */
diff --git a/exynos/libdrm_exynos.pc b/exynos/libdrm_exynos.pc
new file mode 100644
index 000..434dc3f
--- /dev/null
+++ b/exynos/libdrm_exynos.pc
@@ -0,0 +1,11 @@
+prefix=/home/daeinki/project/share
+exec_prefix=${prefix}
+libdir=${exec_prefix}/lib
+includedir=${prefix}/include
+
+Name: libdrm_exynos
+Description: Userspace interface to exynos kernel DRM services
+Version: 0.6
+Libs: -L${libdir} -ldrm_exynos
+Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/exynos
+Requires.private: libdrm
diff --git a/exynos/libdrm_exynos.pc.in b/exynos/libdrm_exynos.pc.in
new file mode 100644
index 000..5ce9118
--- /dev/null
+++ b/exynos/libdrm_exynos.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libdrm_exynos
+Description: Userspace interface to exynos kernel DRM services
+Version: 0.6
+Libs: -L${libdir} -ldrm_exynos
+Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/exynos
+Requires.private: libdrm
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 5784622..8012ecc 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1099,7 +1099,7 @@ int main(int argc, char **argv)
int c;
int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers
= 0;
int test_vsync = 0;
- char *modules[] = { i915, radeon, nouveau, vmwgfx, omapdrm
};
+ char *modules[] = { i915, radeon, nouveau, vmwgfx,
omapdrm, exynos };
unsigned int i;
int count = 0, plane_count = 0;
struct connector con_args[2];
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 903ca0f..4fccd59 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -103,7 +103,7 @@ static void usage(char *name)
int main(int argc, char **argv)
{
int i, c, fd, ret;
- char *modules[] = { i915, radeon, nouveau, vmwgfx };
+ char *modules[] = { i915, radeon, nouveau, vmwgfx, exynos
};
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats
나의 iPad에서 보냄
2012. 4. 6. 오후 4:43 Ville Syrjälä syrj...@sci.fi 작성:
On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
Hi Ville,
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, April 06, 2012 3:14 AM
To: airl...@redhat.com
Cc: inki@samsung.com; kyungmin.p...@samsung.com; dri-
de...@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 sw0312@samsung.com
---
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ä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: base prime/dma-buf support
Reviewed-by: Inki Dae inki@samsung.com
2012. 3. 27. 오전 12:02 Dave Airlie airl...@gmail.com 작성:
From: Dave Airlie airl...@redhat.com
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 airl...@redhat.com
---
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(priv-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(file_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 linux/mman.h
#include linux/pagemap.h
#include linux/shmem_fs.h
+#include linux/dma-buf.h
#include drmP.h
/** @file drm_gem.c
@@ -232,6 +233,10 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(filp-object_idr, handle);
spin_unlock(filp-table_lock);
+if (obj-import_attach)
+drm_prime_remove_fd_handle_mapping(filp-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)
+
[PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
Hi, Sascha Hauer. thank you for your comments and below is my answer. Sascha Hauer wrote: > Hi, > > On Fri, Jul 29, 2011 at 04:24:35PM +0900, Inki Dae wrote: >> This patch is a DRM Driver(only including FIMD Driver yet) >> for Samsung SoC Exynos4210. and as RFC, I am sending only DRM driver part. >> >> this patch is based on git repository below: >> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git, >> branch: drm-next >> commit-id: 5a96a899bbdee86024ab9ea6d02b9e242faacbed >> >> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c >> based on Linux framebuffer) but couldn't so because lowlevel codes >> of s3c-fb.c are included internally and so this driver shares only >> platform device. >> >> Sub drivers such as fimd or hdmi have indenpendent platform device and >> Platform driver and when driver's probe is called, the driver object >> including callbacks(for hardware control) would be registered to >> Samsung drm driver. and then when samsung drm driver is probed, >> each probe callback of the driver object registered is called so that >> additional callbacks for drm framework would be set at this time. >> >> We used GEM framework for buffer management and this driver supports >> only physically continuous memory yet(non-iommu). and for buffer allocation, >> we used DMA APIs(dma_alloc_writecombine) but we will change it to CMA instead >> of DMA APIs later. >> >> Refer to this link for CMA(Continuous Memory Allocator): >> http://lkml.org/lkml/2011/7/20/45 >> >> Future works: >> - HDMI support. >> - drm plane feature support. >> refer to this link for drm plane feature: >> http://www.spinics.net/lists/dri-devel/msg11778.html >> - change the allocator to CMA. >> - iommu support.(for non-continuous physical memory usage) >> - fimd driver update. >> - add exception codes and code clean. >> >> to support all features above, we need long time and hard work. >> so we wish that only some features(fimd and non-iommu) are applied to >> mainline first. >> >> We would be pleased you to give us your comments. > > So far I only had a quick look over the driver. You might know that > I wrote a Freescale i.MX drm driver which I posted to the list some time > ago. > > My driver lacks GEM support which your driver has, so I specifically > looked at this part. It seems we could reuse the GEM code on i.MX and > probably on most other ARMs aswell. Can you split out this code > and remove the samsung_ namespace? > By any chance, you mean drm_gem_free_mmap_offset()? this patch had already been posted by Rob Clark, Omap TI as RFC. you can refer to this link for it. http://www.spinics.net/lists/dri-devel/msg13018.html if so, I am aware of it but his patch isn't applied to drm-next yet and so my drm driver doesn't include his patch. of course I will reuse it and remove the samsung_ namespace as you pointed out if the patch is applied to drm-next. > btw you should probably Cc the arm Linux Kernel mailing list as this > is the list where your users are. > > I look forward to have the first ARM drm drivers mainline, so I really > appreciate your work :) > > Sascha > Thank you for your comments and advice again. :)
Re: [PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
Hi, Sascha Hauer. thank you for your comments and below is my answer. Sascha Hauer wrote: Hi, On Fri, Jul 29, 2011 at 04:24:35PM +0900, Inki Dae wrote: This patch is a DRM Driver(only including FIMD Driver yet) for Samsung SoC Exynos4210. and as RFC, I am sending only DRM driver part. this patch is based on git repository below: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git, branch: drm-next commit-id: 5a96a899bbdee86024ab9ea6d02b9e242faacbed We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c based on Linux framebuffer) but couldn't so because lowlevel codes of s3c-fb.c are included internally and so this driver shares only platform device. Sub drivers such as fimd or hdmi have indenpendent platform device and Platform driver and when driver's probe is called, the driver object including callbacks(for hardware control) would be registered to Samsung drm driver. and then when samsung drm driver is probed, each probe callback of the driver object registered is called so that additional callbacks for drm framework would be set at this time. We used GEM framework for buffer management and this driver supports only physically continuous memory yet(non-iommu). and for buffer allocation, we used DMA APIs(dma_alloc_writecombine) but we will change it to CMA instead of DMA APIs later. Refer to this link for CMA(Continuous Memory Allocator): http://lkml.org/lkml/2011/7/20/45 Future works: - HDMI support. - drm plane feature support. refer to this link for drm plane feature: http://www.spinics.net/lists/dri-devel/msg11778.html - change the allocator to CMA. - iommu support.(for non-continuous physical memory usage) - fimd driver update. - add exception codes and code clean. to support all features above, we need long time and hard work. so we wish that only some features(fimd and non-iommu) are applied to mainline first. We would be pleased you to give us your comments. So far I only had a quick look over the driver. You might know that I wrote a Freescale i.MX drm driver which I posted to the list some time ago. My driver lacks GEM support which your driver has, so I specifically looked at this part. It seems we could reuse the GEM code on i.MX and probably on most other ARMs aswell. Can you split out this code and remove the samsung_ namespace? By any chance, you mean drm_gem_free_mmap_offset()? this patch had already been posted by Rob Clark, Omap TI as RFC. you can refer to this link for it. http://www.spinics.net/lists/dri-devel/msg13018.html if so, I am aware of it but his patch isn't applied to drm-next yet and so my drm driver doesn't include his patch. of course I will reuse it and remove the samsung_ namespace as you pointed out if the patch is applied to drm-next. btw you should probably Cc the arm Linux Kernel mailing list as this is the list where your users are. I look forward to have the first ARM drm drivers mainline, so I really appreciate your work :) Sascha Thank you for your comments and advice again. :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Some questions about DRM(Direct Rendering Manager)
Hi Rob Clark, I'm sorry for that my mean didn't convey to you so I condensed that into brief again. I know drm_fb_helper_single_fb_probe() calls register_framebuffer(), My question is that it's right way to call only drm_fb_helper_set_par() if fb_helper->funcs->fb_probe() returns nonzero. In this case, if fb_helper->funcs->fb_probe() returns zero then register_framebuffer() isn't called and this means linux framebuffer isn't used anymore. one more question, otherwise if it uses drm based framebuffer, register_framebuffer() should be called necessarily at booting time? Thank you. Rob Clark ? ?: > fwiw, drm_fb_helper_single_fb_probe() calls register_framebuffer() (if > that was the question?) > > BR, > -R > > 2011/6/22 InKi Dae : >> It adds dri-devel at lists.freedesktop.org to this mail thread. >> Thank you. >> >> 2011? 6? 22? ?? 3:04, daeinki ?? ?: >>> below is additional comments. >>> >>> daeinki ? ?: >>>> Hi all, >>>> >>>> I'm writing Samsung SoC based DRM framework and this one includes FIMD >>>> and HDMI driver as hardware dependent modules. and for now, encoder, >>>> connector, crtc and fb module has been materialized almost. but I'm >>>> contending with framebuffer setting issue(created fb_info should be >>>> registered to linux framebuffer through register_framebuffer() or not)as >>>> default framebuffer at booting time. >>>> >>>> at drm_fb_helper_single_fb_probe() of drm_fb_helper.c file, fb_helper's >>>> fb_probe callback is called and this one creates new framebuffer and >>>> returns a value more then 0 if true. internally, this process creates an >>>> fb_info object and drm_framebuffer and then drm_framebuffer would be >>>> added to mode_config.fb_list of the drm_device. >>>> >>> it's my mistake. return value is 0 if true, nonzero otherwise. >>> >>>> a value returned, new_fb is used to decide that it calls >>>> register_framebuffer() or drm_fb_helper_set_par(). at this point, I am >>>> confused it's a good way to call register_framebuffer() otherwise >>>> drm_fb_helper_set_par(). if register_framebuffer() is called then I >>>> guess drm_fb_helper_set_par() or drm_crtc_helper_set_config() should be >>>> called somewhere subsequently to apply this one to real hardware because >>>> previous process is just for maintaining data logically.(not set up data >>>> to h/w) >>>> >>>> it's a right way to call register_framebuffer() and then >>>> drm_fb_helper_set_par() or drm_crtc_helper_set_config()? otherwise just >>>> only drm_fb_helper_set_par() or drm_crtc_helper_set_config() ignoring >>>> register_framebuffer()? and what is the purpose of using >>>> register_framebuffer()? >>>> >>> I understood that if fb_probe() callback is fail then fb_info object is >>> registered to linux framebuffer through register_framebuffer() >>> otherwise(if true) hardware configuration would be completed by >>> drm_fb_helper_set_par() so the reason of using register_framebuffer() is >>> that the case of failing fb_probe() callback, it is for drawing on only >>> linux framebuffer. is it right? >>> >>>> In my case, first, register_framebuffer() is called and then if desired >>>> default crtc id is matched with drm_fb_helper->crtc_info[0 ~ n].crtc_id, >>>> it gets mode_set of drm_fb_helper->crtc_info[n] and then it calls >>>> drm_crtc_helper_set_config(mode_set). at this time, all the hardware >>>> configurations would be completed. >>>> >>>> thank you in advance. >>>> >>>> Best Regards >>>> Inki Dae. >>>> >>> >>> ___ >>> linux-arm-kernel mailing list >>> linux-arm-kernel at lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >
Re: Some questions about DRM(Direct Rendering Manager)
Hi Rob Clark, I'm sorry for that my mean didn't convey to you so I condensed that into brief again. I know drm_fb_helper_single_fb_probe() calls register_framebuffer(), My question is that it's right way to call only drm_fb_helper_set_par() if fb_helper-funcs-fb_probe() returns nonzero. In this case, if fb_helper-funcs-fb_probe() returns zero then register_framebuffer() isn't called and this means linux framebuffer isn't used anymore. one more question, otherwise if it uses drm based framebuffer, register_framebuffer() should be called necessarily at booting time? Thank you. Rob Clark 쓴 글: fwiw, drm_fb_helper_single_fb_probe() calls register_framebuffer() (if that was the question?) BR, -R 2011/6/22 InKi Dae daei...@gmail.com: It adds dri-devel@lists.freedesktop.org to this mail thread. Thank you. 2011년 6월 22일 오후 3:04, daeinki inki@samsung.com님의 말: below is additional comments. daeinki 쓴 글: Hi all, I'm writing Samsung SoC based DRM framework and this one includes FIMD and HDMI driver as hardware dependent modules. and for now, encoder, connector, crtc and fb module has been materialized almost. but I'm contending with framebuffer setting issue(created fb_info should be registered to linux framebuffer through register_framebuffer() or not)as default framebuffer at booting time. at drm_fb_helper_single_fb_probe() of drm_fb_helper.c file, fb_helper's fb_probe callback is called and this one creates new framebuffer and returns a value more then 0 if true. internally, this process creates an fb_info object and drm_framebuffer and then drm_framebuffer would be added to mode_config.fb_list of the drm_device. it's my mistake. return value is 0 if true, nonzero otherwise. a value returned, new_fb is used to decide that it calls register_framebuffer() or drm_fb_helper_set_par(). at this point, I am confused it's a good way to call register_framebuffer() otherwise drm_fb_helper_set_par(). if register_framebuffer() is called then I guess drm_fb_helper_set_par() or drm_crtc_helper_set_config() should be called somewhere subsequently to apply this one to real hardware because previous process is just for maintaining data logically.(not set up data to h/w) it's a right way to call register_framebuffer() and then drm_fb_helper_set_par() or drm_crtc_helper_set_config()? otherwise just only drm_fb_helper_set_par() or drm_crtc_helper_set_config() ignoring register_framebuffer()? and what is the purpose of using register_framebuffer()? I understood that if fb_probe() callback is fail then fb_info object is registered to linux framebuffer through register_framebuffer() otherwise(if true) hardware configuration would be completed by drm_fb_helper_set_par() so the reason of using register_framebuffer() is that the case of failing fb_probe() callback, it is for drawing on only linux framebuffer. is it right? In my case, first, register_framebuffer() is called and then if desired default crtc id is matched with drm_fb_helper-crtc_info[0 ~ n].crtc_id, it gets mode_set of drm_fb_helper-crtc_info[n] and then it calls drm_crtc_helper_set_config(mode_set). at this time, all the hardware configurations would be completed. thank you in advance. Best Regards Inki Dae. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
