[PATCH] [media] s5p-mfc: Add QP setting support for vp8 encoder
Adds v4l2 controls to set MIN, MAX QP values and
I, P frame QP for vp8 encoder.
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml| 32 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |4 +++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 44 +++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 20 +++
drivers/media/v4l2-core/v4l2-ctrls.c|4 +++
include/uapi/linux/v4l2-controls.h |4 +++
6 files changed, 108 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..091aa4d 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3161,6 +3161,38 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a
golden frame./entry
/entrytbl
/row
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MIN_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMinimum quantization parameter for
VP8. Valid range: from 0 to 11./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MAX_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMaximum quantization parameter for
VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for an I
frame for VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for a P frame
for VP8. Valid range: from 0 to 127./entry
+ /row
+
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..d91f757 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -422,6 +422,10 @@ struct s5p_mfc_vp8_enc_params {
enum v4l2_vp8_golden_frame_sel golden_frame_sel;
u8 hier_layer;
u8 hier_layer_qp[3];
+ u8 rc_min_qp;
+ u8 rc_max_qp;
+ u8 rc_frame_qp;
+ u8 rc_p_frame_qp;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..33e8ae3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -618,6 +618,38 @@ static struct mfc_control controls[] = {
.default_value = V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_PREV,
.menu_skip_mask = 0,
},
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MAX_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 127,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MIN_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 11,
+ .step = 1,
+ .default_value = 0,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 10,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 10,
+ },
};
#define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1557,6 +1589,18 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
p-codec.vp8.golden_frame_sel = ctrl-val;
break;
+ case V4L2_CID_MPEG_VIDEO_VPX_MIN_QP:
+ p-codec.vp8.rc_min_qp = ctrl-val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP:
+ p-codec.vp8.rc_max_qp = ctrl-val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP:
+ p-codec.vp8.rc_frame_qp = ctrl-val;
+ break;
+ case
Re: [PATCH] [media] s5p-mfc: Add QP setting support for vp8 encoder
Hi Arun,
On 11/11/2013 10:19 AM, Arun Kumar K wrote:
Adds v4l2 controls to set MIN, MAX QP values and
I, P frame QP for vp8 encoder.
I assume these parameters and their ranges are all defined by the VP8 standard?
Or are they HW specific?
Regards,
Hans
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml| 32 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |4 +++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 44
+++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 20 +++
drivers/media/v4l2-core/v4l2-ctrls.c|4 +++
include/uapi/linux/v4l2-controls.h |4 +++
6 files changed, 108 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..091aa4d 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3161,6 +3161,38 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a
golden frame./entry
/entrytbl
/row
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MIN_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMinimum quantization parameter for
VP8. Valid range: from 0 to 11./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MAX_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMaximum quantization parameter for
VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for an I
frame for VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for a P frame
for VP8. Valid range: from 0 to 127./entry
+ /row
+
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..d91f757 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -422,6 +422,10 @@ struct s5p_mfc_vp8_enc_params {
enum v4l2_vp8_golden_frame_sel golden_frame_sel;
u8 hier_layer;
u8 hier_layer_qp[3];
+ u8 rc_min_qp;
+ u8 rc_max_qp;
+ u8 rc_frame_qp;
+ u8 rc_p_frame_qp;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..33e8ae3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -618,6 +618,38 @@ static struct mfc_control controls[] = {
.default_value = V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_PREV,
.menu_skip_mask = 0,
},
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MAX_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 127,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MIN_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 11,
+ .step = 1,
+ .default_value = 0,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 10,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 10,
+ },
};
#define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1557,6 +1589,18 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
p-codec.vp8.golden_frame_sel = ctrl-val;
break;
+ case V4L2_CID_MPEG_VIDEO_VPX_MIN_QP:
+ p-codec.vp8.rc_min_qp = ctrl-val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP:
+ p-codec.vp8.rc_max_qp = ctrl-val;
+
Re: [PATCH v1 00/19] UVC 1.5 VP8 support for uvcvideo
Hi,
2013/11/11 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Paulo,
On Thursday 10 October 2013 11:27:37 Paulo Assis wrote:
Hi,
just want t know the current state on this series.
I'm currently adding h264 stream preview support to guvcview.
It's already working fine on uvc 1.1 cameras like the BCC950
Great ! Is the code already available ?
Yes, the latest git version is working very well, even for the c930,
although for this one, h264, can only be muxed in the MJPG container.
From what I understand Logitech had to remove direct H264 stream
support (no H264 descriptor) due to some issues with a very well known
OS vendor.
but for uvc 1.5 devices like the c930e it could really use some driver
support.
I'm nearly done reviewing the patches (although 19/19 is a huge beast that
will take a bit of time to tame :-)). Getting the code to mainline will still
need some time, but it seems to be going in the right direction. We'll get
hardware compression support for UVC 1.5 in the driver one way or another, it
won't be left to userspace to implement (you will of course have to adapt
existing applications to use the new features, but it should hopefully not be
too complex).
I've test the patches in it's current form and for the c930, at least,
there is a regression that prevents the camera from functioning (it
doesn't create the video node).
The problem happens with patch 3 : uvcvideo: Add support for multiple
chains with common roots, in function uvc_scan_device there is the
following check:
if (UVC_ENTITY_TYPE(entity) != UVC_VC_EXTENSION_UNIT
|| entity-bNrInPins != 1
|| uvc_entity_by_reference(dev, entity-id, NULL)) {
uvc_printk(KERN_INFO, Found an invalid branch
starting at entity id %d.\n, entity-id);
return -1;
}
for unit 12 (the h264 extension control), 'uvc_entity_by_reference'
check fails and this causes the camera initialization to also fail, so
no video node is created.
My very simple fix was to comment the 'uvc_entity_by_reference' check,
this allows the init process to carry on and the video node is
created. The camera will work fine in that case.
I could propose a more appropriate patch, but since this is still
under review I'm not sure if that's OK or if it's better to wait on
other comments.
Regards,
Paulo
2013/8/30 Pawel Osciak posc...@chromium.org:
Hello everyone,
This series adds support for UVC 1.5 and VP8 encoding cameras to the
uvcvideo driver. The official specification for the new standard can be
found here: http://www.usb.org/developers/devclass_docs.
The main change in 1.5 is support for encoding cameras. Those cameras
contain additional UVC entities, called Encoding Units, with their own
set of controls governing encode parameters. Typical encoding cameras
(see examples in class spec) expose two USB Video Streaming Interfaces
(VSIs): one for raw stream formats and one for encoded streams.
Typically, both get their source stream from a single sensor, producing
raw and encoded versions of the video feed simultaneously.
Encoding Units may also support the so-called simulcast formats, which
allow additional sub-streams, or layers, used to achieve temporal
scalability. The spec allows up to 4 simulcast layers. Those layers are
encoded in the same format, but encoding parameters, such as resolution,
bitrate, etc., may, depending on the camera capabilities, be changed
independently for each layer, and their streaming state may also be
controlled independently as well. The layers are streamed from the same
USB VSI, and the information which layer a frame belongs to is contained
in its payload header.
In V4L2 API, a separate video node is created for each VSI: one for raw
formats VSI and another for the encoded formats VSI. Both can operate
completely independently from each other. In addition, if the Encoding
Unit supports simulcast, one V4L2 node is created for each stream layer
instead, and each can be controlled independently, including
streamon/streamoff state, setting resolution and controls. Once a
simulcast format is successfully set for one of the simulcast video nodes
however, it cannot be changed, unless all connected nodes are idle, i.e.
they are not streaming and their buffers are freed.
The userspace can discover if a set of nodes belongs to one encoding unit
by traversing media controller topology of the camera.
I will be gradually posting documentation changes for new features after
initial rounds of reviews. This is a relatively major change to the UVC
driver and although I tried to keep the existing logic for UVC 1.5
cameras intact as much as possible, I would very much appreciate it if
these patches could get some testing from you as well, on your own
devices/systems.
Thanks,
Pawel Osciak
Pawel Osciak (19):
uvcvideo: Add UVC query tracing.
uvcvideo: Return 0 when setting probe
Re: [PATCH] [media] s5p-mfc: Add QP setting support for vp8 encoder
Hi Hans,
On Mon, Nov 11, 2013 at 3:01 PM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Arun,
On 11/11/2013 10:19 AM, Arun Kumar K wrote:
Adds v4l2 controls to set MIN, MAX QP values and
I, P frame QP for vp8 encoder.
I assume these parameters and their ranges are all defined by the VP8
standard?
Or are they HW specific?
These ranges are not defined by VP8 standard. I can see that the
standard does not
give any range. The ranges mentioned are defined by Samsung MFC hardware.
Do you think that for these controls, I shouldnt mention the range as
the standard
does not have it?
Regards
Arun
Regards,
Hans
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml| 32 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |4 +++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 44
+++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 20 +++
drivers/media/v4l2-core/v4l2-ctrls.c|4 +++
include/uapi/linux/v4l2-controls.h |4 +++
6 files changed, 108 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..091aa4d 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3161,6 +3161,38 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a
golden frame./entry
/entrytbl
/row
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MIN_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMinimum quantization parameter for
VP8. Valid range: from 0 to 11./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MAX_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMaximum quantization parameter for
VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for an I
frame for VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for a P
frame for VP8. Valid range: from 0 to 127./entry
+ /row
+
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..d91f757 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -422,6 +422,10 @@ struct s5p_mfc_vp8_enc_params {
enum v4l2_vp8_golden_frame_sel golden_frame_sel;
u8 hier_layer;
u8 hier_layer_qp[3];
+ u8 rc_min_qp;
+ u8 rc_max_qp;
+ u8 rc_frame_qp;
+ u8 rc_p_frame_qp;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..33e8ae3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -618,6 +618,38 @@ static struct mfc_control controls[] = {
.default_value = V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_PREV,
.menu_skip_mask = 0,
},
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MAX_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 127,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MIN_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 11,
+ .step = 1,
+ .default_value = 0,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 10,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 10,
+ },
};
#define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1557,6 +1589,18 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
Re: ivtv 1.4.2/1.4.3 broken in recent kernels?
On 11/06/2013 01:25 AM, Andy Walls wrote: On Mon, 2013-11-04 at 13:44 +0100, Hans Verkuil wrote: On 10/19/2013 07:09 PM, Andy Walls wrote: On Wed, 2013-10-16 at 01:10 +0100, Rajil Saraswat wrote: Try applying the following (untested) patch that is made against the bleeding edge Linux kernel. The test on the mute control state in wm8775_s_routing() appears to have been inverted in the bad commit you isolated. Aargh! I'm pretty sure that's the culprit. Man, that's been broken for ages. Hi Hans, Yes, and only *one* person reported it in those years. I suspect very few people use the comination of conventional PCI, analog video, and SVideo 2 or Composite 2 anymore. I'll see if I can test this patch this week. Thanks! I'm very busy at work until mid-December. I finally managed to test this and this patch does indeed fix the bug. I'll make a pull request for this. 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: ivtv 1.4.2/1.4.3 broken in recent kernels?
On 10/19/2013 07:09 PM, Andy Walls wrote: On Wed, 2013-10-16 at 01:10 +0100, Rajil Saraswat wrote: I was finally able to carry out a git bisect. Had to do a git pull on a fast internet hooked machine and ftp the files over to the remote machine. I started with 'git bisect bad v2.6.36.4' and 'git bisect good v2.6.35.10'. And the result was: 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 is the first bad commit commit 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 Author: Hans Verkuil hverk...@xs4all.nl Date: Sat Apr 24 08:23:53 2010 -0300 V4L/DVB: wm8775: convert to the new control framework Signed-off-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com :04 04 37847ffe592f255c6a9d9daedaf7bbfd3cd7b055 2f094df6f65d7fb296657619c1ad6f93fe085a75 Mdrivers I then removed the patch from linux-2.6.36-gentoo-r8 which are gentoo sources, and confirmed that video/audio now works fine on v4l2-ctl -d /dev/video1 --set-input 4 I wasnt able to remove the patch in 3.10.7 which is gentoo stable kernel. Any idea how can i do that? Try applying the following (untested) patch that is made against the bleeding edge Linux kernel. The test on the mute control state in wm8775_s_routing() appears to have been inverted in the bad commit you isolated. Can you give me your Signed-off-by? Thanks! Hans Along with '--set-input', you may also want to use v4l2-ctl to exercise the mute control as well, to see if it works as expected, once this patch is applied. Regards, Andy file: wm8775_s_route_mute_test_inverted.patch diff --git a/drivers/media/i2c/wm8775.c b/drivers/media/i2c/wm8775.c index 3f584a7..bee7946 100644 --- a/drivers/media/i2c/wm8775.c +++ b/drivers/media/i2c/wm8775.c @@ -130,12 +130,10 @@ static int wm8775_s_routing(struct v4l2_subdev *sd, return -EINVAL; } state-input = input; - if (!v4l2_ctrl_g_ctrl(state-mute)) + if (v4l2_ctrl_g_ctrl(state-mute)) return 0; if (!v4l2_ctrl_g_ctrl(state-vol)) return 0; - if (!v4l2_ctrl_g_ctrl(state-bal)) - return 0; wm8775_set_audio(sd, 1); return 0; } -- 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] videobuf2-dma-sg: Support io userptr operations on io memory
@@ -180,7 +186,26 @@ static void *vb2_dma_sg_get_userptr(void
*alloc_ctx, unsigned long vaddr,
if (!buf-pages)
return NULL;
- num_pages_from_user = get_user_pages(current, current-mm,
+ buf-vma = find_vma(current-mm, vaddr);
+ if (!buf-vma) {
+ dprintk(1, no vma for address %lu\n, vaddr);
+ return NULL;
+ }
+
+ if (vma_is_io(buf-vma)) {
+ for (num_pages_from_user = 0;
+ num_pages_from_user buf-num_pages;
+ ++num_pages_from_user, vaddr += PAGE_SIZE) {
+ unsigned long pfn;
+
+ if (follow_pfn(buf-vma, vaddr, pfn)) {
+ dprintk(1, no page for address %lu\n, vaddr);
+ break;
+ }
+ buf-pages[num_pages_from_user] = pfn_to_page(pfn);
+ }
+ } else
+ num_pages_from_user = get_user_pages(current, current-mm,
vaddr PAGE_MASK,
buf-num_pages,
write,
Can you safely assume that your userptr will cover only one vma? At least,
get_user_pages (calling __get_user_pages) does not assume that and calls
find_vma() whenever vma-vm_end is reached.
– Matthias
CONFIDENTIALITY: The contents of this e-mail are confidential and intended only
for the above addressee(s). If you are not the intended recipient, or the
person responsible for delivering it to the intended recipient, copying or
delivering it to anyone else or using it in any unauthorized manner is
prohibited and may be unlawful. If you receive this e-mail by mistake, please
notify the sender and the systems administrator at straym...@tttech.com
immediately.
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
[PATCHv2] staging: go7007: fix use of uninitialised pointer
go variable is initialised only after the switch case so it cannot be
dereferenced prior to that happening.
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
drivers/staging/media/go7007/go7007-usb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
On Sun, Nov 10 2013, Dan Carpenter wrote:
There are 3 other uses before go gets initialized.
Argh... Other occurrences of the letters “GO” deceived my eyes. Sorry
about that and thanks.
diff --git a/drivers/staging/media/go7007/go7007-usb.c
b/drivers/staging/media/go7007/go7007-usb.c
index 58684da..ee8ab89 100644
--- a/drivers/staging/media/go7007/go7007-usb.c
+++ b/drivers/staging/media/go7007/go7007-usb.c
@@ -1057,7 +1057,7 @@ static int go7007_usb_probe(struct usb_interface *intf,
char *name;
int video_pipe, i, v_urb_len;
- dev_dbg(go-dev, probing new GO7007 USB board\n);
+ dev_dbg(intf-dev, probing new GO7007 USB board\n);
switch (id-driver_info) {
case GO7007_BOARDID_MATRIX_II:
@@ -1097,13 +1097,13 @@ static int go7007_usb_probe(struct usb_interface *intf,
board = board_px_tv402u;
break;
case GO7007_BOARDID_LIFEVIEW_LR192:
- dev_err(go-dev, The Lifeview TV Walker Ultra is not
supported. Sorry!\n);
+ dev_err(intf-dev, The Lifeview TV Walker Ultra is not
supported. Sorry!\n);
return -ENODEV;
name = Lifeview TV Walker Ultra;
board = board_lifeview_lr192;
break;
case GO7007_BOARDID_SENSORAY_2250:
- dev_info(go-dev, Sensoray 2250 found\n);
+ dev_info(intf-dev, Sensoray 2250 found\n);
name = Sensoray 2250/2251;
board = board_sensoray_2250;
break;
@@ -1112,7 +1112,7 @@ static int go7007_usb_probe(struct usb_interface *intf,
board = board_ads_usbav_709;
break;
default:
- dev_err(go-dev, unknown board ID %d!\n,
+ dev_err(intf-dev, unknown board ID %d!\n,
(unsigned int)id-driver_info);
return -ENODEV;
}
--
1.8.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
Re: [PATCH 1/1] v4l: Add frame end event
Hi Sakari, On 11/01/2013 02:10 PM, Sakari Ailus wrote: Add an event to signal frame end. This is not necessarily the same timestamp as the video buffer done timestamp, and can be also subscribed by other processes than the one controlling streaming and buffer (de)queueing. Also make all event type constants appear as constants in documentation and move frame sync event struct documentation after all control event documentation. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- Hi folks, As we have a frame sync event that's being used to tell about the frame start, I thought of having a frame end event as well. This isn't exactly the same as a buffer ready event which could take place already earlier for instance if cropping is being done. I propose to use the id field for the purpose (V4L2_EVENT_FRAME_SYNC_START / V4L2_EVENT_FRAME_SYNC_END). The frame start event will retain its old id zero. Originally I think we thought of using the id field for the line, but now I think it's worth adding a distinct event for that purpose: line based events are typically triggered from other sources than line based events. Frame sync, in my opinion, matches better with frame start and frame end than to anything related to lines. So should line based events be supported, they should have their own event type and use the id field as the line number. I have no objections to this patch. You do need to adapt drivers/media/platform/omap3isp/ispccdc.c a bit since it is using the FRAME_SYNC event and so it should check the id field. But will you also be upstreaming a driver that uses the SYNC_END? I don't really want to merge this if nobody is using it. Regards, Hans Kind regards, Sakari Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 58 +++--- .../DocBook/media/v4l/vidioc-subscribe-event.xml | 11 +++- include/uapi/linux/videodev2.h | 3 ++ 3 files changed, 51 insertions(+), 21 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 89891ad..e258c6e 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -76,21 +76,22 @@ entry/entry entryv4l2-event-vsync;/entry entrystructfieldvsync/structfield/entry - entryEvent data for event V4L2_EVENT_VSYNC. + entryEvent data for event constantV4L2_EVENT_VSYNC/constant. /entry /row row entry/entry entryv4l2-event-ctrl;/entry entrystructfieldctrl/structfield/entry - entryEvent data for event V4L2_EVENT_CTRL. + entryEvent data for event constantV4L2_EVENT_CTRL/constant. /entry /row row entry/entry entryv4l2-event-frame-sync;/entry entrystructfieldframe_sync/structfield/entry - entryEvent data for event V4L2_EVENT_FRAME_SYNC./entry + entryEvent data for event constantV4L2_EVENT_FRAME_SYNC + /constant./entry /row row entry/entry @@ -226,22 +227,6 @@ /tgroup /table -table frame=none pgwide=1 id=v4l2-event-frame-sync - titlestruct structnamev4l2_event_frame_sync/structname/title - tgroup cols=3 - cs-str; - tbody valign=top - row - entry__u32/entry - entrystructfieldframe_sequence/structfield/entry - entry - The sequence number of the frame being received. - /entry - /row - /tbody - /tgroup -/table - table pgwide=1 frame=none id=changes-flags titleChanges/title tgroup cols=3 @@ -270,6 +255,41 @@ /tbody /tgroup /table + +table frame=none pgwide=1 id=v4l2-event-frame-sync + titlestruct structnamev4l2_event_frame_sync/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldframe_sequence/structfield/entry + entry + The sequence number of the frame being received. + /entry + /row + /tbody + /tgroup +/table + +table pgwide=1 frame=none id=v4l2-event-frame-sync-ids + titleFrame sync event IDs/title + tgroup cols=3 + cs-def; + tbody valign=top + row + entryconstantV4L2_EVENT_FRAME_SYNC_START/constant/entry + entry0x/entry + entryFrame sync event delivered at frame start./entry + /row + row + entryconstantV4L2_EVENT_FRAME_SYNC_END/constant/entry + entry0x0001/entry + entryFrame sync event delivered at frame end./entry + /row + /tbody + /tgroup +/table /refsect1 refsect1 return-value; diff --git
Re: videobuf mmap deadlock
Hi Pete,
On 11/01/2013 07:54 PM, Pete Eberlein wrote:
The patch videobuf_vm_{open,close} race fixes
https://linuxtv.org/patch/18365/ introduced a deadlock in 3.11.
My driver uses videobuf_vmalloc initialized with ext_lock set to NULL.
Which driver are we talking about?
My driver's mmap function calls videobuf_mmap_mapper
videobuf_mmap_mapper calls videobuf_queue_lock on q
videobuf_mmap_mapper calls __videobuf_mmap_mapper
__videobuf_mmap_mapper calls videobuf_vm_open
videobuf_vm_open calls videobuf_queue_lock on q (introduced by above patch)
deadlocked
This is not an issue if ext_lock is non-NULL, since videobuf_queue_lock
is a no-op in that case.
Did I do something wrong, or is this a valid regression?
I think this is a valid regression. Using an atomic_t for the count is a better
solution IMHO. Anyone up for writing a patch?
Locking in videobuf is very messy and I recommend moving to videobuf2 which is
much more reliable and much easier to understand as well.
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: [REVIEW PATCH 6/9] si4713 : Added the USB driver for Si4713
On Thu, Nov 7, 2013 at 3:40 AM, Hans Verkuil hverk...@xs4all.nl wrote:
On 11/05/2013 03:18 PM, edubez...@gmail.com wrote:
Dinesh
On Tue, Oct 15, 2013 at 11:24 AM, Dinesh Ram dinesh@cern.ch wrote:
This is the USB driver for the Silicon Labs development board.
It contains the Si4713 FM transmitter chip.
I tried this driver again. The system attempts to probe the device but
it fails because the product revision read out of the USB device is
wrong.
[ 220.855158] usb 2-1.3.3: new full-speed USB device number 10 using
ehci-pci
[ 220.949677] usb 2-1.3.3: New USB device found, idVendor=10c4,
idProduct=8244
[ 220.949683] usb 2-1.3.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 220.949688] usb 2-1.3.3: Product: Si47xx Baseboard
[ 220.949691] usb 2-1.3.3: Manufacturer: SILICON LABORATORIES INC.
[ 220.949695] usb 2-1.3.3: SerialNumber: CBDA8-00-0
[ 220.950157] usbhid 2-1.3.3:1.0: couldn't find an input interrupt endpoint
[ 1014.981012] radio-usb-si4713 2-1.3.3:1.0: Si4713 development board
discovered: (10C4:8244)
[ 1015.870984] si4713 12-0063: IRQ not configured. Using timeouts.
[ 1015.943551] si4713 12-0063: Invalid product numberHere is
the code without modification
[ 1015.943556] si4713 12-0063: Failed to probe device information.
[ 1015.943568] si4713: probe of 12-0063 failed with error -22
[ 1015.943613] radio-usb-si4713 2-1.3.3:1.0: cannot get v4l2 subdevice
[ 1015.943672] usbcore: registered new interface driver radio-usb-si4713
[ 1274.419987] perf samples too long (2504 2500), lowering
kernel.perf_event_max_sample_rate to 5
[ 1308.851059] usbcore: deregistering interface driver radio-usb-si4713
[ 1500.478308] radio-usb-si4713 2-1.3.3:1.0: Si4713 development board
discovered: (10C4:8244)
[ 1500.612240] si4713 12-0063: IRQ not configured. Using timeouts.
[ 1500.683489] si4713 12-0063: Invalid product number 0x15 Here it
prints the PN read
[ 1500.683495] si4713 12-0063: Failed to probe device information.
[ 1500.683509] si4713: probe of 12-0063 failed with error -22
[ 1500.683558] radio-usb-si4713 2-1.3.3:1.0: cannot get v4l2 subdevice
[ 1500.683624] usbcore: registered new interface driver radio-usb-si4713
Here is simple diff of what I used to print the PN value:
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index aadecb5..ee53584 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -464,7 +464,7 @@ static int si4713_checkrev(struct si4713_device *sdev)
v4l2_info(sdev-sd, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
} else {
- v4l2_err(sdev-sd, Invalid product number\n);
+ v4l2_err(sdev-sd, Invalid product number 0x%X\n,
resp[1]);
rval = -EINVAL;
}
return rval;
It is expected to be 0x0D instead of 0x15, if I am not mistaken.
What are the markings on the si471x chip on your USB board? Perhaps you have
a slightly different version of the chip?
A value of 0x15 suggests a si4721 transceiver instead of a si4713 transmitter.
Which might actually still work with this driver (although with the TX
functionality only, of course), so you might try accepting the 0x15 value.
In fact I have a si4721 board :-(. Sorry for the noise. I am gonna
give it a shot any way by hacking the kernel and allowing it to be
recognized.
Regards,
Hans
Signed-off-by: Dinesh Ram dinesh@cern.ch
---
drivers/media/radio/si4713/Kconfig| 15 +
drivers/media/radio/si4713/Makefile |1 +
drivers/media/radio/si4713/radio-usb-si4713.c | 540
+
3 files changed, 556 insertions(+)
create mode 100644 drivers/media/radio/si4713/radio-usb-si4713.c
--
Eduardo Bezerra Valentin
--
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 v7] videobuf2: Add missing lock held on vb2_fop_relase
On 11/06/2013 04:41 PM, Ricardo Ribalda Delgado wrote:
From: Ricardo Ribalda ricardo.riba...@gmail.com
vb2_fop_release does not held the lock although it is modifying the
queue-owner field.
This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:
[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops: #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX: RBX: 880158a23000 RCX:
dead00100100
[ 308.298003] RDX: RSI: dead00200200 RDI:
[ 308.298012] RBP: 88014dc03e58 R08: R09:
0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12:
880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15:
01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS: ES: CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4:
07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
[ 308.298296] [8116e639] vfs_read+0xa9/0x160
[ 308.298312] [8116e882] SyS_read+0x52/0xb0
[ 308.298328] [81784179] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 88014dc03df8
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
Acked-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
v2: Comments by Sylvester Nawrocki
fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.
v3: Comments by Sylvester Nawrocki and Mauro Carvalho Chehab
Use vb2_fop_release_locked instead of __vb2_fop_release
v4: Comments by Sylvester Nawrocki
Rename vb2_fop_release_locked to __vb2_fop_release and fix patch format
v5: Comments by Sylvester Nawrocki and Hans Verkuil
Rename __vb2_fop_release to vb2_fop_release_unlock and rearrange
arguments
v6: Comments by Hans Verkuil
Fix typo on description
Rename vb2_fop_release_locked to vb2_fop_release_no_lock
v7: Comments by Hans Verkuil and Sylvester Nawrocki
Export _vb2_fop_release instead of using vb2_fop_release_no_lock
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 15 ++-
include/media/videobuf2-core.h | 1 +
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..8a712ca 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
- ret = vb2_fop_release(file);
+ ret = _vb2_fop_release(file, NULL);
if (close) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..d3b32b6 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
Re: [PATCHv2] staging: go7007: fix use of uninitialised pointer
On Mon, Nov 11, 2013 at 12:46:24PM +0100, Michal Nazarewicz wrote: go variable is initialised only after the switch case so it cannot be dereferenced prior to that happening. Signed-off-by: Michal Nazarewicz min...@mina86.com Looks good. Thanks. :) regards, dan carpenter -- 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 v4] videodev2: Set vb2_rect's width and height as unsigned
Hi Ricardo, A few comments below... On 11/06/2013 05:44 PM, Ricardo Ribalda Delgado wrote: As addressed on the media summit 2013, there is no reason for the width and height to be signed. Therefore this patch is an attempt to convert those fields into unsigned. Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com --- v3: Comments by Sakari -Update also doc v2: Comments by Sakari Ailus and Laurent Pinchart -Fix alignment on all drivers -Replace min with min_t where possible and remove unneeded checks Documentation/DocBook/media/v4l/compat.xml | 12 Documentation/DocBook/media/v4l/dev-overlay.xml| 8 ++--- Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 8 ++--- drivers/media/i2c/mt9m032.c| 16 +- drivers/media/i2c/mt9p031.c| 28 ++ drivers/media/i2c/mt9t001.c| 26 ++--- drivers/media/i2c/mt9v032.c| 34 -- drivers/media/i2c/smiapp/smiapp-core.c | 8 ++--- drivers/media/i2c/soc_camera/mt9m111.c | 4 +-- drivers/media/i2c/tvp5150.c| 14 - drivers/media/pci/bt8xx/bttv-driver.c | 6 ++-- drivers/media/pci/saa7134/saa7134-video.c | 4 --- drivers/media/platform/soc_camera/soc_scale_crop.c | 4 +-- include/uapi/linux/videodev2.h | 4 +-- 14 files changed, 97 insertions(+), 79 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 0c7195e..5dbe68b 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2523,6 +2523,18 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.12/title That will be 3.14 since this change won't go in earlier. You also need to update v4l2.xml: update the revision number at line 504 to 3.14 and add a revision entry for 3.14 at line 143. + orderedlist +listitem + para In struct structnamev4l2_rect/structname, the type +of structfieldwidth/structfield and structfieldheight/structfield +fields changed from _s32 to _u32. + /para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/dev-overlay.xml b/Documentation/DocBook/media/v4l/dev-overlay.xml index 40d1d76..a44ac66 100644 --- a/Documentation/DocBook/media/v4l/dev-overlay.xml +++ b/Documentation/DocBook/media/v4l/dev-overlay.xml @@ -346,16 +346,14 @@ rectangle, in pixels./entry rectangle, in pixels. Offsets increase to the right and down./entry /row row - entry__s32/entry + entry__u32/entry entrystructfieldwidth/structfield/entry entryWidth of the rectangle, in pixels./entry /row row - entry__s32/entry + entry__u32/entry entrystructfieldheight/structfield/entry - entryHeight of the rectangle, in pixels. Width and -height cannot be negative, the fields are signed for hysterical -reasons. !-- video4linux-l...@redhat.com on 22 Oct 2002 subject + entryHeight of the rectangle, in pixels.!-- video4linux-l...@redhat.com on 22 Oct 2002 subject Re:[V4L][patches!] Re:v4l2/kernel-2.5 --/entry Remove the '!--' comment as well as that is no longer valid. /row /tbody diff --git a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml index bf7cc97..26b8f8f 100644 --- a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml @@ -133,16 +133,14 @@ rectangle, in pixels./entry rectangle, in pixels./entry /row row - entry__s32/entry + entry__u32/entry entrystructfieldwidth/structfield/entry entryWidth of the rectangle, in pixels./entry /row row - entry__s32/entry + entry__u32/entry entrystructfieldheight/structfield/entry - entryHeight of the rectangle, in pixels. Width -and height cannot be negative, the fields are signed for -hysterical reasons. !-- video4linux-l...@redhat.com + entryHeight of the rectangle, in pixels.!-- video4linux-l...@redhat.com on 22 Oct 2002 subject Re:[V4L][patches!] Re:v4l2/kernel-2.5 -- /entry /row diff --git a/drivers/media/i2c/mt9m032.c b/drivers/media/i2c/mt9m032.c index 846b15f..85ec3ba 100644 --- a/drivers/media/i2c/mt9m032.c +++ b/drivers/media/i2c/mt9m032.c @@ -459,13 +459,15 @@ static int mt9m032_set_pad_crop(struct v4l2_subdev *subdev, MT9M032_COLUMN_START_MAX);
Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On 11/10/2013 06:16 PM, Antti Palosaari wrote:
Convert unsigned 8 to float 32 [-1 to +1], which is commonly
used format for baseband signals.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
contrib/freebsd/include/linux/videodev2.h | 4
include/linux/videodev2.h | 4
lib/libv4lconvert/libv4lconvert.c | 29 -
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/freebsd/include/linux/videodev2.h
b/contrib/freebsd/include/linux/videodev2.h
index 1fcfaeb..8829400 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -465,6 +465,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3
interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
+
/*
* F O R M A T E N U M E R A T I O N
*/
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 437f1b0..14299a6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -431,6 +431,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3
interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
I would prefer V4L2_PIX_FMT_SDR_FLOAT and _FMT_SDR_U8.
That way it is clear that this format refers to - and should be interpreted as
- an SDR format.
Otherwise it looks fine to me (but it needs to be documented as well, of
course).
Regards,
Hans
+
/*
* F O R M A T E N U M E R A T I O N
*/
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index e2afc27..38c9125 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -78,7 +78,8 @@ static void v4lconvert_get_framesizes(struct
v4lconvert_data *data,
{ V4L2_PIX_FMT_RGB24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_BGR24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_YUV420, 12, 6, 1, 0 }, \
- { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }
+ { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }, \
+ { V4L2_PIX_FMT_FLOAT,0, 0, 0, 0 }
static const struct v4lconvert_pixfmt supported_src_pixfmts[] = {
SUPPORTED_DST_PIXFMTS,
@@ -131,6 +132,8 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
{ V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
+ /* SDR formats */
+ { V4L2_PIX_FMT_U8, 0, 0, 0, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -1281,6 +1284,25 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ /* SDR */
+ case V4L2_PIX_FMT_U8:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_FLOAT:
+ {
+ /* 8-bit unsigned to 32-bit float */
+ unsigned int i;
+ float ftmp;
+ for (i = 0; i src_size; i++) {
+ ftmp = *src++;
+ ftmp -= 127.5;
+ ftmp /= 127.5;
+ memcpy(dest, ftmp, 4);
+ dest += 4;
+ }
+ }
+ }
+ break;
+
default:
V4LCONVERT_ERR(Unknown src format in conversion\n);
errno = EINVAL;
@@ -1349,6 +1371,11 @@ int v4lconvert_convert(struct v4lconvert_data *data,
temp_needed =
my_src_fmt.fmt.pix.width * my_src_fmt.fmt.pix.height *
3 / 2;
break;
+ /* SDR */
+ case V4L2_PIX_FMT_FLOAT:
+ dest_needed = src_size * 4; /* 8-bit to 32-bit */
+ temp_needed = dest_needed;
+ break;
default:
V4LCONVERT_ERR(Unknown dest format in conversion\n);
errno = EINVAL;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH] media: i2c: Add camera driver for ov9655 chips.
Hi Marek,
Thanks for the patch!
I have a few small comments below...
On 11/08/2013 10:46 PM, Marek Belisko wrote:
This is a driver for the Omnivision OV9655 camera module
connected to the OMAP3 parallel camera interface and using
the ISP (Image Signal Processor). It supports SXGA and VGA
plus some other modes.
It was tested on gta04 board.
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
drivers/media/i2c/Kconfig |8 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov9655.c | 1205
include/media/ov9655.h | 17 +
4 files changed, 1231 insertions(+)
create mode 100644 drivers/media/i2c/ov9655.c
create mode 100644 include/media/ov9655.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 842654d..97d5e4e 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -501,6 +501,14 @@ config VIDEO_OV9650
This is a V4L2 sensor-level driver for the Omnivision
OV9650 and OV9652 camera sensors.
+config VIDEO_OV9655
+ tristate OmniVision OV9655 sensor support
+ depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV9655 image sensor.
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index e03f177..367ea01 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
+obj-$(CONFIG_VIDEO_OV9655) += ov9655.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/ov9655.c b/drivers/media/i2c/ov9655.c
new file mode 100644
index 000..770abfe
--- /dev/null
+++ b/drivers/media/i2c/ov9655.c
snip
+
+/*
-
+ * V4L2 subdev control operations
+ */
+
+#define V4L2_CID_BLC_AUTO(V4L2_CID_USER_BASE | 0x1002)
+#define V4L2_CID_BLC_TARGET_LEVEL(V4L2_CID_USER_BASE | 0x1003)
+#define V4L2_CID_BLC_ANALOG_OFFSET (V4L2_CID_USER_BASE | 0x1004)
+#define V4L2_CID_BLC_DIGITAL_OFFSET (V4L2_CID_USER_BASE | 0x1005)
For private controls you need to reserve a control range in
include/uapi/linux/v4l2-controls.h. Search for V4L2_CID_USER_TI_VPE_BASE to
see how that is done.
Then you can use that BASE define for the controls above.
You also have to document these controls. You can do that in this source
somewhere,
but it has to be clear what the controls do.
+
+static int ov9655_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ov9655 *ov9655 =
+ container_of(ctrl-handler, struct ov9655, ctrls);
+ int ret;
+
+ switch (ctrl-id) {
+ case V4L2_CID_TEST_PATTERN:
+ if (!ctrl-val) {
+ /* Restore the black level compensation settings. */
+ if (ov9655-blc_auto-cur.val != 0) {
+ ret = ov9655_s_ctrl(ov9655-blc_auto);
+ if (ret 0)
+ return ret;
+ }
+ if (ov9655-blc_offset-cur.val != 0) {
+ ret = ov9655_s_ctrl(ov9655-blc_offset);
+ if (ret 0)
+ return ret;
+ }
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static struct v4l2_ctrl_ops ov9655_ctrl_ops = {
+ .s_ctrl = ov9655_s_ctrl,
+};
+
+static const char * const ov9655_test_pattern_menu[] = {
+ Disabled,
+ Color Field,
+ Horizontal Gradient,
+ Vertical Gradient,
+ Diagonal Gradient,
+ Classic Test Pattern,
+ Walking 1s,
+ Monochrome Horizontal Bars,
+ Monochrome Vertical Bars,
+ Vertical Color Bars,
+};
+
+static const struct v4l2_ctrl_config ov9655_ctrls[] = {
+ {
+ .ops= ov9655_ctrl_ops,
+ .id = V4L2_CID_BLC_AUTO,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = BLC, Auto,
+ .min= 0,
+ .max= 1,
+ .step = 1,
+ .def= 1,
+ .flags = 0,
+ }, {
+ .ops= ov9655_ctrl_ops,
+ .id = V4L2_CID_BLC_TARGET_LEVEL,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = BLC
Re: [PATCH] [media] s5p-mfc: Add QP setting support for vp8 encoder
On 11/11/2013 11:44 AM, Arun Kumar K wrote:
Hi Hans,
On Mon, Nov 11, 2013 at 3:01 PM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Arun,
On 11/11/2013 10:19 AM, Arun Kumar K wrote:
Adds v4l2 controls to set MIN, MAX QP values and
I, P frame QP for vp8 encoder.
I assume these parameters and their ranges are all defined by the VP8
standard?
Or are they HW specific?
These ranges are not defined by VP8 standard. I can see that the
standard does not
give any range. The ranges mentioned are defined by Samsung MFC hardware.
Do you think that for these controls, I shouldnt mention the range as
the standard
does not have it?
Either leave it out or just say that the range is hardware dependent.
Regards,
Hans
Regards
Arun
Regards,
Hans
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml| 32 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |4 +++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 44
+++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 20 +++
drivers/media/v4l2-core/v4l2-ctrls.c|4 +++
include/uapi/linux/v4l2-controls.h |4 +++
6 files changed, 108 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..091aa4d 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3161,6 +3161,38 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a
golden frame./entry
/entrytbl
/row
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MIN_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMinimum quantization parameter for
VP8. Valid range: from 0 to 11./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_MAX_QP/constant/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrMaximum quantization parameter for
VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for an I
frame for VP8. Valid range: from 0 to 127./entry
+ /row
+
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP/constantnbsp;/entry
+ entryinteger/entry
+ /row
+ rowentry spanname=descrQuantization parameter for a P
frame for VP8. Valid range: from 0 to 127./entry
+ /row
+
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..d91f757 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -422,6 +422,10 @@ struct s5p_mfc_vp8_enc_params {
enum v4l2_vp8_golden_frame_sel golden_frame_sel;
u8 hier_layer;
u8 hier_layer_qp[3];
+ u8 rc_min_qp;
+ u8 rc_max_qp;
+ u8 rc_frame_qp;
+ u8 rc_p_frame_qp;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..33e8ae3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -618,6 +618,38 @@ static struct mfc_control controls[] = {
.default_value =
V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_PREV,
.menu_skip_mask = 0,
},
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MAX_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 127,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_MIN_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 11,
+ .step = 1,
+ .default_value = 0,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+ .default_value = 10,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .minimum = 0,
+ .maximum = 127,
+ .step = 1,
+
Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On 11.11.2013 15:14, Hans Verkuil wrote:
On 11/10/2013 06:16 PM, Antti Palosaari wrote:
Convert unsigned 8 to float 32 [-1 to +1], which is commonly
used format for baseband signals.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
contrib/freebsd/include/linux/videodev2.h | 4
include/linux/videodev2.h | 4
lib/libv4lconvert/libv4lconvert.c | 29 -
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/freebsd/include/linux/videodev2.h
b/contrib/freebsd/include/linux/videodev2.h
index 1fcfaeb..8829400 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -465,6 +465,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3
interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float 32-bit
*/
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
+
/*
*F O R M A T E N U M E R A T I O N
*/
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 437f1b0..14299a6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -431,6 +431,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3
interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float 32-bit
*/
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
I would prefer V4L2_PIX_FMT_SDR_FLOAT and _FMT_SDR_U8.
That way it is clear that this format refers to - and should be interpreted as
- an SDR format.
Otherwise it looks fine to me (but it needs to be documented as well, of
course).
Thanks for the comments!
What do you think is it OK to abuse/reuse pixelformat for radio signals?
Basically the only one field needed is just that, whilst those image
only fields (width/height) are not needed at all. Good point to reuse
existing things as much as possible is that it does not bloat Kernel
data structures etc.
I am also going to make some tests to find out if actual float
conversion is faster against pre-calculated LUT, in Kernel or in
libv4lconvert and so. Worst scenario I have currently is Mirics ADC with
14-bit resolution = 16384 quantization levels = 32-bit float LUT will
be 16384 * 4 = 65536 bytes. Wonder if that much big LUT is allowed to
library - but maybe you could alloc() and populate LUT on the fly if
needed. Or maybe native conversion is fast enough.
regards
Antti
Regards,
Hans
+
/*
*F O R M A T E N U M E R A T I O N
*/
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index e2afc27..38c9125 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -78,7 +78,8 @@ static void v4lconvert_get_framesizes(struct v4lconvert_data
*data,
{ V4L2_PIX_FMT_RGB24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_BGR24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_YUV420, 12, 6, 1, 0 }, \
- { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }
+ { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }, \
+ { V4L2_PIX_FMT_FLOAT,0, 0, 0, 0 }
static const struct v4lconvert_pixfmt supported_src_pixfmts[] = {
SUPPORTED_DST_PIXFMTS,
@@ -131,6 +132,8 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
{ V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
+ /* SDR formats */
+ { V4L2_PIX_FMT_U8, 0, 0, 0, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -1281,6 +1284,25 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ /* SDR */
+ case V4L2_PIX_FMT_U8:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_FLOAT:
+ {
+ /* 8-bit unsigned to 32-bit float */
+ unsigned int i;
+ float ftmp;
+ for (i = 0; i src_size; i++) {
+ ftmp = *src++;
+ ftmp -= 127.5;
+ ftmp /= 127.5;
+ memcpy(dest, ftmp, 4);
+ dest += 4;
+
Re: ivtv 1.4.2/1.4.3 broken in recent kernels?
On Mon, 2013-11-11 at 12:14 +0100, Hans Verkuil wrote: On 10/19/2013 07:09 PM, Andy Walls wrote: On Wed, 2013-10-16 at 01:10 +0100, Rajil Saraswat wrote: I was finally able to carry out a git bisect. Had to do a git pull on a fast internet hooked machine and ftp the files over to the remote machine. I started with 'git bisect bad v2.6.36.4' and 'git bisect good v2.6.35.10'. And the result was: 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 is the first bad commit commit 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 Author: Hans Verkuil hverk...@xs4all.nl Date: Sat Apr 24 08:23:53 2010 -0300 V4L/DVB: wm8775: convert to the new control framework Signed-off-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com :04 04 37847ffe592f255c6a9d9daedaf7bbfd3cd7b055 2f094df6f65d7fb296657619c1ad6f93fe085a75 Mdrivers I then removed the patch from linux-2.6.36-gentoo-r8 which are gentoo sources, and confirmed that video/audio now works fine on v4l2-ctl -d /dev/video1 --set-input 4 I wasnt able to remove the patch in 3.10.7 which is gentoo stable kernel. Any idea how can i do that? Try applying the following (untested) patch that is made against the bleeding edge Linux kernel. The test on the mute control state in wm8775_s_routing() appears to have been inverted in the bad commit you isolated. Can you give me your Signed-off-by? Signed-off-by: Andy Walls awa...@md.metrocast.net Bisected-by: Rajil Saraswat raji...@gmail.com Reported-by: Rajil Saraswat raji...@gmail.com Thanks! Hans Along with '--set-input', you may also want to use v4l2-ctl to exercise the mute control as well, to see if it works as expected, once this patch is applied. Regards, Andy file: wm8775_s_route_mute_test_inverted.patch diff --git a/drivers/media/i2c/wm8775.c b/drivers/media/i2c/wm8775.c index 3f584a7..bee7946 100644 --- a/drivers/media/i2c/wm8775.c +++ b/drivers/media/i2c/wm8775.c @@ -130,12 +130,10 @@ static int wm8775_s_routing(struct v4l2_subdev *sd, return -EINVAL; } state-input = input; - if (!v4l2_ctrl_g_ctrl(state-mute)) + if (v4l2_ctrl_g_ctrl(state-mute)) return 0; if (!v4l2_ctrl_g_ctrl(state-vol)) return 0; - if (!v4l2_ctrl_g_ctrl(state-bal)) - return 0; wm8775_set_audio(sd, 1); return 0; } -- 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 RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On 11/11/2013 02:40 PM, Antti Palosaari wrote:
On 11.11.2013 15:14, Hans Verkuil wrote:
On 11/10/2013 06:16 PM, Antti Palosaari wrote:
Convert unsigned 8 to float 32 [-1 to +1], which is commonly
used format for baseband signals.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
contrib/freebsd/include/linux/videodev2.h | 4
include/linux/videodev2.h | 4
lib/libv4lconvert/libv4lconvert.c | 29
-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/freebsd/include/linux/videodev2.h
b/contrib/freebsd/include/linux/videodev2.h
index 1fcfaeb..8829400 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -465,6 +465,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /*
S5C73M3 interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
+
/*
*F O R M A T E N U M E R A T I O N
*/
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 437f1b0..14299a6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -431,6 +431,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /*
S5C73M3 interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
I would prefer V4L2_PIX_FMT_SDR_FLOAT and _FMT_SDR_U8.
That way it is clear that this format refers to - and should be interpreted
as - an SDR format.
Otherwise it looks fine to me (but it needs to be documented as well, of
course).
Thanks for the comments!
What do you think is it OK to abuse/reuse pixelformat for radio signals?
Basically the only one field needed is just that, whilst those image
only fields (width/height) are not needed at all. Good point to reuse
existing things as much as possible is that it does not bloat Kernel
data structures etc.
I've no problems with that. While usually the buffers contain images, this
is not always the case. Strictly speaking it is just a DMA API and pixelformat
is used to define the contents. We use it to transport VBI data as well, and
in rare cases even audio (even though we shouldn't).
Regards,
Hans
I am also going to make some tests to find out if actual float
conversion is faster against pre-calculated LUT, in Kernel or in
libv4lconvert and so. Worst scenario I have currently is Mirics ADC with
14-bit resolution = 16384 quantization levels = 32-bit float LUT will
be 16384 * 4 = 65536 bytes. Wonder if that much big LUT is allowed to
library - but maybe you could alloc() and populate LUT on the fly if
needed. Or maybe native conversion is fast enough.
regards
Antti
Regards,
Hans
+
/*
*F O R M A T E N U M E R A T I O N
*/
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index e2afc27..38c9125 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -78,7 +78,8 @@ static void v4lconvert_get_framesizes(struct
v4lconvert_data *data,
{ V4L2_PIX_FMT_RGB24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_BGR24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_YUV420, 12, 6, 1, 0 }, \
- { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }
+ { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }, \
+ { V4L2_PIX_FMT_FLOAT,0, 0, 0, 0 }
static const struct v4lconvert_pixfmt supported_src_pixfmts[] = {
SUPPORTED_DST_PIXFMTS,
@@ -131,6 +132,8 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
{ V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
+ /* SDR formats */
+ { V4L2_PIX_FMT_U8, 0, 0, 0, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -1281,6 +1284,25 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ /* SDR */
+ case V4L2_PIX_FMT_U8:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_FLOAT:
+ {
+ /* 8-bit unsigned to 32-bit float */
+ unsigned int i;
+
Re: [PATCH v1 03/19] uvcvideo: Add support for multiple chains with common roots.
Hi,
I'm repeating myself, but this seems the proper place to post this.
This patch causes a regression with the logitech c930e.
Please see comments below:
2013/11/10 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Pawel,
Thank you for the patch.
On Friday 30 August 2013 11:17:02 Pawel Osciak wrote:
This adds support for pipelines that fork into branches consisting of more
than one entity, creating a chain for each fork and putting common entities
on all chains that share them.
This requires us to share the ctrl_mutex across forked chains. Whenever we
discover a shared part of a chain, we assign the pointer to an existing
mutex to the sharing chain instead of creating a new one.
The forward scan is not needed anymore, as after scanning back from OTs,
we go over all entities which are not on a path from an OT and accept
single-XU branches, adding them to the existing chains.
Also extract control locking into __uvc_ctrl_{lock,unlock} functions.
This is one core piece of the UVC 1.5 rework, and I have mixed feelings about
it.
Adding entities to multiple overlapping chains somehow doesn't feel right.
What would you think about using a pipeline object instead, which would store
all entities in the pipeline ?
The driver currently iterates over all entities in a chain for several
purposes:
- registering streaming terminals as video nodes (uvc_driver.c)
- registering MC entities (uvc_entity.c)
- enumerating inputs (uvc_v4l2.c)
- finding controls and extension units (uvc_ctrl.c)
The first two uses could easily be replaced by iterations over the whole
pipeline. Input enumeration would probably require a bit of custom code
anyway, so we would be left with controls.
At first sight it would make sense to expose on a video node only the controls
that can be reached from that video node moving up the pipeline (relatively to
the video flow). However, this might break existing applications, as the
driver currently also includes controls reacheable by forward scans of side
branches. We thus need to carefully think about what controls to include, and
we need to take into account output video nodes corresponding to input
streaming terminals.
Signed-off-by: Pawel Osciak posc...@chromium.org
---
drivers/media/usb/uvc/uvc_ctrl.c | 70 -
drivers/media/usb/uvc/uvc_driver.c | 210 +++--
drivers/media/usb/uvc/uvc_entity.c | 15 ++-
drivers/media/usb/uvc/uvc_v4l2.c | 9 +-
drivers/media/usb/uvc/uvcvideo.h | 20 +++-
5 files changed, 199 insertions(+), 125 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
b/drivers/media/usb/uvc/uvc_ctrl.c index a2f4501..ba159a4 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -841,6 +841,7 @@ static struct uvc_control *uvc_find_control(struct
uvc_video_chain *chain, {
struct uvc_control *ctrl = NULL;
struct uvc_entity *entity;
+ struct uvc_chain_entry *entry;
int next = v4l2_id V4L2_CTRL_FLAG_NEXT_CTRL;
*mapping = NULL;
@@ -849,7 +850,8 @@ static struct uvc_control *uvc_find_control(struct
uvc_video_chain *chain, v4l2_id = V4L2_CTRL_ID_MASK;
/* Find the control. */
- list_for_each_entry(entity, chain-entities, chain) {
+ list_for_each_entry(entry, chain-entities, chain_entry) {
+ entity = entry-entity;
__uvc_find_control(entity, v4l2_id, mapping, ctrl, next);
if (ctrl !next)
return ctrl;
@@ -1048,6 +1050,16 @@ static int __uvc_query_v4l2_ctrl(struct
uvc_video_chain *chain, return 0;
}
+int __uvc_ctrl_lock(struct uvc_video_chain *chain)
+{
+ return mutex_lock_interruptible(chain-pipeline-ctrl_mutex) ?
+ -ERESTARTSYS : 0;
+}
+void __uvc_ctrl_unlock(struct uvc_video_chain *chain)
+{
+ mutex_unlock(chain-pipeline-ctrl_mutex);
+}
+
int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
struct v4l2_queryctrl *v4l2_ctrl)
{
@@ -1055,9 +1067,9 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
struct uvc_control_mapping *mapping;
int ret;
- ret = mutex_lock_interruptible(chain-ctrl_mutex);
+ ret = __uvc_ctrl_lock(chain);
if (ret 0)
- return -ERESTARTSYS;
+ return ret;
ctrl = uvc_find_control(chain, v4l2_ctrl-id, mapping);
if (ctrl == NULL) {
@@ -1067,7 +1079,7 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
ret = __uvc_query_v4l2_ctrl(chain, ctrl, mapping, v4l2_ctrl);
done:
- mutex_unlock(chain-ctrl_mutex);
+ __uvc_ctrl_unlock(chain);
return ret;
}
@@ -1094,9 +1106,9 @@ int uvc_query_v4l2_menu(struct uvc_video_chain *chain,
query_menu-id = id;
query_menu-index = index;
- ret = mutex_lock_interruptible(chain-ctrl_mutex);
+ ret = __uvc_ctrl_lock(chain);
if (ret 0)
- return -ERESTARTSYS;
+
Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On Sun, 2013-11-10 at 19:16 +0200, Antti Palosaari wrote:
Convert unsigned 8 to float 32 [-1 to +1], which is commonly
used format for baseband signals.
Hi Annti,
I don't think this a good idea. Floating point representations are
inherently non-portable. Even though most everything now uses IEEE-754
representation, things like denormaliazed numbers may be treated
differently by different machines. If someone saves the data to a file,
endianess issues aside, there are no guarantees that a different machine
reading is going to interpret all the floating point data from that file
properly.
I really would recommend staying with scaled integer representations or
explicit integer mantissa, exponent representations.
Two more comments below...
Signed-off-by: Antti Palosaari cr...@iki.fi
---
contrib/freebsd/include/linux/videodev2.h | 4
include/linux/videodev2.h | 4
lib/libv4lconvert/libv4lconvert.c | 29 -
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/freebsd/include/linux/videodev2.h
b/contrib/freebsd/include/linux/videodev2.h
index 1fcfaeb..8829400 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -465,6 +465,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3
interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
+
/*
* F O R M A T E N U M E R A T I O N
*/
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 437f1b0..14299a6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -431,6 +431,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3
interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
+
/*
* F O R M A T E N U M E R A T I O N
*/
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index e2afc27..38c9125 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -78,7 +78,8 @@ static void v4lconvert_get_framesizes(struct
v4lconvert_data *data,
{ V4L2_PIX_FMT_RGB24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_BGR24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_YUV420, 12, 6, 1, 0 }, \
- { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }
+ { V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }, \
+ { V4L2_PIX_FMT_FLOAT,0, 0, 0, 0 }
static const struct v4lconvert_pixfmt supported_src_pixfmts[] = {
SUPPORTED_DST_PIXFMTS,
@@ -131,6 +132,8 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
{ V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
+ /* SDR formats */
+ { V4L2_PIX_FMT_U8, 0, 0, 0, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -1281,6 +1284,25 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ /* SDR */
+ case V4L2_PIX_FMT_U8:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_FLOAT:
+ {
+ /* 8-bit unsigned to 32-bit float */
+ unsigned int i;
+ float ftmp;
+ for (i = 0; i src_size; i++) {
+ ftmp = *src++;
+ ftmp -= 127.5;
+ ftmp /= 127.5;
+ memcpy(dest, ftmp, 4);
+ dest += 4;
Replace the 4's with sizeof(float).
You have no guarantees that sizeof(float) == 4, but it is usally a safe
assumption for 'float' on Unix.
sizeof(long double) is certainly different for IA32 machines (80 bits)
vs. other 32 bit platforms. I was burned by this many years ago on a
RedHat 9.0 machine (the GNU Ada Translator's libm bindings made some bad
assumptions about the size of float types).
+ }
+ }
+ }
+ break;
+
[GIT PULL FOR v3.13] Various fixes.
The following changes since commit 80f93c7b0f4599ffbdac8d964ecd1162b8b618b9: [media] media: st-rc: Add ST remote control driver (2013-10-31 08:20:08 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.13e for you to fetch changes up to e83c52b545afd331056f34a030099ed5c801b26e: wm8775: fix broken audio routing. (2013-11-11 15:26:02 +0100) Dan Carpenter (1): cx231xx: use after free on error path in probe Hans Verkuil (3): bttv: don't setup the controls if there are no video devices. tef6862/radio-tea5764: actually assign clamp result. wm8775: fix broken audio routing. Libin Yang (1): marvell-ccic: drop resource free in driver remove Wei Yongjun (1): saa7164: fix return value check in saa7164_initdev() drivers/media/i2c/wm8775.c | 4 +--- drivers/media/pci/bt8xx/bttv-driver.c| 3 ++- drivers/media/pci/saa7164/saa7164-core.c | 4 +++- drivers/media/platform/marvell-ccic/mmp-driver.c | 7 --- drivers/media/radio/radio-tea5764.c | 2 +- drivers/media/radio/tef6862.c| 2 +- drivers/media/usb/cx231xx/cx231xx-cards.c| 2 +- 7 files changed, 9 insertions(+), 15 deletions(-) -- 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 FOR v3.14] Patches for 3.14.
The following changes since commit 80f93c7b0f4599ffbdac8d964ecd1162b8b618b9: [media] media: st-rc: Add ST remote control driver (2013-10-31 08:20:08 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.14a for you to fetch changes up to 604f2fe58dae50a0bc1bd3ad7f8c4660ea48a329: media: marvell-ccic: use devm to release clk (2013-11-11 15:28:38 +0100) Georg Kaindl (1): usbtv: Add support for PAL video source. Jonathan McCrohan (1): media_tree: Fix spelling errors Libin Yang (2): marvell-ccic: drop resource free in driver remove media: marvell-ccic: use devm to release clk Ricardo Ribalda (2): em28xx-video: Swap release order to avoid lock nesting ths7303: Declare as static a private function drivers/media/common/siano/smscoreapi.h | 4 +- drivers/media/common/siano/smsdvb.h | 2 +- drivers/media/dvb-core/dvb_demux.c | 2 +- drivers/media/dvb-frontends/dib8000.c| 4 +- drivers/media/dvb-frontends/drxk_hard.c | 18 drivers/media/i2c/Kconfig| 2 +- drivers/media/i2c/adv7183.c | 2 +- drivers/media/i2c/adv7183_regs.h | 6 +-- drivers/media/i2c/adv7604.c | 2 +- drivers/media/i2c/adv7842.c | 2 +- drivers/media/i2c/ir-kbd-i2c.c | 2 +- drivers/media/i2c/m5mols/m5mols_controls.c | 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 4 +- drivers/media/i2c/s5c73m3/s5c73m3.h | 2 +- drivers/media/i2c/saa7115.c | 2 +- drivers/media/i2c/soc_camera/ov5642.c| 2 +- drivers/media/i2c/ths7303.c | 3 +- drivers/media/pci/cx18/cx18-driver.h | 2 +- drivers/media/pci/cx23885/cx23885-417.c | 2 +- drivers/media/pci/pluto2/pluto2.c| 2 +- drivers/media/platform/coda.c| 2 +- drivers/media/platform/exynos4-is/fimc-core.c| 2 +- drivers/media/platform/exynos4-is/media-dev.c| 2 +- drivers/media/platform/marvell-ccic/mmp-driver.c | 46 drivers/media/platform/omap3isp/isp.c| 2 +- drivers/media/platform/s5p-mfc/regs-mfc.h| 2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 12 +++--- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c| 2 +- drivers/media/platform/s5p-tv/mixer.h| 2 +- drivers/media/platform/s5p-tv/mixer_video.c | 4 +- drivers/media/platform/soc_camera/omap1_camera.c | 2 +- drivers/media/platform/vivi.c| 4 +- drivers/media/platform/vsp1/vsp1_drv.c | 2 +- drivers/media/radio/radio-si476x.c | 4 +- drivers/media/rc/imon.c | 2 +- drivers/media/rc/redrat3.c | 2 +- drivers/media/tuners/mt2063.c| 4 +- drivers/media/tuners/tuner-xc2028-types.h| 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf.c | 4 +- drivers/media/usb/em28xx/em28xx-video.c | 2 +- drivers/media/usb/gspca/gl860/gl860.c| 2 +- drivers/media/usb/gspca/pac207.c | 2 +- drivers/media/usb/gspca/pac7302.c| 2 +- drivers/media/usb/gspca/stv0680.c| 2 +- drivers/media/usb/gspca/zc3xx.c | 2 +- drivers/media/usb/pwc/pwc-if.c | 2 +- drivers/media/usb/usbtv/usbtv.c | 174 ++- drivers/media/usb/uvc/uvc_video.c| 2 +- drivers/media/v4l2-core/v4l2-ctrls.c | 2 +- 49 files changed, 215 insertions(+), 146 deletions(-) -- 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 RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On 11/11/2013 03:19 PM, Andy Walls wrote:
On Sun, 2013-11-10 at 19:16 +0200, Antti Palosaari wrote:
Convert unsigned 8 to float 32 [-1 to +1], which is commonly
used format for baseband signals.
Hi Annti,
I don't think this a good idea. Floating point representations are
inherently non-portable. Even though most everything now uses IEEE-754
representation, things like denormaliazed numbers may be treated
differently by different machines. If someone saves the data to a file,
endianess issues aside, there are no guarantees that a different machine
reading is going to interpret all the floating point data from that file
properly.
I really would recommend staying with scaled integer representations or
explicit integer mantissa, exponent representations.
For what it's worth: ALSA does support float format as well (both LE and BE).
Regards,
Hans
Two more comments below...
Signed-off-by: Antti Palosaari cr...@iki.fi
---
contrib/freebsd/include/linux/videodev2.h | 4
include/linux/videodev2.h | 4
lib/libv4lconvert/libv4lconvert.c | 29 -
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/freebsd/include/linux/videodev2.h
b/contrib/freebsd/include/linux/videodev2.h
index 1fcfaeb..8829400 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -465,6 +465,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /*
S5C73M3 interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
+
/*
* F O R M A T E N U M E R A T I O N
*/
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 437f1b0..14299a6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -431,6 +431,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SE401 v4l2_fourcc('S', '4', '0', '1') /* se401
janggu compressed rgb */
#define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /*
S5C73M3 interleaved UYVY/JPEG */
+/* SDR */
+#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float
32-bit */
+#define V4L2_PIX_FMT_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned
8-bit */
+
/*
* F O R M A T E N U M E R A T I O N
*/
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index e2afc27..38c9125 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -78,7 +78,8 @@ static void v4lconvert_get_framesizes(struct
v4lconvert_data *data,
{ V4L2_PIX_FMT_RGB24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_BGR24, 24, 1, 5, 0 }, \
{ V4L2_PIX_FMT_YUV420, 12, 6, 1, 0 }, \
-{ V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }
+{ V4L2_PIX_FMT_YVU420, 12, 6, 1, 0 }, \
+{ V4L2_PIX_FMT_FLOAT,0, 0, 0, 0 }
static const struct v4lconvert_pixfmt supported_src_pixfmts[] = {
SUPPORTED_DST_PIXFMTS,
@@ -131,6 +132,8 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
{ V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
+/* SDR formats */
+{ V4L2_PIX_FMT_U8, 0, 0, 0, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -1281,6 +1284,25 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+/* SDR */
+case V4L2_PIX_FMT_U8:
+switch (dest_pix_fmt) {
+case V4L2_PIX_FMT_FLOAT:
+{
+/* 8-bit unsigned to 32-bit float */
+unsigned int i;
+float ftmp;
+for (i = 0; i src_size; i++) {
+ftmp = *src++;
+ftmp -= 127.5;
+ftmp /= 127.5;
+memcpy(dest, ftmp, 4);
+dest += 4;
Replace the 4's with sizeof(float).
You have no guarantees that sizeof(float) == 4, but it is usally a safe
assumption for 'float' on Unix.
sizeof(long double) is certainly different for IA32 machines (80 bits)
vs. other 32 bit platforms. I was burned by this many years ago on a
RedHat 9.0 machine (the GNU Ada Translator's libm bindings made some bad
assumptions
ccdc image capture interrupts
Hello, I want to capture an image with my ov3640 camera sensor connected with a gumstix overo board. I tried to change the isp registers and the registers of the ov3640 like in an old driver which worked with kernel version 2.6.34. I was able to get an image but I don't understand what the problem might be. sudo ./media-ctl -v -r -l 'ov3640 3-003c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' sudo ./media-ctl -v -V 'ov3640 3-003c:0 [UYVY2X8 640x480], OMAP3 ISP CCDC:1 [UYVY2X8 640x480]' sudo ./yavta -p -f UYVY -s 640x480 -n 4 --skip 3 --capture=13 --file=img#.raw /dev/video2 the picture I got looks like this (should be a standard test pattern): http://s7.directupload.net/file/d/3435/2s5kuacl_png.htm does someone know on which signal each of these 3 functions (ccdc_vd0_isr; ccdc_vd1_isr; ccdc_hs_vs_isr) are called. what signal has to be high? Regards, Tom -- 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 v9 01/13] [media] exynos5-is: Adding media device driver for exynos5
On Fri, Sep 27, 2013 at 11:59:06AM +0100, Arun Kumar K wrote: From: Shaik Ameer Basha shaik.am...@samsung.com This patch adds support for media device for EXYNOS5 SoCs. The current media device supports the following ips to connect through the media controller framework. [...] diff --git a/Documentation/devicetree/bindings/media/exynos5250-camera.txt b/Documentation/devicetree/bindings/media/exynos5250-camera.txt new file mode 100644 index 000..09420ba --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5250-camera.txt @@ -0,0 +1,126 @@ +Samsung EXYNOS5 SoC Camera Subsystem + + +The Exynos5 SoC Camera subsystem comprises of multiple sub-devices +represented by separate device tree nodes. Currently this includes: FIMC-LITE, +MIPI CSIS and FIMC-IS. + +The sub-device nodes are referenced using phandles in the common 'camera' node +which also includes common properties of the whole subsystem not really +specific to any single sub-device, like common camera port pins or the common +camera bus clocks. + +Common 'camera' node + + +Required properties: + +- compatible : must be samsung,exynos5250-fimc +- clocks : list of clock specifiers, corresponding to entries in + the clock-names property Minor nit: clocks are references by phandle + clock-specifier pairs, as the clock-specifier is separate from the phandle to the clock. +- clock-names : must contain sclk_bayer entry +- samsung,csis : list of phandles to the mipi-csis device nodes +- samsung,fimc-lite: list of phandles to the fimc-lite device nodes +- samsung,fimc-is : phandle to the fimc-is device node + +The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used +to define a required pinctrl state named default. + +'parallel-ports' node +- + +This node should contain child 'port' nodes specifying active parallel video +input ports. It includes camera A, camera B and RGB bay inputs. +'reg' property in the port nodes specifies the input type: + 1 - parallel camport A + 2 - parallel camport B + 5 - RGB camera bay + +3, 4 are for MIPI CSI-2 bus and are already described in samsung-mipi-csis.txt I believe the parallel ports node must have #address-cells and #size-cells defined for the child nodes' reg properties to be meaningful. Judging by the examples and code, it seems you expect #address-cells = 1 and #size-cells = 0. It would be nice to have that described. Cheers, Mark. -- 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 v9 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation
On Fri, Sep 27, 2013 at 11:59:07AM +0100, Arun Kumar K wrote: The patch adds the DT binding documentation for Samsung Exynos5 SoC series imaging subsystem (FIMC-IS). Signed-off-by: Arun Kumar K arun...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- .../devicetree/bindings/media/exynos5-fimc-is.txt | 84 1 file changed, 84 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-fimc-is.txt diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt new file mode 100644 index 000..0525417 --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt @@ -0,0 +1,84 @@ +Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS) +-- + +The camera subsystem on Samsung Exynos5 SoC has some changes relative +to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and +FIMC-LITE IPs but has a much improved version of FIMC-IS which can +handle sensor controls and camera post-processing operations. The +Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many +post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two +dedicated scalers (SCC and SCP). + +fimc-is node + + +Required properties: + +- compatible: must be samsung,exynos5250-fimc-is s/must be/should contain/ +- reg : physical base address and size of the memory mapped + registers +- interrupt-parent : parent interrupt controller Is this actually necessary? Is it not implicit in most cases? +- interrupts: fimc-is interrupt to the parent interrupt controller - interrupts: interrupt-specifier for the sole interrupt generated by the device. +- clocks: list of clock specifiers, corresponding to entries in + clock-names property - clocks: A list of phandle + clock-specifier pairs corresponding to entries in clock-names +- clock-names : must contain isp, mcu_isp, isp_div0, isp_div1, + isp_divmpwm, mcu_isp_div0, mcu_isp_div1 entries, + matching entries in the clocks property +- samsung,pmu : phandle to the Power Management Unit (PMU) node + It may be worth point out that #address-cells, #size-cells, and ranges need to be present as approriate for mapping sub-nodes. +i2c-isp (ISP I2C bus controller) nodes +-- +The i2c-isp node is defined as the child node of fimc-is. + +Required properties: + +- compatible : should be samsung,exynos4212-i2c-isp for Exynos4212, + Exynos4412 and Exynos5250 SoCs s/should be/should contain/ +- reg: physical base address and length of the registers set +- clocks : must contain gate clock specifier for this controller +- clock-names: must contain i2c_isp entry Please reword clocks to be in terms of clock-names, as above. e.g. - clocks: A list of phandle + clock-specifier pairs corresponding to entries in clock-names - clock-names: Should contain i2c_isp fot the gate clock Otherwise, I think this looks ok. Cheers, Mark. -- 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/1] v4l: Add frame end event
Hi Hans, Thanks for your comments. Hans Verkuil wrote: ... I have no objections to this patch. You do need to adapt drivers/media/platform/omap3isp/ispccdc.c a bit since it is using the FRAME_SYNC event and so it should check the id field. Good point. But will you also be upstreaming a driver that uses the SYNC_END? I don't really want to merge this if nobody is using it. I agree --- I can't say right now when there could be an upstreamable driver using that event. Let's keep it out of the tree for now. Especially that after giving some thought to the multi stream use cases --- now arguing against my own proposal ;-) --- the id field would be better used to make a difference between different streams, especially for the frame start event. We're not exactly running out of possible values for the type field. So I'd now prefer an entirely separate event to tell about the frame end, and perhaps add an alias for the frame sync event (FRAME_START). (This again is a proof of why things that are not going to get used pretty much immediately should almost never be merged.) I can send a patch on that as well, and, should someone else need it, that one can be merged, naturally after a review. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com -- 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] [RESEND] gspca-stk1135: Add delay after configuring clock
Add a small delay at the end of configure_clock() to allow sensor to initialize. This is needed by Asus VX2S laptop webcam to detect sensor type properly (the already-supported MT9M112). Signed-off-by: Ondrej Zary li...@rainbow-software.org --- drivers/media/usb/gspca/stk1135.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/usb/gspca/stk1135.c b/drivers/media/usb/gspca/stk1135.c index 8add2f7..d8a813c 100644 --- a/drivers/media/usb/gspca/stk1135.c +++ b/drivers/media/usb/gspca/stk1135.c @@ -361,6 +361,9 @@ static void stk1135_configure_clock(struct gspca_dev *gspca_dev) /* set serial interface clock divider (30MHz/0x1f*16+2) = 60240 kHz) */ reg_w(gspca_dev, STK1135_REG_SICTL + 2, 0x1f); + + /* wait a while for sensor to catch up */ + udelay(1000); } static void stk1135_camera_disable(struct gspca_dev *gspca_dev) -- Ondrej Zary -- 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] [RESEND] gspca-stk1135: Add delay after configuring clock
Hi Ondrej, On 11/11/2013 11:31 PM, Ondrej Zary wrote: Add a small delay at the end of configure_clock() to allow sensor to initialize. This is needed by Asus VX2S laptop webcam to detect sensor type properly (the already-supported MT9M112). Signed-off-by: Ondrej Zaryli...@rainbow-software.org --- drivers/media/usb/gspca/stk1135.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/usb/gspca/stk1135.c b/drivers/media/usb/gspca/stk1135.c index 8add2f7..d8a813c 100644 --- a/drivers/media/usb/gspca/stk1135.c +++ b/drivers/media/usb/gspca/stk1135.c @@ -361,6 +361,9 @@ static void stk1135_configure_clock(struct gspca_dev *gspca_dev) /* set serial interface clock divider (30MHz/0x1f*16+2) = 60240 kHz) */ reg_w(gspca_dev, STK1135_REG_SICTL + 2, 0x1f); + + /* wait a while for sensor to catch up */ + udelay(1000); Instead of this 1 ms busy loop waiting it might be more optimal to use usleep_range(), e.g. usleep_range(1000, 1100); } static void stk1135_camera_disable(struct gspca_dev *gspca_dev) -- Regards, Sylwester -- 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/3] media: Add SH-Mobile RCAR-H2 Lager board support
Hi Valentine, On Tuesday 24 September 2013 17:38:33 Valentine Barshak wrote: The following patches add ADV7611/ADV7612 HDMI receiver I2C driver and add RCAR H2 SOC support along with ADV761x output format support to rcar_vin soc_camera driver. These changes are needed for SH-Mobile R8A7790 Lager board video input support. Do you plan to submit a v2 ? I need the ADV761x driver pretty soon and I'd like to avoid submitting a competing patch :-) Valentine Barshak (3): media: i2c: Add ADV761X support media: rcar_vin: Add preliminary r8a7790 H2 support media: rcar_vin: Add RGB888_1X24 input format support drivers/media/i2c/Kconfig| 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/adv761x.c | 1060 +++ drivers/media/platform/soc_camera/rcar_vin.c | 17 +- include/media/adv761x.h | 28 + 5 files changed, 1114 insertions(+), 3 deletions(-) create mode 100644 drivers/media/i2c/adv761x.c create mode 100644 include/media/adv761x.h -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Nov 12 04:00:19 CET 2013 git branch: test git hash: 80f93c7b0f4599ffbdac8d964ecd1162b8b618b9 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK apps: WARNINGS spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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][RESEND 3/8] dma: mmp_tdma: use gen_pool_dma_alloc() to allocate descriptor
On Fri, Nov 01, 2013 at 07:48:16PM +0800, Nicolin Chen wrote: Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Acked-by: Vinod Koul vinod.k...@intel.com -- ~Vinod -- 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] [media] s5p-mfc: Add QP setting support for vp8 encoder
Hi Hans, On Mon, Nov 11, 2013 at 7:03 PM, Hans Verkuil hverk...@xs4all.nl wrote: On 11/11/2013 11:44 AM, Arun Kumar K wrote: Hi Hans, On Mon, Nov 11, 2013 at 3:01 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Arun, On 11/11/2013 10:19 AM, Arun Kumar K wrote: Adds v4l2 controls to set MIN, MAX QP values and I, P frame QP for vp8 encoder. I assume these parameters and their ranges are all defined by the VP8 standard? Or are they HW specific? These ranges are not defined by VP8 standard. I can see that the standard does not give any range. The ranges mentioned are defined by Samsung MFC hardware. Do you think that for these controls, I shouldnt mention the range as the standard does not have it? Either leave it out or just say that the range is hardware dependent. Ok will do that. Thanks Regards Arun -- 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
