RE: [PATCH v17 00/13] davinci vpbe: dm6446 v4l2 driver
Sekhar, Kevin, These patches have gone through considerable reviews. Could you please ACK from your end? Thanks and Regards, -Manju On Tue, Mar 15, 2011 at 19:26:28, Hadli, Manjunath wrote: version17: The more important among the patch history from previous comments 1. Replacing _raw_readl() with readl(). 2. Removal of platform resource overlap. 3. Removal of unused macros. 4. Fixing the module params typo. 5. Minor changes in the GPL licensing header. 6. Removed the initializer for field inversion parameter. 7. Changing the Field inversion #ifdef to platform based implementation. 8. Interchanged platform and board specific patches due to dependencies. Manjunath Hadli (13): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe davinci: move DM64XX_VDD3P3V_PWDN to devices.c davinci: eliminate use of IO_ADDRESS() on sysmod davinci: dm644x: Replace register base value with a defined macro davinci: dm644x: change vpfe capture structure variables for consistency davinci: dm644x: move vpfe init from soc to board specific files davinci: dm644x: add support for v4l2 video display davinci: dm644x EVM: add support for VPBE display Documentation/video4linux/README.davinci-vpbe | 93 ++ arch/arm/mach-davinci/board-dm644x-evm.c | 131 ++- arch/arm/mach-davinci/devices.c | 24 +- arch/arm/mach-davinci/dm355.c |1 + arch/arm/mach-davinci/dm365.c |1 + arch/arm/mach-davinci/dm644x.c| 172 ++- arch/arm/mach-davinci/dm646x.c|1 + arch/arm/mach-davinci/include/mach/dm644x.h |7 +- arch/arm/mach-davinci/include/mach/hardware.h |7 +- drivers/media/video/davinci/Kconfig | 22 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 826 ++ drivers/media/video/davinci/vpbe_display.c| 2084 + drivers/media/video/davinci/vpbe_osd.c| 1216 ++ drivers/media/video/davinci/vpbe_osd_regs.h | 364 + drivers/media/video/davinci/vpbe_venc.c | 556 +++ drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ include/media/davinci/vpbe.h | 185 +++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 + include/media/davinci/vpbe_types.h| 91 ++ include/media/davinci/vpbe_venc.h | 41 + 22 files changed, 6500 insertions(+), 44 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- 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
[RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls
Hello, This is third version of RFC patch series about adding auto focus mode and controls. The patch of the previous version bring about the issue to be able to execute only once, not repeatedly. Because the each modes are defined by menu type. To solve this, we add the new control of choosing focus mode, and if doing repeatedly, it's alright that you determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO. In the case of new added rectangle mode, these each controls belongs to 4 new controls, can make to point by the form of rectangle. These 4 new each control values mean left x coordinate, top y coordinate, width x length, height y length. It's similar to structure v4l2_rect. You can find previous threads about this: http://www.spinics.net/lists/linux-media/msg29446.html Thanks and Regards, Heungjun Kim -- 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
[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus
It supports various modes of auto focus. Each modes define as the enumerations
of menu type.
V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE
In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.
V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
Signed-off-by: Kim, Heungjun riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ctrls.c | 16
include/linux/videodev2.h| 13 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Aperture Priority Mode,
NULL
};
+ static const char * const camera_focus_auto_mode[] = {
+ Normal Mode,
+ Macro Mode,
+ Continuous Mode,
+ Face Detection Mode,
+ Rectangle Mode,
+ NULL
+ };
static const char * const colorfx[] = {
None,
Black White,
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO_MODE:
+ return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return Privacy;
case V4L2_CID_IRIS_ABSOLUTE:return Iris, Absolute;
case V4L2_CID_IRIS_RELATIVE:return Iris, Relative;
+ case V4L2_CID_FOCUS_AUTO_MODE: return Focus, Mode;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return Focus, Rectangle Left;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return Focus, Rectangle Top;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return Focus, Rectangle
Width;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return Focus, Rectangle
Height;
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_FOCUS_AUTO_MODE (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum v4l2_focus_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT (V4L2_CID_CAMERA_CLASS_BASE+23)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 2/2] v4l2-ctrls: update auto focus mode documentation
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/DocBook/v4l/controls.xml| 67 +
Documentation/DocBook/v4l/videodev2.h.xml |8 +++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..b940e21 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1860,6 +1860,73 @@ it one step further. This is a write-only
control./entry
/row
rowentry/entry/row
+ row id=v4l2-focus-auto-mode-type
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_MODE/constantnbsp;/entry
+ entryenumnbsp;v4l2_focus_auto_mode_type/entry
+ /rowrowentry spanname=descrEnables setting modes of
+auto focus. The focus has 5 kinds of mode, and each enumerations express
+current auto focus mode in which the camera is. In the case of
+V4L2_FOCUS_AUTO_RECTANGLE, this control id can be clustered with
+4 control id which means focusing spot expressed by 4 point of rectangle.
+ /entry
+ /row
+ row
+ entrytbl spanname=descr cols=2
+ tbody valign=top
+ row
+
entryconstantV4L2_FOCUS_AUTO_NORMAL/constantnbsp;/entry
+ entryNormal mode Auto focus, single shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_MACRO/constantnbsp;/entry
+ entryMacro mode Auto focus, single shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_CONTINUOUS/constantnbsp;/entry
+ entryContinuous mode Auto focus, continuous shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_FACE_DETECTION/constantnbsp;/entry
+ entryFace detection mode Auto focus, single shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_RECTANGLE/constantnbsp;/entry
+ entryRectangle mode Auto focus, single shot./entry
+ /row
+ /tbody
+ /entrytbl
+ /row
+ rowentry/entry/row
+
+ row
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the left
+side's point of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_TOP/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the top
+side's point of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the width
+length of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the height
+length of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
row
entry
spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry
entryboolean/entry
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2..6bb67a6 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1385,6 +1385,14 @@ enum link
linkend=v4l2-exposure-auto-typev4l2_exposure_auto_type/link {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+enum link
linkend=v4l2-focus-auto-mode-typev4l2_focus_auto_mode_type/link {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
Re: [RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls
The comments of 2/2 patch are wrong. It's my fault. Please ignore this. And I'll send again. Sorry to confuse. 2011-03-22 오후 5:34, Kim, HeungJun 쓴 글: Hello, This is third version of RFC patch series about adding auto focus mode and controls. The patch of the previous version bring about the issue to be able to execute only once, not repeatedly. Because the each modes are defined by menu type. To solve this, we add the new control of choosing focus mode, and if doing repeatedly, it's alright that you determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO. In the case of new added rectangle mode, these each controls belongs to 4 new controls, can make to point by the form of rectangle. These 4 new each control values mean left x coordinate, top y coordinate, width x length, height y length. It's similar to structure v4l2_rect. You can find previous threads about this: http://www.spinics.net/lists/linux-media/msg29446.html Thanks and Regards, Heungjun Kim -- 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 -- 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
[RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls
Hello, This is third version of RFC patch series about adding auto focus mode and controls. The patch of the previous version bring about the issue to be able to execute only once, not repeatedly. Because the each modes are defined by menu type. To solve this, we add the new control of choosing focus mode, and if doing repeatedly, it's alright that you determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO. In the case of new added rectangle mode, these each controls belongs to 4 new controls, can make to point by the form of rectangle. These 4 new each control values mean left x coordinate, top y coordinate, width x length, height y length. It's similar to structure v4l2_rect. You can find previous threads about this: http://www.spinics.net/lists/linux-media/msg29446.html Thanks and Regards, Heungjun Kim -- 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
[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus
It supports various modes of auto focus. Each modes define as the enumerations
of menu type.
V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE
In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.
V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
Signed-off-by: Kim, Heungjun riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ctrls.c | 16
include/linux/videodev2.h| 13 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Aperture Priority Mode,
NULL
};
+ static const char * const camera_focus_auto_mode[] = {
+ Normal Mode,
+ Macro Mode,
+ Continuous Mode,
+ Face Detection Mode,
+ Rectangle Mode,
+ NULL
+ };
static const char * const colorfx[] = {
None,
Black White,
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO_MODE:
+ return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return Privacy;
case V4L2_CID_IRIS_ABSOLUTE:return Iris, Absolute;
case V4L2_CID_IRIS_RELATIVE:return Iris, Relative;
+ case V4L2_CID_FOCUS_AUTO_MODE: return Focus, Mode;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return Focus, Rectangle Left;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return Focus, Rectangle Top;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return Focus, Rectangle
Width;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return Focus, Rectangle
Height;
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_FOCUS_AUTO_MODE (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum v4l2_focus_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT (V4L2_CID_CAMERA_CLASS_BASE+23)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus
It supports various modes of auto focus. Each modes define as the enumerations
of menu type.
V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE
In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.
V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
Signed-off-by: Kim, Heungjun riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ctrls.c | 16
include/linux/videodev2.h| 13 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Aperture Priority Mode,
NULL
};
+ static const char * const camera_focus_auto_mode[] = {
+ Normal Mode,
+ Macro Mode,
+ Continuous Mode,
+ Face Detection Mode,
+ Rectangle Mode,
+ NULL
+ };
static const char * const colorfx[] = {
None,
Black White,
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO_MODE:
+ return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return Privacy;
case V4L2_CID_IRIS_ABSOLUTE:return Iris, Absolute;
case V4L2_CID_IRIS_RELATIVE:return Iris, Relative;
+ case V4L2_CID_FOCUS_AUTO_MODE: return Focus, Mode;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return Focus, Rectangle Left;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return Focus, Rectangle Top;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return Focus, Rectangle
Width;
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return Focus, Rectangle
Height;
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_FOCUS_AUTO_MODE (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum v4l2_focus_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT (V4L2_CID_CAMERA_CLASS_BASE+23)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 2/2] v4l2-ctrls: update auto focus mode documentation
Document about the mode of auto focus and new controls about rectangle auto
focus
Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/DocBook/v4l/controls.xml| 67 +
Documentation/DocBook/v4l/videodev2.h.xml |8 +++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..b940e21 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1860,6 +1860,73 @@ it one step further. This is a write-only
control./entry
/row
rowentry/entry/row
+ row id=v4l2-focus-auto-mode-type
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_MODE/constantnbsp;/entry
+ entryenumnbsp;v4l2_focus_auto_mode_type/entry
+ /rowrowentry spanname=descrEnables setting modes of
+auto focus. The focus has 5 kinds of mode, and each enumerations express
+current auto focus mode in which the camera is. In the case of
+V4L2_FOCUS_AUTO_RECTANGLE, this control id can be clustered with
+4 control id which means focusing spot expressed by 4 point of rectangle.
+ /entry
+ /row
+ row
+ entrytbl spanname=descr cols=2
+ tbody valign=top
+ row
+
entryconstantV4L2_FOCUS_AUTO_NORMAL/constantnbsp;/entry
+ entryNormal mode Auto focus, single shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_MACRO/constantnbsp;/entry
+ entryMacro mode Auto focus, single shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_CONTINUOUS/constantnbsp;/entry
+ entryContinuous mode Auto focus, continuous shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_FACE_DETECTION/constantnbsp;/entry
+ entryFace detection mode Auto focus, single shot./entry
+ /row
+ row
+
entryconstantV4L2_FOCUS_AUTO_RECTANGLE/constantnbsp;/entry
+ entryRectangle mode Auto focus, single shot./entry
+ /row
+ /tbody
+ /entrytbl
+ /row
+ rowentry/entry/row
+
+ row
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the left
+side's point of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_TOP/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the top
+side's point of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the width
+length of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
+ entry
spanname=idconstantV4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control means the height
+length of the rectangle expressing focusing spot./entry
+ /row
+ rowentry/entry/row
+
row
entry
spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry
entryboolean/entry
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2..6bb67a6 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1385,6 +1385,14 @@ enum link
linkend=v4l2-exposure-auto-typev4l2_exposure_auto_type/link {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+enum link
linkend=v4l2-focus-auto-mode-typev4l2_focus_auto_mode_type/link {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
Em 04-03-2011 20:11, Andrew de Quincey escreveu:
On 4 March 2011 22:59, Antti Palosaari cr...@iki.fi wrote:
On 03/05/2011 12:44 AM, Andrew de Quincey wrote:
Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner
accesses will take multiple i2c transactions.
Therefore, the following patch overrides the dvb_frontend_ops
functions to add a per-device lock around them: only one frontend can
now use the i2c bus at a time. Testing with the scripts above shows
this has eliminated the errors.
This have annoyed me too, but since it does not broken functionality much
I
haven't put much effort for fixing it. I like that fix since it is in
AF9015
driver where it logically belongs to. But it looks still rather complex.
I
see you have also considered bus lock to af9015_i2c_xfer() which could
be
much smaller in code size (that's I have tried to implement long time
back).
I would like to ask if it possible to check I2C gate open / close inside
af9015_i2c_xfer() and lock according that? Something like:
Hmm, I did think about that, but I felt overriding the functions was
just cleaner: I felt it was more obvious what it was doing. Doing
exactly this sort of tweaking was one of the main reasons we added
that function overriding feature.
I don't like the idea of returning error locked by FE since that'll
mean the tuning will randomly fail sometimes in a way visible to
userspace (unless we change the core dvb_frontend code), which was one
of the things I was trying to avoid. Unless, of course, I've
misunderstood your proposal.
Not returning error, but waiting in lock like that:
if (mutex_lock_interruptible(d-i2c_mutex) 0)
return -EAGAIN;
Ah k, sorry
However, looking at the code again, I realise it is possible to
simplify it. Since its only the demod gates that cause a problem, we
only /actually/ need to lock the get_frontend() and set_frontend()
calls.
I don't understand why .get_frontend() causes problem, since it does not
access tuner at all. It only reads demod registers. The main problem is
(like schema in af9015.c shows) that there is two tuners on same I2C bus
using same address. And demod gate is only way to open access for desired
tuner only.
AFAIR /some/ tuner code accesses the tuner hardware to read the exact
tuned frequency back on a get_frontend(); was just being extra
paranoid :)
You should block traffic based of tuner not demod. And I think those
callbacks which are needed for override are tuner driver callbacks. Consider
situation device goes it v4l-core calls same time both tuner .sleep() ==
problem.
Hmm, yeah, you're right, let me have another look tomorrow.
Andrew, Antti,
I'm understanding that I should wait for another patch on this subject, right?
Please let me know when you have a patch ready for me to apply.
Btw, I think that the long term solution would be, instead, to provide some
sort of
resource locking inside DVB (and V4L) core. I have here 3 devices not supported
yet that
uses the same tuner (and the same demod - DRX-K) for both DVB-C and DVB-T. It
would
be a way better to use some core-provided solution to prevent that both DVB-C
and DVB-T
would be used at the same time on such devices, instead of cloning the same code
(or modified versions on it) on each driver that have such issues.
One solution could be to have a callback like:
enum dvb_fe_lock_type {
ATV_DEMOD_LOCK,
DTV_DEMOD_T_LOCK,
DTV_DEMOD_S_LOCK,
DTV_DEMOD_C_LOCK,
TUNER_T_LOCK,
TUNER_S_LOCK,
TUNER_C_LOCK,
TUNER_FM_LOCK,
FM_DEMOD_LOCK,
};
/**
* dvb_fe_lock - locks a frontend resource
* @fe: DVB frontend struct
* @type: type of resource to lock
* @lock: true indicates to lock the resource, false to unlock
*
* Returns true if the resource was locked, false otherwise.
* routine may wait for a pending transaction to happen before returning.
*/
bool (*dvb_fe_lock)(struct dvb_frontend *fe, enum dvb_fe_lock_type type, bool
lock);
What do you think?
Thanks,
Mauro.
--
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
Re: [GIT PATCHES FOR 2.6.39] Make the UVC API public (and bug fixes)
Hi Mauro,
Thanks for the review.
On Monday 21 March 2011 20:39:17 Mauro Carvalho Chehab wrote:
Em 27-02-2011 14:36, Laurent Pinchart escreveu:
Hi Mauro,
These patches move the uvcvideo.h header file from
drivers/media/video/uvc to include/linux, making the UVC API public.
Martin Rubli has committed support for the public API to libwebcam, so
userspace support is up to date.
The following changes since commit
9e650fdb12171a5a5839152863eaab9426984317:
[media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM
driver (2011-02-27 07:50:42 -0300)
are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
Laurent Pinchart (6):
uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
There are some places there saying that the removal will happen at 2.6.39.
I'll fix that.
uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
uvcvideo: Include linux/types.h in uvcvideo.h
uvcvideo: Move uvcvideo.h to include/linux
-'U'00-0F drivers/media/video/uvc/uvcvideo.h conflict!
+'U'00-0F linux/uvcvideo.hconflict!
Please avoid conflicts at userspace API's.
The uvcvideo driver already uses 'U'. I can change it, but it will break the
ABI.
uvcvideo: Fix descriptor parsing for video output devices
This one seems independent from API changes. Applying it.
v4l: videobuf2: Typo fix
What about this one ?
Martin Rubli (2):
uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
uvcvideo: Add driver documentation
Please, don't use enum at the public API:
+ __u32 id V4L2 control identifier
+ __u8name[32]V4L2 control name
+ __u8entity[16] UVC extension unit GUID
+ __u8selectorUVC control selector
+ __u8sizeV4L2 control size (in bits)
+ __u8offset V4L2 control offset (in bits)
+ enum v4l2_ctrl_type
+ v4l2_type V4L2 control type
+ enum uvc_control_data_type
+ data_type UVC control data type
+ struct uvc_menu_info
+ *menu_info Array of menu entries (for menu controls
only) + __u32 menu_count Number of menu entries (for menu
controls only) +
+ * struct uvc_menu_info
+
+ __u32 value Menu entry value used by the device
+ __u8name[32]Menu entry name
enum size is not portable. (OK, I know that V4L2 API has some enum's, but
let's not add new stuff using it). Also, please be sure that the new API
won't require any compat32 bits.
OK I'll fix that.
Stephan Lachowsky (1):
uvcvideo: Fix uvc_fixup_video_ctrl() format search
This one seems independent from API changes. Applying it.
--
Regards,
Laurent Pinchart
--
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
Re: soc-camera layer2 driver
Dear Dr Guennadi, Thank you for your answer. 1. soc-camera core 2. camera host driver (receive from sensor, DMA to RAM) 3. camera sensor drivers If you're developing new hardware, you'll have to write new layer 2 driver for it. I do understand that part, I guess what I was asking was for any pointers to some up-to-date guides on how to do this. I couldn't find a good documentation on how to to that. I must add that even though I have written drivers to other operating systems, I am new at writing drivers for Linux. The V4L2 layer appears very powerful and, at the same time, there is a lot of documentation out there but, a lot also appears to be obsolete. Of course, the best way is to modify something current. I will attempt to do this but I would still appreciate any current howtos you could point me to. As for stereo vision: since you're going to use the same sensor, you will either have to put it on a different i2c bus, or wire it to configure a different i2c address. In either case communicating to it shouldn't be a problem. Yes, of course and I can change the I2C address so I can use the same bus. My question was more related to synchronization of both frames. Initially, I thought about multiplexing the cameras at the hardware level so that every frame, the data bus would switch to the other camera but then, one has not control over the camera horizontal sync signals. There is no way to guarantee that both cameras HSync are ... well synchronized. Then of course, the other problem would be that the frames would be out of sync in terms of time of capture. Anyway, the question was more related to synchronicity. And I guess the answer would depend on whether I wanted to capture frame-alternative 3D or side-by-side 3D. Maybe this is too new, I just can't find detailed information about 3D in V4L2. I appreciate any up-to-date documents you can point me to. Cheers, Gilles . On Mar 21, 2011, at 01:02 , Guennadi Liakhovetski wrote: Hi Gilles On Mon, 21 Mar 2011, Gilles wrote: Hi, I am sorry to bother you but after hours of searching google without luck I thought I'd ask you what might take you 5 minutes to answer if you please would. I have developed a custom hardware which can host one or two cameras and I am a little confused (mainly because I can't seem to find up-to-date documentation on how to do it) as to: All (non-commercial) requests should really be discussed on the Linux Media Mailing List linux-media@vger.kernel.org mailing list. Please, repost your query to the list with my email in CC. In short, if I understood you right, you are developing new hardware, that receives data from video sensors and DMAs it into RAM, correct? In general the soc-camera stack consists of 3 layers: 1. soc-camera core 2. camera host driver (receive from sensor, DMA to RAM) 3. camera sensor drivers If you're developing new hardware, you'll have to write new layer 2 driver for it. As for stereo vision: since you're going to use the same sensor, you will either have to put it on a different i2c bus, or wire it to configure a different i2c address. In either case communicating to it shouldn't be a problem. We can further discuss details on the mailing list. Thanks Guennadi - Which files do I need to modify so that soc-camera knows where/how to access the hardware pins where the camera is connected to. - I'm not sure I understand how the H/V sync works. My camera is connected to a parallel interface which is designed to do DMA into memory (clocked by the camera pixel clock). Don't the H/V signals need to generate an interrupt to reset the DMA addresses? It appears as the soc infrastructure does not require that but I don't understand how the drivers know that a new frame is available? - Curently, the hardware I designed is designed to handle one camera at once but I have been asked if it would be possible to modify the hardware to run both cameras at once (which I can easily do). How would you recommend implementing stereo-vision? If both cameras are of the same kind (same driver), I am also a little confused how the same soc driver would know which one of the two hardwares it needs to bind to. If you could just point me to *any* documentation that would explain (something up-to-date) how to adapt linux to match my hardware, I would GREATLY appreciate it as I am a bit lost. Thank you, Gilles . --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi Mauro, On Tuesday 22 March 2011 01:27:44 Mauro Carvalho Chehab wrote: Em 03-03-2011 07:10, Laurent Pinchart escreveu: On Thursday 03 March 2011 03:16:32 Kim, HeungJun wrote: As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO, maintaining v4l2 menu index. Signed-off-by: Heungjun Kim riverful@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I'm assuming that you'll be applying those patches on your tree and sending me a pull request, right? The patch depends on other V4L2 core patches in the same series, so I wasn't planning to push it through my tree, but it can be done. There are still issues with this series though, as we haven't reached an agreement on the auto-focus ABI yet. -- Regards, Laurent Pinchart -- 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
Re: soc-camera layer2 driver
Hi On Tue, 22 Mar 2011, Gilles wrote: Dear Dr Guennadi, Thank you for your answer. 1. soc-camera core 2. camera host driver (receive from sensor, DMA to RAM) 3. camera sensor drivers If you're developing new hardware, you'll have to write new layer 2 driver for it. I do understand that part, I guess what I was asking was for any pointers to some up-to-date guides on how to do this. I couldn't find a good documentation on how to to that. I must add that even though I have written drivers to other operating systems, I am new at writing drivers for Linux. The V4L2 layer appears very powerful and, at the same time, there is a lot of documentation out there but, a lot also appears to be obsolete. Of course, the best way is to modify something current. I will attempt to do this but I would still appreciate any current howtos you could point me to. Well, there's a Documentation/video4linux/soc-camera.txt but it's not really that modern (it mentions 2.6.27 in it...). Last time it has been updated for 2.6.32. I have to update it again at some point, things change way too quickly. So, yes, your best bet would be to take existing drivers. If you plan to support scatter-gather DMA, look at pxa_camera.c, if your buffers are going to be contiguous (even though you're not going to use the videobuf2-dma-contig allocator), look at sh_mobile_ceu for an advanced example, or at one of mx3_camera, mx2_camera, mx1_camera for simpler ones. omap1_camera is also trying to support both sg and contig... If you have questions, don't hesitate to ask on the ML, also cc me and / or the respective driver author. Maybe you end up writing some such howto too;) As for stereo vision: since you're going to use the same sensor, you will either have to put it on a different i2c bus, or wire it to configure a different i2c address. In either case communicating to it shouldn't be a problem. Yes, of course and I can change the I2C address so I can use the same bus. My question was more related to synchronization of both frames. Initially, I thought about multiplexing the cameras at the hardware level so that every frame, the data bus would switch to the other camera but then, one has not control over the camera horizontal sync signals. There is no way to guarantee that both cameras HSync are ... well synchronized. Then of course, the other problem would be that the frames would be out of sync in terms of time of capture. Anyway, the question was more related to synchronicity. And I guess the answer would depend on whether I wanted to capture frame-alternative 3D or side-by-side 3D. Maybe this is too new, I just can't find detailed information about 3D in V4L2. I'm not aware about any 3d efforts in v4l2... I would've thought, that one would want to synchronize frames at the driver level, the application level is too indeterministic. So, you would need to add an API to retrieve pairs of frames, I presume, one of which is marked left, other right. This frame-pair handling is one addition to the generic V4L2 API. You'll also need a way to open / associate two sensors with one v4l2 device node. Then, how you assemble two different frames from two sensors in one stereo-frame is up to your driver, I presume. Alternatively you could use two device nodes and reassemble stereo frames in user-space based on indices or timestamps. This should also be possible, as long as you guarantee in your driver, that that information is really consistent. Those were just a couple of quick ideas, perhaps, 3d / stereo-vision support in v4l2 requires a careful study and some RFC-rounds... Thanks Guennadi I appreciate any up-to-date documents you can point me to. Cheers, Gilles . On Mar 21, 2011, at 01:02 , Guennadi Liakhovetski wrote: Hi Gilles On Mon, 21 Mar 2011, Gilles wrote: Hi, I am sorry to bother you but after hours of searching google without luck I thought I'd ask you what might take you 5 minutes to answer if you please would. I have developed a custom hardware which can host one or two cameras and I am a little confused (mainly because I can't seem to find up-to-date documentation on how to do it) as to: All (non-commercial) requests should really be discussed on the Linux Media Mailing List linux-media@vger.kernel.org mailing list. Please, repost your query to the list with my email in CC. In short, if I understood you right, you are developing new hardware, that receives data from video sensors and DMAs it into RAM, correct? In general the soc-camera stack consists of 3 layers: 1. soc-camera core 2. camera host driver (receive from sensor, DMA to RAM) 3. camera sensor drivers If you're developing new hardware, you'll have to write new layer 2 driver for it. As for stereo vision: since you're going to use the same sensor, you will either have to put it on a
Re: S2-3200 switching-timeouts on 2.6.38
Manu Abraham abraham.m...@gmail.com writes: On Tue, Mar 22, 2011 at 1:46 AM, Randy Dunlap rdun...@xenotime.net wrote: On Mon, 21 Mar 2011 20:46:23 +0100 Rico Tzschichholz wrote: Hello, I would like to know if there is any intention to include this patch soon? https://patchwork.kernel.org/patch/244201/ There are MANY posted but unmerged patches in patchwork from the linux-media mailing list. What is going on (or not going on) with patch merging? Actually, quite a lot of effort was put in to get that part right. It does the reverse thing that's to be done. The revamped version is here [1] If the issue persists still, then it needs to be investigated further. [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html So the patch state should be Rejected and not Under Review. Would certainly help us all if the patchwork state was updated whenever a patch actually was processed... Bjørn -- 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
Re: [GIT PATCHES FOR 2.6.39] Make the UVC API public (and bug fixes)
Em 22-03-2011 06:17, Laurent Pinchart escreveu:
Hi Mauro,
Thanks for the review.
On Monday 21 March 2011 20:39:17 Mauro Carvalho Chehab wrote:
Em 27-02-2011 14:36, Laurent Pinchart escreveu:
Hi Mauro,
These patches move the uvcvideo.h header file from
drivers/media/video/uvc to include/linux, making the UVC API public.
Martin Rubli has committed support for the public API to libwebcam, so
userspace support is up to date.
The following changes since commit
9e650fdb12171a5a5839152863eaab9426984317:
[media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM
driver (2011-02-27 07:50:42 -0300)
are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
Laurent Pinchart (6):
uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
There are some places there saying that the removal will happen at 2.6.39.
I'll fix that.
uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
uvcvideo: Include linux/types.h in uvcvideo.h
uvcvideo: Move uvcvideo.h to include/linux
-'U'00-0F drivers/media/video/uvc/uvcvideo.h conflict!
+'U'00-0F linux/uvcvideo.hconflict!
Please avoid conflicts at userspace API's.
The uvcvideo driver already uses 'U'. I can change it, but it will break the
ABI.
Yes, but, as we've discussed on IRC, API will be broken anyway, with the
removal of the 4 old ioctls. This is not so serious here, as the API is defined
on an internal header (drivers/media/video/uvc/uvcvideo.h) that are not exported
via make headers-install. Yet, we'll need to keep the old set of ioctls during
some kernel versions.
uvcvideo: Fix descriptor parsing for video output devices
This one seems independent from API changes. Applying it.
v4l: videobuf2: Typo fix
What about this one ?
Were already applied:
commit 4c3e702cf541a6bee8afb345f22300b1e3c2fe08
Author: Laurent Pinchart laurent.pinch...@ideasonboard.com
AuthorDate: Sun Feb 27 14:38:19 2011 -0300
Commit: Mauro Carvalho Chehab mche...@redhat.com
CommitDate: Wed Mar 2 17:37:16 2011 -0300
Martin Rubli (2):
uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
uvcvideo: Add driver documentation
Please, don't use enum at the public API:
+ __u32 id V4L2 control identifier
+ __u8name[32]V4L2 control name
+ __u8entity[16] UVC extension unit GUID
+ __u8selectorUVC control selector
+ __u8sizeV4L2 control size (in bits)
+ __u8offset V4L2 control offset (in bits)
+ enum v4l2_ctrl_type
+ v4l2_type V4L2 control type
+ enum uvc_control_data_type
+ data_type UVC control data type
+ struct uvc_menu_info
+ *menu_info Array of menu entries (for menu controls
only) + __u32 menu_count Number of menu entries (for menu
controls only) +
+ * struct uvc_menu_info
+
+ __u32 value Menu entry value used by the device
+ __u8name[32]Menu entry name
enum size is not portable. (OK, I know that V4L2 API has some enum's, but
let's not add new stuff using it). Also, please be sure that the new API
won't require any compat32 bits.
OK I'll fix that.
Stephan Lachowsky (1):
uvcvideo: Fix uvc_fixup_video_ctrl() format search
This one seems independent from API changes. Applying it.
Mauro.
--
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
[GIT PATCHES FOR 2.6.39] gspca for_v2.6.39
The following changes since commit d2803205ff3be8e8ea4634709799606c5d5294b5: [media] via-camera: Fix OLPC serial check (2011-03-21 21:48:25 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v2.6.39 Jean-François Moine (9): gspca - nw80x: Cleanup source gspca - nw80x: The webcam dsb-c110 is the same as the twinkle gspca - nw80x: Do some initialization at probe time gspca - nw80x: Fix the gain, exposure and autogain gspca - nw80x: Check the bridge from the webcam type gspca - nw80x: Fix some image resolutions gspca - nw80x: Get the sensor ID when bridge et31x110 gspca - nw80x: Fix exposure for some webcams gspca - zc3xx: Add exposure control for sensor hv7131r Patrice Chotard (1): gspca - main: Add endpoint direction test in alt_xfer drivers/media/video/gspca/gspca.c |3 +- drivers/media/video/gspca/nw80x.c | 858 - drivers/media/video/gspca/zc3xx.c | 76 +++- 3 files changed, 351 insertions(+), 586 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
Re: Yet another memory provider: can linaro organize a meeting?
On Monday 21 March 2011 19:03:38 Hans Verkuil wrote: On Wednesday, March 16, 2011 09:14:54 Kyungmin Park wrote: Rough schedules. 1. Warsaw meetings (3/16~3/18): mostly v4l2 person and some SoC vendors Make a consensence at media developers. and share the information. Please note that it's v4l2 brainstorming meeting. so memory management is not the main issue. I have asked all participants to the meeting to try and assemble requirements for their hardware in the next week. 2. ELC (4/11~4/13): DRM, DRI and v4l2 person. Discuss GEM/TTM is acceptable for non-X86 system and find out the which modules are acceptable. We studied the GEM for our environment. but it's too huge and not much benefit for us since current frameworks are enough. The missing is that no generic memory passing mechanism. We need the generic memory passing interface. that's all. Who will be there? Is there a BoF or something similar organized? 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons. I hope several person are anticipated and made a small step for final goal. I should be able to join, at least for the part related to buffer pools and related topics. Same for me. I might not join for the whole week, so it would be nice if we could draft an agenda in the near future. -- Regards, Laurent Pinchart -- 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
Re: S2-3200 switching-timeouts on 2.6.38
Em 22-03-2011 06:53, Bjørn Mork escreveu: Manu Abraham abraham.m...@gmail.com writes: On Tue, Mar 22, 2011 at 1:46 AM, Randy Dunlap rdun...@xenotime.net wrote: On Mon, 21 Mar 2011 20:46:23 +0100 Rico Tzschichholz wrote: Hello, I would like to know if there is any intention to include this patch soon? https://patchwork.kernel.org/patch/244201/ There are MANY posted but unmerged patches in patchwork from the linux-media mailing list. What is going on (or not going on) with patch merging? Actually, quite a lot of effort was put in to get that part right. It does the reverse thing that's to be done. The revamped version is here [1] If the issue persists still, then it needs to be investigated further. [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html So the patch state should be Rejected and not Under Review. Would certainly help us all if the patchwork state was updated whenever a patch actually was processed... Yes, but the thing is that somebody needs to manually update me about status change, as patchwork doesn't provide any way for it. Patchwork's permission for a project is all or nothing: or you completely own a project, or you have just read-only access. There's no way, currently, for me to delegate a patch to someone without allowing that person to touch at the non-delegated patches. Also, patchwork also doesn't allow me to change contributor status (there's just one global admin that creates and/or modifies account access on patchwork). Anyway, I've updated the status for #244201. Thanks, Mauro. -- 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
Re: [PATCH 0/6] get rid of on-stack dma buffers
On Mon, Mar 21, 2011 at 05:03:15PM -0400, Florian Mickler wrote: I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) Freeing is very well an issue. All you can expect from the DMA-API is to give you a valid DMA handle for your device. But it can not prevent that a device uses this handle after you returned it. You need to make sure yourself that any pending DMA is canceled before calling kfree(). Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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
Re: soc-camera layer2 driver
On Tuesday 22 March 2011 10:37:36 Guennadi Liakhovetski wrote: On Tue, 22 Mar 2011, Gilles wrote: Dear Dr Guennadi, Thank you for your answer. 1. soc-camera core 2. camera host driver (receive from sensor, DMA to RAM) 3. camera sensor drivers If you're developing new hardware, you'll have to write new layer 2 driver for it. I do understand that part, I guess what I was asking was for any pointers to some up-to-date guides on how to do this. I couldn't find a good documentation on how to to that. I must add that even though I have written drivers to other operating systems, I am new at writing drivers for Linux. The V4L2 layer appears very powerful and, at the same time, there is a lot of documentation out there but, a lot also appears to be obsolete. Of course, the best way is to modify something current. I will attempt to do this but I would still appreciate any current howtos you could point me to. Well, there's a Documentation/video4linux/soc-camera.txt but it's not really that modern (it mentions 2.6.27 in it...). Last time it has been updated for 2.6.32. I have to update it again at some point, things change way too quickly. So, yes, your best bet would be to take existing drivers. If you plan to support scatter-gather DMA, look at pxa_camera.c, if your buffers are going to be contiguous (even though you're not going to use the videobuf2-dma-contig allocator), look at sh_mobile_ceu for an advanced example, or at one of mx3_camera, mx2_camera, mx1_camera for simpler ones. omap1_camera is also trying to support both sg and contig... If you have questions, don't hesitate to ask on the ML, also cc me and / or the respective driver author. Maybe you end up writing some such howto too;) As for stereo vision: since you're going to use the same sensor, you will either have to put it on a different i2c bus, or wire it to configure a different i2c address. In either case communicating to it shouldn't be a problem. Yes, of course and I can change the I2C address so I can use the same bus. My question was more related to synchronization of both frames. Initially, I thought about multiplexing the cameras at the hardware level so that every frame, the data bus would switch to the other camera but then, one has not control over the camera horizontal sync signals. There is no way to guarantee that both cameras HSync are ... well synchronized. Then of course, the other problem would be that the frames would be out of sync in terms of time of capture. Anyway, the question was more related to synchronicity. And I guess the answer would depend on whether I wanted to capture frame-alternative 3D or side-by-side 3D. Maybe this is too new, I just can't find detailed information about 3D in V4L2. I'm not aware about any 3d efforts in v4l2... I would've thought, that one would want to synchronize frames at the driver level, the application level is too indeterministic. So, you would need to add an API to retrieve pairs of frames, I presume, one of which is marked left, other right. This frame-pair handling is one addition to the generic V4L2 API. You'll also need a way to open / associate two sensors with one v4l2 device node. Then, how you assemble two different frames from two sensors in one stereo-frame is up to your driver, I presume. Alternatively you could use two device nodes and reassemble stereo frames in user-space based on indices or timestamps. This should also be possible, as long as you guarantee in your driver, that that information is really consistent. Those were just a couple of quick ideas, perhaps, 3d / stereo-vision support in v4l2 requires a careful study and some RFC-rounds... What about using the multi-plane API for that ? -- Regards, Laurent Pinchart -- 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
Re: [Query] VIDIOC_QBUF and VIDIOC_STREAMON order
Hi Hans, On Tuesday 15 March 2011 08:50:45 Hans Verkuil wrote: On Tuesday, March 15, 2011 04:21:05 Pawel Osciak wrote: On Mon, Mar 14, 2011 at 03:49, Subash Patel subas...@gmail.com wrote: VIDIOC_STREAMON expects buffers to be queued before hardware part of image/video pipe is enabled. From my experience of V4L2 user space, I have always QBUFfed before invoking the STREAMON. Below is the API specification which also speaks something same: Not exactly. It says that the API requires buffers to be queued for output devices. It does not require any buffers to be queued for input devices. Sylwester is right here. This feature of not having to queue input buffers before STREAMON introduces problems to driver implementations and I am personally not a big fan of it either. But I'm seeing some additional problems here. Suppose we forced QBUF to be done before STREAMON. This would work, but what happens next? What should happen when we want to DQBUF the last buffer? If the device couldn't start without any buffers queued, can it continue streaming with all of them dequeued? I would guess not. So we'd either have to deny DQBUF of the last buffer (which for me personally is almost unacceptable) or have the last DQBUF automatically cause a STREAMOFF. So, for the latter, should applications, after they get all the data they wanted, be made to always have one more buffer queued as a throwaway buffer? This is probably the only reasonable solution here, but the applications would have to keep count of their queued buffers and be aware of this. Also, there might still be situations where being able to STREAMON without buffers queued would be beneficial. For example, enabling the device might be a slow/expensive operation and we might prefer to keep it running even if we don't want any data at the moment. Even for faster devices, being able to keep them on and periodically take a snapshot would be faster without having to call STREAMON anyway... The problem is that what is possible is highly hardware dependent. All video capture device I know of (composite in, HDMI in, etc) require that buffers are queued and they won't release that buffer to userspace until a new free buffer is available. That's funny, all video capture devices I know of behave the opposite way :-) They either pause the stream when they run out of buffers and resume it when a new buffer gets queued, or they throw away the data when intermediate buffers are used (such as with USB devices). They DMA continuously and stopping the DMA at the last buffer and restarting it when a new one appears tends to be too expensive and leads to additional loss of frames. In part how this should act depends on the use-case: if you are streaming video, then requiring buffers to be present before STREAMON and holding on to a buffer if userspace can't keep up seems quite reasonable to me. But for snapshot and codec type streams this behavior doesn't make sense. The main difference is that in this case the DMA is not driven by an external input, but by internal (userspace) demand. Something for our meeting to discuss. -- Regards, Laurent Pinchart -- 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
Re: [PATCH 0/6] get rid of on-stack dma buffers
On Mon, 21 Mar 2011, Florian Mickler wrote: To be blunt, I'm not shure I fully understand the requirements myself. But as far as I grasped it, the main problem is that we need memory which the processor can see as soon as the device has scribbled upon it. (think caches and the like) Somewhere down the line, the buffer to usb_control_msg get's to be a parameter to dma_map_single which is described as part of the DMA API in Documentation/DMA-API.txt The main point I filter out from that is that the memory has to begin exactly at a cache line boundary... I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) I cc'd some people that hopefully will correct me if I'm wrong... It all boils down to making sure that you don't free the memory which is used as target of DMA transfer. This is very likely to hit you when DMA memory region is on stack, but blindly just converting this to kmalloc()/kfree() isn't any better if you don't make sure that all the DMA transfers have been finished and device will not be making any more to that particular memory region. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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
Re: S2-3200 switching-timeouts on 2.6.38
Hello Manu, Actually, quite a lot of effort was put in to get that part right. It does the reverse thing that's to be done. The revamped version is here [1] If the issue persists still, then it needs to be investigated further. [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html I am not sure how this is related to stb6100? Does that mean the current stb0899 patch [2] isnt ready to be proposed for 2.6.39 yet? Or does the stb6100 patch has a better design to solve this issue which should be adapted for stb0899 then? I was hoping to see it included before the merge window is closed again. [2] https://patchwork.kernel.org/patch/244201/ Best regards, Rico signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/3] ARM: switch mackerel to dynamically manage the platform camera
On Mon, Mar 21, 2011 at 10:22 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Wed, 16 Mar 2011, Magnus Damm wrote: On Tue, Feb 22, 2011 at 6:57 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Use soc_camera_platform helper functions to dynamically manage the camera device. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- arch/arm/mach-shmobile/board-mackerel.c | 28 +++- 1 files changed, 7 insertions(+), 21 deletions(-) I just tested patch 1/3 and patch 3/3 on my Mackerel board. Thanks for testing! Unfortunately I get this printout on the console: sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0 soc_camera_platform soc_camera_platform.0: Platform has not set soc_camera_device pointer! soc_camera_platform: probe of soc_camera_platform.0 failed with error -22 sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0 Without these two patches everything work just fine. Any ideas on how to fix it? I'd be happy to test V2. =) Hm, yes, looks like I'm initialising the pointer too late. Could you, please, test the patch below on top, if it helps, I'll send v2. Yes, this fix incremental change solves the problem. Thanks! Please post V2 and add: Acked-by: Magnus Damm d...@opensource.se -- 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
Re: [PATCH 3/3] ARM: switch mackerel to dynamically manage the platform camera
On Mon, Mar 21, 2011 at 10:22 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Wed, 16 Mar 2011, Magnus Damm wrote: On Tue, Feb 22, 2011 at 6:57 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Use soc_camera_platform helper functions to dynamically manage the camera device. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- arch/arm/mach-shmobile/board-mackerel.c | 28 +++- 1 files changed, 7 insertions(+), 21 deletions(-) I just tested patch 1/3 and patch 3/3 on my Mackerel board. Thanks for testing! Unfortunately I get this printout on the console: sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0 soc_camera_platform soc_camera_platform.0: Platform has not set soc_camera_device pointer! soc_camera_platform: probe of soc_camera_platform.0 failed with error -22 sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0 Without these two patches everything work just fine. Any ideas on how to fix it? I'd be happy to test V2. =) Hm, yes, looks like I'm initialising the pointer too late. Could you, please, test the patch below on top, if it helps, I'll send v2. Yes, this incremental change solves the problem. Thanks! Please post V2 and add: Acked-by: Magnus Damm d...@opensource.se -- 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
Re: Demande de support V4L2
On 03/21/2011 06:43 PM, Laurent Pinchart wrote: Hi Loïc, On Friday 18 March 2011 16:43:40 Loïc Akue wrote: Hi, Do you know if Gstreamer or Mplayer are able to capture some vidéo from the CCDC output? I've been trying with the v4l2src plugin but Gstreamer can negociate format. I haven't tried mplayer or v4l2src with the OAMP3 ISP, sorry. Hi Loïc, GStreamer relies on ENUM_FMT to negotiate the format, which the current ISP driver doesn't provide. I have patched my kernel to do this and I have gotten GStreamer to display UYVY images from the previewer output, but I haven't spent much time trying to get it from the CCDC yet. I would be interested to hear your progress there. I will submit my ENUM_FMT patch to the list in a different thread. -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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
RE: [PATCH v17 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod
On Tue, Mar 15, 2011 at 19:28:43, Hadli, Manjunath wrote:
Current devices.c file has a number of instances where
IO_ADDRESS() is used for system module register
access. Eliminate this in favor of a ioremap()
based access.
Consequent to this, a new global pointer davinci_sysmodbase
has been introduced which gets initialized during
the initialization of each relevant SoC.
In this patch davinci_sysmodbase is used by davinci_setup_mmc
but the later patches in the series use the same in different
places using DAVINCI_SYSMODULE_VIRT.This patch lays the
foundation for that.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
arch/arm/mach-davinci/devices.c | 23 ++-
arch/arm/mach-davinci/dm355.c |1 +
arch/arm/mach-davinci/dm365.c |1 +
arch/arm/mach-davinci/dm644x.c|1 +
arch/arm/mach-davinci/dm646x.c|1 +
arch/arm/mach-davinci/include/mach/hardware.h |6 ++
6 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index d3b2040..b7ef950 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,14 @@
#define DM365_MMCSD0_BASE 0x01D11000
#define DM365_MMCSD1_BASE 0x01D0
+void __iomem *davinci_sysmodbase;
+
+void davinci_map_sysmod(void)
+{
+ davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+ WARN_ON(!davinci_sysmodbase);
+}
+
static struct resource i2c_resources[] = {
{
.start = DAVINCI_I2C_BASE,
@@ -210,12 +218,12 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
davinci_cfg_reg(DM355_SD1_DATA2);
davinci_cfg_reg(DM355_SD1_DATA3);
} else if (cpu_is_davinci_dm365()) {
- void __iomem *pupdctl1 =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
/* Configure pull down control */
- __raw_writel((__raw_readl(pupdctl1) ~0xfc0),
- pupdctl1);
+ void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
+ unsigned v;
+
+ v = __raw_readl(pupdctl1);
+ __raw_writel(v ~0xfc0, pupdctl1);
You fixed this as Sergei requested...
mmcsd1_resources[0].start = DM365_MMCSD1_BASE;
mmcsd1_resources[0].end = DM365_MMCSD1_BASE +
@@ -244,11 +252,8 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
/* REVISIT: should this be in board-init code? */
- void __iomem *base =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
/* Power-on 3.3V IO cells */
- __raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
+ writel(0, DAVINCI_SYSMODULE_VIRT(DM64XX_VDD3P3V_PWDN));
.. but forgot to fix this. There is nothing wrong with
using writel, but it doesn't fit into what the subject
of this patch is.
Thanks,
Sekhar
--
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
RE: [PATCH v17 10/13] davinci: dm644x: change vpfe capture structure variables for consistency
On Tue, Mar 15, 2011 at 19:29:12, Hadli, Manjunath wrote: change the vpfe capture related configuration structure variables from config to dm644xevm_config to make it consistent with the rest of the file. This description is not fully accurate. You also have changes where you add SoC prefix to variable names. I guess you can just say Add SoC and board prefixes to variable names so that.. Thanks, Sekhar -- 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
RE: [PATCH v17 13/13] davinci: dm644x EVM: add support for VPBE display
On Tue, Mar 15, 2011 at 19:29:55, Hadli, Manjunath wrote: This patch adds support for V4L2 video display to DM6446 EVM. Support for SD and ED modes is provided, along with Composite and Component outputs. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com --- arch/arm/mach-davinci/board-dm644x-evm.c| 108 ++- arch/arm/mach-davinci/dm644x.c |4 +- arch/arm/mach-davinci/include/mach/dm644x.h |3 +- The changes adding the SoC support should be folded into patch 12/13. Thanks, Sekhar -- 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
RE: [PATCH v17 00/13] davinci vpbe: dm6446 v4l2 driver
Manju, On Tue, Mar 22, 2011 at 12:23:14, Hadli, Manjunath wrote: Sekhar, Kevin, These patches have gone through considerable reviews. Could you please ACK from your end? I have some minor comments which I have already posted and once you fix those you can add: Acked-by: Sekhar Nori nsek...@ti.com to the platform patches. On Tue, Mar 15, 2011 at 19:26:28, Hadli, Manjunath wrote: version17: The more important among the patch history from previous comments 1. Replacing _raw_readl() with readl(). This is not valid. Thanks, Sekhar -- 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
[PATCH] omap3isp: implement ENUM_FMT
From dccbd4a0a717ee72a3271075b1e3456a9c67ca0e Mon Sep 17 00:00:00 2001
From: Michael Jones michael.jo...@matrix-vision.de
Date: Tue, 22 Mar 2011 11:47:22 +0100
Subject: [PATCH] omap3isp: implement ENUM_FMT
Whatever format is currently being delivered will be declared as the only
possible format
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
Some V4L2 apps require ENUM_FMT, which is a mandatory ioctl for V4L2.
This patch doesn't enumerate all of the formats which could possibly be
set (as is intended by ENUM_FMT), but at least it reports the one that
is currently set.
This patch applies to Laurent's 'media-2.6.38-0001-omap3isp' branch.
drivers/media/video/omap3isp/ispvideo.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index a0bb5db..8e25f47 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -642,6 +642,28 @@ isp_video_get_format(struct file *file, void *fh, struct
v4l2_format *format)
}
static int
+isp_video_enum_format(struct file *file, void *fh, struct v4l2_fmtdesc
*fmtdesc)
+{
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+
+ if (fmtdesc-index)
+ return -EINVAL;
+
+ if (fmtdesc-type != video-type)
+ return -EINVAL;
+
+ fmtdesc-flags = 0;
+ fmtdesc-description[0] = 0;
+
+ mutex_lock(video-mutex);
+ fmtdesc-pixelformat = vfh-format.fmt.pix.pixelformat;
+ mutex_unlock(video-mutex);
+
+ return 0;
+}
+
+static int
isp_video_set_format(struct file *file, void *fh, struct v4l2_format *format)
{
struct isp_video_fh *vfh = to_isp_video_fh(fh);
@@ -1059,6 +1081,7 @@ isp_video_s_input(struct file *file, void *fh, unsigned
int input)
static const struct v4l2_ioctl_ops isp_video_ioctl_ops = {
.vidioc_querycap= isp_video_querycap,
+ .vidioc_enum_fmt_vid_cap= isp_video_enum_format,
.vidioc_g_fmt_vid_cap = isp_video_get_format,
.vidioc_s_fmt_vid_cap = isp_video_set_format,
.vidioc_try_fmt_vid_cap = isp_video_try_format,
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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
Re: S2-3200 switching-timeouts on 2.6.38
Rico Tzschichholz ric...@t-online.de writes: Actually, quite a lot of effort was put in to get that part right. It does the reverse thing that's to be done. The revamped version is here [1] If the issue persists still, then it needs to be investigated further. [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html I am not sure how this is related to stb6100? Does that mean the current stb0899 patch [2] isnt ready to be proposed for 2.6.39 yet? Or does the stb6100 patch has a better design to solve this issue which should be adapted for stb0899 then? I believe the point was that the real issue was a noise problem in the stb6100 tuner driver, and that the stb0899 frontend patch just papered over this. I was hoping to see it included before the merge window is closed again. [2] https://patchwork.kernel.org/patch/244201/ Please test the driver with the patch Manu refers to and report if there still are issues. The patch is now upstream in the 2.6.38 kernel, so testing it should be fairly easy. Do you still have this issue with a plain 2.6.38 driver? Bjørn -- 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
Re: [PATCH 0/6] get rid of on-stack dma buffers
Am Dienstag, 22. März 2011, 14:08:17 schrieb Florian Mickler: Am 22.03.2011 12:10 schrieb Roedel, Joerg joerg.roe...@amd.com: On Mon, Mar 21, 2011 at 05:03:15PM -0400, Florian Mickler wrote: I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) Freeing is very well an issue. All you can expect from the DMA-API is to give you a valid DMA handle for your device. But it can not prevent that a device uses this handle after you returned it. You need to make sure yourself that any pending DMA is canceled before calling kfree(). Does usb_control_msg do this? It waits for completion but takes also a timeout parameter. I will recheck this once I'm home. It uses usb_start_wait_urb() which upon a timeout kills the URB. The buffer is unused after usb_control_msg() returns. HTH Oliver -- 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
Re: [PATCH v17 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod
On Tuesday 22 March 2011, Nori, Sekhar wrote: .. but forgot to fix this. There is nothing wrong with using writel, but it doesn't fit into what the subject of this patch is. Well, to be more exact, the __raw_writel was actually wrong here and it should be writel(), but it's certainly better to mention the reason in the changelog, or to make a separate patch for it. Arnd -- 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
Re: [PATCH 0/6] get rid of on-stack dma buffers
On Tue, Mar 22, 2011 at 11:59:32AM +0100, Jiri Kosina wrote: On Mon, 21 Mar 2011, Florian Mickler wrote: To be blunt, I'm not shure I fully understand the requirements myself. But as far as I grasped it, the main problem is that we need memory which the processor can see as soon as the device has scribbled upon it. (think caches and the like) Somewhere down the line, the buffer to usb_control_msg get's to be a parameter to dma_map_single which is described as part of the DMA API in Documentation/DMA-API.txt The main point I filter out from that is that the memory has to begin exactly at a cache line boundary... I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) I cc'd some people that hopefully will correct me if I'm wrong... It all boils down to making sure that you don't free the memory which is used as target of DMA transfer. This is very likely to hit you when DMA memory region is on stack, but blindly just converting this to kmalloc()/kfree() isn't any better if you don't make sure that all the DMA transfers have been finished and device will not be making any more to that particular memory region. I think it is important that one cache line is not shared between a DMA buffer and other objects, especially on architectures where cache coherency is managed in software (ARM, MIPS etc.). If you use kmalloc() for the DMA buffer that is guaranteed. (E.g. DMA API will do writeback/invalidate before the DMA starts, but if the CPU accesses a variable which is next to the buffer while DMA is still pending then the whole cacheline is read back into the cache. If the CPU is then trying to read the DMA buffer after the DMA finished it will see stale data from the cache. You lose.) It depends on the device doing DMA if it needs special alignment. If you meet its alignment requirements, and wait for the end of the DMA before returning, and make sure the buffer does not share cache lines with neighbouring objects on the stack, then you can use DMA buffers on stack. In practice it's simpler and much less error prone to use kmalloc(). Regarding usb_control_msg(), since it is a synchronous API which waits for the end of the transfer I'm relatively sure there is no DMA pending when it returns, even if it aborts with timeout or any other error code. Johannes -- 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
Re: [PATCH 0/6] get rid of on-stack dma buffers
On Mon, 2011-03-21 at 22:03 +0100, Florian Mickler wrote: On Mon, 21 Mar 2011 15:26:43 -0400 Andy Walls awa...@md.metrocast.net wrote: Florian Mickler flor...@mickler.org wrote: Hi all! These patches get rid of on-stack dma buffers for some of the dvb-usb drivers. I do not own the hardware, so these are only compile tested. I would appreciate testing and review. They were previously sent to the list, but some error on my side prevented (some of?) them from beeing delivered to all parties (the lists). These changes are motivated by https://bugzilla.kernel.org/show_bug.cgi?id=15977 . The patches which got tested already were submitted to Mauro (and lkml/linux-media) yesterday seperately. Those fix this same issue for ec168, ce6230, au6610 and lmedm04. A fix for vp702x has been submitted seperately for review on the list. I have similiar fixes like the vp702x-fix for dib0700 (overlooked some on-stack buffers in there in my original submission as well) and gp8psk, but I am holding them back 'till I got time to recheck those and getting some feedback on vp702x. Please review and test. Regards, Flo Florian Mickler (6): [media] a800: get rid of on-stack dma buffers [media v2] vp7045: get rid of on-stack dma buffers [media] friio: get rid of on-stack dma buffers [media] dw2102: get rid of on-stack dma buffer [media] m920x: get rid of on-stack dma buffers [media] opera1: get rid of on-stack dma buffer drivers/media/dvb/dvb-usb/a800.c | 17 ++--- drivers/media/dvb/dvb-usb/dw2102.c | 10 ++- drivers/media/dvb/dvb-usb/friio.c | 23 ++--- drivers/media/dvb/dvb-usb/m920x.c | 33 drivers/media/dvb/dvb-usb/opera1.c | 31 +++ drivers/media/dvb/dvb-usb/vp7045.c | 47 ++-- 6 files changed, 116 insertions(+), 45 deletions(-) -- 1.7.4.1 -- 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 Florian, For all of these, what happens when the USB call times out and you kfree() the buffer? Can the USB DMA actually complete after this kfree(), possibly corrupting space that has been reallocated off the heap, since the kfree()? This is the scenario for which I assume allocating off the stack is bad. Do these changes simply make corruption less noticable since heap gets corrupted vs stack? Regards, Andy To be blunt, I'm not shure I fully understand the requirements myself. But as far as I grasped it, the main problem is that we need memory which the processor can see as soon as the device has scribbled upon it. (think caches and the like) Somewhere down the line, the buffer to usb_control_msg get's to be a parameter to dma_map_single which is described as part of the DMA API in Documentation/DMA-API.txt The main point I filter out from that is that the memory has to begin exactly at a cache line boundary... The API will round up so that the correct region covers the API. However, if you have other structures packed into the space (as very often happens on stack), you get cache line interference in the CPU if they get accessed: The act of accessing an adjacent object pulls in cache above your object and destroys DMA coherence. This is the principle reason why DMA to stack is a bad idea. I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) No, it doesn't take any precautions like this. the DMA API is just mapping (possibly via an IOMMU). If the transfer times out, that's done in the DMA engine of the card, and must be cleaned up by the driver and unmapped. The general rule though is never DMA to stack. On some processors, the way stack is allocated can actually make this not work. James -- 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
Re: [PATCH 0/6] get rid of on-stack dma buffers
2011/3/22 James Bottomley james.bottom...@hansenpartnership.com: On Mon, 2011-03-21 at 22:03 +0100, Florian Mickler wrote: On Mon, 21 Mar 2011 15:26:43 -0400 Andy Walls awa...@md.metrocast.net wrote: Florian Mickler flor...@mickler.org wrote: To be blunt, I'm not shure I fully understand the requirements myself. But as far as I grasped it, the main problem is that we need memory which the processor can see as soon as the device has scribbled upon it. (think caches and the like) Somewhere down the line, the buffer to usb_control_msg get's to be a parameter to dma_map_single which is described as part of the DMA API in Documentation/DMA-API.txt The main point I filter out from that is that the memory has to begin exactly at a cache line boundary... The API will round up so that the correct region covers the API. However, if you have other structures packed into the space (as very often happens on stack), you get cache line interference in the CPU if they get accessed: The act of accessing an adjacent object pulls in cache above your object and destroys DMA coherence. This is the principle reason why DMA to stack is a bad idea. Thanks, this was the missing piece of information to make sense of why it's bad for stack memory to be part of this. I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) I did mean s/dma api/usb_control_msg/ in the above paragraph. As that is the ''dma api'' these drivers are using... sorry for the confusion there... No, it doesn't take any precautions like this. the DMA API is just mapping (possibly via an IOMMU). If the transfer times out, that's done in the DMA engine of the card, and must be cleaned up by the driver and unmapped. ok. The general rule though is never DMA to stack. On some processors, the way stack is allocated can actually make this not work. James thanks, Flo p.s.: hope this message get's through to the list... I am on the road at the moment, so I'm not shure that there won't be any html in it again :( -- 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
Re: [PATCH 0/6] get rid of on-stack dma buffers
2011/3/22 Roedel, Joerg joerg.roe...@amd.com: On Mon, Mar 21, 2011 at 05:03:15PM -0400, Florian Mickler wrote: I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) Freeing is very well an issue. All you can expect from the DMA-API is to give you a valid DMA handle for your device. But it can not prevent that a device uses this handle after you returned it. You need to make sure yourself that any pending DMA is canceled before calling kfree(). sorry, I meant usb_control_msg above when I said 'dma api'... as that is the function these drivers use to do the dma. Regards, Flo -- 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
RE: [PATCH v17 12/13] davinci: dm644x: add support for v4l2 video display
On Tue, Mar 15, 2011 at 19:29:40, Hadli, Manjunath wrote:
Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm644x.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = VPBE_VERSION_1,
+ .setup_clock= dm644x_venc_setup_clock,
+};
Sparse pointed out that this symbol can
be static.
Can you please build the complete series with
C=1 on the command line? This will enable
sparse check on all files being re-compiled.
I also noticed some sparse warnings on vpbe_venc.c
Also, please build with CONFIG_DEBUG_SECTION_MISMATCH=y
on the command line. I noticed some section
mismatches as well with the new code.
Thanks,
Sekhar
--
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
OMAP3 ISP outputs 5555 5555 5555 5555 ...
Hello omap isp devs, maybe you can help me, I am a bit desperate with my current cam problem: I use a ov5642 chip and get only 0x55 in my data output when I use a camclk 1 MHz. With 1 MHz data rate from the camera chip to the omap all works (well the colorspace is strange - it's greenish, but that is not my main concern). I looked up the data on the oscilloscope and all flanks seem to be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data pins are flickering fine. Looks like a picture. I found that the isp stats module uses 0x55 as a magic number but I don't see why it should confuse my readout. I use 2592x1944 raw bayer output via the ccdc. Next to the logical right config I tried all possible configurations of vs/hs active high and low on camera and isp. The isp gets the vs flanks right as the images come out in time (sometimes it misses 1 frame). Anyone of you had this behaviour before? Thanks so much for reading this, Bastian Hecht -- 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
[RFC PATCH] HDMI:Support for EDID parsing in kernel.
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by
a digital display to describe its capabilities to a video source, This a
standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some
of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
parsing of EDID should be done in a library, which is agnostic of the
framework (V4l2, DRM, FB) which is using the functionality, just based on
the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's
It would be better to have a common EDID code in one place.It also helps to
provide better interoperability with variety of TV/Monitor may be even by
listing out quirks which might get missed with several custom implementation
of EDID.
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
This patch tries to add functions to parse some portion EDID (detailed timing,
monitor limits, AV delay information, deep color mode support, Audio and VSDB)
If we can align on this library approach i can enhance this library to parse
other blocks and probably we could also add quirks from other implementation
as well.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/include/asm/edid.h | 243 ++
drivers/video/edid.c| 340 +++
2 files changed, 583 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/edid.h
create mode 100644 drivers/video/edid.c
diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
new file mode 100644
index 000..843346a
--- /dev/null
+++ b/arch/arm/include/asm/edid.h
@@ -0,0 +1,243 @@
+/*
+ * edid.h
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Mythri P K mythr...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ * History:
+ */
+
+#ifndef _EDID_H_
+#define _EDID_H_
+
+/* HDMI EDID Length */
+#define HDMI_EDID_MAX_LENGTH 512
+
+/* HDMI EDID Extension Data Block Tags */
+#define HDMI_EDID_EX_DATABLOCK_TAG_MASK0xE0
+#define HDMI_EDID_EX_DATABLOCK_LEN_MASK0x1F
+
+#define EDID_TIMING_DESCRIPTOR_SIZE0x12
+#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
+#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
+#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
+#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
+
+/* EDID Detailed TimingInfo 0 begin offset */
+#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36
+
+#define HDMI_EDID_PIX_CLK_OFFSET 0
+#define HDMI_EDID_H_ACTIVE_OFFSET 2
+#define HDMI_EDID_H_BLANKING_OFFSET3
+#define HDMI_EDID_V_ACTIVE_OFFSET 5
+#define HDMI_EDID_V_BLANKING_OFFSET6
+#define HDMI_EDID_H_SYNC_OFFSET8
+#define HDMI_EDID_H_SYNC_PW_OFFSET 9
+#define HDMI_EDID_V_SYNC_OFFSET10
+#define HDMI_EDID_V_SYNC_PW_OFFSET 11
+#define HDMI_EDID_H_IMAGE_SIZE_OFFSET 12
+#define HDMI_EDID_V_IMAGE_SIZE_OFFSET 13
+#define HDMI_EDID_H_BORDER_OFFSET 15
+#define HDMI_EDID_V_BORDER_OFFSET 16
+#define HDMI_EDID_FLAGS_OFFSET 17
+
+/* HDMI EDID DTDs */
+#define HDMI_EDID_MAX_DTDS 4
+
+/* HDMI EDID DTD Tags */
+#define HDMI_EDID_DTD_TAG_MONITOR_NAME 0xFC
+#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM0xFF
+#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD
+#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
+#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA 0xFB
+#define HDMI_EDID_DTD_TAG_ASCII_STRING 0xFE
+
+#define HDMI_IMG_FORMAT_MAX_LENGTH 20
+#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10
+
+/* HDMI EDID Extenion Data Block Values: Video */
+#define HDMI_EDID_EX_VIDEO_NATIVE 0x80
+#define HDMI_EDID_EX_VIDEO_MASK0x7F
+#define HDMI_EDID_EX_VIDEO_MAX 35
+
+#define STANDARD_HDMI_TIMINGS_NB 34
+#define STANDARD_HDMI_TIMINGS_VESA_START 15
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+enum extension_edid_db {
+ DATABLOCK_AUDIO = 1,
+ DATABLOCK_VIDEO = 2,
+ DATABLOCK_VENDOR = 3,
+ DATABLOCK_SPEAKERS = 4,
+};
+
+struct img_edid {
+ bool pref;
+ int
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
Em 22-03-2011 14:32, Mythri P K escreveu: Adding support for common EDID parsing in kernel. EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA. There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information. With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well. Signed-off-by: Mythri P K mythr...@ti.com --- arch/arm/include/asm/edid.h | 243 ++ drivers/video/edid.c| 340 +++ Hmm... if you want this to be agnostic, the header file should not be inside arch/arm, but on some other place, like include/video/. 2 files changed, 583 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/edid.h create mode 100644 drivers/video/edid.c diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h new file mode 100644 index 000..843346a --- /dev/null +++ b/arch/arm/include/asm/edid.h @@ -0,0 +1,243 @@ +/* + * edid.h + * + * Copyright (C) 2011 Texas Instruments + * Author: Mythri P K mythr...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see http://www.gnu.org/licenses/. + * History: + */ + +#ifndef _EDID_H_ +#define _EDID_H_ + +/* HDMI EDID Length */ +#define HDMI_EDID_MAX_LENGTH 512 + +/* HDMI EDID Extension Data Block Tags */ +#define HDMI_EDID_EX_DATABLOCK_TAG_MASK 0xE0 +#define HDMI_EDID_EX_DATABLOCK_LEN_MASK 0x1F + +#define EDID_TIMING_DESCRIPTOR_SIZE 0x12 +#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36 +#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80 +#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4 +#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4 + +/* EDID Detailed Timing Info 0 begin offset */ +#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36 + +#define HDMI_EDID_PIX_CLK_OFFSET 0 +#define HDMI_EDID_H_ACTIVE_OFFSET2 +#define HDMI_EDID_H_BLANKING_OFFSET 3 +#define HDMI_EDID_V_ACTIVE_OFFSET5 +#define HDMI_EDID_V_BLANKING_OFFSET 6 +#define HDMI_EDID_H_SYNC_OFFSET 8 +#define HDMI_EDID_H_SYNC_PW_OFFSET 9 +#define HDMI_EDID_V_SYNC_OFFSET 10 +#define HDMI_EDID_V_SYNC_PW_OFFSET 11 +#define HDMI_EDID_H_IMAGE_SIZE_OFFSET12 +#define HDMI_EDID_V_IMAGE_SIZE_OFFSET13 +#define HDMI_EDID_H_BORDER_OFFSET15 +#define HDMI_EDID_V_BORDER_OFFSET16 +#define HDMI_EDID_FLAGS_OFFSET 17 + +/* HDMI EDID DTDs */ +#define HDMI_EDID_MAX_DTDS 4 + +/* HDMI EDID DTD Tags */ +#define HDMI_EDID_DTD_TAG_MONITOR_NAME 0xFC +#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM 0xFF +#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD +#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA +#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA 0xFB +#define HDMI_EDID_DTD_TAG_ASCII_STRING 0xFE + +#define HDMI_IMG_FORMAT_MAX_LENGTH 20 +#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10 + +/* HDMI EDID Extenion Data Block Values: Video */ +#define HDMI_EDID_EX_VIDEO_NATIVE0x80 +#define HDMI_EDID_EX_VIDEO_MASK 0x7F +#define HDMI_EDID_EX_VIDEO_MAX 35 + +#define STANDARD_HDMI_TIMINGS_NB 34
Re: [PATCH v2] New Jeilin dual-mode camera support
Em 14-03-2011 19:38, Patrice Chotard escreveu: I have forgotten to include the Documentation/video4linux/gspca.txt modification in my previous patch Patrice. Sportscam_DV15.patch Signed-off-by: Patrice CHOTARD patricechot...@free.fr Theodore Kilgore kilg...@banach.math.auburn.edu --- Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/jeilinj.c | 396 ++- 2 files changed, 345 insertions(+), 52 deletions(-) Please, don't send patches like that. It makes harder to handle. Instead, use: patch description Signed-off-by: Patrice CHOTARD patricechot...@free.fr Signed-off-by: Theodore Kilgore kilg...@banach.math.auburn.edu --- I have forgotten to include the Documentation/video4linux/gspca.txt modification in my previous patch (and/or any other review comments that you might have - everything between --- and the diff will be discarded by usual scripts). Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/jeilinj.c | 396 ++- 2 files changed, 345 insertions(+), 52 deletions(-) - /me is waiting for Jean-Francois final review, in order to apply it upstream. Thanks, Mauro -- 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
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote: Em 22-03-2011 14:32, Mythri P K escreveu: Adding support for common EDID parsing in kernel. EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA. There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information. With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well. Signed-off-by: Mythri P K mythr...@ti.com --- arch/arm/include/asm/edid.h | 243 ++ drivers/video/edid.c| 340 +++ Hmm... if you want this to be agnostic, the header file should not be inside arch/arm, but on some other place, like include/video/. Ironically this adds a drivers/video/edid.c but completely ignores drivers/video/edid.h which already exists and already contains many of these definitions. I like the idea of a generalized library, but it would be nice to see the existing edid.h evolved and its users updated incrementally. -- 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
Re: [PATCH -next] drivers:media:radio: wl128x: fix printk format and text
Em 18-03-2011 13:18, Randy Dunlap escreveu:
What happened to this driver in linux-next of 2011.0318?
It's in linux-next of 2011.0317.
Here's a patch that was prepared against linux-next of 2011.0317.
---
From: Randy Dunlap randy.dun...@oracle.com
Fix text spacing and grammar.
Fix printk format warning:
drivers/media/radio/wl128x/fmdrv_common.c:274: warning: format '%d' expects
type 'int', but argument 4 has type 'long unsigned int'
Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
drivers/media/radio/wl128x/fmdrv_common.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20110317.orig/drivers/media/radio/wl128x/fmdrv_common.c
+++ linux-next-20110317/drivers/media/radio/wl128x/fmdrv_common.c
@@ -271,8 +271,8 @@ static void recv_tasklet(unsigned long a
/* Process all packets in the RX queue */
while ((skb = skb_dequeue(fmdev-rx_q))) {
if (skb-len sizeof(struct fm_event_msg_hdr)) {
- fmerr(skb(%p) has only %d bytes
- atleast need %d bytes to decode\n, skb,
+ fmerr(skb(%p) has only %d bytes;
+ need at least %zd bytes to decode\n, skb,
skb-len, sizeof(struct fm_event_msg_hdr));
kfree_skb(skb);
continue;
Thanks, but it got superseeded by this one:
commit c6a721201f0ab67dc86709afe7b8f0e549bcdd07
Author: Hans Verkuil hverk...@xs4all.nl
AuthorDate: Sun Mar 6 09:30:02 2011 -0300
Commit: Mauro Carvalho Chehab mche...@redhat.com
CommitDate: Fri Mar 11 14:13:23 2011 -0300
[media] fmdrv_common.c: fix compiler warning
drivers/media/radio/wl128x/fmdrv_common.c: In function 'recv_tasklet':
drivers/media/radio/wl128x/fmdrv_common.c:274:4: warning: format '%d'
expects type 'int', but argument 4 has type 'long unsigned int'
The result of sizeof() should be printed with %zu.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
b/drivers/media/radio/wl128x/fmdrv_common.c
index 12f4c65..64454d3 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -271,8 +271,8 @@ static void recv_tasklet(unsigned long arg)
/* Process all packets in the RX queue */
while ((skb = skb_dequeue(fmdev-rx_q))) {
if (skb-len sizeof(struct fm_event_msg_hdr)) {
- fmerr(skb(%p) has only %d bytes
- atleast need %d bytes to decode\n, skb,
+ fmerr(skb(%p) has only %d bytes,
+ at least need %zu bytes to decode\n, skb,
skb-len, sizeof(struct fm_event_msg_hdr));
kfree_skb(skb);
continue;
Thanks,
Mauro
--
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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 22 March 2011 09:00, Mauro Carvalho Chehab mche...@redhat.com wrote:
Em 04-03-2011 20:11, Andrew de Quincey escreveu:
On 4 March 2011 22:59, Antti Palosaari cr...@iki.fi wrote:
On 03/05/2011 12:44 AM, Andrew de Quincey wrote:
Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner
accesses will take multiple i2c transactions.
Therefore, the following patch overrides the dvb_frontend_ops
functions to add a per-device lock around them: only one frontend can
now use the i2c bus at a time. Testing with the scripts above shows
this has eliminated the errors.
This have annoyed me too, but since it does not broken functionality much
I
haven't put much effort for fixing it. I like that fix since it is in
AF9015
driver where it logically belongs to. But it looks still rather complex.
I
see you have also considered bus lock to af9015_i2c_xfer() which could
be
much smaller in code size (that's I have tried to implement long time
back).
I would like to ask if it possible to check I2C gate open / close inside
af9015_i2c_xfer() and lock according that? Something like:
Hmm, I did think about that, but I felt overriding the functions was
just cleaner: I felt it was more obvious what it was doing. Doing
exactly this sort of tweaking was one of the main reasons we added
that function overriding feature.
I don't like the idea of returning error locked by FE since that'll
mean the tuning will randomly fail sometimes in a way visible to
userspace (unless we change the core dvb_frontend code), which was one
of the things I was trying to avoid. Unless, of course, I've
misunderstood your proposal.
Not returning error, but waiting in lock like that:
if (mutex_lock_interruptible(d-i2c_mutex) 0)
return -EAGAIN;
Ah k, sorry
However, looking at the code again, I realise it is possible to
simplify it. Since its only the demod gates that cause a problem, we
only /actually/ need to lock the get_frontend() and set_frontend()
calls.
I don't understand why .get_frontend() causes problem, since it does not
access tuner at all. It only reads demod registers. The main problem is
(like schema in af9015.c shows) that there is two tuners on same I2C bus
using same address. And demod gate is only way to open access for desired
tuner only.
AFAIR /some/ tuner code accesses the tuner hardware to read the exact
tuned frequency back on a get_frontend(); was just being extra
paranoid :)
You should block traffic based of tuner not demod. And I think those
callbacks which are needed for override are tuner driver callbacks. Consider
situation device goes it v4l-core calls same time both tuner .sleep() ==
problem.
Hmm, yeah, you're right, let me have another look tomorrow.
Andrew, Antti,
I'm understanding that I should wait for another patch on this subject, right?
Please let me know when you have a patch ready for me to apply.
Btw, I think that the long term solution would be, instead, to provide some
sort of
resource locking inside DVB (and V4L) core. I have here 3 devices not
supported yet that
uses the same tuner (and the same demod - DRX-K) for both DVB-C and DVB-T. It
would
be a way better to use some core-provided solution to prevent that both DVB-C
and DVB-T
would be used at the same time on such devices, instead of cloning the same
code
(or modified versions on it) on each driver that have such issues.
One solution could be to have a callback like:
enum dvb_fe_lock_type {
ATV_DEMOD_LOCK,
DTV_DEMOD_T_LOCK,
DTV_DEMOD_S_LOCK,
DTV_DEMOD_C_LOCK,
TUNER_T_LOCK,
TUNER_S_LOCK,
TUNER_C_LOCK,
TUNER_FM_LOCK,
FM_DEMOD_LOCK,
};
/**
* dvb_fe_lock - locks a frontend resource
* @fe: DVB frontend struct
* @type: type of resource to lock
* @lock: true indicates to lock the resource, false to unlock
*
* Returns true if the resource was locked, false otherwise.
* routine may wait for a pending transaction to happen before returning.
*/
bool (*dvb_fe_lock)(struct dvb_frontend *fe, enum dvb_fe_lock_type type, bool
lock);
What do you think?
Have to think on it, but it does sound sensible to do it in the core
if there are other things like this.
Definitely hold off on the dual patch though, as it doesn't fix the
tuner lockup issue I'm seeing unfortunately.
--
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
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
Adding dri-devel.
On Tue, Mar 22, 2011 at 1:32 PM, Mythri P K mythr...@ti.com wrote:
Adding support for common EDID parsing in kernel.
EDID - Extended display identification data is a data structure provided by
a digital display to describe its capabilities to a video source, This a
standard supported by CEA and VESA.
There are several custom implementations for parsing EDID in kernel, some
of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
parsing of EDID should be done in a library, which is agnostic of the
framework (V4l2, DRM, FB) which is using the functionality, just based on
the raw EDID pointer with size/segment information.
With other RFC's such as the one below, which tries to standardize HDMI API's
It would be better to have a common EDID code in one place.It also helps to
provide better interoperability with variety of TV/Monitor may be even by
listing out quirks which might get missed with several custom implementation
of EDID.
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
This patch tries to add functions to parse some portion EDID (detailed timing,
monitor limits, AV delay information, deep color mode support, Audio and VSDB)
If we can align on this library approach i can enhance this library to parse
other blocks and probably we could also add quirks from other implementation
as well.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/include/asm/edid.h | 243 ++
drivers/video/edid.c | 340
+++
2 files changed, 583 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/edid.h
create mode 100644 drivers/video/edid.c
diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
new file mode 100644
index 000..843346a
--- /dev/null
+++ b/arch/arm/include/asm/edid.h
@@ -0,0 +1,243 @@
+/*
+ * edid.h
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Mythri P K mythr...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ * History:
+ */
+
+#ifndef _EDID_H_
+#define _EDID_H_
+
+/* HDMI EDID Length */
+#define HDMI_EDID_MAX_LENGTH 512
+
+/* HDMI EDID Extension Data Block Tags */
+#define HDMI_EDID_EX_DATABLOCK_TAG_MASK 0xE0
+#define HDMI_EDID_EX_DATABLOCK_LEN_MASK 0x1F
+
+#define EDID_TIMING_DESCRIPTOR_SIZE 0x12
+#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
+#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
+#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
+#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
+
+/* EDID Detailed Timing Info 0 begin offset */
+#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36
+
+#define HDMI_EDID_PIX_CLK_OFFSET 0
+#define HDMI_EDID_H_ACTIVE_OFFSET 2
+#define HDMI_EDID_H_BLANKING_OFFSET 3
+#define HDMI_EDID_V_ACTIVE_OFFSET 5
+#define HDMI_EDID_V_BLANKING_OFFSET 6
+#define HDMI_EDID_H_SYNC_OFFSET 8
+#define HDMI_EDID_H_SYNC_PW_OFFSET 9
+#define HDMI_EDID_V_SYNC_OFFSET 10
+#define HDMI_EDID_V_SYNC_PW_OFFSET 11
+#define HDMI_EDID_H_IMAGE_SIZE_OFFSET 12
+#define HDMI_EDID_V_IMAGE_SIZE_OFFSET 13
+#define HDMI_EDID_H_BORDER_OFFSET 15
+#define HDMI_EDID_V_BORDER_OFFSET 16
+#define HDMI_EDID_FLAGS_OFFSET 17
+
+/* HDMI EDID DTDs */
+#define HDMI_EDID_MAX_DTDS 4
+
+/* HDMI EDID DTD Tags */
+#define HDMI_EDID_DTD_TAG_MONITOR_NAME 0xFC
+#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM 0xFF
+#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD
+#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
+#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA 0xFB
+#define HDMI_EDID_DTD_TAG_ASCII_STRING 0xFE
+
+#define HDMI_IMG_FORMAT_MAX_LENGTH 20
+#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10
+
+/* HDMI EDID Extenion Data Block Values: Video */
+#define HDMI_EDID_EX_VIDEO_NATIVE 0x80
+#define HDMI_EDID_EX_VIDEO_MASK 0x7F
+#define HDMI_EDID_EX_VIDEO_MAX 35
+
+#define STANDARD_HDMI_TIMINGS_NB 34
+#define STANDARD_HDMI_TIMINGS_VESA_START 15
+
+#ifdef __cplusplus
+extern C {
+#endif
Re: [patch] Fix AF9015 Dual tuner i2c write failures
Em 22-03-2011 15:26, adq escreveu:
On 22 March 2011 09:00, Mauro Carvalho Chehab mche...@redhat.com wrote:
Em 04-03-2011 20:11, Andrew de Quincey escreveu:
On 4 March 2011 22:59, Antti Palosaari cr...@iki.fi wrote:
On 03/05/2011 12:44 AM, Andrew de Quincey wrote:
Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner
accesses will take multiple i2c transactions.
Therefore, the following patch overrides the dvb_frontend_ops
functions to add a per-device lock around them: only one frontend can
now use the i2c bus at a time. Testing with the scripts above shows
this has eliminated the errors.
This have annoyed me too, but since it does not broken functionality much
I
haven't put much effort for fixing it. I like that fix since it is in
AF9015
driver where it logically belongs to. But it looks still rather complex.
I
see you have also considered bus lock to af9015_i2c_xfer() which could
be
much smaller in code size (that's I have tried to implement long time
back).
I would like to ask if it possible to check I2C gate open / close inside
af9015_i2c_xfer() and lock according that? Something like:
Hmm, I did think about that, but I felt overriding the functions was
just cleaner: I felt it was more obvious what it was doing. Doing
exactly this sort of tweaking was one of the main reasons we added
that function overriding feature.
I don't like the idea of returning error locked by FE since that'll
mean the tuning will randomly fail sometimes in a way visible to
userspace (unless we change the core dvb_frontend code), which was one
of the things I was trying to avoid. Unless, of course, I've
misunderstood your proposal.
Not returning error, but waiting in lock like that:
if (mutex_lock_interruptible(d-i2c_mutex) 0)
return -EAGAIN;
Ah k, sorry
However, looking at the code again, I realise it is possible to
simplify it. Since its only the demod gates that cause a problem, we
only /actually/ need to lock the get_frontend() and set_frontend()
calls.
I don't understand why .get_frontend() causes problem, since it does not
access tuner at all. It only reads demod registers. The main problem is
(like schema in af9015.c shows) that there is two tuners on same I2C bus
using same address. And demod gate is only way to open access for desired
tuner only.
AFAIR /some/ tuner code accesses the tuner hardware to read the exact
tuned frequency back on a get_frontend(); was just being extra
paranoid :)
You should block traffic based of tuner not demod. And I think those
callbacks which are needed for override are tuner driver callbacks.
Consider
situation device goes it v4l-core calls same time both tuner .sleep() ==
problem.
Hmm, yeah, you're right, let me have another look tomorrow.
Andrew, Antti,
I'm understanding that I should wait for another patch on this subject,
right?
Please let me know when you have a patch ready for me to apply.
Btw, I think that the long term solution would be, instead, to provide some
sort of
resource locking inside DVB (and V4L) core. I have here 3 devices not
supported yet that
uses the same tuner (and the same demod - DRX-K) for both DVB-C and DVB-T.
It would
be a way better to use some core-provided solution to prevent that both
DVB-C and DVB-T
would be used at the same time on such devices, instead of cloning the same
code
(or modified versions on it) on each driver that have such issues.
One solution could be to have a callback like:
enum dvb_fe_lock_type {
ATV_DEMOD_LOCK,
DTV_DEMOD_T_LOCK,
DTV_DEMOD_S_LOCK,
DTV_DEMOD_C_LOCK,
TUNER_T_LOCK,
TUNER_S_LOCK,
TUNER_C_LOCK,
TUNER_FM_LOCK,
FM_DEMOD_LOCK,
};
/**
* dvb_fe_lock - locks a frontend resource
* @fe: DVB frontend struct
* @type: type of resource to lock
* @lock: true indicates to lock the resource, false to unlock
*
* Returns true if the resource was locked, false otherwise.
* routine may wait for a pending transaction to happen before returning.
*/
bool (*dvb_fe_lock)(struct dvb_frontend *fe, enum dvb_fe_lock_type type,
bool lock);
What do you think?
Have to think on it, but it does sound sensible to do it in the core
if there are other things like this.
Yes, but the current way it is done right now (e. g. the standard i2c gate
control) is not fitting anymore. There are tons of cases where it is not
covered,
and several different implementations to work around it. On complex devices like
cx231xx (that has 4 I2C buses, one of them with an internal switch inside the
bridge chip), locking it at I2C level is not enough.
So, it is better to provide a new way and replace the existing methods with the
new one were required.
Definitely hold off on the dual patch though, as it doesn't fix the
tuner lockup issue I'm seeing unfortunately.
Ok, I'll mark those patches as Rejected at patchwork and I'll wait for a new
set.
Re: [RFC PATCH 1/3] tea575x-tuner: various improvements
Em 21-03-2011 08:48, Takashi Iwai escreveu:
At Sat, 19 Mar 2011 16:32:53 +0100,
Ondrej Zary wrote:
Improve tea575x-tuner with various good things from radio-maestro:
- extend frequency range to 50-150MHz
- fix querycap(): card name, CAP_RADIO
- improve g_tuner(): CAP_STEREO, stereo and tuned indication
- improve g_frequency(): tuner index checking and reading frequency from HW
- improve s_frequency(): tuner index and type checking
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Applied these 3 patches now to topic/misc branch of sound git tree
(i.e. for 2.6.40 kernel).
Patches look sane to me, you may add my ACK if you want.
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
I leave the removal of radio-maestro to v4l guys, as this is fairly
independent.
thanks,
Takashi
--- linux-2.6.38-rc4-orig/sound/i2c/other/tea575x-tuner.c2011-02-08
01:03:55.0 +0100
+++ linux-2.6.38-rc4/sound/i2c/other/tea575x-tuner.c 2011-03-19
15:40:14.0 +0100
@@ -37,8 +37,8 @@ static int radio_nr = -1;
module_param(radio_nr, int, 0);
#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
-#define FREQ_LO (87 * 16000)
-#define FREQ_HI (108 * 16000)
+#define FREQ_LO (50UL * 16000)
+#define FREQ_HI (150UL * 16000)
/*
* definitions
@@ -77,15 +77,29 @@ static struct v4l2_queryctrl radio_qctrl
* lowlevel part
*/
+static void snd_tea575x_get_freq(struct snd_tea575x *tea)
+{
+unsigned long freq;
+
+freq = tea-ops-read(tea) TEA575X_BIT_FREQ_MASK;
+/* freq *= 12.5 */
+freq *= 125;
+freq /= 10;
+/* crystal fixup */
+if (tea-tea5759)
+freq += tea-freq_fixup;
+else
+freq -= tea-freq_fixup;
+
+tea-freq = freq * 16; /* from kHz */
+}
+
static void snd_tea575x_set_freq(struct snd_tea575x *tea)
{
unsigned long freq;
-freq = tea-freq / 16; /* to kHz */
-if (freq 108000)
-freq = 108000;
-if (freq 87000)
-freq = 87000;
+freq = clamp(tea-freq, FREQ_LO, FREQ_HI);
+freq /= 16; /* to kHz */
/* crystal fixup */
if (tea-tea5759)
freq -= tea-freq_fixup;
@@ -109,29 +123,33 @@ static int vidioc_querycap(struct file *
{
struct snd_tea575x *tea = video_drvdata(file);
-strcpy(v-card, tea-tea5759 ? TEA5759 : TEA5757);
strlcpy(v-driver, tea575x-tuner, sizeof(v-driver));
-strlcpy(v-card, Maestro Radio, sizeof(v-card));
+strlcpy(v-card, tea-tea5759 ? TEA5759 : TEA5757, sizeof(v-card));
sprintf(v-bus_info, PCI);
v-version = RADIO_VERSION;
-v-capabilities = V4L2_CAP_TUNER;
+v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
return 0;
}
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
+struct snd_tea575x *tea = video_drvdata(file);
+
if (v-index 0)
return -EINVAL;
+tea-ops-read(tea);
+
strcpy(v-name, FM);
v-type = V4L2_TUNER_RADIO;
+v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
v-rangelow = FREQ_LO;
v-rangehigh = FREQ_HI;
-v-rxsubchans = V4L2_TUNER_SUB_MONO|V4L2_TUNER_SUB_STEREO;
-v-capability = V4L2_TUNER_CAP_LOW;
-v-audmode = V4L2_TUNER_MODE_MONO;
-v-signal = 0x;
+v-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
+v-audmode = tea-stereo ? V4L2_TUNER_MODE_STEREO :
V4L2_TUNER_MODE_MONO;
+v-signal = tea-tuned ? 0x : 0;
+
return 0;
}
@@ -148,7 +166,10 @@ static int vidioc_g_frequency(struct fil
{
struct snd_tea575x *tea = video_drvdata(file);
+if (f-tuner != 0)
+return -EINVAL;
f-type = V4L2_TUNER_RADIO;
+snd_tea575x_get_freq(tea);
f-frequency = tea-freq;
return 0;
}
@@ -158,6 +179,9 @@ static int vidioc_s_frequency(struct fil
{
struct snd_tea575x *tea = video_drvdata(file);
+if (f-tuner != 0 || f-type != V4L2_TUNER_RADIO)
+return -EINVAL;
+
if (f-frequency FREQ_LO || f-frequency FREQ_HI)
return -EINVAL;
--- linux-2.6.38-rc4-orig/include/sound/tea575x-tuner.h 2011-02-08
01:03:55.0 +0100
+++ linux-2.6.38-rc4/include/sound/tea575x-tuner.h 2011-03-19
14:18:06.0 +0100
@@ -38,8 +38,10 @@ struct snd_tea575x {
struct snd_card *card;
struct video_device *vd;/* video device */
int dev_nr; /* requested device number + 1 */
-int tea5759;/* 5759 chip is present */
-int mute; /* Device is muted? */
+bool tea5759; /* 5759 chip is present */
+bool mute; /* Device is muted? */
+bool stereo;/* receiving stereo */
+bool tuned; /* tuned to a station
Re: [RFC PATCH 4/3] remove radio-maestro
Hi Takashi, Em 19-03-2011 13:23, Ondrej Zary escreveu: Remove broken radio-maestro driver as the radio functionality is now integrated in the es1968 driver. I prefer if you could also add it on your tree, as we want to make sure that this patch will be applied together with the patches that moved Maestro support into the es1968 driver. I have no means to test if the es1968 changes work with a Maestro radio (as I don't have this hardware), but I'm OK with this change. So: Acked-by: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Ondrej Zary li...@rainbow-software.org diff -urNp linux-2.6.38-rc4-orig/drivers/media/radio/Kconfig linux-2.6.38-rc4/drivers/media/radio/Kconfig --- linux-2.6.38-rc4-orig/drivers/media/radio/Kconfig 2011-02-08 01:03:55.0 +0100 +++ linux-2.6.38-rc4/drivers/media/radio/Kconfig 2011-03-19 17:12:32.0 +0100 @@ -166,21 +166,6 @@ config RADIO_MAXIRADIO To compile this driver as a module, choose M here: the module will be called radio-maxiradio. -config RADIO_MAESTRO - tristate Maestro on board radio - depends on VIDEO_V4L2 PCI - ---help--- - Say Y here to directly support the on-board radio tuner on the - Maestro 2 or 2E sound card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to v4l programs may be found at - file:Documentation/video4linux/API.html. - - To compile this driver as a module, choose M here: the - module will be called radio-maestro. - config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio depends on ISA VIDEO_V4L2 SND diff -urNp linux-2.6.38-rc4-orig/drivers/media/radio/Makefile linux-2.6.38-rc4/drivers/media/radio/Makefile --- linux-2.6.38-rc4-orig/drivers/media/radio/Makefile2011-02-08 01:03:55.0 +0100 +++ linux-2.6.38-rc4/drivers/media/radio/Makefile 2011-03-19 17:12:39.0 +0100 @@ -16,7 +16,6 @@ obj-$(CONFIG_RADIO_GEMTEK) += radio-gemt obj-$(CONFIG_RADIO_TRUST) += radio-trust.o obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o -obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_RADIO_SI470X) += si470x/ diff -urNp linux-2.6.38-rc4-orig/drivers/media/radio/radio-maestro.c linux-2.6.38-rc4/drivers/media/radio/radio-maestro.c --- linux-2.6.38-rc4-orig/drivers/media/radio/radio-maestro.c 2011-02-08 01:03:55.0 +0100 +++ linux-2.6.38-rc4/drivers/media/radio/radio-maestro.c 1970-01-01 01:00:00.0 +0100 @@ -1,452 +0,0 @@ -/* Maestro PCI sound card radio driver for Linux support - * (c) 2000 A. Tlalka, at...@pg.gda.pl - * Notes on the hardware - * - * + Frequency control is done digitally - * + No volume control - only mute/unmute - you have to use Aux line volume - * control on Maestro card to set the volume - * + Radio status (tuned/not_tuned and stereo/mono) is valid some time after - * frequency setting (100ms) and only when the radio is unmuted. - * version 0.02 - * + io port is automatically detected - only the first radio is used - * version 0.03 - * + thread access locking additions - * version 0.04 - * + code improvements - * + VIDEO_TUNER_LOW is permanent - * - * Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org - */ - -#include linux/module.h -#include linux/init.h -#include linux/ioport.h -#include linux/delay.h -#include linux/version.h /* for KERNEL_VERSION MACRO */ -#include linux/pci.h -#include linux/videodev2.h -#include linux/io.h -#include linux/slab.h -#include media/v4l2-device.h -#include media/v4l2-ioctl.h - -MODULE_AUTHOR(Adam Tlalka, at...@pg.gda.pl); -MODULE_DESCRIPTION(Radio driver for the Maestro PCI sound card radio.); -MODULE_LICENSE(GPL); - -static int radio_nr = -1; -module_param(radio_nr, int, 0); - -#define RADIO_VERSION KERNEL_VERSION(0, 0, 6) -#define DRIVER_VERSION 0.06 - -#define GPIO_DATA0x60 /* port offset from ESS_IO_BASE */ - -#define IO_MASK 4 /* mask register offset from GPIO_DATA - bits 1=unmask write to given bit */ -#define IO_DIR 8 /* direction register offset from GPIO_DATA - bits 0/1=read/write direction */ - -#define GPIO60x0040 /* mask bits for GPIO lines */ -#define GPIO70x0080 -#define GPIO80x0100 -#define GPIO90x0200 - -#define STR_DATA GPIO6 /* radio TEA5757 pins and GPIO bits */ -#define STR_CLK GPIO7 -#define STR_WREN GPIO8 -#define STR_MOST GPIO9 - -#define FREQ_LO 50*16000 -#define FREQ_HI 150*16000 - -#define
Re: Prof_Revolution_DVB-S2_8000_PCI-E Linux Kernel 2.6.38-rc8-next-20110314
Em 20-03-2011 16:32, Wojciech Myrda escreveu:
It turns ot that revised patch not only applies cleanly but compiles as
well agaist Linux Kernel 2.6.38-rc8-next-20110321. Looking at dmesg
everything is recognized properly as well. Do you guys think if it is
possible to include it into the tree?
Please post the patch again, with a few fixes (see bellow), and add your
Signed-off-by: (please read how to submit patches section at linuxtv.org wiki
for more details).
diff -r 1da5fed5c8b2 linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c Sun Sep 19
02:23:09 2010 -0300
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c Sat Oct 02
11:19:50 2010 +0300
/linux? Are you using the old -hg tree? Please don't do that. The mercurial
tree is not touched for the last 8 months! Please use, instead the
media_tree.git
(media_build.git allows you to compile/test a driver against the media_tree.git
tree).
@@ -169,6 +169,10 @@
.name = TurboSight TBS 6920,
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_PROF_8000] = {
+ .name = Prof Revolution DVB-S2 8000,
+ .portb = CX23885_MPEG_DVB,
+ },
[CX23885_BOARD_TEVII_S470] = {
.name = TeVii S470,
.portb = CX23885_MPEG_DVB,
@@ -388,6 +392,10 @@
.subdevice = 0x,
.card = CX23885_BOARD_TBS_6920,
}, {
+ .subvendor = 0x8000,
+ .subdevice = 0x3034,
+ .card = CX23885_BOARD_PROF_8000,
+ }, {
.subvendor = 0xd470,
.subdevice = 0x9022,
.card = CX23885_BOARD_TEVII_S470,
@@ -813,6 +821,7 @@
mdelay(20);
cx_set(GP0_IO, 0x00040004);
break;
+ case CX23885_BOARD_PROF_8000:
case CX23885_BOARD_TBS_6920:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
@@ -1043,6 +1052,7 @@
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
+ case CX23885_BOARD_PROF_8000:
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_DVBWORLD_2005:
ts1-gen_ctrl_val = 0x5; /* Parallel */
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c.old 2011-03-20
08:20:37.384001338 +0100
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c 2011-03-20
08:29:56.757001476 +0100
@@ -47,6 +47,9 @@
#include dibx000_common.h
#include zl10353.h
#include stv0900.h
+#include stb6100.h
+#include stb6100_proc.h
+#include stv0900.h
If you're adding more dependencies here, you'll need to touch also
drivers/media/video/cx23885/Kconfig
in order to select the right frontends.
#include stv0900_reg.h
#include stv6110.h
#include lnbh24.h
@@ -478,6 +478,35 @@
.if_khz = 5380,
};
+static int p8000_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t
voltage)
+{
+ struct cx23885_tsport *port = fe-dvb-priv;
+ struct cx23885_dev *dev = port-dev;
+
+ if (voltage == SEC_VOLTAGE_18)
+ cx_write(MC417_RWD, 0x1e00);
+ else if (voltage == SEC_VOLTAGE_13)
+ cx_write(MC417_RWD, 0x1a00);
+ else
+ cx_write(MC417_RWD, 0x1800);
+ return 0;
+}
+
+static struct stv0900_config prof_8000_stv0900_config = {
+ .demod_address = 0x6a,
+ .xtal = 2700,
+ .clkmode = 3,
+ .diseqc_mode = 2,
+ .tun1_maddress = 0,
+ .tun1_adc = 0,
+ .path1_mode = 3,
+};
+
+static struct stb6100_config prof_8000_stb6100_config = {
+ .tuner_address = 0x60,
+ .refclock = 2700,
+};
+
static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
struct dvb_frontend_parameters *param)
{
@@ -1094,6 +1123,29 @@
goto frontend_detach;
}
break;
+ case CX23885_BOARD_PROF_8000: {
+ struct dvb_tuner_ops *tuner_ops = NULL;
+
+ i2c_bus = dev-i2c_bus[0];
+ fe0-dvb.frontend = dvb_attach(stv0900_attach,
+ prof_8000_stv0900_config,
+ i2c_bus-i2c_adap, 0);
+ if (fe0-dvb.frontend != NULL) {
+ if (dvb_attach(stb6100_attach, fe0-dvb.frontend,
+ prof_8000_stb6100_config,
+ i2c_bus-i2c_adap)) {
+ tuner_ops = fe0-dvb.frontend-ops.tuner_ops;
+ tuner_ops-set_frequency = stb6100_set_freq;
+ tuner_ops-get_frequency = stb6100_get_freq;
+ tuner_ops-set_bandwidth =
New Signed-off-by and copyright starting with 2.6.40
Hi all, Just a short announcement that starting with 2.6.40 any V4L work I do will have a Cisco Signed-of-by line and Cisco copyright instead of my regular email and personal copyright. Until recently all the V4L work I did was separate (although sponsored) from my normal job at Cisco, but those boundaries were getting very murky indeed. So to simplify things I'll be switching over to a Cisco SoB and copyright for any future patches. This also means that this work is no longer sponsored but that it is now part of my regular job. I'll miss that 'sponsored by' signature :-) There are no other changes, this is just a formality. Regards, Hans -- 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
Re: [RFC PATCH 1/3] tea575x-tuner: various improvements
On Saturday, March 19, 2011 16:32:53 Ondrej Zary wrote:
Improve tea575x-tuner with various good things from radio-maestro:
- extend frequency range to 50-150MHz
- fix querycap(): card name, CAP_RADIO
- improve g_tuner(): CAP_STEREO, stereo and tuned indication
- improve g_frequency(): tuner index checking and reading frequency from HW
- improve s_frequency(): tuner index and type checking
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Acked-by: Hans Verkuil hverk...@xs4all.nl
BTW, can you run the v4l2-compliance utility for the two boards that use
this radio tuner?
This utility is part of the v4l-utils repository
(http://git.linuxtv.org/v4l-utils.git).
Run as 'v4l2-compliance -r /dev/radioX -v2'.
I'm sure there will be some errors/warnings (warnings regarding G/S_PRIORITY
are to be expected). But I can use it to make a patch for 2.6.40 that fixes
any issues.
Regards,
Hans
--- linux-2.6.38-rc4-orig/sound/i2c/other/tea575x-tuner.c 2011-02-08
01:03:55.0 +0100
+++ linux-2.6.38-rc4/sound/i2c/other/tea575x-tuner.c 2011-03-19
15:40:14.0 +0100
@@ -37,8 +37,8 @@ static int radio_nr = -1;
module_param(radio_nr, int, 0);
#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
-#define FREQ_LO (87 * 16000)
-#define FREQ_HI (108 * 16000)
+#define FREQ_LO (50UL * 16000)
+#define FREQ_HI (150UL * 16000)
/*
* definitions
@@ -77,15 +77,29 @@ static struct v4l2_queryctrl radio_qctrl
* lowlevel part
*/
+static void snd_tea575x_get_freq(struct snd_tea575x *tea)
+{
+ unsigned long freq;
+
+ freq = tea-ops-read(tea) TEA575X_BIT_FREQ_MASK;
+ /* freq *= 12.5 */
+ freq *= 125;
+ freq /= 10;
+ /* crystal fixup */
+ if (tea-tea5759)
+ freq += tea-freq_fixup;
+ else
+ freq -= tea-freq_fixup;
+
+ tea-freq = freq * 16; /* from kHz */
+}
+
static void snd_tea575x_set_freq(struct snd_tea575x *tea)
{
unsigned long freq;
- freq = tea-freq / 16; /* to kHz */
- if (freq 108000)
- freq = 108000;
- if (freq 87000)
- freq = 87000;
+ freq = clamp(tea-freq, FREQ_LO, FREQ_HI);
+ freq /= 16; /* to kHz */
/* crystal fixup */
if (tea-tea5759)
freq -= tea-freq_fixup;
@@ -109,29 +123,33 @@ static int vidioc_querycap(struct file *
{
struct snd_tea575x *tea = video_drvdata(file);
- strcpy(v-card, tea-tea5759 ? TEA5759 : TEA5757);
strlcpy(v-driver, tea575x-tuner, sizeof(v-driver));
- strlcpy(v-card, Maestro Radio, sizeof(v-card));
+ strlcpy(v-card, tea-tea5759 ? TEA5759 : TEA5757, sizeof(v-card));
sprintf(v-bus_info, PCI);
v-version = RADIO_VERSION;
- v-capabilities = V4L2_CAP_TUNER;
+ v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
return 0;
}
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
+ struct snd_tea575x *tea = video_drvdata(file);
+
if (v-index 0)
return -EINVAL;
+ tea-ops-read(tea);
+
strcpy(v-name, FM);
v-type = V4L2_TUNER_RADIO;
+ v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
v-rangelow = FREQ_LO;
v-rangehigh = FREQ_HI;
- v-rxsubchans = V4L2_TUNER_SUB_MONO|V4L2_TUNER_SUB_STEREO;
- v-capability = V4L2_TUNER_CAP_LOW;
- v-audmode = V4L2_TUNER_MODE_MONO;
- v-signal = 0x;
+ v-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
+ v-audmode = tea-stereo ? V4L2_TUNER_MODE_STEREO :
V4L2_TUNER_MODE_MONO;
+ v-signal = tea-tuned ? 0x : 0;
+
return 0;
}
@@ -148,7 +166,10 @@ static int vidioc_g_frequency(struct fil
{
struct snd_tea575x *tea = video_drvdata(file);
+ if (f-tuner != 0)
+ return -EINVAL;
f-type = V4L2_TUNER_RADIO;
+ snd_tea575x_get_freq(tea);
f-frequency = tea-freq;
return 0;
}
@@ -158,6 +179,9 @@ static int vidioc_s_frequency(struct fil
{
struct snd_tea575x *tea = video_drvdata(file);
+ if (f-tuner != 0 || f-type != V4L2_TUNER_RADIO)
+ return -EINVAL;
+
if (f-frequency FREQ_LO || f-frequency FREQ_HI)
return -EINVAL;
--- linux-2.6.38-rc4-orig/include/sound/tea575x-tuner.h 2011-02-08
01:03:55.0 +0100
+++ linux-2.6.38-rc4/include/sound/tea575x-tuner.h2011-03-19
14:18:06.0 +0100
@@ -38,8 +38,10 @@ struct snd_tea575x {
struct snd_card *card;
struct video_device *vd;/* video device */
int dev_nr; /* requested device number + 1 */
- int tea5759;/* 5759 chip is present */
- int mute; /* Device is muted? */
+ bool tea5759; /* 5759 chip is present */
+
Re: S2-3200 switching-timeouts on 2.6.38
Hello Rico, On Tue, Mar 22, 2011 at 5:03 PM, Rico Tzschichholz ric...@t-online.de wrote: Hello Manu, Actually, quite a lot of effort was put in to get that part right. It does the reverse thing that's to be done. The revamped version is here [1] If the issue persists still, then it needs to be investigated further. [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html I am not sure how this is related to stb6100? Does that mean the current stb0899 patch [2] isnt ready to be proposed for 2.6.39 yet? Or does the stb6100 patch has a better design to solve this issue which should be adapted for stb0899 then? I was hoping to see it included before the merge window is closed again. [2] https://patchwork.kernel.org/patch/244201/ stb0899 is a channel decoder (or demodulator in other words) while the stb6100 is a tuner which provides I-Q components to the demod. When a tuner locks to a transponder, in the spectrum in the absence of a signal, it will be contain White (Gaussian) noise. In such a case the demod has a hard time to lock to the signal. In this particular case, we had a bit of luck additionally, ie we found a case where the stb0899 demodulator functioned perfectly well with another tuner, but with the same hardware configuration. This helped in narrowing the bug to the tuner and hence the fix. The one in patchwork, does modify the step size but that doesn't reduce the white noise, which is something like a lucky dip. (similar to what Bjorn pointed out in another post.) I am not really sure whether modifying the step size of any benefit/disadvantage, but need to do some research on that aspect. Best Regards, Manu ] -- 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
[GIT PULL] IR Updates for 2.6.39
This heaping helping of patches goes a long way to improve the lirc_zilog driver (courtesy of Andy Walls) to the point where it no longer crashes and burns if you unplug a device while its loaded and cleans up a fair bit of inconsistent key mappings, as well as making the Hauppauge-specific keymaps much cleaner, with ir-kbd-i2c properly passing entire rc5 scancodes, making use of non-Hauppauge RC5 remotes with Hauppauge i2c-based receivers work much better (all courtesy of Mauro Carvalho Chehab). I fixed a few little things here and there too, and tested out the zilog and ir-kbd-i2c changes. This series does include a rewritten i2c master for the hdpvr, based heavily on the pvrusb2 driver's i2c master, which in theory, was going to make it behave better, but has had no noticeable impact yet. However, it may also be necessary for some more forthcoming lirc_zilog changes based on Devin Heitmueller's work for the Hauppauge Broadway device. There's also a small change to the NEC IR decoder, which will make it try passing along full 32-bit scancodes if/when the command/not_command checksum test fails. Should be of no consequence for existing keymaps, and allow the creation of full 32-bit ones for the likes of the Apple and TiVo remotes I've got. (Patches adding those forthcoming). The following changes since commit 97ad124749a060d8c4f546911474db3b555f: ite-cir: Fix a breakage caused by my cleanup patch (2011-03-22 17:20:34 -0300) are available in the git repository at: git+ssh://ja...@master.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-ir.git/ staging Andy Walls (13): lirc_zilog: Restore checks for existence of the IR_tx object lirc_zilog: Remove broken, ineffective reference counting lirc_zilog: Convert ir_device instance array to a linked list lirc_zilog: Convert the instance open count to an atomic_t lirc_zilog: Use kernel standard methods for marking device non-seekable lirc_zilog: Don't acquire the rx-buf_lock in the poll() function lirc_zilog: Remove unneeded rx-buf_lock lirc_zilog: Always allocate a Rx lirc_buffer object lirc_zilog: Move constants from ir_probe() into the lirc_driver template lirc_zilog: Add ref counting of struct IR, IR_tx, and IR_rx lirc_zilog: Add locking of the i2c_clients when in use lirc_zilog: Fix somewhat confusing information messages in ir_probe() lirc_zilog: Update TODO list based on work completed and revised plans Jarod Wilson (9): docs: fix typo in lirc_device_interface.xml imon: add more panel scancode mappings hdpvr: i2c master enhancements ir-kbd-i2c: pass device code w/key in hauppauge case hdpvr: use same polling interval as other OS lirc: silence some compile warnings lirc_zilog: error out if buffer read bytes != chunk size mceusb: topseed 0x0011 needs gen3 init for tx to work rc: interim support for 32-bit NEC-ish scancodes Mauro Carvalho Chehab (14): rc/keymaps: use KEY_CAMERA for snapshots rc/keymaps: Use KEY_VIDEO for Video Source rc/keymaps: Fix most KEY_PROG[n] keycodes rc/keymaps: Use KEY_LEFTMETA were pertinent dw2102: Use multimedia keys instead of an app-specific mapping opera1: Use multimedia keys instead of an app-specific mapping a800: Fix a few wrong IR key assignments rc-winfast: Fix the keycode tables rc-rc5-hauppauge-new: Add the old control to the table rc-rc5-hauppauge-new: Add support for the old Black RC rc-rc5-hauppauge-new: Fix Hauppauge Grey mapping rc/keymaps: Rename Hauppauge table as rc-hauppauge remove the old RC_MAP_HAUPPAUGE_NEW RC map [media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap .../DocBook/v4l/lirc_device_interface.xml |2 +- drivers/media/dvb/dvb-usb/a800.c |8 +- drivers/media/dvb/dvb-usb/digitv.c |2 +- drivers/media/dvb/dvb-usb/dw2102.c | 40 +- drivers/media/dvb/dvb-usb/opera1.c | 33 +- drivers/media/dvb/siano/sms-cards.c|2 +- drivers/media/dvb/ttpci/budget-ci.c| 15 +- drivers/media/rc/imon.c| 11 +- drivers/media/rc/ir-nec-decoder.c | 10 +- drivers/media/rc/keymaps/Makefile |4 +- drivers/media/rc/keymaps/rc-adstech-dvb-t-pci.c|6 +- drivers/media/rc/keymaps/rc-avermedia-dvbt.c |4 +- drivers/media/rc/keymaps/rc-avermedia-m135a.c |2 +- .../media/rc/keymaps/rc-avermedia-m733a-rm-k6.c|2 +- drivers/media/rc/keymaps/rc-avermedia-rm-ks.c |2 +- drivers/media/rc/keymaps/rc-behold-columbus.c |2 +- drivers/media/rc/keymaps/rc-behold.c |2 +- drivers/media/rc/keymaps/rc-budget-ci-old.c|3 +- drivers/media/rc/keymaps/rc-cinergy.c |2 +- drivers/media/rc/keymaps/rc-dntv-live-dvb-t.c |
Re: [PATCH] [media] mantis: trivial module parameter documentation fix
2011/3/22 Bjørn Mork bj...@mork.no: The default for verbose is 0. Update description to match. Signed-off-by: Bjørn Mork bj...@mork.no --- drivers/media/dvb/mantis/hopper_cards.c | 2 +- drivers/media/dvb/mantis/mantis_cards.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb/mantis/hopper_cards.c b/drivers/media/dvb/mantis/hopper_cards.c index 70e73af..1402062 100644 --- a/drivers/media/dvb/mantis/hopper_cards.c +++ b/drivers/media/dvb/mantis/hopper_cards.c @@ -44,7 +44,7 @@ static unsigned int verbose; module_param(verbose, int, 0644); -MODULE_PARM_DESC(verbose, verbose startup messages, default is 1 (yes)); +MODULE_PARM_DESC(verbose, verbose startup messages, default is 0 (no)); #define DRIVER_NAME Hopper diff --git a/drivers/media/dvb/mantis/mantis_cards.c b/drivers/media/dvb/mantis/mantis_cards.c index 40da225..05cbb9d 100644 --- a/drivers/media/dvb/mantis/mantis_cards.c +++ b/drivers/media/dvb/mantis/mantis_cards.c @@ -52,7 +52,7 @@ static unsigned int verbose; module_param(verbose, int, 0644); -MODULE_PARM_DESC(verbose, verbose startup messages, default is 1 (yes)); +MODULE_PARM_DESC(verbose, verbose startup messages, default is 0 (no)); static int devs; -- 1.7.2.5 -- Thanks. Acked-by: Manu Abraham m...@linuxtv.org -- 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
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
On Mon, 2011-03-21 at 21:40 -0300, Mauro Carvalho Chehab wrote: Em 21-03-2011 21:32, Malcolm Priestley escreveu: On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote: Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 1.76 relates to remote control patches. https://patchwork.kernel.org/patch/499391/ https://patchwork.kernel.org/patch/499401/ Ah! Ok, I'll be applying them. Btw, please, move the keycode tables to the proper place and use the RC core stuff. The idea is to remove all those keytables from kernel in a near future, and use the userspace tool to load it via udev. For some reason patch to 1.81(552551) was also missing from the Patchwork list earlier, although it is there now. https://patchwork.kernel.org/patch/553551/ I will put the RC on the TODO list and hope to complete in the near future. Regards Malcolm -- 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
[PULL] soc-camera: 4 more feature-commits for 2.6.39
Hi Mauro The following changes since commit c002e112822c2fe152e55feb5db036c642681b1a: [media] stv0367: typo in function parameter (2011-03-22 07:00:39 -0300) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.39 Guennadi Liakhovetski (1): V4L: soc-camera: explicitly require V4L2_BUF_TYPE_VIDEO_CAPTURE Pawel Osciak (2): sh_mobile_ceu_camera: Do not call vb2's mem_ops directly videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t Sergio Aguirre (1): v4l: soc-camera: Store negotiated buffer settings drivers/media/video/sh_mobile_ceu_camera.c |4 +--- drivers/media/video/soc_camera.c | 25 - drivers/media/video/videobuf2-dma-contig.c |2 +- include/media/soc_camera.h |2 ++ include/media/videobuf2-dma-contig.h |9 ++--- 5 files changed, 26 insertions(+), 16 deletions(-) As I mentioned earlier today on the IRC, I've got a few more fixes, that I will be posting and pushing a bit later, they can also go in after -rc1. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote: On 03/22/2011 02:32 AM, Malcolm Priestley wrote: On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote: Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestleytvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestleytvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 1.76 relates to remote control patches. https://patchwork.kernel.org/patch/499391/ https://patchwork.kernel.org/patch/499401/ Those are NEC extended remotes. You are now setting it as 32 bit NEC, in my understanding it should be defined as 24 bit NEC extended. Anyhow, my opinion is still that we *should* make all NEC remotes as 32 bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For example AF9015 current NEC handling is too complex for that reason... I don't like how it is implemented currently. One of the reasons for using 32 bit was interference from other consumer remotes. It appears, these near identical bubble remotes originate from a Chinese factory and supplied with the same product with completely different key mapping. I am not sure how many of these remotes are common to other devices. Regards Malcolm -- 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
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
Em 22-03-2011 18:34, Malcolm Priestley escreveu: On Mon, 2011-03-21 at 21:40 -0300, Mauro Carvalho Chehab wrote: Em 21-03-2011 21:32, Malcolm Priestley escreveu: On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote: Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 1.76 relates to remote control patches. https://patchwork.kernel.org/patch/499391/ https://patchwork.kernel.org/patch/499401/ Ah! Ok, I'll be applying them. Btw, please, move the keycode tables to the proper place and use the RC core stuff. The idea is to remove all those keytables from kernel in a near future, and use the userspace tool to load it via udev. For some reason patch to 1.81(552551) was also missing from the Patchwork list earlier, although it is there now. https://patchwork.kernel.org/patch/553551/ It where on my list of broken patches (due to the module_version change). Applied. I will put the RC on the TODO list and hope to complete in the near future. OK, thanks! Regards Malcolm -- 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 -- 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
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
Em 22-03-2011 19:12, Malcolm Priestley escreveu: On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote: On 03/22/2011 02:32 AM, Malcolm Priestley wrote: On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote: Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestleytvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestleytvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 1.76 relates to remote control patches. https://patchwork.kernel.org/patch/499391/ https://patchwork.kernel.org/patch/499401/ Those are NEC extended remotes. You are now setting it as 32 bit NEC, in my understanding it should be defined as 24 bit NEC extended. Anyhow, my opinion is still that we *should* make all NEC remotes as 32 bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For example AF9015 current NEC handling is too complex for that reason... I don't like how it is implemented currently. One of the reasons for using 32 bit was interference from other consumer remotes. It appears, these near identical bubble remotes originate from a Chinese factory and supplied with the same product with completely different key mapping. I am not sure how many of these remotes are common to other devices. Drivers should get the 32 bit codes form NEC when hardware provides it. What we currently do is to identify if the code has 16, 24 or 32 bits, but it is probably better to always handle them as if they have 32 bits. Regards Malcolm -- 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 -- 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
RE: [Query] VIDIOC_QBUF and VIDIOC_STREAMON order
Hi all, On Tuesday, March 22, 2011 7:54 PM Laurent Pinchart wrote: On Tuesday 15 March 2011 08:50:45 Hans Verkuil wrote: On Tuesday, March 15, 2011 04:21:05 Pawel Osciak wrote: On Mon, Mar 14, 2011 at 03:49, Subash Patel subas...@gmail.com wrote: VIDIOC_STREAMON expects buffers to be queued before hardware part of image/video pipe is enabled. From my experience of V4L2 user space, I have always QBUFfed before invoking the STREAMON. Below is the API specification which also speaks something same: Not exactly. It says that the API requires buffers to be queued for output devices. It does not require any buffers to be queued for input devices. Sylwester is right here. This feature of not having to queue input buffers before STREAMON introduces problems to driver implementations and I am personally not a big fan of it either. But I'm seeing some additional problems here. Suppose we forced QBUF to be done before STREAMON. This would work, but what happens next? What should happen when we want to DQBUF the last buffer? If the device couldn't start without any buffers queued, can it continue streaming with all of them dequeued? I would guess not. So we'd either have to deny DQBUF of the last buffer (which for me personally is almost unacceptable) or have the last DQBUF automatically cause a STREAMOFF. So, for the latter, should applications, after they get all the data they wanted, be made to always have one more buffer queued as a throwaway buffer? This is probably the only reasonable solution here, but the applications would have to keep count of their queued buffers and be aware of this. Also, there might still be situations where being able to STREAMON without buffers queued would be beneficial. For example, enabling the device might be a slow/expensive operation and we might prefer to keep it running even if we don't want any data at the moment. Even for faster devices, being able to keep them on and periodically take a snapshot would be faster without having to call STREAMON anyway... The problem is that what is possible is highly hardware dependent. All video capture device I know of (composite in, HDMI in, etc) require that buffers are queued and they won't release that buffer to userspace until a new free buffer is available. That's funny, all video capture devices I know of behave the opposite way :-) They either pause the stream when they run out of buffers and resume it when a new buffer gets queued, or they throw away the data when intermediate buffers are used (such as with USB devices). Laurent, Exynos capture device is the same with your example. It should pause the stream not to overwrite when they run out of buffers and resume it when a new buffer gets queued. Hans, Do you mean that the buffer is overwritten without pause and resume until a new free buffer is coming ? They DMA continuously and stopping the DMA at the last buffer and restarting it when a new one appears tends to be too expensive and leads to additional loss of frames. In part how this should act depends on the use-case: if you are streaming video, then requiring buffers to be present before STREAMON and holding on to a buffer if userspace can't keep up seems quite reasonable to me. But for snapshot and codec type streams this behavior doesn't make sense. The main difference is that in this case the DMA is not driven by an external input, but by internal (userspace) demand. Something for our meeting to discuss. -- Regards, Laurent Pinchart -- 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 Best regards, Jonghun Han -- 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
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythr...@ti.com wrote: Adding support for common EDID parsing in kernel. EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA. There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) which is using the functionality, just based on the raw EDID pointer with size/segment information. With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well. If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high. Dave. -- 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
Re: [PATCH] tm6000: fix s-video input
Hi Stefan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.03.2011 01:08, schrieb Dmitri Belimov:
Hi
Add compatibility for composite and s-video inputs. Some TV cards
hasn't it.
Fix S-Video input, the s-video cable has only video signals no
audio.
Call the function of audio configure kill chroma in signal. only b/w
video.
Known bugs:
after s-video the audio for radio didn't work, TV crashed hardly
after composite TV crashed hardly too.
P.S. After this patch I'll want to rework the procedure of configure
video. Now it has a lot of junk and dubles.
Why you use caps to define video input and audio with avideo and/or
aradio as flags? Better is , I think, we use a struct for edge
virtual input (Video type (s-vhs, composite, tuner), video input pin
(video port a, video port b or both), video mode gpio, audio type ,
audio input pin (adc 1, adc 2 or sif)). If we are called
vidioc_s_input or radio_g_input setting input number. In tm6000_std.c
we can use this input number and the input struct with the same number
and can use all setting from here to set it.
It's very intresting but right now much better for me make full-working TV
cards.
You can rework this part of code as you want. Or we can do it togehter.
With my best regards, Dmitry.
Stefan Ringel
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 88144a1..146c7e8 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -235,11 +235,13 @@ struct tm6000_board tm6000_boards[] = {
.avideo = TM6000_AIP_SIF1,
.aradio = TM6000_AIP_LINE1,
.caps = {
- .has_tuner = 1,
- .has_dvb = 1,
- .has_zl10353 = 1,
- .has_eeprom = 1,
- .has_remote = 1,
+ .has_tuner = 1,
+ .has_dvb = 1,
+ .has_zl10353 = 1,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ .has_input_comp = 1,
+ .has_input_svid = 1,
},
.gpio = {
.tuner_reset = TM6010_GPIO_0,
@@ -255,11 +257,13 @@ struct tm6000_board tm6000_boards[] = {
.avideo = TM6000_AIP_SIF1,
.aradio = TM6000_AIP_LINE1,
.caps = {
- .has_tuner = 1,
- .has_dvb = 0,
- .has_zl10353 = 0,
- .has_eeprom = 1,
- .has_remote = 1,
+ .has_tuner = 1,
+ .has_dvb = 0,
+ .has_zl10353 = 0,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ .has_input_comp = 1,
+ .has_input_svid = 1,
},
.gpio = {
.tuner_reset = TM6010_GPIO_0,
@@ -327,10 +331,13 @@ struct tm6000_board tm6000_boards[] = {
.avideo = TM6000_AIP_SIF1,
.aradio = TM6000_AIP_LINE1,
.caps = {
- .has_tuner = 1,
- .has_dvb = 1,
- .has_zl10353 = 1,
- .has_eeprom = 1,
+ .has_tuner = 1,
+ .has_dvb = 1,
+ .has_zl10353 = 1,
+ .has_eeprom = 1,
+ .has_remote = 0,
+ .has_input_comp = 0,
+ .has_input_svid = 0,
},
.gpio = {
.tuner_reset = TM6010_GPIO_0,
@@ -346,10 +353,13 @@ struct tm6000_board tm6000_boards[] = {
.avideo = TM6000_AIP_SIF1,
.aradio = TM6000_AIP_LINE1,
.caps = {
- .has_tuner = 1,
- .has_dvb = 0,
- .has_zl10353 = 0,
- .has_eeprom = 1,
+ .has_tuner = 1,
+ .has_dvb = 0,
+ .has_zl10353 = 0,
+ .has_eeprom = 1,
+ .has_remote = 0,
+ .has_input_comp = 0,
+ .has_input_svid = 0,
},
.gpio = {
.tuner_reset = TM6010_GPIO_0,
diff --git a/drivers/staging/tm6000/tm6000-stds.c
b/drivers/staging/tm6000/tm6000-stds.c
index a4c07e5..da3e51b 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++ b/drivers/staging/tm6000/tm6000-stds.c
@@ -1161,8 +1161,6 @@ int tm6000_set_standard(struct tm6000_core
*dev,
v4l2_std_id * norm)
rc = tm6000_load_std(dev, svideo_stds[i].common,
sizeof(svideo_stds[i].
common));
- tm6000_set_audio_std(dev, svideo_stds[i].audio_default_std);
-
goto ret;
}
}
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index b550340..c80a316 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -1080,18 +1080,27 @@ static int vidioc_s_std (struct file *file,
void *priv, v4l2_std_id *norm)
static int vidioc_enum_input(struct file *file, void *priv,
struct v4l2_input *inp)
{
+ struct tm6000_fh *fh = priv;
+ struct tm6000_core *dev = fh-dev;
+
switch (inp-index) {
case TM6000_INPUT_TV:
inp-type = V4L2_INPUT_TYPE_TUNER;
strcpy(inp-name, Television);
break;
case TM6000_INPUT_COMPOSITE:
- inp-type = V4L2_INPUT_TYPE_CAMERA;
- strcpy(inp-name, Composite);
+ if (dev-caps.has_input_comp) {
+ inp-type = V4L2_INPUT_TYPE_CAMERA;
+ strcpy(inp-name, Composite);
+ } else
+ return -EINVAL;
break;
case TM6000_INPUT_SVIDEO:
- inp-type = V4L2_INPUT_TYPE_CAMERA;
- strcpy(inp-name, S-Video);
+ if (dev-caps.has_input_svid) {
+ inp-type = V4L2_INPUT_TYPE_CAMERA;
+ strcpy(inp-name, S-Video);
+ } else
+ return -EINVAL;
break;
default:
return -EINVAL;
diff --git a/drivers/staging/tm6000/tm6000.h
b/drivers/staging/tm6000/tm6000.h
index ccd120f..99ae50e 100644
---
