RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
-Original Message-
From: Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, May 19, 2009 10:52 AM
To: Dongsoo, Nathaniel Kim; Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
[Shah, Hardik] Rotation requires the VRFB contexts and limited number of
contexts are available. So maximum number of buffers is fixed to 4 when
rotation is enabled.
Thanks,
Hardik
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it
is the userspace app responsability to check the value again, to confirm how
many of the requested buffers are actually available.
Regards,
Sergio
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Inki,
I was on vacation just came,
Below are my comments.
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 6:19 PM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Thank you Shah, Hardik.
I have patched your driver through that git.
but your patch recognizes video2 layer as video1 device node in case
that DSS2 has fb0 and fb1.
[Shah, Hardik] There is no need to change the nodes. If there is only one
video device present than it should be /dev/video1 and not /dev/video2. Its
upto the driver to use which video pipeline 1 or 2. So let the node
nomenclature be same.
Regards,
Hardik
you said my patch will give rise to couple of more bugs related to
global_alpha and pixel formats
maybe that would be because of vout-vid_info.id = k + vout_count;
so I have applied your patch to my way.
this patch is more flexible and recognizes video2 layer correctly as
video2 device node.
--
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2204,7 +2204,7 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device
*pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -2212,6 +2212,8 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
struct omap2video_device *vid_dev = container_of(v4l2_dev, struct
omap2video_device, v4l2_dev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2225,12 +2227,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_dev = vid_dev;
- /* Select video2 if only 1 overlay is controlled by V4L2 */
- if (pdev-num_resources == 1)
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 2];
- else
- /* Else select video1 and video2 one by one. */
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k +
vout_count];
vout-vid_info.num_overlays = 1;
vout-vid_info.id = k + 1;
vid_dev-num_videos++;
@@ -2253,7 +2250,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count) 0) {
printk(KERN_ERR VOUT_NAME : could not register
Video for Linux device\n);
vfd-minor = -1
--
--
-
2009/4/30 Shah, Hardik hardik.s...@ti.com:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shah, Hardik
Sent: Thursday, April 30, 2009 11:51 AM
To: InKi Dae
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2
RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2246,11 +2246,13 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device
*pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2266,9 +2268,9 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_info.vid_dev = vid_dev;
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
- vout-vid_info.id = k + 1;
+ vout-vid_info.id = k + vout_count;
vid_dev-num_videos++;
/* Setup the default configuration for the video devices
@@ -2289,7 +2291,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count)
0) {
printk(KERN_ERR VOUT_NAME : could not register \
Video for Linux device\n);
vfd-minor = -1;
2009/4/22 Shah, Hardik hardik.s...@ti.com:
[Shah, Hardik] Yes this is correct,
I will apply this patch. I already found it and fixed it in different way but
any way I will apply your patch.
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, April 22, 2009 1:53 PM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565
4. Supports Alpha blending.
5. Supports Color keying both source and destination.
6. Supports rotation with RGB565 and RGB32 pixels formats.
7. Supports cropping.
8. Supports Background color setting.
9. Works on latest DSS2 library from Tomi
http://www.bat.org/~tomba/git/linux-omap-dss.git/
10. 1/4x scaling added. Detail testing left
TODOS
1. Ioctls needs to be added for color space conversion matrix
coefficient programming.
2. To be tested on DVI resolutions.
Comments fixed from community.
1. V4L2 Driver for OMAP3/3 DSS.
2. Conversion of the custom ioctls to standard V4L2 ioctls like alpha
blending,
color keying, rotation and back ground color setting
3. Re-organised the code as per community comments.
4. Added proper copyright year.
5. Added module name in printk
6. Kconfig option copy/paste
RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shah, Hardik
Sent: Thursday, April 30, 2009 11:51 AM
To: InKi Dae
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2246,11 +2246,13 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device
*pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2266,9 +2268,9 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_info.vid_dev = vid_dev;
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
- vout-vid_info.id = k + 1;
+ vout-vid_info.id = k + vout_count;
vid_dev-num_videos++;
/* Setup the default configuration for the video devices
@@ -2289,7 +2291,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count)
0) {
printk(KERN_ERR VOUT_NAME : could not register \
Video for Linux device\n);
vfd-minor = -1;
2009/4/22 Shah, Hardik hardik.s...@ti.com:
[Shah, Hardik] Yes this is correct,
I will apply this patch. I already found it and fixed it in different way but
any way I will apply your patch.
[Shah, Hardik] Further on this inki. Solving this bug will give rise to couple
of more bugs related to global_alpha and pixel formats. That also is fixed. You
can refer
http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=summary
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, April 22, 2009 1:53 PM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav,
Brijesh
R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24,
RGB565
4. Supports Alpha blending.
5. Supports Color keying both source and destination.
6. Supports rotation with RGB565 and RGB32 pixels formats.
7. Supports
RE: [PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs.
Hi All, -Original Message- From: Shah, Hardik Sent: Friday, March 20, 2009 10:49 AM To: linux-me...@vger.kernel.org Cc: linux-omap@vger.kernel.org Subject: [PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs. Hi All, I will be posting series of three patches for the V4L2 driver on the OMAP2/3 DSS. Patch 1 - This is the second revision of the patch. Documentation added for the following new CIDs and bit fields added in V4L2 framework. V4L2_CID_BG_COLOR: Added new CID for setting of the back ground color on the output device. V4L2_CID_ROTATION: Added new CID for setting up of the rotation on the device. Both of the above ioctls are discussed in detail. V4L2_FBUF_FLAG_SRC_CHROMAKEY: Added the flags bit field to the flags field of the v4l2_framebuffer structure for supporting the source chroma keying. It's exactly opposite of the chroma keying supported with the flag V4L2_FBUF_FLAG_CHROMAKEY. V4L2_FBUF_CAP_SRC_CHROMAKEY: Added the capability bit field for the capability field of the v4l2_framebuffer structure. Documentation change related to the new bit field for the source chroma keying is new from the previous version. [Shah, Hardik] No comment, on the earlier one. So not sending it again. Previous patch can be found at http://patchwork.kernel.org/patch/16519/ Patch 2 - Added New Control IDs for OMAP class of Devices as discussed above. This is the third revision of the patch of adding the new control IDs and bit fields. V4L2_FBUF_CAP_SRC_CHROMAKEY and V4L2_FBUF_FLAG_SRC_CHROMAKEY are newly added compared to previous revision of patch. New Ioctl for programming the color space conversion matrix is dropped from this patch as the accompanying driver with this patch is not still having implementation for the same. Related documentation is also removed. I will submit a separate patch for that with the necessary changes in driver to support the programming of the color space conversion. Some changes are required in DSS2 library also for doing the same. [Shah, Hardik] No comments received on this either. Not sending the patches again. Previous patch can be found at http://patchwork.kernel.org/patch/16520/ Patch 3 - This is a review patch since the DSS2 library is still to be accepted in community This is the third revision of the patch. This patch contains the V4L2 driver on the OMAP3 DSS2 using all of the above newly implemented CIDS and bit fields. Following are the changes in the driver compared to the previous version. 1. Added the chroma keying support. 2. Added alpha blending support. 3. Minor community comment fixed. 4. Ported to work with Tomi's latest DSS2 library with minor modification in DSS2 library. Path to Tomi's DSS2 library is http://www.bat.org/~tomba/git/linux-omap-dss.git/ commit id bc6dc4c7fabb8ba3bfe637a6c5dc271595a1bef6 [Shah, Hardik] I am re-submitting the 3rd patch of this series with the bunch of community comments fixed specially from Hans. This patch includes some new features like flip and yuv rotation. Also the patch is rebased on the latest Tomi git tree. Patch is tested on OMAP3evm board. Board specific porting needs to be done on other boards. Tomi git tree with commit id on which this patch is based. http://www.bat.org/~tomba/git/linux-omap-dss.git/ 0f88992b2681aed4f31dc7dd3926b357bbc95154. DSS2: DSI: decrease sync timeout from 60s to 2s This is still a review patch since the DSS2 library is not submitted. All the comments and inputs are welcomed. Thanks and Regards Hardik Shah -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, April 22, 2009 1:53 PM To: Shah, Hardik Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver Hi, On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote: This is the version 5th of the Driver. Following are the features supported. 1. Provides V4L2 user interface for the video pipelines of DSS 2. Basic streaming working on LCD and TV. 3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565 4. Supports Alpha blending. 5. Supports Color keying both source and destination. 6. Supports rotation with RGB565 and RGB32 pixels formats. 7. Supports cropping. 8. Supports Background color setting. 9. Works on latest DSS2 library from Tomi http://www.bat.org/~tomba/git/linux-omap-dss.git/ 10. 1/4x scaling added. Detail testing left TODOS 1. Ioctls needs to be added for color space conversion matrix coefficient programming. 2. To be tested on DVI resolutions. Comments fixed from community. 1. V4L2 Driver for OMAP3/3 DSS. 2. Conversion of the custom ioctls to standard V4L2 ioctls like alpha blending, color keying, rotation and back ground color setting 3. Re-organised the code as per community comments. 4. Added proper copyright year. 5. Added module name in printk 6. Kconfig option copy/paste error 7. Module param desc addded. 8. Query control implemented using standard query_fill 9. Re-arranged if-else constructs. 10. Changed to use mutex instead of semaphore. 11. Removed dual usage of rotation angles. 12. Implemented function to convert the V4L2 angle to DSS angle. 13. Y-position was set half by video driver for TV output Now its done by DSS so removed that. 14. Minor cleanup 15. Added support to pass the page offset to application. 14. Minor cleanup 15. Added support to pass the page offset to application. 16. Renamed V4L2_CID_ROTATION to V4L2_CID_ROTATE 17. Major comment from Hans fixed. 18. Copy right year changed. 19. Added module name for each error/warning print message. Changes from Previous Version. 1. Supported YUV rotation. 2. Supported Flipping. 3. Rebased line with Tomi's latest DSS2 master branch with commit id f575a02edf2218a18d6f2ced308b4f3e26b44ce2. 4. Kconfig option removed to select between the TV and LCD. Now supported dynamically by DSS2 library. 5. Kconfig option for the NTSC_M and PAL_BDGHI mode but not supported by DSS2. so it will not work now. There is basic support for this. See the DSS doc: /sys/devices/platform/omapdss/display? directory: ... timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) When writing, two special timings are accepted for tv-out: pal and ntsc [Shah, Hardik] I was not aware of it will remove the compile time option and for now let the sysfs entry change the standard. In future I will try to do it with the S_STD and G_STD ioctls of the V4L2 framework. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.]
Hi Tomi, Can you please merge the YUV rotation patches with your latest? Thanks and Regards, Haardik -Original Message- From: plasma...@gmail.com [mailto:plasma...@gmail.com] On Behalf Of Tim Yamin Sent: Tuesday, April 14, 2009 2:30 AM To: Shah, Hardik Cc: grego...@gentil.com; tomi.valkei...@nokia.com; linux-omap@vger.kernel.org; beaglebo...@googlegroups.com Subject: Re: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.] Hi Hardik, Thanks for fixing up the patch. I can confirm that YUV rotation is fine and patches are ready to be merged -- although the attached fix is needed as well for the userspace layer to know the correct row strides when writing YUV to the framebuffer. I'm still having VID1_FIFO_UNDERFLOW errors when I try to play rotated video on plane 1 and plane 0 is rotated as well. Do you have any ideas how to debug this further? Thanks, Tim Hi Tomi, If YUV rotation with frame buffer passes can you please review the patch and merge it to your latest. Regards, Hardik -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.]
Hi, -Original Message- From: plasma...@gmail.com [mailto:plasma...@gmail.com] On Behalf Of Tim Yamin Sent: Wednesday, April 08, 2009 12:31 AM To: Shah, Hardik Cc: grego...@gentil.com; tomi.valkei...@nokia.com; linux-omap@vger.kernel.org; beaglebo...@googlegroups.com Subject: Re: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.] Hi Hardik / Tomi, [Shah, Hardik] I have also patched the DSS to support the DSS YUV rotation. Here the rotation type is passed to know the type of rotation required by driver. I have also modified the FBDEV driver to use this patch. Please find the both patches. I have tested it on the old master of tomi. Commit id is 4261fafc4fdc0730b3d4dd83c036d8be09ec8575. I am planning to rebase it on the latest master soon. I have tested the FBDEV driver with different rotation and resolution settings. Hi Tim, I have done few changes to your patch. - else if (bytespp == 2) + width = 1; Will not work for 32 bit formats like ARGB or RGB24u. Secondly I have fixed lot many check patch warnings/errors in your patch. So please do that before providing patches. Third I have implemented VRFB mirroring also. I have tested YUV, UYVY, RGB24u, RGB16, and ARGB on V4L2 driver with rotation and mirroring with different resolutions on LCD and its working fine. Tim, Will you please test the YUV rotation with frame buffer driver with the attached patch and let us know the result. I have tested RGB rotation and its working fine. Hi Tomi, If YUV rotation with frame buffer passes can you please review the patch and merge it to your latest. Regards, Hardik I've merged my changes with your patches and rebased against master, please find the new patch attached. [Shah, Hardik] Hi Tim, I have modified your DSS2 rotation patch to make it more generic to support YUV as well as ARGB32 and RGB24u formats. [Shah, Hardik] In past I saw setting the FIFO size eliminates this problem. I have some FIFO setting can you please try this out and let me know the result. FIFO_HIGH_THRES = 0x3FC and GFX_FIFO_LOW_THRES = 0x3BC. This I tried in on OMAP3. Tried this (see attached patch) but does not help -- still getting these errors as soon as I try to play a video: omapdss DISPC error: VID1_FIFO_UNDERFLOW, disabling VID1 omapdss DISPC error: SYNC_LOST, disabling LCD The FIFOs are configured as follows: omapdss DISPC: fifo(0) size 1024, low/high old 3008/3071, new 956/1020 omapdss DISPC: fifo(1) size 1024, low/high old 956/1020, new 956/1020 Cheers, Tim 0002-DSS2-OMAPFB-Added-support-for-the-YUV-VRFB-rotatio.patch Description: 0002-DSS2-OMAPFB-Added-support-for-the-YUV-VRFB-rotatio.patch 0001-DSS2-VRFB-rotation-and-mirroring-implemented.patch Description: 0001-DSS2-VRFB-rotation-and-mirroring-implemented.patch
RE: [PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs.
Hi All, -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, March 20, 2009 12:56 PM To: Shah, Hardik Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs. On Friday 20 March 2009 06:18:44 Shah, Hardik wrote: Hi All, I will be posting series of three patches for the V4L2 driver on the OMAP2/3 DSS. Thanks! I'll review this within the week. [Shah, Hardik] I have fixed most of the comments and re-posting the patches. Regards, Hans Patch 1 - This is the second revision of the patch. Documentation added for the following new CIDs and bit fields added in V4L2 framework. V4L2_CID_BG_COLOR: Added new CID for setting of the back ground color on the output device. V4L2_CID_ROTATION: Added new CID for setting up of the rotation on the device. Both of the above ioctls are discussed in detail. V4L2_FBUF_FLAG_SRC_CHROMAKEY: Added the flags bit field to the flags field of the v4l2_framebuffer structure for supporting the source chroma keying. It's exactly opposite of the chroma keying supported with the flag V4L2_FBUF_FLAG_CHROMAKEY. V4L2_FBUF_CAP_SRC_CHROMAKEY: Added the capability bit field for the capability field of the v4l2_framebuffer structure. Documentation change related to the new bit field for the source chroma keying is new from the previous version. Patch 2 - Added New Control IDs for OMAP class of Devices as discussed above. This is the third revision of the patch of adding the new control IDs and bit fields. V4L2_FBUF_CAP_SRC_CHROMAKEY and V4L2_FBUF_FLAG_SRC_CHROMAKEY are newly added compared to previous revision of patch. New Ioctl for programming the color space conversion matrix is dropped from this patch as the accompanying driver with this patch is not still having implementation for the same. Related documentation is also removed. I will submit a separate patch for that with the necessary changes in driver to support the programming of the color space conversion. Some changes are required in DSS2 library also for doing the same. Patch 3 - This is a review patch since the DSS2 library is still to be accepted in community This is the third revision of the patch. This patch contains the V4L2 driver on the OMAP3 DSS2 using all of the above newly implemented CIDS and bit fields. Following are the changes in the driver compared to the previous version. 1. Added the chroma keying support. 2. Added alpha blending support. 3. Minor community comment fixed. 4. Ported to work with Tomi's latest DSS2 library with minor modification in DSS2 library. Path to Tomi's DSS2 library is http://www.bat.org/~tomba/git/linux-omap-dss.git/ commit id bc6dc4c7fabb8ba3bfe637a6c5dc271595a1bef6 All the comments and inputs are welcomed. Thanks and Regards Hardik Shah -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
Hi Hans,
Please find my comments inline. Most of the comments are taken care of.
Regards,
Hardik Shah
static struct twl4030_hsmmc_info mmc[] __initdata = {
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 19cf3b8..91e4529 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -711,6 +711,26 @@ config VIDEO_CAFE_CCIC
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+#config VIDEO_OMAP3
+#tristate OMAP 3 Camera support
+# select VIDEOBUF_GEN
+# select VIDEOBUF_DMA_SG
+# depends on VIDEO_V4L2 ARCH_OMAP34XX
+# ---help---
+#Driver for an OMAP 3 camera controller.
Why add a commented config?
[Shah, Hardik] To make explicit that camera and display will have same config.
But any way removed and put a comment in config option.
+
+config VID1_LCD_MANAGER
+bool Use LCD Managaer
+help
+ Select this option if you want VID1 pipeline on LCD Overlay
manager
+endchoice
+
+choice
+ prompt VID2 Overlay manager
+ depends on VIDEO_OMAP_VIDEOOUT
+ default VID2_LCD_MANAGER
+
+config VID2_TV_MANAGER
+ bool Use TV Manager
+ help
+ Select this option if you want VID2 pipeline on TV Overlay manager
+
+config VID2_LCD_MANAGER
+ bool Use LCD Managaer
+ help
+ Select this option if you want VID2 pipeline on LCD Overlay manager
+endchoice
+
+choice
+prompt TV Mode
+depends on VID2_TV_MANAGER || VID1_TV_MANAGER
+default NTSC_M
+
+config NTSC_M
+bool Use NTSC_M mode
+help
+ Select this option if you want NTSC_M mode on TV
+
+config PAL_BDGHI
+bool Use PAL_BDGHI mode
+help
+ Select this option if you want PAL_BDGHI mode on TV
Why are these config options? Isn't it possible to do this dynamically
through VIDIOC_S_STD?
[Shah, Hardik] Currently is not tested/supported dynamically. I will add it at
todos.
+
+static u32 video1_numbuffers = 3;
+static u32 video2_numbuffers = 3;
+static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
+static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
+module_param(video1_numbuffers, uint, S_IRUGO);
+module_param(video2_numbuffers, uint, S_IRUGO);
+module_param(video1_bufsize, uint, S_IRUGO);
+module_param(video2_bufsize, uint, S_IRUGO);
I recommend adding MODULE_PARM_DESC() as well to provide a description of
these module options.
[Shah, Hardik] Added MODULE_PARM_DESC
+
+static int omap_vout_create_video_devices(struct platform_device *pdev);
+static int omapvid_apply_changes(struct omap_vout_device *vout, u32 addr,
+ int init);
+static int omapvid_setup_overlay(struct omap_vout_device *vout,
+ struct omap_overlay *ovl, int posx, int posy,
+ int outw, int outh, u32 addr, int tv_field1_offset, int init);
+static enum omap_color_mode video_mode_to_dss_mode(struct omap_vout_device
+ *vout);
+static void omap_vout_isr(void *arg, unsigned int irqstatus);
+static void omap_vout_cleanup_device(struct omap_vout_device *vout);
+/* module parameters */
^^ This comment should be moved up.
[Shah, Hardik] Done
+static int omap_vout_try_format(struct v4l2_pix_format *pix,
+ struct v4l2_pix_format *def_pix)
+{
+ int ifmt, bpp = 0;
+
+ if (pix-width VID_MAX_WIDTH)
+ pix-width = VID_MAX_WIDTH;
+ if (pix-height VID_MAX_HEIGHT)
+ pix-height = VID_MAX_HEIGHT;
+
+ if (pix-width = VID_MIN_WIDTH)
+ pix-width = def_pix-width;
+ if (pix-height = VID_MIN_HEIGHT)
+ pix-height = def_pix-height;
Linux provides some nice clamp macros for this. See linux/kernel.h.
[Shah, Hardik] I tried using it but still if condition is required as I have
four values to select from so I reverted back to same old method.
The else below should be indented one tab to the left.
+ } else {
+ dmabuf = videobuf_to_dma(q-bufs[vb-i]);
+
+ vout-queued_buf_addr[vb-i] = (u8 *) dmabuf-bus_addr;
+ }
Note this it is better to handle the else part first and return.
Then the large if-part can be handled after that and can be indented
on tab to the left as well.
I.e.:
if (cond) {
// lots of code
} else {
// small amount of code
}
can be rewritten as:
if (!cond) {
// small amount of code
return 0;
}
// lots of code.
+ return 0;
[Shah, Hardik] Done, Implemented
+}
+ /* get the display device attached to the overlay */
+ if (!ovl-manager || !ovl-manager-display)
+ return -1;
+ cur_display = ovl-manager-display;
+
+ if ((cur_display-type == OMAP_DISPLAY_TYPE_VENC)
+ ((win-w.width == crop-width)
+ (win-w.height == crop-height
RE: [PATCH 2/3] New V4L2 CIDs for OMAP class of Devices.
Hi Hans,
Please find my comments inline.
Regards,
Hardik Shah
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, March 30, 2009 5:29 PM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: Re: [PATCH 2/3] New V4L2 CIDs for OMAP class of Devices.
On Friday 20 March 2009 06:19:57 Hardik Shah wrote:
Added V4L2_CID_BG_COLOR for background color setting.
Added V4L2_CID_ROTATION for rotation setting.
Above two ioclts are indepth discussed. Posting
again with the driver usage.
---
linux/drivers/media/video/v4l2-common.c |7 +++
linux/include/linux/videodev2.h |6 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index 3c42316..fa408f0 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -422,6 +422,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_CHROMA_AGC: return Chroma AGC;
case V4L2_CID_COLOR_KILLER: return Color Killer;
case V4L2_CID_COLORFX: return Color Effects;
+ case V4L2_CID_ROTATION: return Rotation;
I'm having second thoughts about this name. I think V4L2_CID_ROTATE is better,
since it is an action ('you rotate an image') rather than a status ('what is
the rotation of an image').
What do you think?
[Shah, Hardik] Yes, it should be V4L2_CID_ROTATE as V4L2_CID_HFLIP.
+ case V4L2_CID_BG_COLOR: return Background color;
/* MPEG controls */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
@@ -547,6 +549,10 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
break;
+ case V4L2_CID_BG_COLOR:
+qctrl-type = V4L2_CTRL_TYPE_INTEGER;
+step = 1;
+break;
Set the min to 0 and max to 0xff.
[Shah, Hardik] Added
default:
qctrl-type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -571,6 +577,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
+ case V4L2_CID_BG_COLOR:
This definitely isn't a slider control.
[Shah, Hardik] Removed
--
1.5.6
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] Documentation for new V4L2 CIDs added.
Hi Hans, Please find my comments inline. Regards, Hardik -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, March 30, 2009 5:23 PM To: Shah, Hardik Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav Subject: Re: [PATCH 1/3] Documentation for new V4L2 CIDs added. Hi Hardik, OK, so it took a little longer than a week. So sue me :-) Typo: chorma - chroma [Shah, Hardik] Done in next post +images will be replaced by the video images. Exactly +opposite of constantV4L2_FBUF_CAP_CHROMAKEY/constant/entry Hmm. This is a bit obscure. CAP_CHROMAKEY means that framebuffer pixels with the chromakey color are replaced by video pixels. CAP_SRC_CHROMAKEY means that video pixels with the chromakey color are replaced by the framebuffer pixels. At least the way I read it this is the opposite of what you wrote. It pays to be very precise here since it can get confusing very quickly. [Shah, Hardik] Done in next post + /row /tbody /tgroup /table @@ -411,6 +418,18 @@ images, but with an inverted alpha value. The blend function is: output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The actual alpha depth depends on the framebuffer pixel format./entry /row + row + entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry + entry0x0040/entry + entryUse chroma-keying. The chroma-key color is Write: 'Use source chroma-keying.' to prevent confusion with V4L2_FBUF_FLAG_CHROMAKEY. [Shah, Hardik] Done in next post +determined by the structfieldchromakey/structfield field of +v4l2-window; and negotiated with the VIDIOC-S-FMT; ioctl, see xref +linkend=overlay and xref linkend=osd. +Since any one of the chorma keying can be active at a time as both Typo: chorma - chroma [Shah, Hardik] Done in next post +of them are exactly opposite same structfieldchromakey/structfield Typo: 'opposite same' - 'opposite the same' [Shah, Hardik] Done in next post +field of v4l2-window; can be used to set the chroma key for source +keying also./entry + /row /tbody /tgroup /table -- 1.5.6 Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.]
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gregoire Gentil Sent: Tuesday, April 07, 2009 10:00 AM To: tomi.valkei...@nokia.com Cc: linux-omap@vger.kernel.org; beaglebo...@googlegroups.com; pl...@roo.me.uk Subject: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.] Tomi, Tim has patched your latest DSS2 2.6.29 git (master branch) to add support for YUV rotation. It has been successfully tested on the coming Touch Book, as well as the Beagleboard Rev B6 with the exception of the bug mentioned below. You may want to review this patch and perhaps integrate once we have fixed the problem below. A couple of questions and comments: 1. dss.c has no way of knowing whether VRFB is being used or not -- this is a problem because you need to decide whether to call calc_rotation_offset_vrfb(...) or calc_rotation_offset(...). Any suggestions on how the rotation mode should be passed between dss.c and omapfb-main.c? [Shah, Hardik] I have also patched the DSS to support the DSS YUV rotation. Here the rotation type is passed to know the type of rotation required by driver. I have also modified the FBDEV driver to use this patch. Please find the both patches. I have tested it on the old master of tomi. Commit id is 4261fafc4fdc0730b3d4dd83c036d8be09ec8575. I am planning to rebase it on the latest master soon. I have tested the FBDEV driver with different rotation and resolution settings. 2. If I try to rotate both plane 0 and plane 1 to either 90 degrees or 270 (doesn't matter which is which), as soon as you try to play a video you get VID1_FIFO_UNDERFLOW error messages, so it seems that the hardware seems to be struggling a little when you have two sets of 90/270 degree rotations. If one of the planes is 0/180 and the other is 90/270, then everything is fine. Would changing the FIFO settings somehow improve this or do you have any ideas about what else might make it work better? [Shah, Hardik] In past I saw setting the FIFO size eliminates this problem. I have some FIFO setting can you please try this out and let me know the result. FIFO_HIGH_THRES = 0x3FC and GFX_FIFO_LOW_THRES = 0x3BC. This I tried in on OMAP3. Regards, Hardik Shah Thanks in advance, Grégoire Gentil [Shah, Hardik] Hi, 0002-DSS2-OMAPFB-Changed-to-support-YUV-VRFB-rotation.patch Description: 0002-DSS2-OMAPFB-Changed-to-support-YUV-VRFB-rotation.patch 0001-DSS2-Added-support-for-the-YUV-VRFB-rotation.patch Description: 0001-DSS2-Added-support-for-the-YUV-VRFB-rotation.patch
RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
-Original Message- From: Koen Kooi [mailto:k.k...@student.utwente.nl] Sent: Friday, March 20, 2009 2:34 PM To: Shah, Hardik Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav Subject: Re: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS. Op 20 mrt 2009, om 06:20 heeft Hardik Shah het volgende geschreven: --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -711,6 +711,26 @@ config VIDEO_CAFE_CCIC CMOS camera controller. This is the controller found on first- generation OLPC systems. +#config VIDEO_OMAP3 +#tristate OMAP 3 Camera support +# select VIDEOBUF_GEN +# select VIDEOBUF_DMA_SG +# depends on VIDEO_V4L2 ARCH_OMAP34XX +# ---help--- +#Driver for an OMAP 3 camera controller. + +config VIDEO_OMAP3 + bool OMAP2/OMAP3 Camera and V4L2-DSS drivers + select VIDEOBUF_GEN + select VIDEOBUF_DMA_SG + select OMAP2_DSS + depends on VIDEO_DEV (ARCH_OMAP24XX || ARCH_OMAP34XX) + default y + ---help--- +V4L2 DSS and Camera driver support for OMAP2/3 based boards. Copy/paste error? regards, Koen [Shah, Hardik] Yes, I will correct it, Its indeed copy paste error Regards, Hardik -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
-Original Message-
From: Alexey Klimov [mailto:klimov.li...@gmail.com]
Sent: Friday, March 20, 2009 6:02 PM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
snip
Hello again,
my previous message due to bad connection was send with no end.
Sorry about that.
+ vout-vid = k;
+ vid_dev-vouts[k] = vout;
+ vout-vid_info.vid_dev = vid_dev;
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.num_overlays = 1;
+ vout-vid_info.id = k + 1;
+ vid_dev-num_videos++;
+
+ /* Setup the default configuration for the video devices
+*/
+ if (omap_vout_setup_video_data(vout) != 0) {
+ r = -ENOMEM;
+ goto error;
+ }
+
+ /* Allocate default number of buffers for the video
streaming
+* and reserve the VRFB space for rotation
+*/
+ if (omap_vout_setup_video_bufs(pdev, k) != 0) {
+ r = -ENOMEM;
+ goto error1;
+ }
+
+ /* Register the Video device with V4L2
+*/
+ vfd = vout-vfd;
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0)
{
+ printk(KERN_ERR VOUT_NAME : could not register \
+ Video for Linux device\n);
+ vfd-minor = -1;
+ r = -ENODEV;
+ goto error2;
+ }
+
+ if (k == 0)
+ saved_v1out = vout;
+ else
+ saved_v2out = vout;
+
+ r = omapvid_apply_changes(vid_dev-vouts[k], 0, 1);
+
+ if (r)
+ goto error2;
+ else
+ goto success;
+error2:
+ omap_vout_release_vrfb(vout);
+ omap_vout_free_buffers(vout);
+error1:
+ video_device_release(vfd);
+error:
+ kfree(vout);
+ return r;
+
+success:
+ printk(KERN_INFO VOUT_NAME : registered and initialized\
+ video device %d [v4l2]\n, vfd-minor);
+ if (k == (pdev-num_resources - 1))
+ return 0;
+ }
+ return -ENODEV;
+
+}
+
+int omapvid_apply_changes(struct omap_vout_device *vout, u32 addr, int
init)
+{
+ int r = 0;
+ struct omapvideo_info *ovid = (vout-vid_info);
+ struct omap_overlay *ovl;
+ int posx, posy;
+ int outw, outh, temp, rotation;
+ int i;
+ struct v4l2_window *win;
+ struct omap_video_timings *timing;
+ struct omap_display *cur_display;
+
+ win = vout-win;
+ rotation = vout-rotation;
+ for (i = 0; i ovid-num_overlays; i++) {
+ ovl = ovid-overlays[i];
+ if (!ovl-manager || !ovl-manager-display)
+ return -EINVAL;
+
+ timing = ovl-manager-display-panel-timings;
+ cur_display = ovl-manager-display;
+
+ if (init || (ovl-caps OMAP_DSS_OVL_CAP_SCALE) == 0) {
+ outw = win-w.width;
+ outh = win-w.height;
+
+ } else {
+ outw = win-w.width;
+ outh = win-w.height;
+ }
+ if (init) {
+ posx = 0;
+ posy = 0;
+ } else {
+ switch (rotation) {
+
+ case 1:
+ /* Invert the height and widht for 90
+* and 270 degree rotation
+*/
+ temp = outw;
+ outw = outh;
+ outh = temp;
+ posy = (timing-y_res - win-w.width)-
+ win-w.left;
+ posx = win-w.top;
+ break;
+
+ case 2:
+ posx = (timing-x_res - win-w.width) -
+ win-w.left;
+ posy = (timing-y_res - win-w.height) -
+ win-w.top;
+ break;
+
+ case 3:
+ temp = outw;
+ outw = outh;
+ outh = temp
[PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs.
Hi All, I will be posting series of three patches for the V4L2 driver on the OMAP2/3 DSS. Patch 1 - This is the second revision of the patch. Documentation added for the following new CIDs and bit fields added in V4L2 framework. V4L2_CID_BG_COLOR: Added new CID for setting of the back ground color on the output device. V4L2_CID_ROTATION: Added new CID for setting up of the rotation on the device. Both of the above ioctls are discussed in detail. V4L2_FBUF_FLAG_SRC_CHROMAKEY: Added the flags bit field to the flags field of the v4l2_framebuffer structure for supporting the source chroma keying. It's exactly opposite of the chroma keying supported with the flag V4L2_FBUF_FLAG_CHROMAKEY. V4L2_FBUF_CAP_SRC_CHROMAKEY: Added the capability bit field for the capability field of the v4l2_framebuffer structure. Documentation change related to the new bit field for the source chroma keying is new from the previous version. Patch 2 - Added New Control IDs for OMAP class of Devices as discussed above. This is the third revision of the patch of adding the new control IDs and bit fields. V4L2_FBUF_CAP_SRC_CHROMAKEY and V4L2_FBUF_FLAG_SRC_CHROMAKEY are newly added compared to previous revision of patch. New Ioctl for programming the color space conversion matrix is dropped from this patch as the accompanying driver with this patch is not still having implementation for the same. Related documentation is also removed. I will submit a separate patch for that with the necessary changes in driver to support the programming of the color space conversion. Some changes are required in DSS2 library also for doing the same. Patch 3 - This is a review patch since the DSS2 library is still to be accepted in community This is the third revision of the patch. This patch contains the V4L2 driver on the OMAP3 DSS2 using all of the above newly implemented CIDS and bit fields. Following are the changes in the driver compared to the previous version. 1. Added the chroma keying support. 2. Added alpha blending support. 3. Minor community comment fixed. 4. Ported to work with Tomi's latest DSS2 library with minor modification in DSS2 library. Path to Tomi's DSS2 library is http://www.bat.org/~tomba/git/linux-omap-dss.git/ commit id bc6dc4c7fabb8ba3bfe637a6c5dc271595a1bef6 All the comments and inputs are welcomed. Thanks and Regards Hardik Shah -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Hello Tomi Valkeinen, I have some questions about dss2 driver.
Hi Dae, I am attaching one patch which adds the support of rotation on top of Tomi's DSS library. But this patch is created against the patches posted by tomi long back. You can have look at _dispc_calc_and_set_row_inc and _dispc_set_rotation_mirroring function for reference to add the YUV support. I have tested it with YUV, UYVY, RGB16 and RGB24u pixel format. Currently it supports pixel and row increment calculation only for rotation case. Thanks and Regards, Hardik Shah -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of InKi Dae Sent: Wednesday, March 11, 2009 10:28 AM To: Tomi Valkeinen Cc: linux-omap@vger.kernel.org Subject: Hello Tomi Valkeinen, I have some questions about dss2 driver. I am using your dss2 driver downloaded from your git server and tried to rotate an image(RGB24U and YUV2 format) using OMAPFB_ROT_DMA command. but I can't see rotated image on screen. I added variables for rotating like below. as the result, LCD Panel is stoped. omapfb.rotate=2 omapfb.vrfb=n and then I tried again using OMAPFB_ROT_VRFB command like below. omapfb.rotate=2 omapfb.vrfb=y In this case, I can see rotated image(only RGB24U format) on screen. You asid Rotation and mirroring currently only supports RGB565 and RGB modes. VRFB does not support mirroring through /Documentation/arm/OMAP/DSS file. Doesn't your dss2 driver support DMA rotation? I am trying to add rotation feature for YUV2 image using VRFB to your dss2 driver. for this, I think that it have to change rot and mirror become 0 if rotation_type is OMAPFB_ROT_VRFB to be rot=ofbi-rotation and mirror = ofbi-mirror (in omapfb-main.c file) and add codes for calculating offset0, offset1, pixel increment and row increment value for YUV2 format also pixel size becomes 4 in YUV2 case (in dispc.c fild). omap_vrfb_setup function must be modifed also (in vrfb.c file)? Do you have any idea? I need your help and advice. Thank you. - InKi- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 0002-Changes-Done-to-DSS-Library.patch Description: 0002-Changes-Done-to-DSS-Library.patch
RE: [Linux-fbdev-devel] [PATCH 02/12] DSS: Display subsystem for OMAP2/3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Monday, January 12, 2009 6:32 PM To: Tomi Valkeinen Cc: linux-fbdev-de...@lists.sourceforge.net; linux-omap@vger.kernel.org Subject: Re: [Linux-fbdev-devel] [PATCH 02/12] DSS: Display subsystem for OMAP2/3 * Tomi Valkeinen tomi.valkei...@nokia.com [090112 14:37]: Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com --- arch/arm/plat-omap/Kconfig|2 arch/arm/plat-omap/Makefile |2 arch/arm/plat-omap/dss/Kconfig| 71 + arch/arm/plat-omap/dss/Makefile |6 arch/arm/plat-omap/dss/dispc.c| 2113 + arch/arm/plat-omap/dss/display.c | 787 +++ arch/arm/plat-omap/dss/dpi.c | 344 + arch/arm/plat-omap/dss/dss.c | 774 +++ arch/arm/plat-omap/dss/dss.h | 274 arch/arm/plat-omap/dss/sdi.c | 174 ++ arch/arm/plat-omap/include/mach/display.h | 462 ++ 11 files changed, 5009 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/dss/Kconfig create mode 100644 arch/arm/plat-omap/dss/Makefile create mode 100644 arch/arm/plat-omap/dss/dispc.c create mode 100644 arch/arm/plat-omap/dss/display.c create mode 100644 arch/arm/plat-omap/dss/dpi.c create mode 100644 arch/arm/plat-omap/dss/dss.c create mode 100644 arch/arm/plat-omap/dss/dss.h create mode 100644 arch/arm/plat-omap/dss/sdi.c create mode 100644 arch/arm/plat-omap/include/mach/display.h Sorry, no subdirectories allowed under arch/arm/*omap*. Please move these to live under drivers/video somewhere. Also, you should not need to use cpu_is_omap() macros under drivers, please separate out the low-level init to happen under arch/arm/*omap* and pass the necessary things to the driver in the platform_data. See how usb and mmc are doing it for example. [Shah, Hardik] Hi Tony, DSS library will be used by both V4L2 driver and the FBDEV driver. So will you please suggest the ideal directory for the DSS library? Moving the DSS library files under /drivers/video will break V4L2 will moving it under /drivers/media/video/ will break fbdev. Thanks and Regards, Hardik Shah Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description
-Original Message- From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2008 9:40 PM To: [EMAIL PROTECTED] Cc: linux-omap@vger.kernel.org Subject: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description New Display Subsystem for OMAP2/3 - This patch set implements new Display Subsystem (DSS) for OMAP2/3 processors. The DSS is still under work and these patches are for review. Note that there is also another new DSS implementation from TI. The DSS has been tested on OMAP3 SDP board, Beagle Board and on two unreleased boards with DSI and SDI displays. The DSS used to work on OMAP2 board also, but it's been a while since I was able to test with OMAP2 board. The first patch is a doc file that tries to explain a bit how the drivers work. The patch set is based on the current linux-omap tree. You can find the patches also from a git tree at http://www.bat.org/~tomba/git/linux-omap-dss.git/ Note that you also need two patches from Mans Rullgard to make things work. These are needed to be able to reconfigure DSS functional clock. http://git.mansr.com/?p=linux- omap;a=commit;h=e2de5e5578fbaa9b4b75074796da0608fc93e6ae http://git.mansr.com/?p=linux- omap;a=commit;h=2b7b958dc79e51127d7a4ecf88ce12dbc6c31426 Questions/problems -- Perhaps the biggest problems I have is the interface to user space. OMAP hardware doesn't quite fit in to the framebuffer framework. The problem is that a framebuffer can go to multiple overlays, and also the target display, to which a framebuffer goes, can change. In addition, the framebuffer size is used as overlay size, not display resolution. So a framebuffer != display. I believe DRM modesetting could be of help here, at least partially, but I haven't tried that approach yet. But DRM modesetting wouldn't solve all the problems. For example, we still need to configure overlays and overlay managers, and they don't quite belong to either the framebuffer side or the display side. Currently you configure them via a hackish sysfs interface, but I've been wondering if a /dev/omap-dss device with ioctls would be a better choice. There's currently no V4L2 support, but I have been thinking about that. I don't want to make any hardcoded configuration for those, because sometimes you want to use framebuffer devices for video overlays. So what I'd like to have is a way, compile time or run time, to configure which overlays go to framebuffer devices and which go to V4L2 devices. [Shah, Hardik] Hi Tomi, We are successful to bring up the basic functionality of the V4L2 driver onto your patches. We will be posting those patches in a day or two. Based on our V4L2 driver development we have few questions/suggestions on DSS patches you submitted. 1. Display enable function is returning false if the display is already enabled. Instead it should just return without error if display is already enabled as V4L2 and fbdev both may be enabling it without each other's knowledge. 2. Second display enable/disable should maintain the reference count as disabling of the display by one driver will leave other driver without display. 3. I think the row increment value should not be calculate inside the dispc.c file instead high level driver will pass the value it requires based on his buffer requirement and dispc.c should program it dumbly. This is mainly due to the odd row_inc_value requirement for the VRFB space. 4.There is API in dispc.c file to change pixel increment value. 5. We need separate API to enable the plane and enable the clocks. Oncethe clock is enabled driver can directly go and program registers through low level dispc APIs instead of dispc APIs enabling the clock for each register programming and then disabling it. This will avoid the enabling and disabling of the clocks for each frame displayed. As for V4L2 interface driver will enable planes and clocks during VIDIOC_STREAMON ioctls and during the streaming it will just change the buffer address for displaying frames. This way delaybetween the enabling/disabling of the clocks can also be saved. It would be driver's responsibility to enable the clocks before programmingany registers. Same may be true for setting the GO bit of the respective overlay managers. 6. We also need a public API to program the color conversion values. Some application may need to program it differently than standard values. Thanks and Regards, Hardik Shah Vaibhav Hiremath -- Tomi Valkeinen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize
RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Koen Kooi
Sent: Friday, November 14, 2008 5:09 PM
To: Hiremath, Vaibhav
Cc: [EMAIL PROTECTED]; linux-omap@vger.kernel.org
Subject: Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches
Op 14 nov 2008, om 07:32 heeft [EMAIL PROTECTED] het volgende geschreven:
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
+ if (system_rev OMAP3430_REV_ES1_0) {
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VPLL2_DEDICATED, TWL4030_VPLL2_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VPLL2_DEV_GRP, TWL4030_VPLL2_DEV_GRP);
+ }
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+ lcd_enabled = 1;
+ return 0;
+}
+
+static void panel_disable_lcd(struct omap_display *display)
+{
+ if (system_rev OMAP3430_REV_ES1_0) {
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x0,
+ TWL4030_VPLL2_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x0,
+ TWL4030_VPLL2_DEV_GRP);
+ }
+ omap_set_gpio_dataout(LCD_PANEL_ENABLE_GPIO, 1);
+ lcd_enabled = 0;
+}
system_rev() is now omap_rev(), you'll get a really green picture
without that change :)
I can confirm that the panel-sdp3430 works on the evm.
[Shah, Hardik] Hi panel-omap3evm.c is working fine. We tested that. And we
were getting the green picture. Thanks for pointing that out. We will change
this also in our next patch.
regards,
Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description
-Original Message- From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 5:01 PM To: Shah, Hardik Cc: Tomi Valkeinen; [EMAIL PROTECTED]; linux- [EMAIL PROTECTED] Subject: RE: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description Hi, On Mon, 10 Nov 2008, ext Shah, Hardik wrote: [Shah, Hardik] We have reviewed the patches in detail and even made modifications to make it work on the OMAP3EVM. Here are our observations: 1) The overall implementation is very much in line with our earlier proposal to provide generic API that supports both V4L2 and FBDEV. 2) The implementation supports multiple output interfaces e.g. RFBI, SDI, DSI, ... that we did not have in our plans 3) You have also validated it on lot many platforms that we do not have access. We believe patches are a good step in right direction. We plan to use this patchset as base for supporting these additional use cases: a) Adding the V4L2 user interface to the video pipelines (I believe video pipelines are natural fit for the V4L2 frame work. If use case is there for FBDEV interface we can have compile time option to expose the video pipelines as the either FBDEV or v4L2 interface). b) Modification of the DSS/DISPC library for supporting V4L2 user interface. c) Supporting the functionality like alpha blending, global alpha blending, setting of various TV standards etc. d) Supporting the mirroring and rotation in both FBDEV and V4L2 driver. Do let us know if you aren't already working on any of these. This sounds very good. I am not currently working on any of those items you mentioned. A couple of comments/thoughts about them: a) Yes, V4L2 interface would be nice. But there are use cases for FB devices also, and sometimes you don't want V4L2 devices at all. So as you suggested, a compile time option to select this is necessary. Or, better yet, a runtime option. One way to implement simultaneous FB and V4L2 devices is to have to separate drivers. But then this needs more locking support to DSS, and pobably some kind of event mechanism. For example, if both FB and V4L2 have overlays on the same display, and one of them changes the screen resolution, the other one needs to know about this also. So what I have been thinking is to have both FB and V4L2 in the same driver. This would make things easier. But then again, I don't know how much code V4L2 needs, and if the combined driver would get too complex. [Shah, Hardik] As long as the screen resolutions and timings are concerned, V4L2 driver will always take into account resolution before setting the format. Same is true for frame buffer driver before panning the display it should get the fscreen info and vscreen info and then start panning. While panning/streaming is going on any of the V4L2/FBDEV driver application has to take care of not changing the screen resolution/timing. b) Do you already have ideas what features V4L2 needs that are not present in DSS currently? [Shah, Hardik] We are working on that. We will be providing the comments on changes/modification in the DSS/DISPC in next two/three days. c) Yes, these would be nice. d) These would be nice also. About rotation, I think there are three kinds of rotation that are handled by different entities: - DMA rotation, for framebuffers in SRAM. Handled by DSS. - External framebuffer rotation, handled by the external framebuffer controller. - VRFB rotation. This is basically a memory handling configuration, and is transparent to the end user (in this case, DSS) of the memory. Should be handled by the entity that allocates the memory, ie. omapfb. [Shah, Hardik] so how are you planning to take care of rotation/mirroring. We have board that only supports VRFB rotation. Hardik Vaibhav Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description
-Original Message- From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2008 9:40 PM To: [EMAIL PROTECTED] Cc: linux-omap@vger.kernel.org Subject: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description New Display Subsystem for OMAP2/3 - This patch set implements new Display Subsystem (DSS) for OMAP2/3 processors. The DSS is still under work and these patches are for review. Note that there is also another new DSS implementation from TI. The DSS has been tested on OMAP3 SDP board, Beagle Board and on two unreleased boards with DSI and SDI displays. The DSS used to work on OMAP2 board also, but it's been a while since I was able to test with OMAP2 board. The first patch is a doc file that tries to explain a bit how the drivers work. The patch set is based on the current linux-omap tree. You can find the patches also from a git tree at http://www.bat.org/~tomba/git/linux-omap-dss.git/ Note that you also need two patches from Mans Rullgard to make things work. These are needed to be able to reconfigure DSS functional clock. http://git.mansr.com/?p=linux- omap;a=commit;h=e2de5e5578fbaa9b4b75074796da0608fc93e6ae http://git.mansr.com/?p=linux- omap;a=commit;h=2b7b958dc79e51127d7a4ecf88ce12dbc6c31426 Questions/problems -- Perhaps the biggest problems I have is the interface to user space. OMAP hardware doesn't quite fit in to the framebuffer framework. The problem is that a framebuffer can go to multiple overlays, and also the target display, to which a framebuffer goes, can change. In addition, the framebuffer size is used as overlay size, not display resolution. So a framebuffer != display. I believe DRM modesetting could be of help here, at least partially, but I haven't tried that approach yet. But DRM modesetting wouldn't solve all the problems. For example, we still need to configure overlays and overlay managers, and they don't quite belong to either the framebuffer side or the display side. Currently you configure them via a hackish sysfs interface, but I've been wondering if a /dev/omap-dss device with ioctls would be a better choice. There's currently no V4L2 support, but I have been thinking about that. I don't want to make any hardcoded configuration for those, because sometimes you want to use framebuffer devices for video overlays. So what I'd like to have is a way, compile time or run time, to configure which overlays go to framebuffer devices and which go to V4L2 devices. --- Tomi Valkeinen (9): DSS: support for OMAP3 SDP board DSS: support for Beagle Board DSS: Add generic DVI panel DSS: OMAPFB: fb driver for new display subsystem DSS: DSI support for OMAP2/3 DSS DSS: TV-out support for OMAP2/3 DSS DSS: RFBI support for OMAP2/3 DSS DSS: New display subsystem driver for OMAP2/3 DSS: Documentation for OMAP2/3 display subsystem [Shah, Hardik] We have reviewed the patches in detail and even made modifications to make it work on the OMAP3EVM. Here are our observations: 1) The overall implementation is very much in line with our earlier proposal to provide generic API that supports both V4L2 and FBDEV. 2) The implementation supports multiple output interfaces e.g. RFBI, SDI, DSI, ... that we did not have in our plans 3) You have also validated it on lot many platforms that we do not have access. We believe patches are a good step in right direction. We plan to use this patchset as base for supporting these additional use cases: a) Adding the V4L2 user interface to the video pipelines (I believe video pipelines are natural fit for the V4L2 frame work. If use case is there for FBDEV interface we can have compile time option to expose the video pipelines as the either FBDEV or v4L2 interface). b) Modification of the DSS/DISPC library for supporting V4L2 user interface. c) Supporting the functionality like alpha blending, global alpha blending, setting of various TV standards etc. d) Supporting the mirroring and rotation in both FBDEV and V4L2 driver. Do let us know if you aren't already working on any of these. BTW, patch for supporting omap3evm will be submitted shortly. Regards, Vaibhav Hiremath [EMAIL PROTECTED] Hardik Shah [EMAIL PROTECTED] -- Tomi Valkeinen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Linux-fbdev-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel -- To unsubscribe from this list: send the line unsubscribe
RE: [Linux-fbdev-devel] [PATCHv2 1/4] OMAP 2/3 DSS Library
-Original Message-
From: Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 25, 2008 12:43 AM
To: Shah, Hardik
Cc: linux-omap@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [Linux-fbdev-devel] [PATCHv2 1/4] OMAP 2/3 DSS Library
Hi,
* Hardik Shah [EMAIL PROTECTED] [081024 03:16]:
Cleaned up the DSS Library according to open source comments
Removed unused #ifdefs
Removed unused #defines
Minor cleanups done
Removed Architecture specific #ifdefs
Signed-off-by: Brijesh Jadav [EMAIL PROTECTED]
Hari Nagalla [EMAIL PROTECTED]
Hardik Shah [EMAIL PROTECTED]
Manjunath Hadli [EMAIL PROTECTED]
R Sivaraj [EMAIL PROTECTED]
Vaibhav Hiremath [EMAIL PROTECTED]
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap/Makefile|2 +-
arch/arm/plat-omap/include/mach/io.h |2 +-
arch/arm/plat-omap/include/mach/omap-dss.h | 921
arch/arm/plat-omap/omap-dss.c | 2248
5 files changed, 3178 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/omap-dss.h
create mode 100644 arch/arm/plat-omap/omap-dss.c
diff --git a/arch/arm/plat-omap/include/mach/io.h b/arch/arm/plat-
omap/include/mach/io.h
index ea55267..2495656 100644
--- a/arch/arm/plat-omap/include/mach/io.h
+++ b/arch/arm/plat-omap/include/mach/io.h
@@ -142,11 +142,11 @@
#define OMAP343X_SDRC_VIRT 0xFD00
#define OMAP343X_SDRC_SIZE SZ_1M
-
#define IO_OFFSET 0x9000
#define __IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L3 and L4 */
#define __OMAP2_IO_ADDRESS(pa) ((pa) + IO_OFFSET)/* Works for L3 and L4
*/
#define io_v2p(va) ((va) - IO_OFFSET)/* Works for L3 and L4 */
+#define io_p2v(pa) __IO_ADDRESS(pa)/* Works for L3 and L4 */
/* DSP */
#define DSP_MEM_34XX_PHYS OMAP34XX_DSP_MEM_BASE /* 0x5800 */
NAK for adding back io_p2v(). See below.
diff --git a/arch/arm/plat-omap/include/mach/omap-dss.h b/arch/arm/plat-
omap/include/mach/omap-dss.h
new file mode 100644
index 000..d9a33bd
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/omap-dss.h
@@ -0,0 +1,921 @@
+/*
+ * arch/arm/plat-omap/include/mach/omap-dss.h
+ *
+ * Copyright (C) 2004-2005 Texas Instruments.
+ * Copyright (C) 2006 Texas Instruments.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+
+ * Leveraged from original Linux 2.6 framebuffer driver for OMAP24xx
+ * Author: Andy Lowe ([EMAIL PROTECTED])
+ * Copyright (C) 2004 MontaVista Software, Inc.
+ *
+ */
+
+#ifndef__ASM_ARCH_OMAP_DISP_H
+#define__ASM_ARCH_OMAP_DISP_H
+
+/* 16 bit uses LDRH/STRH, base +/- offset_8 */
+typedef struct {
+ volatile u16 offset[256];
+} __regbase16;
+#define __REGV16(vaddr)(((__regbase16 *)((vaddr)~0xff)) \
+ -offset[((vaddr)0xff)1])
+#define __REG16(paddr) __REGV16(io_p2v(paddr))
+
+/* 8/32 bit uses LDR/STR, base +/- offset_12 */
+typedef struct {
+ volatile u8 offset[4096];
+} __regbase8;
+#define __REGV8(vaddr) (((__regbase8 *)((vaddr)~4095)) \
+ -offset[((vaddr)4095)0])
+#define __REG8(paddr) __REGV8(io_p2v(paddr))
+
+typedef struct {
+ volatile u32 offset[4096];
+} __regbase32;
+#define __REGV32(vaddr)(((__regbase32 *)((vaddr)~4095)) \
+ -offset[((vaddr)4095)2])
+#define __REG32(paddr) __REGV32(io_p2v(paddr))
+
NAK for adding back the __REG stuff. We've just spent quite a bit of
effort to remove these. The __REG stuff is not portable.
Please use ioremap and then __raw_read/write instead.
[Shah, Hardik] Hi Tony,
Please let me know if there are any other obvious issues you can see for
pushing onto git. I will clear this all the send you the final version for
pushing.
Regards,
Hardik
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAP 2/3 DSS Library and V4L2 Display Driver
Hi All, I will be posting the version 2 of the DSS library and V4L2 display driver with almost all the comments from the community taken care of. It will be series of 4 patches containing OMAP 2/3 DSS Library OMAP3 EVM TV encoder Driver. New IOCTLS added to V4L2 Framework (Already posted on V4L2 mailing list) OMAP 2/3 V4L2 Display driver on the Video planes of DSS hardware. We are enhancing the DSS library. This is the first post containing the features like power management, video pipeline, Digital overlay manager, clock management support. Further plan is to add graphics pipeline, LCD overlay manager, RFBI, DSI, support and frame buffer interface for graphics pipeline Please let us know your comments on further enhancements of the DSS Library and V4L2 display driver. Further discussions on DSS Library and V4L2 driver can be found at below threads. http://lists-archives.org/video4linux/24597-new-display-subsystem-for-omap2-3.html http://lists-archives.org/video4linux/24409-omap2-3-dss-library.html http://lists-archives.org/video4linux/24410-omap-2-3-v4l2-display-driver-on-video-planes.html http://lists-archives.org/video4linux/24600-omap-2-3-v4l2-display-driver-on-video-planes.html Thanks and Regards, Hardik Shah -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP 2/3 V4L2 display driver on video planes
-Original Message- From: Hans Verkuil [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2008 11:59 AM To: Shah, Hardik Cc: Mauro Carvalho Chehab; [EMAIL PROTECTED]; linux- [EMAIL PROTECTED]; [EMAIL PROTECTED]; Hadli, Manjunath Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes On Monday 06 October 2008 08:06:30 Shah, Hardik wrote: Hi, -Original Message- From: Mauro Carvalho Chehab [mailto:[EMAIL PROTECTED] Sent: Sunday, October 05, 2008 4:50 PM To: Shah, Hardik Cc: Hans Verkuil; [EMAIL PROTECTED]; linux-omap@vger.kernel.org; linux-fbdev- [EMAIL PROTECTED] Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes On Fri, 3 Oct 2008 20:10:36 +0530 Shah, Hardik [EMAIL PROTECTED] wrote: I don't like the idea of having private ioctls. This generally means that only a very restricted subset of userspace apps that are aware of the that API will work. This is really bad. So, I prefer to discuss the need for newer ioctls and add it into the standard whenever make some sense (ok, maybe you might have some ioctls that are really very specific for your app and that won't break userspace apps - I've acked with 2 private ioctls on uvc driver in the past due to that). [Shah, Hardik] Following are the custom IOCTLs used in the V4L2 display driver of DSS. 1. VIDIOC_S/G_OMAP2_MIRROR: This ioctl is used to enable the mirroring of the image. Hardware supports mirroring. As pointed out by Hans it will be better to move it to VIDIOC_S_CTRL ioctl. we can add the new control id for the mirroring. HFLIP and VFLIP user controls already exist. 2. VIDIOC_S/G_OMAP2_ROTATION: Rotation is used to enable the rotation of the image. This also can be moved to the VIDIOC_S_CTRL ioctl. Need to add new control id for the rotation also. A new standard user control can be added for this. 3. VIDIOC_S/G_OMAP2_LINK: This feature is software provided. OMAP DSS is having two video pipelines. Using this feature user can link the two video pipelines. This means the streaming of the video on one pipeline will be linked to the other pipeline with the same parameters as the original pipeline. Same image can be streamed on both the pipelines, one of the pipeline's output going to TV and other one to LCD. I believe this feature is very specific to OMAP, and should remain as the custom ioctl. I agree. 4. VIDIOC_S/G_OMAP2_COLORKEY: Color keying allows the pixels with the defined color on the video pipelines to be replaced with the pixels on the graphics pipelines. I believe similar feature must be available on almost all next generation of video hardware. We can add new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF ioctl is used for setting up the buffer parameters on per buffer basis. So IMHO this ioctl is not a natural fit for the above functionality. Please provide your comments on same. Do I understand correctly that if the color in the *video* streams matches the colorkey, then it is replaced by the color in the *framebuffer* (aka menu/overlay)? Usually it is the other way around: if the framebuffer (menu) has chromakey pixels, then those pixels are replaced by pixels from the video stream. That's what the current API does. 5. VIDIOC_S/G_OMAP2_BGCOLOR: This ioctl is used to set the Background color on either TV or LCD. It takes two inputs, first is the output device second is the color to be set. I think this can be added to the standard ioctl list but is it ok to have the output device as one of the parameters in the input structure? Instead we can set the background color for the current output. Setting the background color for the current output is the more logical choice. It would also be a nice addition for e.g. the ivtv driver where a similar functionality exists (currently unused). I assume that background color refers to the part of the display not covered by a menu or video? 6. VIDIOC_OMAP2_COLORKEY_ENABLE/DISABLE. This ioctl is used to enable or the disable the color keying feature described above. This can be added as the one of the control using VIDIOC_S_CTRL ioctl. Depends on the answer to 4). 7. VIDIOC_S/G_OMAP2_COLORCONV: This is a hardware feature. Video pipelines of the DSS are capable of getting the buffer in the YUV/UYVY format. But internally DSS operates on RGB format. So hardware has a capability to convert the YUV format to RGB format. This is done using the color conversion matrix in the hardware. It accepts the structure as input which has 9 unsigned short variables representing the coefficients for color conversion. I think this feature will also be present in many new devices. So we can have the standard ioctl for this. I think so too, it's pretty much a standard operation. 8. VIDIOC_S_OMAP2_DEFCOLORCONV: This ioctl just programs
RE: [PREVIEW] New display subsystem for OMAP2/3
-Original Message- From: Hiremath, Vaibhav Sent: Friday, October 03, 2008 7:46 PM To: Tony Lindgren; Tomi Valkeinen Cc: [EMAIL PROTECTED]; Shah, Hardik; linux-omap@vger.kernel.org; video4linux- [EMAIL PROTECTED] Subject: RE: [PREVIEW] New display subsystem for OMAP2/3 Thanks, Vaibhav Hiremath Senior Software Engg. Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -Original Message- From: Tony Lindgren [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2008 7:04 PM To: Tomi Valkeinen Cc: Hiremath, Vaibhav; [EMAIL PROTECTED]; Shah, Hardik; linux- [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PREVIEW] New display subsystem for OMAP2/3 * Tomi Valkeinen [EMAIL PROTECTED] [081003 16:26]: Hi, -Original Message- From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2008 1:55 PM To: Hiremath, Vaibhav Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux- [EMAIL PROTECTED] Subject: RE: [PREVIEW] New display subsystem for OMAP2/3 Hi Vaibhav, On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote: Tomi, Have you got a chance to review the DSS library and V4l2 driver which we have posted? Unfortunately not very much. I've been glancing the DSS side of the driver, but not the v4l side as I don't know much about it. There seems to be awfully lot ifdefs for board/cpu types in the code. As far as ifdefs are concerned, they are added to take care of OMAP2/3 variants. Especially you will find many instances of CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't have VENC. As I have mentioned before, DSS library is designed to support both LCD, TV, and many more. They make the code unclear. I have divided the functionality to separate files, that can easily be left out. So for OMAP3410 I would just disable the VENC config option. And then I can test for CONFIG_DSS_VENC, instead of OMAP3410 || OMAP2410 || OMAPwhatnot. Of course you can't do this for all things, but at least VENC is not one of these. And all board specific code should, in my opinion, be in board files. I don't have any board specific definitions in the DSS driver or the LCD/controller drivers. (well, ok, there is something in the DSI driver, it's still quite raw). Yeah we should be able to compile in any combination of omap boards with whatever configuration from board-*.c files as platform_data. So ifdefs will totally break this. Point taken, we will try to avoid ifdefs as much as possible and will divide depending on the functionality. My biased and superficial view of the differences between my DSS and yours is that: Tomi, here I differ from you. There should not be biased opinion. What we are looking here is a good design which will fulfill all our requirements/use case, like LCD, DVI, HDMI and TV for us and DSI, RFBI for you. Agreed. I was just pointing out that I haven't used enough time to study your DSS to really comment on it, and that a coder tends to like his own code =). - My implementation is cleaner, better organized and more generic Again, here both of us will be having biased comments to support our own design, so I would prefer not to comment on this. Lets people on the community decide whose design is better. - My implementation has support for DSI, SDI, RFBI, L4 updates DSI, SDI and RFBI are the modes, which we can add anytime to the system depending as per our requirement. It is again driven by use case; you have use cases for DSI, SDI and RFBI. We have for TV, DVI, HDMI and LCD, so we strongly concentrated on these. We can very well add these supports to DSS Library with minimal effort. SDI is quite easy, but I wouldn't say adding RFBI and DSI is minimal effort. DSI is quite complex in itself, and the manual update mode changes how the DSS has to handle things. - Your implementation has better support for extra things like VRFB, color conversions, alpha etc. - Your implementation most likely has better power management support. - And of course what is most visible to the user, my version uses only framebuffers, and yours uses also v4l2 devices. You really can't deny the V4L2 framework advantages over framebuffer, especially for streaming kind of applications. Looking towards the hardware features OMAP supports; we would really require to have such support/capabilities. Community is also in agreement for the V4L2 interface on OMAP-DSS. Well, I'm not the best one to comment on V4L2 as I don't know much about it. But I remember seeing quite negative comments about V4L2 a while ago in this or related mail thread, so I'm not yet ready
RE: [PATCH] OMAP 2/3 V4L2 display driver on video planes
Hi, -Original Message- From: Mauro Carvalho Chehab [mailto:[EMAIL PROTECTED] Sent: Sunday, October 05, 2008 4:50 PM To: Shah, Hardik Cc: Hans Verkuil; [EMAIL PROTECTED]; linux-omap@vger.kernel.org; linux-fbdev- [EMAIL PROTECTED] Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes On Fri, 3 Oct 2008 20:10:36 +0530 Shah, Hardik [EMAIL PROTECTED] wrote: I don't like the idea of having private ioctls. This generally means that only a very restricted subset of userspace apps that are aware of the that API will work. This is really bad. So, I prefer to discuss the need for newer ioctls and add it into the standard whenever make some sense (ok, maybe you might have some ioctls that are really very specific for your app and that won't break userspace apps - I've acked with 2 private ioctls on uvc driver in the past due to that). [Shah, Hardik] Following are the custom IOCTLs used in the V4L2 display driver of DSS. 1. VIDIOC_S/G_OMAP2_MIRROR: This ioctl is used to enable the mirroring of the image. Hardware supports mirroring. As pointed out by Hans it will be better to move it to VIDIOC_S_CTRL ioctl. we can add the new control id for the mirroring. 2. VIDIOC_S/G_OMAP2_ROTATION: Rotation is used to enable the rotation of the image. This also can be moved to the VIDIOC_S_CTRL ioctl. Need to add new control id for the rotation also. 3. VIDIOC_S/G_OMAP2_LINK: This feature is software provided. OMAP DSS is having two video pipelines. Using this feature user can link the two video pipelines. This means the streaming of the video on one pipeline will be linked to the other pipeline with the same parameters as the original pipeline. Same image can be streamed on both the pipelines, one of the pipeline's output going to TV and other one to LCD. I believe this feature is very specific to OMAP, and should remain as the custom ioctl. 4. VIDIOC_S/G_OMAP2_COLORKEY: Color keying allows the pixels with the defined color on the video pipelines to be replaced with the pixels on the graphics pipelines. I believe similar feature must be available on almost all next generation of video hardware. We can add new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF ioctl is used for setting up the buffer parameters on per buffer basis. So IMHO this ioctl is not a natural fit for the above functionality. Please provide your comments on same. 5. VIDIOC_S/G_OMAP2_BGCOLOR: This ioctl is used to set the Background color on either TV or LCD. It takes two inputs, first is the output device second is the color to be set. I think this can be added to the standard ioctl list but is it ok to have the output device as one of the parameters in the input structure? Instead we can set the background color for the current output. 6. VIDIOC_OMAP2_COLORKEY_ENABLE/DISABLE. This ioctl is used to enable or the disable the color keying feature described above. This can be added as the one of the control using VIDIOC_S_CTRL ioctl. 7. VIDIOC_S/G_OMAP2_COLORCONV: This is a hardware feature. Video pipelines of the DSS are capable of getting the buffer in the YUV/UYVY format. But internally DSS operates on RGB format. So hardware has a capability to convert the YUV format to RGB format. This is done using the color conversion matrix in the hardware. It accepts the structure as input which has 9 unsigned short variables representing the coefficients for color conversion. I think this feature will also be present in many new devices. So we can have the standard ioctl for this. 8. VIDIOC_S_OMAP2_DEFCOLORCONV: This ioctl just programs the default color conversion matrix defined by the driver. This we can have as one of the controls using VIDIOC_S_CTRL ioctl. Please let me know your view/thoughts on above custom ioctls added in the driver. So, if you are having several points where you're violating the rule, probably your code is very complex or you are using long names instead of short ones. On the fisrt case, try to break the complex stuff into smaller and simpler static functions. The compiler will deal with those functions like inline, so this won't cost cpu cycles, but it will make easier for people to understand what you're doing. [Shah, Hardik] I will revisit the code and structure it properly. Perhaps the better would be for you to have one public machine where you all can work and merge your work. I'm OK on pulling and seeing patches outside LinuxTV. [Shah, Hardik] we are in process of coordinating this. One option in the future is to base your work on a git tree. I've changed a lot the proccess of submitting patches upstream, to avoid having to rebase my tree (Yet, I had to do two rebases during 2.6.27 cycle). If I can keep my tree without rebase, the developers may rely on it and start sending me git pull requests also. Let's see if I can do this for 2.6.28. I think we should start discussing
RE: [PATCH] OMAP 2/3 V4L2 display driver on video planes
Hi, -Original Message- From: Hans Verkuil [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2008 11:59 AM To: Shah, Hardik Cc: Mauro Carvalho Chehab; [EMAIL PROTECTED]; linux-omap@vger.kernel.org; linux-fbdev- [EMAIL PROTECTED]; Hadli, Manjunath Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes On Monday 06 October 2008 08:06:30 Shah, Hardik wrote: Hi, -Original Message- From: Mauro Carvalho Chehab [mailto:[EMAIL PROTECTED] Sent: Sunday, October 05, 2008 4:50 PM To: Shah, Hardik Cc: Hans Verkuil; [EMAIL PROTECTED]; linux-omap@vger.kernel.org; linux-fbdev- [EMAIL PROTECTED] Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes On Fri, 3 Oct 2008 20:10:36 +0530 Shah, Hardik [EMAIL PROTECTED] wrote: I don't like the idea of having private ioctls. This generally means that only a very restricted subset of userspace apps that are aware of the that API will work. This is really bad. So, I prefer to discuss the need for newer ioctls and add it into the standard whenever make some sense (ok, maybe you might have some ioctls that are really very specific for your app and that won't break userspace apps - I've acked with 2 private ioctls on uvc driver in the past due to that). [Shah, Hardik] Following are the custom IOCTLs used in the V4L2 display driver of DSS. 1. VIDIOC_S/G_OMAP2_MIRROR: This ioctl is used to enable the mirroring of the image. Hardware supports mirroring. As pointed out by Hans it will be better to move it to VIDIOC_S_CTRL ioctl. we can add the new control id for the mirroring. HFLIP and VFLIP user controls already exist. 2. VIDIOC_S/G_OMAP2_ROTATION: Rotation is used to enable the rotation of the image. This also can be moved to the VIDIOC_S_CTRL ioctl. Need to add new control id for the rotation also. A new standard user control can be added for this. 3. VIDIOC_S/G_OMAP2_LINK: This feature is software provided. OMAP DSS is having two video pipelines. Using this feature user can link the two video pipelines. This means the streaming of the video on one pipeline will be linked to the other pipeline with the same parameters as the original pipeline. Same image can be streamed on both the pipelines, one of the pipeline's output going to TV and other one to LCD. I believe this feature is very specific to OMAP, and should remain as the custom ioctl. I agree. 4. VIDIOC_S/G_OMAP2_COLORKEY: Color keying allows the pixels with the defined color on the video pipelines to be replaced with the pixels on the graphics pipelines. I believe similar feature must be available on almost all next generation of video hardware. We can add new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF ioctl is used for setting up the buffer parameters on per buffer basis. So IMHO this ioctl is not a natural fit for the above functionality. Please provide your comments on same. Do I understand correctly that if the color in the *video* streams matches the colorkey, then it is replaced by the color in the *framebuffer* (aka menu/overlay)? Usually it is the other way around: if the framebuffer (menu) has chromakey pixels, then those pixels are replaced by pixels from the video stream. That's what the current API does [Shah, Hardik] This is a hardware provided feature. It can be both ways as hardware supports both the features. It means replacing the graphics pipelines pixels with video pipeline pixels and other way is also true. When both graphics and video pipelines are going to the same output device and when the colorkeying is enabled then the pixels of the video pipelines of specific color are replaced by the pixels of the graphics pipeline. This is done automatically done by the overlay manager aka compositor. Graphics pipeline can be controlled by frame buffer interface or V4L2 interface. In driver we only need to enable the color keying and state that whether it is a source color keying or destination color keying along with the color code. 5. VIDIOC_S/G_OMAP2_BGCOLOR: This ioctl is used to set the Background color on either TV or LCD. It takes two inputs, first is the output device second is the color to be set. I think this can be added to the standard ioctl list but is it ok to have the output device as one of the parameters in the input structure? Instead we can set the background color for the current output. Setting the background color for the current output is the more logical choice. It would also be a nice addition for e.g. the ivtv driver where a similar functionality exists (currently unused). I assume that background color refers to the part of the display not covered by a menu or video? [Shah, Hardik] Yes background color refers to the whole display screen. Its not covered by menu or video. 6. VIDIOC_OMAP2_COLORKEY_ENABLE/DISABLE. This ioctl
RE: [PATCH] OMAP 2/3 V4L2 display driver on video planes
-Original Message- From: Hans Verkuil [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2008 8:04 PM To: [EMAIL PROTECTED] Cc: Shah, Hardik; linux-omap@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes On Wednesday 17 September 2008 17:05:42 Hardik Shah wrote: From: Vaibhav Hiremath [EMAIL PROTECTED] OMAP 2/3 V4L2 display driver sits on top of DSS library and uses TV overlay and 2 video pipelines (video1 and video2) to display image on TV. It exposes 2 V4L2 nodes for user interface. It supports standard V4L2 ioctls. Signed-off-by: Brijesh Jadav [EMAIL PROTECTED] Hari Nagalla [EMAIL PROTECTED] Hardik Shah [EMAIL PROTECTED] Manju Hadli [EMAIL PROTECTED] R Sivaraj [EMAIL PROTECTED] Vaibhav Hiremath [EMAIL PROTECTED] I've taken a quick look and I have a two main comments: 1) Please use video_ioctl2 rather than setting up your own ioctl callback. New drivers should use it. 2) Can you describe what the non-standard v4l2 ioctls are used for? I suspect that some of these can be done differently. Something like a chromakey is already available in v4l2 (through VIDIOC_G/S_FBUF and VIDIOC_G/S_FMT), things like mirror is available as a control, and rotation should perhaps be a control as well. Ditto for background color. These are just ideas, it depends on how it is used exactly. [Shah, Hardik] Hans I will revisit the code and will provide you with the sufficient information. 3) Some of the lines are broken up rather badly probably to respect the 80 column maximum. Note that the 80 column maximum is a recommendation, and that readability is more important. So IMHO it's better to have a slightly longer line and break it up at a more logical place. However, switching to video_ioctl2 will automatically reduce the indentation, so this might not be that much of an issue anymore. [Shah, Hardik] 80 column was implemented to make the checkpatch pass. Point noted and will take care of this. It is possible to setup a mercurial repository on linuxtv.org? I thought that Manju has an account by now. This is useful as well for all the other omap camera patches. I've seen omap patches popping up all over the place for the past six months (if not longer) but it needs to be a bit more organized if you want it to be merged. Setting up v4l-dvb repositories containing the new patches is a good way of streamlining the process. Obviously the process is more complicated for you since the omap stuff relies on various subsystems and platform code. Perhaps someone within TI should be coordinating this? [Shah, Hardik] we are in process of coordinating this. Regards, Hans --- drivers/media/video/Kconfig | 10 +- drivers/media/video/Makefile|2 + drivers/media/video/omap/Kconfig| 12 + drivers/media/video/omap/Makefile |2 + drivers/media/video/omap/omap_vout.c| 3524 +++ drivers/media/video/omap/omap_voutdef.h | 196 ++ drivers/media/video/omap/omap_voutlib.c | 283 +++ drivers/media/video/omap/omap_voutlib.h | 34 + include/linux/omap_vout.h | 60 + 9 files changed, 4121 insertions(+), 2 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout.c create mode 100644 drivers/media/video/omap/omap_voutdef.h create mode 100644 drivers/media/video/omap/omap_voutlib.c create mode 100644 drivers/media/video/omap/omap_voutlib.h create mode 100644 include/linux/omap_vout.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] OMAP3 Display Driver (V4L2)
RFC- High level design for pushing the V4L2 driver based on TI Soc. Hardware Background == DSS (Display Sub System) IP on the OMAP3 SoC of TI provides a logic to display a video frame from the memory frame buffer on a liquid crystal display (LCD) panel or a TV set. It includes two video pipelines and one graphic pipeline. It also includes two overlay managers for compositing the pictures from different pipelines. Below is the high level block diagram of the DSS IP and its capabilities on OMAP3 video1 pipeline --|---compositor 0--|---TV encoder|---S Video, composite outputs video2 pipeline --| graphic pipeline --|---compositor 1--|---LCD Note: Output of all the pipelines can go to any of the compositors. High level design of the OMAP3 SoC can be found at http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12643contentId=14649 Frame buffer driver is already there on the GIT controlling the graphic pipeline. This is the initial proposal to push the V4L2 display driver onto GIT for controlling the video pipelines. This will be done in different phases. Proposal As shown in the block diagram compositor number 0 connected to TV will be controlled by the V4L2 driver and compositor number 1 connected to LCD will be controlled by FBDEV driver. FBDEV driver implementation controlling the graphics pipeline is already there on GIT tree. V4L2 driver controlling the video pipelines needs to be pushed. Below is the software implementation block diagram for the above hardware block diagram. /dev/video0--|video1 pipeline--|---compositor 0--|---TV encoder /dev/video1--|video2 pipeline--| Below implementation is already there on GIT tree. /dev/fb0--|graphics pipeline--|---compositor 1--|---LCD As there is a single compositor between both the video pipelines there will be some coherency issues like changing the standard on one pipeline will affect the standard on other one. omap2_dss.c functional layer will maintain the coherency between two pipelines for the common hardware like compositor. Future enhancement is targeted to use both FBDEV and V4L2 drivers using both the compositors and all the functional level code is in omap2_dss.c and omap2_venc.c file, so we want omap2_dss.c and omap2_venc.c files to be placed in architecture directory (arch/arm/plat-omap/). Future enhancements will also cover all the existing functionality provided by FBDEV driver like RFBI etc. Since both the driver frame work is different and compositors will be shared by both (FBDEV and V4L2 drivers) in future enhancements. There should be some way of central entity for controlling the compositors. Comments are welcomed on this design issue. High Level Design. === Following are the files consisting the TI V4L2 driver. /arch/arm/plat-omap/omap2_dss.c === This is a functional layer for the DSS hardware. It mainly has functions like configuring the video pipelines, starting the streaming on video pipelines, setting the color conversion etc. /arch/arm/plat-omap/omap2_venc.c = It is a functional layer for the video encoder. In DSS the encoder is inside the IP. This file mainly deals with configuration of the encoder registers according to the TV standard selected. For on-board encoders (off-chip) encoder specific file will be in board directory. /drivers/media/video/omap/omap2_display.c == This is a core V4L2 driver file. It registers two video pipelines with the V4L2 frame work. It also implements the necessary ioctls supported by the V4L2. It also implements some of the custom ioctls not supported by V4L2 framework but hardware supports it. /drivers/media/video/omap/omap2_lib.c === This is a library file for the V4L2 driver. DSS provides some of the functionalities like cropping, window size and window position. This library file helps in setting all the parameters depending upon the crop window and display window selected. DSS also supports on the fly scaling so it also calculates the vertical and horizontal scaling factor depending upon the display and crop window selected. Thanks and Regards, Hardik Shah -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
