Re: [PATCH v1 10/19] uvcvideo: Support UVC 1.5 runtime control property.
On 08/30/2013 04:17 AM, Pawel Osciak wrote:
UVC 1.5 introduces the concept of runtime controls, which can be set during
streaming. Non-runtime controls can only be changed while device is idle.
I don't know if you know this, but the V4L2_CTRL_FLAG_GRABBED flag can be set
for
controls that cannot be changed while streaming. Typically drivers will set that
flag for the relevant controls when streaming starts and clear it when streaming
stops.
Toggling that flag also means that a control event has to be generated reporting
a change of the control flags.
Regards,
Hans
Signed-off-by: Pawel Osciak posc...@chromium.org
---
drivers/media/usb/uvc/uvc_ctrl.c | 45
+---
drivers/media/usb/uvc/uvc_v4l2.c | 18 ++--
drivers/media/usb/uvc/uvcvideo.h | 12 +++
3 files changed, 57 insertions(+), 18 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
b/drivers/media/usb/uvc/uvc_ctrl.c
index d735c88..b0a19b9 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1076,8 +1076,19 @@ void __uvc_ctrl_unlock(struct uvc_video_chain *chain)
mutex_unlock(chain-pipeline-ctrl_mutex);
}
+static int uvc_check_ctrl_runtime(struct uvc_control *ctrl, bool streaming)
+{
+ if (streaming !ctrl-in_runtime) {
+ uvc_trace(UVC_TRACE_CONTROL,
+ Control disabled while streaming\n);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
- struct v4l2_queryctrl *v4l2_ctrl)
+ struct v4l2_queryctrl *v4l2_ctrl, bool streaming)
{
struct uvc_control *ctrl;
struct uvc_control_mapping *mapping;
@@ -1093,6 +1104,10 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
goto done;
}
+ ret = uvc_check_ctrl_runtime(ctrl, streaming);
+ if (ret 0)
+ goto done;
+
ret = __uvc_query_v4l2_ctrl(chain, ctrl, mapping, v4l2_ctrl);
done:
__uvc_ctrl_unlock(chain);
@@ -1109,7 +1124,7 @@ done:
* manually.
*/
int uvc_query_v4l2_menu(struct uvc_video_chain *chain,
- struct v4l2_querymenu *query_menu)
+ struct v4l2_querymenu *query_menu, bool streaming)
{
struct uvc_menu_info *menu_info;
struct uvc_control_mapping *mapping;
@@ -1132,6 +1147,10 @@ int uvc_query_v4l2_menu(struct uvc_video_chain *chain,
goto done;
}
+ ret = uvc_check_ctrl_runtime(ctrl, streaming);
+ if (ret 0)
+ goto done;
+
if (query_menu-index = mapping-menu_count) {
ret = -EINVAL;
goto done;
@@ -1436,21 +1455,26 @@ done:
return ret;
}
-int uvc_ctrl_get(struct uvc_video_chain *chain,
- struct v4l2_ext_control *xctrl)
+int uvc_ctrl_get(struct uvc_video_chain *chain, struct v4l2_ext_control
*xctrl,
+ bool streaming)
{
struct uvc_control *ctrl;
struct uvc_control_mapping *mapping;
+ int ret;
ctrl = uvc_find_control(chain, xctrl-id, mapping);
if (ctrl == NULL)
return -EINVAL;
+ ret = uvc_check_ctrl_runtime(ctrl, streaming);
+ if (ret 0)
+ return ret;
+
return __uvc_ctrl_get(chain, ctrl, mapping, xctrl-value);
}
-int uvc_ctrl_set(struct uvc_video_chain *chain,
- struct v4l2_ext_control *xctrl)
+int uvc_ctrl_set(struct uvc_video_chain *chain, struct v4l2_ext_control
*xctrl,
+ bool streaming)
{
struct uvc_control *ctrl;
struct uvc_control_mapping *mapping;
@@ -1466,6 +1490,10 @@ int uvc_ctrl_set(struct uvc_video_chain *chain,
if (!(ctrl-info.flags UVC_CTRL_FLAG_SET_CUR))
return -EACCES;
+ ret = uvc_check_ctrl_runtime(ctrl, streaming);
+ if (ret 0)
+ return ret;
+
/* Clamp out of range values. */
switch (mapping-v4l2_type) {
case V4L2_CTRL_TYPE_INTEGER:
@@ -1885,8 +1913,9 @@ static int uvc_ctrl_add_info(struct uvc_device *dev,
struct uvc_control *ctrl,
ctrl-initialized = 1;
uvc_trace(UVC_TRACE_CONTROL, Added control %pUl/%u to device %s
- entity %u\n, ctrl-info.entity, ctrl-info.selector,
- dev-udev-devpath, ctrl-entity-id);
+ entity %u, init/runtime %d/%d\n, ctrl-info.entity,
+ ctrl-info.selector, dev-udev-devpath, ctrl-entity-id,
+ ctrl-on_init, ctrl-in_runtime);
done:
if (ret 0)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
b/drivers/media/usb/uvc/uvc_v4l2.c
index a899159..decd65f 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -597,7 +597,8 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
/* Get, Set Query control */
case VIDIOC_QUERYCTRL:
- return uvc_query_v4l2_ctrl(chain, arg);
+
Re: [PATCH v1 14/19] v4l: Add v4l2_buffer flags for VP8-specific special frames.
On 08/30/2013 04:17 AM, Pawel Osciak wrote:
Add bits for previous, golden and altref frame types.
Signed-off-by: Pawel Osciak posc...@chromium.org
Kamil, is this something that applies as well to your MFC driver?
---
include/uapi/linux/videodev2.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..c011ee0 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -687,6 +687,10 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 0x
#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC0x2000
#define V4L2_BUF_FLAG_TIMESTAMP_COPY 0x4000
+/* VP8 special frames */
+#define V4L2_BUF_FLAG_PREV_FRAME 0x1 /* VP8 prev frame */
+#define V4L2_BUF_FLAG_GOLDEN_FRAME 0x2 /* VP8 golden frame */
+#define V4L2_BUF_FLAG_ALTREF_FRAME 0x4 /* VP8 altref frame */
Would it be an idea to use the same bit values as for KEYFRAME/PFRAME/BFRAME?
After all, these can never be used at the same time. I'm a bit worried that the
bits in this field are eventually all used up by different encoder flags.
Regards,
Hans
/**
* struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
--
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 v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:
On Thu 29 August 2013 14:32:49 Archit Taneja wrote:
VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.
We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.
Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are added.
Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and stores
them in the buffer. There are also some VPDMA parameters like frame start and
line mode which needs to be configured, these are configured by direct register
writes via the VPDMA helper functions.
The driver's device_run() mem2mem op will add each descriptor based on how the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
upload MMR registers, start DMA of video buffers on the various input and output
clients/ports.
When the list is parsed completely(and the DMAs on all the output ports done),
an interrupt is generated which we use to notify that the source and destination
buffers are done.
The rest of the driver is quite similar to other mem2mem drivers, we use the
multiplane v4l2 ioctls as the HW support coplanar formats.
Signed-off-by: Archit Taneja arc...@ti.com
Thanks for the patch. Just a few small comments below...
---
drivers/media/platform/Kconfig | 16 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/ti-vpe/Makefile |5 +
drivers/media/platform/ti-vpe/vpe.c | 1740 ++
drivers/media/platform/ti-vpe/vpe_regs.h | 496 +
5 files changed, 2259 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/Makefile
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
new file mode 100644
index 000..85b0880
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/vpe.c
snip
+static int vpe_enum_fmt(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if (V4L2_TYPE_IS_OUTPUT(f-type))
+ return __enum_fmt(f, VPE_FMT_TYPE_OUTPUT);
+ else
The line above isn't necessary.
Oh right, thanks for spotting that.
+ return __enum_fmt(f, VPE_FMT_TYPE_CAPTURE);
+}
+
snip
+
+ pix-field = V4L2_FIELD_NONE;
+
+ v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
+ pix-height, MIN_H, MAX_H, H_ALIGN,
+ S_ALIGN);
+
+ pix-num_planes = fmt-coplanar ? 2 : 1;
+ pix-pixelformat = fmt-fourcc;
+ pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?
+ V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
pix-priv should be set to NULL as well.
I'll fix this.
snip
+}
+
+#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000)
Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h.
Similar to the ones already defined there.
That will ensure that controls for this driver have unique IDs.
Thanks, I took this from the mem2mem-testdev driver, a test driver
doesn't need to worry about this I suppose.
I had a query regarding this. I am planning to add a capture driver in
the future for a similar IP which can share some of the control IDs with
VPE. Is it possible for 2 different drivers to share the IDs?
Also, I noticed in the header that most drivers reserve space for 16
IDs. The current driver just has one, but there will be more custom ones
in the future. Is it fine if I reserve 16 for this driver too?
snip
+
+static int queue_init(void *priv, struct vb2_queue *src_vq,
+ struct vb2_queue *dst_vq)
+{
+ struct vpe_ctx *ctx = priv;
+ int ret;
+
+ memset(src_vq, 0, sizeof(*src_vq));
+ src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
+ src_vq-io_modes = VB2_MMAP;
+ src_vq-drv_priv = ctx;
+ src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
+ src_vq-ops = vpe_qops;
+ src_vq-mem_ops = vb2_dma_contig_memops;
+ src_vq-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
Shouldn't this be TIMESTAMP_COPY?
Right, it should be, I'll fix
Re: [PATCH v1 16/19] v4l: Add encoding camera controls.
On 08/30/2013 04:17 AM, Pawel Osciak wrote:
Add defines for controls found in UVC 1.5 encoding cameras.
Signed-off-by: Pawel Osciak posc...@chromium.org
---
drivers/media/v4l2-core/v4l2-ctrls.c | 29 +
include/uapi/linux/v4l2-controls.h | 31 +++
2 files changed, 60 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index c3f0803..0b3a632 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -781,6 +781,35 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_AUTO_FOCUS_STATUS:return Auto Focus, Status;
case V4L2_CID_AUTO_FOCUS_RANGE: return Auto Focus, Range;
+ case V4L2_CID_ENCODER_MIN_FRAME_INTERVAL: return Encoder, min. frame
interval;
+ case V4L2_CID_ENCODER_RATE_CONTROL_MODE: return Encoder, rate control
mode;
+ case V4L2_CID_ENCODER_AVERAGE_BITRATE: return Encoder, average
bitrate;
+ case V4L2_CID_ENCODER_CPB_SIZE: return Encoder, CPB size;
+ case V4L2_CID_ENCODER_PEAK_BIT_RATE:return Encoder, peak bit rate;
+ case V4L2_CID_ENCODER_QP_PARAM_I: return Encoder, QP param for I
frames;
+ case V4L2_CID_ENCODER_QP_PARAM_P: return Encoder, QP param for P
frames;
+ case V4L2_CID_ENCODER_QP_PARAM_BG: return Encoder, QP param for
B/G frames;
A lot of these exist already. E.g. V4L2_CID_MPEG_VIDEO_MPEG4_I/P/B_FRAME_QP.
Samsung added support for many of these parameters for their MFC encoder
(including
VP8 support) so you should use them as well. As mentioned in v4l2-controls.h the
MPEG part of the control name is historical. Interpret it as 'CODEC', not MPEG.
+ case V4L2_CID_ENCODER_NUM_GDR_FRAMES: return Encoder, number of GDR
frames;
+ case V4L2_CID_ENCODER_LTR_BUFFER_CONTROL: return Encoder, LTR buffer
control;
+ case V4L2_CID_ENCODER_LTR_BUFFER_TRUST_MODE: return Encoder, LTR
buffer trust mode;
+ case V4L2_CID_ENCODER_LTR_PICTURE_POSITION: return Encoder, LTR
picture position;
+ case V4L2_CID_ENCODER_LTR_PICTURE_MODE: return Encoder, LTR picture
mode;
+ case V4L2_CID_ENCODER_LTR_VALIDATION: return Encoder, LTR
validation;
+ case V4L2_CID_ENCODER_MIN_QP: return Encoder, minimum QP
param;
+ case V4L2_CID_ENCODER_MAX_QP: return Encoder, maximum QP
param;
+ case V4L2_CID_ENCODER_SYNC_FRAME_INTERVAL: return Encoder, sync frame
interval;
+ case V4L2_CID_ENCODER_ERROR_RESILIENCY: return Encoder, error
resiliency;
+ case V4L2_CID_ENCODER_TEMPORAL_LAYER_ENABLE: return Encoder, temporal
layer enable;
+
+ case V4L2_CID_ENCODER_VP8_SLICE_MODE: return Encoder, VP8 slice
mode;
+ case V4L2_CID_ENCODER_VP8_SYNC_FRAME_TYPE: return Encoder, VP8 sync
frame type;
+ case V4L2_CID_ENCODER_VP8_DCT_PARTS_PER_FRAME: return Encoder, VP8,
DCT partitions per frame;
+
+ case V4L2_CID_ENCODER_H264_PROFILE_TOOLSET: return Encoder, H.264
profile and toolset;
+ case V4L2_CID_ENCODER_H264_LEVEL_IDC_LIMIT: return Encoder, H.264
level IDC limit;
+ case V4L2_CID_ENCODER_H264_SEI_PAYLOAD_TYPE: return Encoder, H.264 SEI
payload type;
+ case V4L2_CID_ENCODER_H264_LAYER_PRIORITY: return Encoder, H.264 layer
priority;
+
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
case V4L2_CID_FM_TX_CLASS: return FM Radio Modulator
Controls;
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 083bb5a..ef3a30d 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -729,6 +729,37 @@ enum v4l2_auto_focus_range {
V4L2_AUTO_FOCUS_RANGE_INFINITY = 3,
};
+/* Controls found in UVC 1.5 encoding cameras */
+#define V4L2_CID_ENCODER_MIN_FRAME_INTERVAL (V4L2_CID_CAMERA_CLASS_BASE+32)
+#define V4L2_CID_ENCODER_RATE_CONTROL_MODE (V4L2_CID_CAMERA_CLASS_BASE+33)
+#define V4L2_CID_ENCODER_AVERAGE_BITRATE (V4L2_CID_CAMERA_CLASS_BASE+34)
+#define V4L2_CID_ENCODER_CPB_SIZE(V4L2_CID_CAMERA_CLASS_BASE+35)
+#define V4L2_CID_ENCODER_PEAK_BIT_RATE
(V4L2_CID_CAMERA_CLASS_BASE+36)
+#define V4L2_CID_ENCODER_QP_PARAM_I (V4L2_CID_CAMERA_CLASS_BASE+37)
+#define V4L2_CID_ENCODER_QP_PARAM_P (V4L2_CID_CAMERA_CLASS_BASE+38)
+#define V4L2_CID_ENCODER_QP_PARAM_BG (V4L2_CID_CAMERA_CLASS_BASE+39)
+#define V4L2_CID_ENCODER_NUM_GDR_FRAMES
(V4L2_CID_CAMERA_CLASS_BASE+40)
+#define V4L2_CID_ENCODER_LTR_BUFFER_CONTROL (V4L2_CID_CAMERA_CLASS_BASE+41)
+#define V4L2_CID_ENCODER_LTR_BUFFER_TRUST_MODE
(V4L2_CID_CAMERA_CLASS_BASE+42)
+#define V4L2_CID_ENCODER_LTR_PICTURE_POSITION
(V4L2_CID_CAMERA_CLASS_BASE+43)
+#define V4L2_CID_ENCODER_LTR_PICTURE_MODE
Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On 08/30/2013 08:47 AM, Archit Taneja wrote:
On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:
On Thu 29 August 2013 14:32:49 Archit Taneja wrote:
VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color
space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.
We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.
Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are
added.
Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and
stores
them in the buffer. There are also some VPDMA parameters like frame start
and
line mode which needs to be configured, these are configured by direct
register
writes via the VPDMA helper functions.
The driver's device_run() mem2mem op will add each descriptor based on how
the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA
will
upload MMR registers, start DMA of video buffers on the various input and
output
clients/ports.
When the list is parsed completely(and the DMAs on all the output ports
done),
an interrupt is generated which we use to notify that the source and
destination
buffers are done.
The rest of the driver is quite similar to other mem2mem drivers, we use the
multiplane v4l2 ioctls as the HW support coplanar formats.
Signed-off-by: Archit Taneja arc...@ti.com
Thanks for the patch. Just a few small comments below...
---
drivers/media/platform/Kconfig | 16 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/ti-vpe/Makefile |5 +
drivers/media/platform/ti-vpe/vpe.c | 1740
++
drivers/media/platform/ti-vpe/vpe_regs.h | 496 +
5 files changed, 2259 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/Makefile
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
new file mode 100644
index 000..85b0880
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/vpe.c
snip
+static int vpe_enum_fmt(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if (V4L2_TYPE_IS_OUTPUT(f-type))
+ return __enum_fmt(f, VPE_FMT_TYPE_OUTPUT);
+ else
The line above isn't necessary.
Oh right, thanks for spotting that.
+ return __enum_fmt(f, VPE_FMT_TYPE_CAPTURE);
+}
+
snip
+
+ pix-field = V4L2_FIELD_NONE;
+
+ v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
+ pix-height, MIN_H, MAX_H, H_ALIGN,
+ S_ALIGN);
+
+ pix-num_planes = fmt-coplanar ? 2 : 1;
+ pix-pixelformat = fmt-fourcc;
+ pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?
+ V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
pix-priv should be set to NULL as well.
I'll fix this.
snip
+}
+
+#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000)
Reserve a control range for this driver in
include/uapi/linux/v4l2-controls.h.
Similar to the ones already defined there.
That will ensure that controls for this driver have unique IDs.
Thanks, I took this from the mem2mem-testdev driver, a test driver
doesn't need to worry about this I suppose.
I had a query regarding this. I am planning to add a capture driver in
the future for a similar IP which can share some of the control IDs with
VPE. Is it possible for 2 different drivers to share the IDs?
Certainly. There are three levels of controls:
1) Standard controls: can be used by any driver and are documented in the spec.
2) IP-specific controls: controls specific for a commonly used IP.
These can be used by any driver containing that IP and are documented as well
in the spec. Good examples are the MFC and CX2341x MPEG controls.
3) Driver-specific controls: these are specific to a driver and do not have to
be
documented in the spec, only in the header/source specifying them. A range
of controls needs to be assigned to such a driver in v4l2-dv-controls.h.
In your case it looks like the controls would fall into category 2.
Also, I noticed in the header that most drivers reserve space for 16
IDs. The current
Re: How to express planar formats with mediabus format code?
Hi Sakari, On Thu, Aug 22, 2013 at 7:29 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jiaquan, On Wednesday 21 August 2013 18:14:50 Su Jiaquan wrote: On Tue, Aug 20, 2013 at 8:53 PM, Laurent Pinchart wrote: Hi Jiaquan, I'm not sure if that's needed here. Vendor-specific formats still need to be documented, so we could just create a custom YUV format for your case. Let's start with the beginning, could you describe what gets transmitted on the bus when that special format is selected ? For YUV420P format, the data format sent from IPC is similar to V4L2_MBUS_FMT_YUYV8_1_5X8, but the content for each line is different: For odd line, it's YYU YYU YYU... For even line, it's YYV YYV YYV... then DMA engine send them to RAM in planar format. For YUV420SP format, the data format sent from IPC is YYUV YYUV YYUV(maybe called V4L2_MBUS_FMT_YYUV8_2X8?), but DMA engine drop UV every other line, then send them to RAM as semi-planar. V4L2_MBUS_FMT_YYUV8_2X8 looks good to me. Well, the first data format is too odd, I don't have a clue how to call it, do you have suggestion? Maybe V4L2_MBUS_FMT_YU8_YV8_1_5X8 ? I've CC'ed Sakari Ailus, he's often pretty creative for these issues. -- Regards, Laurent Pinchart Does the format V4L2_MBUS_FMT_YU8_YV8_1_5X8 sounds good to you? Do you have better idea how we should describe this format? If there is no further concern, I'll prepare a patch Thanks -- 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 v1 14/19] v4l: Add v4l2_buffer flags for VP8-specific special frames.
On Fri 30 August 2013 09:28:36 Pawel Osciak wrote:
On Fri, Aug 30, 2013 at 3:42 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On 08/30/2013 04:17 AM, Pawel Osciak wrote:
Add bits for previous, golden and altref frame types.
Signed-off-by: Pawel Osciak posc...@chromium.org
Kamil, is this something that applies as well to your MFC driver?
---
include/uapi/linux/videodev2.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h
index 437f1b0..c011ee0 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -687,6 +687,10 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 0x
#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC0x2000
#define V4L2_BUF_FLAG_TIMESTAMP_COPY 0x4000
+/* VP8 special frames */
+#define V4L2_BUF_FLAG_PREV_FRAME 0x1 /* VP8 prev frame
*/
+#define V4L2_BUF_FLAG_GOLDEN_FRAME 0x2 /* VP8 golden
frame */
+#define V4L2_BUF_FLAG_ALTREF_FRAME 0x4 /* VP8 altref
frame */
Would it be an idea to use the same bit values as for
KEYFRAME/PFRAME/BFRAME?
After all, these can never be used at the same time. I'm a bit worried
that the
bits in this field are eventually all used up by different encoder flags.
VP8 also has a concept of I and P frames and they are orthogonal to the
concept of Prev, Golden and Alt. There is no relationship at all, i.e. we
can't infer I P from Prev Golden Alt and vice versa.
Ah, OK. Me no VP8 expert :-)
For the I, P
dimension, we need one bit, but same could be said about H264, we need 2
bits, not 3 there (if it's not I or P, it's B), and we have 3 bits
nevertheless.
For Prev Golden Alt dimension, we do need 3 bits.
Now, technically, in VP8, the first bit of the frame header indicates if
the frame is I or P, so we could technically use that in userspace and
overload I P B to mean Prev Golden Alt for VP8. But while I understand the
problem with running out of bits very well, as I and P exist in VP8 as
well, it would be pretty confusing, so it's a trade-off that should be
carefully weighted.
Are prev/golden/altref frames mutually exclusive? If so, then perhaps we
should use a two-bit mask instead of three bits. And those two-bits can
later be expanded to more to support codecs that have more than four
different frame types.
Regards,
Hans
Regards,
Pawel
Regards,
Hans
/**
* struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
--
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: usb: b2c2: Kconfig: add PCI dependancy to DVB_B2C2_FLEXCOP_USB
On 08/30/2013 04:06 PM, Patrick Boettcher wrote: Hi, On Friday 30 August 2013 10:23:24 Chen Gang wrote: DVB_B2C2_FLEXCOP_USB need depend on PCI, or can not pass compiling with allmodconfig for h8300. The related error: drivers/media/usb/b2c2/flexcop-usb.c: In function 'flexcop_usb_transfer_exit': drivers/media/usb/b2c2/flexcop-usb.c:393:3: error: implicit declaration of function 'pci_free_consistent' [-Werror=implicit-function-declaration] pci_free_consistent(NULL, [..] config DVB_B2C2_FLEXCOP_USB tristate Technisat/B2C2 Air/Sky/Cable2PC USB - depends on DVB_CORE I2C + depends on DVB_CORE I2C PCI help Support for the Air/Sky/Cable2PC USB1.1 box (DVB/ATSC) by Technisat/B2C2, Instead of selecting PCI we could/should use usb_alloc_coherent() and usb_free_cohrerent(), shouldn't we? Hmm... maybe it is a good idea, but I am just trying another ways. Just now, I find that the module which calls pci*consistent() may not be pci dependent module (e.g. may depend on ISA or EISA instead of). So arch/h8300/include/asm/pci.h has related issues, I am just fixing. Maybe our case is not an issue, after asm/pci.h fixed (although for our case only, it can be improved, too, and if you are sure about it, please help improving it, thanks). -- Patrick Thanks. -- Chen Gang -- 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: usb: b2c2: Kconfig: add PCI dependancy to DVB_B2C2_FLEXCOP_USB
Hi (sending again due to HTML-nonsense in Mail), On Friday 30 August 2013 10:23:24 Chen Gang wrote: DVB_B2C2_FLEXCOP_USB need depend on PCI, or can not pass compiling with allmodconfig for h8300. The related error: drivers/media/usb/b2c2/flexcop-usb.c: In function 'flexcop_usb_transfer_exit': drivers/media/usb/b2c2/flexcop-usb.c:393:3: error: implicit declaration of function 'pci_free_consistent' [-Werror=implicit-function-declaration] pci_free_consistent(NULL, [..] config DVB_B2C2_FLEXCOP_USB tristate Technisat/B2C2 Air/Sky/Cable2PC USB - depends on DVB_CORE I2C + depends on DVB_CORE I2C PCI help Support for the Air/Sky/Cable2PC USB1.1 box (DVB/ATSC) by Technisat/B2C2, Instead of selecting PCI we could/should use usb_alloc_coherent() and usb_free_cohrerent(), shouldn't we? -- Patrick -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] adv7842: fix compilation with GCC 4.4.6
With GCC 4.4.3 (Ubuntu 10.04) the compilation of the new adv7842 driver
fails with this error:
CC [M] adv7842.o
adv7842.c:549: error: unknown field 'bt' specified in initializer
adv7842.c:550: error: field name not in record or union initializer
adv7842.c:550: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:551: error: field name not in record or union initializer
adv7842.c:551: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:552: error: field name not in record or union initializer
adv7842.c:552: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:553: error: field name not in record or union initializer
adv7842.c:553: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:553: warning: excess elements in array initializer
...
This is caused by the old GCC version, as explained in file v4l2-dv-timings.h.
The proposed fix uses the V4L2_INIT_BT_TIMINGS macro defined there.
Please note that I have also to init the reserved space as otherwise GCC fails
with this error:
CC [M] adv7842.o
adv7842.c:549: error: field name not in record or union initializer
adv7842.c:549: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:549: warning: braces around scalar initializer
adv7842.c:549: warning: (near initialization for
'adv7842_timings_cap_analog.reserved[0]')
...
Maybe the reserved space in struct v4l2_dv_timings_cap could be moved after
the 'bt' field to avoid this?
The same issue applies to other drivers too: ths8200, adv7511 and ad9389b.
If the fix is approved, I can post a patch serie fixing all of them.
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
drivers/media/i2c/adv7842.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index d174890..c21621b 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -546,30 +546,22 @@ static inline bool is_digital_input(struct v4l2_subdev
*sd)
static const struct v4l2_dv_timings_cap adv7842_timings_cap_analog = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1200,
- .min_pixelclock = 2500,
- .max_pixelclock = 17000,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1200, 2500, 17000,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static const struct v4l2_dv_timings_cap adv7842_timings_cap_digital = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1200,
- .min_pixelclock = 2500,
- .max_pixelclock = 22500,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1200, 2500, 22500,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static inline const struct v4l2_dv_timings_cap *
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
Hi, On Friday 30 August 2013 12:37 PM, Hans Verkuil wrote: On 08/30/2013 08:47 AM, Archit Taneja wrote: On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote: On Thu 29 August 2013 14:32:49 Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. snip +} + +#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000) Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h. Similar to the ones already defined there. That will ensure that controls for this driver have unique IDs. Thanks, I took this from the mem2mem-testdev driver, a test driver doesn't need to worry about this I suppose. I had a query regarding this. I am planning to add a capture driver in the future for a similar IP which can share some of the control IDs with VPE. Is it possible for 2 different drivers to share the IDs? Certainly. There are three levels of controls: 1) Standard controls: can be used by any driver and are documented in the spec. 2) IP-specific controls: controls specific for a commonly used IP. These can be used by any driver containing that IP and are documented as well in the spec. Good examples are the MFC and CX2341x MPEG controls. 3) Driver-specific controls: these are specific to a driver and do not have to be documented in the spec, only in the header/source specifying them. A range of controls needs to be assigned to such a driver in v4l2-dv-controls.h. In your case it looks like the controls would fall into category 2. For 2), by commonly used IP, do you mean a commonly used class of IPs like MPEG decoder, FM and camera? Or do you mean a specific vendor IP like say a camera subsystem found on different SoCs. I think the controls in my case are very specific to the VPE and VIP IPs. These 2 IPs have some components like scaler, color space converter, chrominance up/downsampler in common. The controls will be specific to how these components behave. For example, a control can tell what value of frequency of Luminance peaking the scaler needs to perform. I don't think all scalers would provide Luma peaking. This holds for other controls too. So if I understood your explanation correctly, I think 3) might make more sense. Also, I noticed in the header that most drivers reserve space for 16 IDs. The current driver just has one, but there will be more custom ones in the future. Is it fine if I reserve 16 for this driver too? Sure, that's no problem. Make sure you reserve enough space for future expansion, i.e. IDs are cheap, so no need to be conservative when defining the range. Thanks for the clarification. Archit -- 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] [media] uvcvideo: quirk PROBE_DEF for Dell SP2008WFP monitor.
Hi Greg, On Thursday 29 August 2013 21:00:21 Greg KH wrote: On Fri, Aug 30, 2013 at 02:41:17AM +0200, Laurent Pinchart wrote: On Thursday 29 August 2013 11:17:41 Joseph Salisbury wrote: BugLink: http://bugs.launchpad.net/bugs/1217957 Add quirk for Dell SP2008WFP monitor: 05a9:2641 Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com Tested-by: Christopher Townsend christopher.towns...@canonical.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: sta...@vger.kernel.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've applied it to my tree. Given that we're too close to the v3.12 merge window I will push it for v3.13. A quirk has to wait that long? That's not ok, they should go in much sooner than that... Can such a patch get merged during the -rc phase ? If so I will push it to v3.12. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx + ov2640 and v4l2-clk
Hi Frank, On Fri, 23 Aug 2013, Frank Schäfer wrote: Hi Sylwester, Am 21.08.2013 23:42, schrieb Sylwester Nawrocki: Hi Frank, On 08/21/2013 10:39 PM, Frank Schäfer wrote: Am 20.08.2013 18:34, schrieb Frank Schäfer: Am 20.08.2013 15:38, schrieb Laurent Pinchart: Hi Mauro, On Sunday 18 August 2013 12:20:08 Mauro Carvalho Chehab wrote: Em Sun, 18 Aug 2013 13:40:25 +0200 Frank Schäfer escreveu: Am 17.08.2013 12:51, schrieb Guennadi Liakhovetski: Hi Frank, As I mentioned on the list, I'm currently on a holiday, so, replying briefly. Sorry, I missed that (can't read all mails on the list). Since em28xx is a USB device, I conclude, that it's supplying clock to its components including the ov2640 sensor. So, yes, I think the driver should export a V4L2 clock. Could you please test this patch series http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/68510 to see whether it fixes this your problem? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On Fri 30 August 2013 12:05:11 Archit Taneja wrote: Hi, On Friday 30 August 2013 12:37 PM, Hans Verkuil wrote: On 08/30/2013 08:47 AM, Archit Taneja wrote: On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote: On Thu 29 August 2013 14:32:49 Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. snip +} + +#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1000) Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h. Similar to the ones already defined there. That will ensure that controls for this driver have unique IDs. Thanks, I took this from the mem2mem-testdev driver, a test driver doesn't need to worry about this I suppose. I had a query regarding this. I am planning to add a capture driver in the future for a similar IP which can share some of the control IDs with VPE. Is it possible for 2 different drivers to share the IDs? Certainly. There are three levels of controls: 1) Standard controls: can be used by any driver and are documented in the spec. 2) IP-specific controls: controls specific for a commonly used IP. These can be used by any driver containing that IP and are documented as well in the spec. Good examples are the MFC and CX2341x MPEG controls. 3) Driver-specific controls: these are specific to a driver and do not have to be documented in the spec, only in the header/source specifying them. A range of controls needs to be assigned to such a driver in v4l2-dv-controls.h. In your case it looks like the controls would fall into category 2. For 2), by commonly used IP, do you mean a commonly used class of IPs like MPEG decoder, FM and camera? Or do you mean a specific vendor IP like say a camera subsystem found on different SoCs. I mean a specific vendor IP found on different SoCs. So different drivers would have to support the same IP. I think the controls in my case are very specific to the VPE and VIP IPs. These 2 IPs have some components like scaler, color space converter, chrominance up/downsampler in common. The controls will be specific to how these components behave. For example, a control can tell what value of frequency of Luminance peaking the scaler needs to perform. I don't think all scalers would provide Luma peaking. This holds for other controls too. So if I understood your explanation correctly, I think 3) might make more sense. That might be a good starting point. It is not uncommon that controls migrate from being custom controls to more standardized controls when other devices appear using the same IP. Or sometimes what seemed like a HW specific feature turns out to be available on other hardware from other vendors as well. Also, I noticed in the header that most drivers reserve space for 16 IDs. The current driver just has one, but there will be more custom ones in the future. Is it fine if I reserve 16 for this driver too? Sure, that's no problem. Make sure you reserve enough space for future expansion, i.e. IDs are cheap, so no need to be conservative when defining the range. Thanks for the clarification. Archit Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] adv7842: fix compilation with GCC 4.4.6
Hi Gianluca,
On Fri 30 August 2013 11:50:27 Gianluca Gennari wrote:
With GCC 4.4.3 (Ubuntu 10.04) the compilation of the new adv7842 driver
fails with this error:
CC [M] adv7842.o
adv7842.c:549: error: unknown field 'bt' specified in initializer
adv7842.c:550: error: field name not in record or union initializer
adv7842.c:550: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:551: error: field name not in record or union initializer
adv7842.c:551: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:552: error: field name not in record or union initializer
adv7842.c:552: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:553: error: field name not in record or union initializer
adv7842.c:553: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:553: warning: excess elements in array initializer
...
This is caused by the old GCC version, as explained in file v4l2-dv-timings.h.
The proposed fix uses the V4L2_INIT_BT_TIMINGS macro defined there.
Please note that I have also to init the reserved space as otherwise GCC
fails with this error:
CC [M] adv7842.o
adv7842.c:549: error: field name not in record or union initializer
adv7842.c:549: error: (near initialization for
'adv7842_timings_cap_analog.reserved')
adv7842.c:549: warning: braces around scalar initializer
adv7842.c:549: warning: (near initialization for
'adv7842_timings_cap_analog.reserved[0]')
...
Maybe the reserved space in struct v4l2_dv_timings_cap could be moved after
the 'bt' field to avoid this?
No, it's part of the public API, so it can't be changed. It's OK to init the
reserved space, although you should prefix it with a small comment saying that
this is necessary when compiling with a gcc 4.6.
The same issue applies to other drivers too: ths8200, adv7511 and ad9389b.
If the fix is approved, I can post a patch serie fixing all of them.
Other than the point I made above it all looks fine.
Regards,
Hans
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
drivers/media/i2c/adv7842.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index d174890..c21621b 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -546,30 +546,22 @@ static inline bool is_digital_input(struct v4l2_subdev
*sd)
static const struct v4l2_dv_timings_cap adv7842_timings_cap_analog = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1200,
- .min_pixelclock = 2500,
- .max_pixelclock = 17000,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1200, 2500, 17000,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static const struct v4l2_dv_timings_cap adv7842_timings_cap_digital = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1200,
- .min_pixelclock = 2500,
- .max_pixelclock = 22500,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1200, 2500, 22500,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static inline const struct v4l2_dv_timings_cap *
--
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 1/1] [media] v4l2-ctrls: Remove duplicate const
The function returns a pointer to a const array. Duplicate use of const
led to the following warning.
drivers/media/v4l2-core/v4l2-ctrls.c:574:32: warning: duplicate const
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/v4l2-core/v4l2-ctrls.c |6 +++---
include/media/v4l2-common.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index c6dc1fd..653d48d 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -565,13 +565,13 @@ EXPORT_SYMBOL(v4l2_ctrl_get_menu);
* Returns NULL or an s64 type array containing the menu for given
* control ID. The total number of the menu items is returned in @len.
*/
-const s64 const *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
+const s64 *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
{
- static const s64 const qmenu_int_vpx_num_partitions[] = {
+ static const s64 qmenu_int_vpx_num_partitions[] = {
1, 2, 4, 8,
};
- static const s64 const qmenu_int_vpx_num_ref_frames[] = {
+ static const s64 qmenu_int_vpx_num_ref_frames[] = {
1, 2, 3,
};
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 16550c4..b87692c 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -86,7 +86,7 @@ int v4l2_ctrl_check(struct v4l2_ext_control *ctrl, struct
v4l2_queryctrl *qctrl,
const char * const *menu_items);
const char *v4l2_ctrl_get_name(u32 id);
const char * const *v4l2_ctrl_get_menu(u32 id);
-const s64 const *v4l2_ctrl_get_int_menu(u32 id, u32 *len);
+const s64 *v4l2_ctrl_get_int_menu(u32 id, u32 *len);
int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32 min, s32 max, s32
step, s32 def);
int v4l2_ctrl_query_menu(struct v4l2_querymenu *qmenu,
struct v4l2_queryctrl *qctrl, const char * const *menu_items);
--
1.7.9.5
--
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 4/6] si4713 : HID blacklist Si4713 USB development board
The Si4713 development board contains a Si4713 FM transmitter chip
and is handled by the radio-usb-si4713 driver.
The board reports itself as (10c4:8244) Cygnal Integrated Products, Inc.
and misidentifies itself as a HID device in its USB interface descriptor.
This patch ignores this device as an HID device and hence loads the custom
driver.
Signed-off-by: Dinesh Ram din...@cisco.com
Cc: Jiri Kosina jkos...@suse.cz
Cc: linux-in...@vger.kernel.org
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 36668d1..109510f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1977,6 +1977,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL,
USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL,
USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CMEDIA, USB_DEVICE_ID_CM109) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS,
USB_DEVICE_ID_CYPRESS_ULTRAMOUSE) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ffe4c7a..2a38726 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -241,6 +241,8 @@
#define USB_VENDOR_ID_CYGNAL 0x10c4
#define USB_DEVICE_ID_CYGNAL_RADIO_SI470X 0x818a
+#define USB_DEVICE_ID_CYGNAL_RADIO_SI4713 0x8244
+
#define USB_VENDOR_ID_CYPRESS 0x04b4
#define USB_DEVICE_ID_CYPRESS_MOUSE0x0001
#define USB_DEVICE_ID_CYPRESS_HIDCOM 0x5500
--
1.8.4.rc2
--
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 2/6] si4713 : Modified i2c driver to handle cases where interrupts are not used
Checks have been introduced at several places in the code to test if an
interrupt is set or not.
For devices which do not use the interrupt, to get a valid response, within a
specified timeout,
the device is polled instead.
Signed-off-by: Dinesh Ram din...@cisco.com
---
drivers/media/radio/si4713/si4713.c | 110
drivers/media/radio/si4713/si4713.h | 1 +
2 files changed, 63 insertions(+), 48 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index ac727e3..55c4d27 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -27,7 +27,6 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/gpio.h
-#include linux/regulator/consumer.h
#include linux/module.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
@@ -213,6 +212,7 @@ static int si4713_send_command(struct si4713_device *sdev,
const u8 command,
u8 response[], const int respn, const int usecs)
{
struct i2c_client *client = v4l2_get_subdevdata(sdev-sd);
+ unsigned long until_jiffies;
u8 data1[MAX_ARGS + 1];
int err;
@@ -228,30 +228,39 @@ static int si4713_send_command(struct si4713_device
*sdev, const u8 command,
if (err != argn + 1) {
v4l2_err(sdev-sd, Error while sending command 0x%02x\n,
command);
- return (err 0) ? -EIO : err;
+ return err 0 ? err : -EIO;
}
+ until_jiffies = jiffies + usecs_to_jiffies(usecs) + 1;
+
/* Wait response from interrupt */
- if (!wait_for_completion_timeout(sdev-work,
+ if (client-irq) {
+ if (!wait_for_completion_timeout(sdev-work,
usecs_to_jiffies(usecs) + 1))
- v4l2_warn(sdev-sd,
+ v4l2_warn(sdev-sd,
(%s) Device took too much time to answer.\n,
__func__);
-
- /* Then get the response */
- err = i2c_master_recv(client, response, respn);
- if (err != respn) {
- v4l2_err(sdev-sd,
- Error while reading response for command 0x%02x\n,
- command);
- return (err 0) ? -EIO : err;
}
- DBG_BUFFER(sdev-sd, Response, response, respn);
- if (check_command_failed(response[0]))
- return -EBUSY;
+ do {
+ err = i2c_master_recv(client, response, respn);
+ if (err != respn) {
+ v4l2_err(sdev-sd,
+ Error %d while reading response for
command 0x%02x\n,
+ err, command);
+ return err 0 ? err : -EIO;
+ }
- return 0;
+ DBG_BUFFER(sdev-sd, Response, response, respn);
+ if (!check_command_failed(response[0]))
+ return 0;
+
+ if (client-irq)
+ return -EBUSY;
+ msleep(1);
+ } while (jiffies = until_jiffies);
+
+ return -EBUSY;
}
/*
@@ -344,14 +353,15 @@ static int si4713_write_property(struct si4713_device
*sdev, u16 prop, u16 val)
*/
static int si4713_powerup(struct si4713_device *sdev)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sdev-sd);
int err;
u8 resp[SI4713_PWUP_NRESP];
/*
* .First byte = Enabled interrupts and boot function
* .Second byte = Input operation mode
*/
- const u8 args[SI4713_PWUP_NARGS] = {
- SI4713_PWUP_CTSIEN | SI4713_PWUP_GPO2OEN | SI4713_PWUP_FUNC_TX,
+ u8 args[SI4713_PWUP_NARGS] = {
+ SI4713_PWUP_GPO2OEN | SI4713_PWUP_FUNC_TX,
SI4713_PWUP_OPMOD_ANALOG,
};
@@ -369,18 +379,22 @@ static int si4713_powerup(struct si4713_device *sdev)
gpio_set_value(sdev-gpio_reset, 1);
}
+ if (client-irq)
+ args[0] |= SI4713_PWUP_CTSIEN;
+
err = si4713_send_command(sdev, SI4713_CMD_POWER_UP,
args, ARRAY_SIZE(args),
resp, ARRAY_SIZE(resp),
TIMEOUT_POWER_UP);
-
+
if (!err) {
v4l2_dbg(1, debug, sdev-sd, Powerup response: 0x%02x\n,
resp[0]);
v4l2_dbg(1, debug, sdev-sd, Device in power up mode\n);
sdev-power_state = POWER_ON;
- err = si4713_write_property(sdev, SI4713_GPO_IEN,
+ if (client-irq)
+ err = si4713_write_property(sdev, SI4713_GPO_IEN,
SI4713_STC_INT | SI4713_CTS);
} else {
if (gpio_is_valid(sdev-gpio_reset))
@@ -447,7 +461,7
[PATCH 0/6] si4713 : USB driver
This is a follow-up to the patch-series mailed on 21-Agu-2013 to the mailing list. Please note that I will not be reachable at the cisco email id anymore. So please send you comments and suggestions to my private email : dinesh@cern.ch All the patches are on top of the latest version of the media-git tree as on 30-August-2013 (10:30 Europe time) The main difference to the aforementioned patch series is that, in this series the radio-i2c-si4713.c is renamed to a more appropriate one - radio-platform-si4713.c. Ofcourse, this also involvs corrosponding changes in the Makefile and Kconfig in drivers/media/radio/si4713. An entry is also added to the MAINTAINERS file. This patch series adds USB support for the SiLabs development board which contains the Si4713 FM transmitter chip. This device can transmit audio through FM. It can transmit RDS and RBDS signals as well. Documentation for this product can be accessed here : http://www.silabs.com/products/audiovideo/fmtransmitters/Pages/si471213.aspx In the source tree, drivers/media/radio has been reorganized to include a new folder drivers/media/radio/si4713 which contains all the si4713 related files. Modified and renamed files : --- drivers/media/radio/si4713-i2c.c == drivers/media/radio/si4713/si4713.c drivers/media/radio/si4713-i2c.h == drivers/media/radio/si4713/si4713.h drivers/media/radio/radio-si4713.c == drivers/media/radio/si4713/radio-platform-si4713.c New files : - drivers/media/radio/si4713/radio-usb-si4713.c The existing i2c driver has been modified to add support for cases where the interrupt is not enabled. Checks have been introduced in several places in the code to test if an interrupt is set or not. The development board is plugged into the host through USB and does not use interrupts. To get a valid response, within a specified timeout, the device is polled instead. The USB driver has been developed by analyzing the the USB traffic obtained by sniffing the USB bus. A bunch of commands are sent during device startup, the specifics of which are not obvious. Nevertheless they seem to be necessary for the proper fuctioning of the device. Note : The i2c driver assumes a 2-wire bus mode. -- 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 3/6] si4713 : Bug fix for si4713_tx_tune_power() method in the i2c driver
In the si4713_tx_tune_power() method, the args array element 'power' can take
values between
SI4713_MIN_POWER and SI4713_MAX_POWER. power = 0 is also valid.
All the values (0 power SI4713_MIN_POWER) are illegal and hence
are all mapped to SI4713_MIN_POWER.
Signed-off-by: Dinesh Ram din...@cisco.com
---
drivers/media/radio/si4713/si4713.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index 55c4d27..5d0be87 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -550,14 +550,14 @@ static int si4713_tx_tune_freq(struct si4713_device
*sdev, u16 frequency)
}
/*
- * si4713_tx_tune_power - Sets the RF voltage level between 88 and 115 dBuV in
+ * si4713_tx_tune_power - Sets the RF voltage level between 88 and 120 dBuV in
* 1 dB units. A value of 0x00 indicates off. The command
* also sets the antenna tuning capacitance. A value of 0
* indicates autotuning, and a value of 1 - 191 indicates
* a manual override, which results in a tuning
* capacitance of 0.25 pF x @antcap.
* @sdev: si4713_device structure for the device we are communicating
- * @power: tuning power (88 - 115 dBuV, unit/step 1 dB)
+ * @power: tuning power (88 - 120 dBuV, unit/step 1 dB)
* @antcap: value of antenna tuning capacitor (0 - 191)
*/
static int si4713_tx_tune_power(struct si4713_device *sdev, u8 power,
@@ -571,16 +571,16 @@ static int si4713_tx_tune_power(struct si4713_device
*sdev, u8 power,
* .Third byte = power
* .Fourth byte = antcap
*/
- const u8 args[SI4713_TXPWR_NARGS] = {
+ u8 args[SI4713_TXPWR_NARGS] = {
0x00,
0x00,
power,
antcap,
};
- if (((power 0) (power SI4713_MIN_POWER)) ||
- power SI4713_MAX_POWER || antcap SI4713_MAX_ANTCAP)
- return -EDOM;
+ /* Map power values 1-87 to MIN_POWER (88) */
+ if (power 0 power SI4713_MIN_POWER)
+ args[2] = power = SI4713_MIN_POWER;
err = si4713_send_command(sdev, SI4713_CMD_TX_TUNE_POWER,
args, ARRAY_SIZE(args), val,
@@ -1457,9 +1457,9 @@ static int si4713_probe(struct i2c_client *client,
V4L2_CID_TUNE_PREEMPHASIS,
V4L2_PREEMPHASIS_75_uS, 0, V4L2_PREEMPHASIS_50_uS);
sdev-tune_pwr_level = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
- V4L2_CID_TUNE_POWER_LEVEL, 0, 120, 1,
DEFAULT_POWER_LEVEL);
+ V4L2_CID_TUNE_POWER_LEVEL, 0, SI4713_MAX_POWER, 1,
DEFAULT_POWER_LEVEL);
sdev-tune_ant_cap = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
- V4L2_CID_TUNE_ANTENNA_CAPACITOR, 0, 191, 1, 0);
+ V4L2_CID_TUNE_ANTENNA_CAPACITOR, 0, SI4713_MAX_ANTCAP,
1, 0);
if (hdl-error) {
rval = hdl-error;
--
1.8.4.rc2
--
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 6/6] si4713 : Added MAINTAINERS entry for radio-usb-si4713 driver
Hans Verkuil hverk...@xs4all.nl will maintain the USB driver for si4713 Signed-off-by: Dinesh Ram din...@cisco.com --- MAINTAINERS | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2618ce..ddd4d5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,7 +7412,7 @@ L:linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/si4713-i2c.? +F: drivers/media/radio/si4713/si4713.? SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER M: Eduardo Valentin edubez...@gmail.com @@ -7420,7 +7420,15 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/radio-si4713.h +F: drivers/media/radio/si4713/radio-platform-si4713.c + +KEENE FM RADIO TRANSMITTER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/si4713/radio-usb-si4713.c SIANO DVB DRIVER M: Mauro Carvalho Chehab m.che...@samsung.com -- 1.8.4.rc2 -- 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 5/6] si4713 : Added the USB driver for Si4713
This is the USB driver for the Silicon Labs development board.
It contains the Si4713 FM transmitter chip.
Signed-off-by: Dinesh Ram din...@cisco.com
---
drivers/media/radio/si4713/Kconfig| 15 +
drivers/media/radio/si4713/Makefile | 1 +
drivers/media/radio/si4713/radio-usb-si4713.c | 538 ++
3 files changed, 554 insertions(+)
create mode 100644 drivers/media/radio/si4713/radio-usb-si4713.c
diff --git a/drivers/media/radio/si4713/Kconfig
b/drivers/media/radio/si4713/Kconfig
index f8ac328..6229078 100644
--- a/drivers/media/radio/si4713/Kconfig
+++ b/drivers/media/radio/si4713/Kconfig
@@ -1,3 +1,18 @@
+config USB_SI4713
+ tristate Silicon Labs Si4713 FM Radio Transmitter support with USB
+ depends on USB RADIO_SI4713
+ select SI4713
+ ---help---
+ This is a driver for USB devices with the Silicon Labs SI4713
+ chip. Currently these devices are known to work.
+ - 10c4:8244: Silicon Labs FM Transmitter USB device.
+
+ Say Y here if you want to connect this type of radio to your
+ computer's USB port.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-usb-si4713.
+
config PLATFORM_SI4713
tristate Silicon Labs Si4713 FM Radio Transmitter support with I2C
depends on I2C RADIO_SI4713
diff --git a/drivers/media/radio/si4713/Makefile
b/drivers/media/radio/si4713/Makefile
index 9d0bd0e..6524674 100644
--- a/drivers/media/radio/si4713/Makefile
+++ b/drivers/media/radio/si4713/Makefile
@@ -3,5 +3,6 @@
#
obj-$(CONFIG_I2C_SI4713) += si4713.o
+obj-$(CONFIG_USB_SI4713) += radio-usb-si4713.o
obj-$(CONFIG_PLATFORM_SI4713) += radio-platform-si4713.o
diff --git a/drivers/media/radio/si4713/radio-usb-si4713.c
b/drivers/media/radio/si4713/radio-usb-si4713.c
new file mode 100644
index 000..7f7b322
--- /dev/null
+++ b/drivers/media/radio/si4713/radio-usb-si4713.c
@@ -0,0 +1,538 @@
+/*
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/* kernel includes */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/input.h
+#include linux/mutex.h
+#include linux/i2c.h
+/* V4l includes */
+#include linux/videodev2.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-event.h
+#include media/si4713.h
+
+#include si4713.h
+
+/* driver and module definitions */
+MODULE_AUTHOR(Dinesh Ram dinesh@cern.ch);
+MODULE_DESCRIPTION(Si4713 FM Transmitter USB driver);
+MODULE_LICENSE(GPL v2);
+
+/* The Device announces itself as Cygnal Integrated Products, Inc. */
+#define USB_SI4713_VENDOR 0x10c4
+#define USB_SI4713_PRODUCT 0x8244
+
+#define BUFFER_LENGTH 64
+#define USB_TIMEOUT1000
+#define USB_RESP_TIMEOUT 5
+
+/* USB Device ID List */
+static struct usb_device_id usb_si4713_usb_device_table[] = {
+ {USB_DEVICE_AND_INTERFACE_INFO(USB_SI4713_VENDOR, USB_SI4713_PRODUCT,
+ USB_CLASS_HID, 0, 0) },
+ { } /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, usb_si4713_usb_device_table);
+
+struct si4713_usb_device {
+ struct usb_device *usbdev;
+ struct usb_interface*intf;
+ struct video_device vdev;
+ struct v4l2_device v4l2_dev;
+ struct v4l2_subdev *v4l2_subdev;
+ struct mutexlock;
+ struct i2c_adapter i2c_adapter;
+
+ u8 *buffer;
+};
+
+static inline struct si4713_usb_device *to_si4713_dev(struct v4l2_device
*v4l2_dev)
+{
+ return container_of(v4l2_dev, struct si4713_usb_device, v4l2_dev);
+}
+
+static int vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ struct si4713_usb_device *radio = video_drvdata(file);
+
+ strlcpy(v-driver, radio-usb-si4713, sizeof(v-driver));
+ strlcpy(v-card, Si4713 FM Transmitter, sizeof(v-card));
+ usb_make_path(radio-usbdev, v-bus_info,
Re: [PATCH v4.1 3/3] v4l: Add V4L2_BUF_FLAG_TIMESTAMP_SOF and use it
Hi Sakari, On Thursday 29 August 2013 14:33:39 Sakari Ailus wrote: On Thu, Aug 29, 2013 at 01:25:05AM +0200, Laurent Pinchart wrote: On Wednesday 28 August 2013 19:39:19 Sakari Ailus wrote: On Wed, Aug 28, 2013 at 06:14:44PM +0200, Laurent Pinchart wrote: ... UVC devices timestamp frames when the frame is captured, not when the first pixel is transmitted. I.e. we shouldn't set the SOF flag? When the frame is captured doesn't say much, or almost anything in terms of *when*. The frames have exposure time and rolling shutter makes a difference, too. The UVC 1.1 specification defines the timestamp as The source clock time in native deviceclock units when the raw frame capture begins. What devices do in practice may differ :-) I think that this should mean start-of-frame - exposure time. I'd really wonder if any practical implementation does that however. It's start-of-frame - exposure time - internal delays (UVC webcams are supposed to report their internal delay value as well). Do they report it? How about the exposure time? It's supposed to be configurable. If you know them all you can calculate the SOF timestamp. The fewer timestamps are available for user programs the better. It's another matter then if there are webcams that report these values wrong. There most probably are :-) Then you could get timestamps that are complete garbage. But I guess you could compare them to the current monotonic timestamp and detect such cases. What's your suggestion; should we use the SOF flag for this or do you prefer the end-of-frame timestamp instead? I think it'd be quite nice for drivers to know which one is which without having to guess, and based on the above start-of-frame comes as close to that definition as is meaningful. SOF is better than EOF. Do we need a start-of-capture flag, or could we document SOF as meaning start-of-capture or start-of-reception depending on what the device can do ? One possibility is to dedicate a few flags for this; by using three bits we'd get eight different timestamps already. But I have to say that fewer is better. :-) Does it really need to be a per-buffer flag ? This seems to be a driver-wide (or at least device-wide) behaviour to me. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [media] v4l2-ctrls: Remove duplicate const
Hi Sachin,
On 08/30/2013 01:11 PM, Sachin Kamat wrote:
The function returns a pointer to a const array. Duplicate use of const
led to the following warning.
drivers/media/v4l2-core/v4l2-ctrls.c:574:32: warning: duplicate const
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Thanks for the patch. I have already submitted a fix for this:
https://patchwork.linuxtv.org/patch/19902/
Regards,
Sylwester
---
drivers/media/v4l2-core/v4l2-ctrls.c |6 +++---
include/media/v4l2-common.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index c6dc1fd..653d48d 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -565,13 +565,13 @@ EXPORT_SYMBOL(v4l2_ctrl_get_menu);
* Returns NULL or an s64 type array containing the menu for given
* control ID. The total number of the menu items is returned in @len.
*/
-const s64 const *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
+const s64 *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
{
- static const s64 const qmenu_int_vpx_num_partitions[] = {
+ static const s64 qmenu_int_vpx_num_partitions[] = {
1, 2, 4, 8,
};
- static const s64 const qmenu_int_vpx_num_ref_frames[] = {
+ static const s64 qmenu_int_vpx_num_ref_frames[] = {
1, 2, 3,
};
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 16550c4..b87692c 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -86,7 +86,7 @@ int v4l2_ctrl_check(struct v4l2_ext_control *ctrl, struct
v4l2_queryctrl *qctrl,
const char * const *menu_items);
const char *v4l2_ctrl_get_name(u32 id);
const char * const *v4l2_ctrl_get_menu(u32 id);
-const s64 const *v4l2_ctrl_get_int_menu(u32 id, u32 *len);
+const s64 *v4l2_ctrl_get_int_menu(u32 id, u32 *len);
int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32 min, s32 max, s32
step, s32 def);
int v4l2_ctrl_query_menu(struct v4l2_querymenu *qmenu,
struct v4l2_queryctrl *qctrl, const char * const *menu_items);
--
Sylwester Nawrocki
Samsung RD Institute Poland
--
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
Linux Media mini-summit in Edinburgh
Hi media developers, This year, we're planning to do a media mini-summit together with the conferences that will be hosted in Edinburgh (LinuxCon EU/ELCE/KS/...), at the Oct 21-25 week. We don't have the specific days for the event yet (we're still closing it with Linux Foundation). Yet, I'd like to know who is interested on participate on the event, and ask for the theme proposals for the discussions. As we're doing over the last years, we'll be using the media-works...@linuxtv.org mailing list for such discussions. Thank you! -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [media] v4l2-ctrls: Remove duplicate const
On 30 August 2013 17:02, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Sachin, On 08/30/2013 01:11 PM, Sachin Kamat wrote: The function returns a pointer to a const array. Duplicate use of const led to the following warning. drivers/media/v4l2-core/v4l2-ctrls.c:574:32: warning: duplicate const Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Sylwester Nawrocki s.nawro...@samsung.com Thanks for the patch. I have already submitted a fix for this: https://patchwork.linuxtv.org/patch/19902/ Oops.. missed out on that. Looks like it is not yet applied to your for-3.12-3 branch? -- With warm regards, Sachin -- 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 4/6] si4713 : HID blacklist Si4713 USB development board
On Fri, 30 Aug 2013, Dinesh Ram wrote: The Si4713 development board contains a Si4713 FM transmitter chip and is handled by the radio-usb-si4713 driver. The board reports itself as (10c4:8244) Cygnal Integrated Products, Inc. and misidentifies itself as a HID device in its USB interface descriptor. This patch ignores this device as an HID device and hence loads the custom driver. Signed-off-by: Dinesh Ram din...@cisco.com Signed-off-by: Jiri Kosina jkos...@suse.cz Please feel free to take it together with my sigoff with the rest of the series. -- Jiri Kosina SUSE Labs -- 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: Linux Media mini-summit in Edinburgh
Hi Mauro, On Friday 30 August 2013 08:39:23 Mauro Carvalho Chehab wrote: Hi media developers, This year, we're planning to do a media mini-summit together with the conferences that will be hosted in Edinburgh (LinuxCon EU/ELCE/KS/...), at the Oct 21-25 week. We don't have the specific days for the event yet (we're still closing it with Linux Foundation). Yet, I'd like to know who is interested on participate on the event, and ask for the theme proposals for the discussions. I'm definitely interested. I will also participate to the Linux ARM Kernel Summit on the 22nd and 23rd, so I might not be available the whole day if we schedule the media mini-summit on one of those days. As we're doing over the last years, we'll be using the media-works...@linuxtv.org mailing list for such discussions. -- 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
[PATCH v4 0/2] media: s5p-tv: clean-up and fixes
This patch series add restoring previous vpll rate after driver offs stream or recives error. It also replace mxr_info, mxr_dbg, mxr_warn and mxr_err macro by generic solution. Mateusz Krawczuk (2): media: s5p-tv: Replace mxr_ macro by default dev_ media: s5p-tv: Restore vpll clock rate drivers/media/platform/s5p-tv/mixer.h | 12 --- drivers/media/platform/s5p-tv/mixer_drv.c | 47 ++- drivers/media/platform/s5p-tv/mixer_grp_layer.c | 2 +- drivers/media/platform/s5p-tv/mixer_reg.c | 6 +- drivers/media/platform/s5p-tv/mixer_video.c | 100 drivers/media/platform/s5p-tv/mixer_vp_layer.c | 2 +- drivers/media/platform/s5p-tv/sdo_drv.c | 25 +- 7 files changed, 101 insertions(+), 93 deletions(-) -- 1.8.1.2 -- 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 v4 2/2] media: s5p-tv: Restore vpll clock rate
Restore vpll clock rate if start stream fail or stream is off.
Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
---
drivers/media/platform/s5p-tv/sdo_drv.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c
b/drivers/media/platform/s5p-tv/sdo_drv.c
index 0afa90f..73a0ca6 100644
--- a/drivers/media/platform/s5p-tv/sdo_drv.c
+++ b/drivers/media/platform/s5p-tv/sdo_drv.c
@@ -55,6 +55,8 @@ struct sdo_device {
struct clk *dacphy;
/** clock for control of VPLL */
struct clk *fout_vpll;
+ /** vpll rate before sdo stream was on */
+ unsigned long vpll_rate;
/** regulator for SDO IP power */
struct regulator *vdac;
/** regulator for SDO plug detection */
@@ -193,17 +195,35 @@ static int sdo_s_power(struct v4l2_subdev *sd, int on)
static int sdo_streamon(struct sdo_device *sdev)
{
+ int ret;
+
/* set proper clock for Timing Generator */
- clk_set_rate(sdev-fout_vpll, 5400);
+ sdev-vpll_rate = clk_get_rate(sdev-fout_vpll);
+ ret = clk_set_rate(sdev-fout_vpll, 5400);
+ if (ret 0) {
+ dev_err(sdev-dev,
+ Failed to set vpll rate\n);
+ return ret;
+ }
dev_info(sdev-dev, fout_vpll.rate = %lu\n,
clk_get_rate(sdev-fout_vpll));
/* enable clock in SDO */
sdo_write_mask(sdev, SDO_CLKCON, ~0, SDO_TVOUT_CLOCK_ON);
- clk_enable(sdev-dacphy);
+ ret = clk_enable(sdev-dacphy);
+ if (ret 0) {
+ dev_err(sdev-dev,
+ clk_enable(dacphy) failed\n);
+ goto fail;
+ }
/* enable DAC */
sdo_write_mask(sdev, SDO_DAC, ~0, SDO_POWER_ON_DAC);
sdo_reg_debug(sdev);
return 0;
+
+fail:
+ sdo_write_mask(sdev, SDO_CLKCON, 0, SDO_TVOUT_CLOCK_ON);
+ clk_set_rate(sdev-fout_vpll, sdev-vpll_rate);
+ return ret;
}
static int sdo_streamoff(struct sdo_device *sdev)
@@ -220,6 +240,7 @@ static int sdo_streamoff(struct sdo_device *sdev)
}
if (tries == 0)
dev_err(sdev-dev, failed to stop streaming\n);
+ clk_set_rate(sdev-fout_vpll, sdev-vpll_rate);
return tries ? 0 : -EIO;
}
--
1.8.1.2
--
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 v4 1/2] media: s5p-tv: Replace mxr_ macro by default dev_
Replace mxr_dbg, mxr_info and mxr_warn by generic solution.
Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
---
drivers/media/platform/s5p-tv/mixer.h | 12 ---
drivers/media/platform/s5p-tv/mixer_drv.c | 47 ++-
drivers/media/platform/s5p-tv/mixer_grp_layer.c | 2 +-
drivers/media/platform/s5p-tv/mixer_reg.c | 6 +-
drivers/media/platform/s5p-tv/mixer_video.c | 100
drivers/media/platform/s5p-tv/mixer_vp_layer.c | 2 +-
6 files changed, 78 insertions(+), 91 deletions(-)
diff --git a/drivers/media/platform/s5p-tv/mixer.h
b/drivers/media/platform/s5p-tv/mixer.h
index 04e6490..c054106 100644
--- a/drivers/media/platform/s5p-tv/mixer.h
+++ b/drivers/media/platform/s5p-tv/mixer.h
@@ -327,18 +327,6 @@ void mxr_streamer_put(struct mxr_device *mdev);
void mxr_get_mbus_fmt(struct mxr_device *mdev,
struct v4l2_mbus_framefmt *mbus_fmt);
-/* Debug */
-
-#define mxr_err(mdev, fmt, ...) dev_err(mdev-dev, fmt, ##__VA_ARGS__)
-#define mxr_warn(mdev, fmt, ...) dev_warn(mdev-dev, fmt, ##__VA_ARGS__)
-#define mxr_info(mdev, fmt, ...) dev_info(mdev-dev, fmt, ##__VA_ARGS__)
-
-#ifdef CONFIG_VIDEO_SAMSUNG_S5P_MIXER_DEBUG
- #define mxr_dbg(mdev, fmt, ...) dev_dbg(mdev-dev, fmt, ##__VA_ARGS__)
-#else
- #define mxr_dbg(mdev, fmt, ...) do { (void) mdev; } while (0)
-#endif
-
/* accessing Mixer's and Video Processor's registers */
void mxr_vsync_set_update(struct mxr_device *mdev, int en);
diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c
b/drivers/media/platform/s5p-tv/mixer_drv.c
index 51805a5..8ce7c3e 100644
--- a/drivers/media/platform/s5p-tv/mixer_drv.c
+++ b/drivers/media/platform/s5p-tv/mixer_drv.c
@@ -59,7 +59,7 @@ void mxr_streamer_get(struct mxr_device *mdev)
{
mutex_lock(mdev-mutex);
++mdev-n_streamer;
- mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_streamer);
+ dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_streamer);
if (mdev-n_streamer == 1) {
struct v4l2_subdev *sd = to_outsd(mdev);
struct v4l2_mbus_framefmt mbus_fmt;
@@ -91,7 +91,7 @@ void mxr_streamer_put(struct mxr_device *mdev)
{
mutex_lock(mdev-mutex);
--mdev-n_streamer;
- mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_streamer);
+ dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_streamer);
if (mdev-n_streamer == 0) {
int ret;
struct v4l2_subdev *sd = to_outsd(mdev);
@@ -113,7 +113,7 @@ void mxr_output_get(struct mxr_device *mdev)
{
mutex_lock(mdev-mutex);
++mdev-n_output;
- mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_output);
+ dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_output);
/* turn on auxiliary driver */
if (mdev-n_output == 1)
v4l2_subdev_call(to_outsd(mdev), core, s_power, 1);
@@ -124,7 +124,7 @@ void mxr_output_put(struct mxr_device *mdev)
{
mutex_lock(mdev-mutex);
--mdev-n_output;
- mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_output);
+ dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_output);
/* turn on auxiliary driver */
if (mdev-n_output == 0)
v4l2_subdev_call(to_outsd(mdev), core, s_power, 0);
@@ -159,42 +159,42 @@ static int mxr_acquire_plat_resources(struct mxr_device
*mdev,
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mxr);
if (res == NULL) {
- mxr_err(mdev, get memory resource failed.\n);
+ dev_err(mdev-dev, get memory resource failed.\n);
ret = -ENXIO;
goto fail;
}
mdev-res.mxr_regs = ioremap(res-start, resource_size(res));
if (mdev-res.mxr_regs == NULL) {
- mxr_err(mdev, register mapping failed.\n);
+ dev_err(mdev-dev, register mapping failed.\n);
ret = -ENXIO;
goto fail;
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vp);
if (res == NULL) {
- mxr_err(mdev, get memory resource failed.\n);
+ dev_err(mdev-dev, get memory resource failed.\n);
ret = -ENXIO;
goto fail_mxr_regs;
}
mdev-res.vp_regs = ioremap(res-start, resource_size(res));
if (mdev-res.vp_regs == NULL) {
- mxr_err(mdev, register mapping failed.\n);
+ dev_err(mdev-dev, register mapping failed.\n);
ret = -ENXIO;
goto fail_mxr_regs;
}
res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, irq);
if (res == NULL) {
- mxr_err(mdev, get interrupt resource failed.\n);
+ dev_err(mdev-dev, get interrupt resource failed.\n);
ret = -ENXIO;
goto fail_vp_regs;
}
ret = request_irq(res-start, mxr_irq_handler, 0, s5p-mixer, mdev);
if (ret) {
- mxr_err(mdev, request
Re: Linux Media mini-summit in Edinburgh
On Fri 30 August 2013 13:39:23 Mauro Carvalho Chehab wrote: Hi media developers, This year, we're planning to do a media mini-summit together with the conferences that will be hosted in Edinburgh (LinuxCon EU/ELCE/KS/...), at the Oct 21-25 week. We don't have the specific days for the event yet (we're still closing it with Linux Foundation). Yet, I'd like to know who is interested on participate on the event, and ask for the theme proposals for the discussions. As we're doing over the last years, we'll be using the media-works...@linuxtv.org mailing list for such discussions. I'll be there. 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: [PATCH 6/6] si4713 : Added MAINTAINERS entry for radio-usb-si4713 driver
On Fri 30 August 2013 13:28:24 Dinesh Ram wrote: Hans Verkuil hverk...@xs4all.nl will maintain the USB driver for si4713 Signed-off-by: Dinesh Ram din...@cisco.com --- MAINTAINERS | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2618ce..ddd4d5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,7 +7412,7 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/si4713-i2c.? +F: drivers/media/radio/si4713/si4713.? SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER M: Eduardo Valentin edubez...@gmail.com @@ -7420,7 +7420,15 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/radio-si4713.h +F: drivers/media/radio/si4713/radio-platform-si4713.c + +KEENE FM RADIO TRANSMITTER DRIVER You forgot to update the driver description! This is the SiLabs si4713 EVB driver, not Keene. Can you make a v2 of this patch fixing this? Regards, Hans +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/si4713/radio-usb-si4713.c SIANO DVB DRIVER M: Mauro Carvalho Chehab m.che...@samsung.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
Re: [PATCH 1/1] [media] v4l2-ctrls: Remove duplicate const
On 08/30/2013 01:42 PM, Sachin Kamat wrote: On 30 August 2013 17:02, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Sachin, On 08/30/2013 01:11 PM, Sachin Kamat wrote: The function returns a pointer to a const array. Duplicate use of const led to the following warning. drivers/media/v4l2-core/v4l2-ctrls.c:574:32: warning: duplicate const Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Sylwester Nawrocki s.nawro...@samsung.com Thanks for the patch. I have already submitted a fix for this: https://patchwork.linuxtv.org/patch/19902/ Oops.. missed out on that. Looks like it is not yet applied to your for-3.12-3 branch? Yup, I didn't apply it since it touches the control framework. Thus I assumed Hans will want to pick it up to his tree. 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/6] si4713 : USB driver
On Fri 30 August 2013 13:28:18 Dinesh Ram wrote: This is a follow-up to the patch-series mailed on 21-Agu-2013 to the mailing list. Please note that I will not be reachable at the cisco email id anymore. So please send you comments and suggestions to my private email : dinesh@cern.ch For patches 1-5: Acked-by: Hans Verkuil hans.verk...@cisco.com Patch 6 has an issue, so I'll wait for the corrected version before Acking it. Regards, Hans All the patches are on top of the latest version of the media-git tree as on 30-August-2013 (10:30 Europe time) The main difference to the aforementioned patch series is that, in this series the radio-i2c-si4713.c is renamed to a more appropriate one - radio-platform-si4713.c. Ofcourse, this also involvs corrosponding changes in the Makefile and Kconfig in drivers/media/radio/si4713. An entry is also added to the MAINTAINERS file. This patch series adds USB support for the SiLabs development board which contains the Si4713 FM transmitter chip. This device can transmit audio through FM. It can transmit RDS and RBDS signals as well. Documentation for this product can be accessed here : http://www.silabs.com/products/audiovideo/fmtransmitters/Pages/si471213.aspx In the source tree, drivers/media/radio has been reorganized to include a new folder drivers/media/radio/si4713 which contains all the si4713 related files. Modified and renamed files : --- drivers/media/radio/si4713-i2c.c == drivers/media/radio/si4713/si4713.c drivers/media/radio/si4713-i2c.h == drivers/media/radio/si4713/si4713.h drivers/media/radio/radio-si4713.c == drivers/media/radio/si4713/radio-platform-si4713.c New files : - drivers/media/radio/si4713/radio-usb-si4713.c The existing i2c driver has been modified to add support for cases where the interrupt is not enabled. Checks have been introduced in several places in the code to test if an interrupt is set or not. The development board is plugged into the host through USB and does not use interrupts. To get a valid response, within a specified timeout, the device is polled instead. The USB driver has been developed by analyzing the the USB traffic obtained by sniffing the USB bus. A bunch of commands are sent during device startup, the specifics of which are not obvious. Nevertheless they seem to be necessary for the proper fuctioning of the device. Note : The i2c driver assumes a 2-wire bus mode. -- 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: Linux Media mini-summit in Edinburgh
Hi, On 08/30/2013 01:39 PM, Mauro Carvalho Chehab wrote: Hi media developers, This year, we're planning to do a media mini-summit together with the conferences that will be hosted in Edinburgh (LinuxCon EU/ELCE/KS/...), at the Oct 21-25 week. We don't have the specific days for the event yet (we're still closing it with Linux Foundation). Yet, I'd like to know who is interested on participate on the event, and ask for the theme proposals for the discussions. As we're doing over the last years, we'll be using the media-works...@linuxtv.org mailing list for such discussions. I will be in Edinburgh the entire week because of kvm-forum. So I'll try to join the mini-summit. I don't have anything specific to discuss. 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: [PATCH v2 6/6] si4713 : Added MAINTAINERS entry for radio-usb-si4713 driver
Hans Verkuil hverk...@xs4all.nl will maintain the USB driver for si4713 Signed-off-by: Dinesh Ram din...@cisco.com --- MAINTAINERS | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2618ce..ddd4d5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,7 +7412,7 @@ L:linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/si4713-i2c.? +F: drivers/media/radio/si4713/si4713.? SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER M: Eduardo Valentin edubez...@gmail.com @@ -7420,7 +7420,15 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/radio-si4713.h +F: drivers/media/radio/si4713/radio-platform-si4713.c + +SI4713 FM RADIO TRANSMITTER USB DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/si4713/radio-usb-si4713.c SIANO DVB DRIVER M: Mauro Carvalho Chehab m.che...@samsung.com -- 1.8.4.rc2 From: Hans Verkuil [hverk...@xs4all.nl] Sent: 30 August 2013 14:07 To: Dinesh Ram Cc: linux-media@vger.kernel.org; Dinesh Ram Subject: Re: [PATCH 6/6] si4713 : Added MAINTAINERS entry for radio-usb-si4713 driver On Fri 30 August 2013 13:28:24 Dinesh Ram wrote: Hans Verkuil hverk...@xs4all.nl will maintain the USB driver for si4713 Signed-off-by: Dinesh Ram din...@cisco.com --- MAINTAINERS | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2618ce..ddd4d5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,7 +7412,7 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/si4713-i2c.? +F: drivers/media/radio/si4713/si4713.? SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER M: Eduardo Valentin edubez...@gmail.com @@ -7420,7 +7420,15 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/radio-si4713.h +F: drivers/media/radio/si4713/radio-platform-si4713.c + +KEENE FM RADIO TRANSMITTER DRIVER You forgot to update the driver description! This is the SiLabs si4713 EVB driver, not Keene. Can you make a v2 of this patch fixing this? Regards, Hans +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/si4713/radio-usb-si4713.c SIANO DVB DRIVER M: Mauro Carvalho Chehab m.che...@samsung.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
Re: [PATCH v2 6/6] si4713 : Added MAINTAINERS entry for radio-usb-si4713 driver
On Fri 30 August 2013 14:14:09 Dinesh Ram wrote: Hans Verkuil hverk...@xs4all.nl will maintain the USB driver for si4713 Signed-off-by: Dinesh Ram din...@cisco.com Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans --- MAINTAINERS | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2618ce..ddd4d5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,7 +7412,7 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/si4713-i2c.? +F: drivers/media/radio/si4713/si4713.? SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER M: Eduardo Valentin edubez...@gmail.com @@ -7420,7 +7420,15 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/radio-si4713.h +F: drivers/media/radio/si4713/radio-platform-si4713.c + +SI4713 FM RADIO TRANSMITTER USB DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/si4713/radio-usb-si4713.c SIANO DVB DRIVER M: Mauro Carvalho Chehab m.che...@samsung.com -- 1.8.4.rc2 From: Hans Verkuil [hverk...@xs4all.nl] Sent: 30 August 2013 14:07 To: Dinesh Ram Cc: linux-media@vger.kernel.org; Dinesh Ram Subject: Re: [PATCH 6/6] si4713 : Added MAINTAINERS entry for radio-usb-si4713 driver On Fri 30 August 2013 13:28:24 Dinesh Ram wrote: Hans Verkuil hverk...@xs4all.nl will maintain the USB driver for si4713 Signed-off-by: Dinesh Ram din...@cisco.com --- MAINTAINERS | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2618ce..ddd4d5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,7 +7412,7 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/si4713-i2c.? +F: drivers/media/radio/si4713/si4713.? SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER M: Eduardo Valentin edubez...@gmail.com @@ -7420,7 +7420,15 @@ L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git W: http://linuxtv.org S: Odd Fixes -F: drivers/media/radio/radio-si4713.h +F: drivers/media/radio/si4713/radio-platform-si4713.c + +KEENE FM RADIO TRANSMITTER DRIVER You forgot to update the driver description! This is the SiLabs si4713 EVB driver, not Keene. Can you make a v2 of this patch fixing this? Regards, Hans +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/si4713/radio-usb-si4713.c SIANO DVB DRIVER M: Mauro Carvalho Chehab m.che...@samsung.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 -- 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 1/4] adv7842: fix compilation with GCC 4.4.6
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
drivers/media/i2c/adv7842.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index d174890..22f729d 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -546,30 +546,24 @@ static inline bool is_digital_input(struct v4l2_subdev
*sd)
static const struct v4l2_dv_timings_cap adv7842_timings_cap_analog = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1200,
- .min_pixelclock = 2500,
- .max_pixelclock = 17000,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ /* keep this initialization for compatibility with GCC 4.4.6 */
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1200, 2500, 17000,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static const struct v4l2_dv_timings_cap adv7842_timings_cap_digital = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1200,
- .min_pixelclock = 2500,
- .max_pixelclock = 22500,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ /* keep this initialization for compatibility with GCC 4.4.6 */
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1200, 2500, 22500,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static inline const struct v4l2_dv_timings_cap *
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ad9389b: fix compilation with GCC 4.4.6
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
drivers/media/i2c/ad9389b.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index bb0c99d..b06a7e5 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -628,16 +628,13 @@ static int ad9389b_s_stream(struct v4l2_subdev *sd, int
enable)
static const struct v4l2_dv_timings_cap ad9389b_timings_cap = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1200,
- .min_pixelclock = 2500,
- .max_pixelclock = 17000,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ /* keep this initialization for compatibility with GCC 4.4.6 */
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1200, 2500, 17000,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static int ad9389b_s_dv_timings(struct v4l2_subdev *sd,
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] adv7511: fix compilation with GCC 4.4.6
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
drivers/media/i2c/adv7511.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 7a57609..cc3880a 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -119,16 +119,14 @@ static int adv7511_s_clock_freq(struct v4l2_subdev *sd,
u32 freq);
static const struct v4l2_dv_timings_cap adv7511_timings_cap = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = ADV7511_MAX_WIDTH,
- .max_height = ADV7511_MAX_HEIGHT,
- .min_pixelclock = ADV7511_MIN_PIXELCLOCK,
- .max_pixelclock = ADV7511_MAX_PIXELCLOCK,
- .standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ /* keep this initialization for compatibility with GCC 4.4.6 */
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, ADV7511_MAX_WIDTH, 0, ADV7511_MAX_HEIGHT,
+ ADV7511_MIN_PIXELCLOCK, ADV7511_MAX_PIXELCLOCK,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE |
- V4L2_DV_BT_CAP_REDUCED_BLANKING | V4L2_DV_BT_CAP_CUSTOM,
- },
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_REDUCED_BLANKING |
+ V4L2_DV_BT_CAP_CUSTOM)
};
static inline struct adv7511_state *get_adv7511_state(struct v4l2_subdev *sd)
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] fix compilation issues with GCC 4.4.6
With GCC 4.4.3 (Ubuntu 10.04) the compilation of the new adv7842 driver fails with this error: CC [M] adv7842.o adv7842.c:549: error: unknown field 'bt' specified in initializer adv7842.c:550: error: field name not in record or union initializer adv7842.c:550: error: (near initialization for 'adv7842_timings_cap_analog.reserved') adv7842.c:551: error: field name not in record or union initializer adv7842.c:551: error: (near initialization for 'adv7842_timings_cap_analog.reserved') adv7842.c:552: error: field name not in record or union initializer adv7842.c:552: error: (near initialization for 'adv7842_timings_cap_analog.reserved') adv7842.c:553: error: field name not in record or union initializer adv7842.c:553: error: (near initialization for 'adv7842_timings_cap_analog.reserved') adv7842.c:553: warning: excess elements in array initializer ... This is caused by the old GCC version (as explained in file v4l2-dv-timings.h). The proposed fix uses the V4L2_INIT_BT_TIMINGS macro defined there. Please note that we need to init the reserved space as well, as otherwise GCC will fail with another error: CC [M] adv7842.o adv7842.c:549: error: field name not in record or union initializer adv7842.c:549: error: (near initialization for 'adv7842_timings_cap_analog.reserved') adv7842.c:549: warning: braces around scalar initializer adv7842.c:549: warning: (near initialization for 'adv7842_timings_cap_analog.reserved[0]') ... A proper comment was added as a remainder. The same issue applies to other drivers too: ths8200, adv7511, ad9389b. The present patch series fixes all of them. Best regards, Gianluca Gianluca Gennari (4): adv7842: fix compilation with GCC 4.4.6 adv7511: fix compilation with GCC 4.4.6 ad9389b: fix compilation with GCC 4.4.6 ths8200: fix compilation with GCC 4.4.6 drivers/media/i2c/ad9389b.c | 15 ++- drivers/media/i2c/adv7511.c | 16 +++- drivers/media/i2c/adv7842.c | 30 -- drivers/media/i2c/ths8200.c | 12 4 files changed, 29 insertions(+), 44 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ths8200: fix compilation with GCC 4.4.6
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
drivers/media/i2c/ths8200.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index a58a8f6..d9f65d7 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -46,14 +46,10 @@ struct ths8200_state {
static const struct v4l2_dv_timings_cap ths8200_timings_cap = {
.type = V4L2_DV_BT_656_1120,
- .bt = {
- .max_width = 1920,
- .max_height = 1080,
- .min_pixelclock = 2500,
- .max_pixelclock = 14850,
- .standards = V4L2_DV_BT_STD_CEA861,
- .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE,
- },
+ /* keep this initialization for compatibility with GCC 4.4.6 */
+ .reserved = { 0 },
+ V4L2_INIT_BT_TIMINGS(0, 1920, 0, 1080, 2500, 14850,
+ V4L2_DV_BT_STD_CEA861, V4L2_DV_BT_CAP_PROGRESSIVE)
};
static inline struct ths8200_state *to_state(struct v4l2_subdev *sd)
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Agenda for the Edinburgh mini-summit
OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. Note: my email availability will be limited in the next three weeks, especially next week, as I am travelling a lot. 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: Agenda for the Edinburgh mini-summit
On 30-08-13 15:01, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. What about a hardware accelerated decoding API/framework? Is there a proper framework for this at all? I see the broadcom module is still in staging and may never come out of it, but how are other video decoding engines handled that don't have cameras or displays. Reason for asking is that we from linux-sunxi have made some positive progress in Reverse engineering the video decoder blob of the Allwinner A10 and this knowledge will need a kernel side driver in some framework. I looked at the exynos video decoders and googling for linux-media hardware accelerated decoding doesn't yield much either. Anyway, just a thought; if you think it's the wrong place for it to be discussed, that's ok :) oliver Note: my email availability will be limited in the next three weeks, especially next week, as I am travelling a lot. 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 -- 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: Agenda for the Edinburgh mini-summit
Em Fri, 30 Aug 2013 15:21:05 +0200 Oliver Schinagl oliver+l...@schinagl.nl escreveu: On 30-08-13 15:01, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. From my side, I'd like to discuss about a better integration between DVB and V4L2, including starting using the media controller API on DVB side too. Btw, it would be great if we could get a status about the media controller API usage on ALSA. I'm planning to work at such integration soon. What about a hardware accelerated decoding API/framework? Is there a proper framework for this at all? I see the broadcom module is still in staging and may never come out of it, but how are other video decoding engines handled that don't have cameras or displays. Reason for asking is that we from linux-sunxi have made some positive progress in Reverse engineering the video decoder blob of the Allwinner A10 and this knowledge will need a kernel side driver in some framework. I looked at the exynos video decoders and googling for linux-media hardware accelerated decoding doesn't yield much either. Anyway, just a thought; if you think it's the wrong place for it to be discussed, that's ok :) Well, the mem2mem V4L2 devices should provide all that would be needed for accelerated encoders/decoders. If not, then feel free to propose extensions to fit your needs. Regards, Mauro oliver Note: my email availability will be limited in the next three weeks, especially next week, as I am travelling a lot. 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 -- 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 -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx + ov2640 and v4l2-clk
Hi Guennadi, Am 30.08.2013 12:30, schrieb Guennadi Liakhovetski: Hi Frank, On Fri, 23 Aug 2013, Frank Schäfer wrote: Hi Sylwester, Am 21.08.2013 23:42, schrieb Sylwester Nawrocki: Hi Frank, On 08/21/2013 10:39 PM, Frank Schäfer wrote: Am 20.08.2013 18:34, schrieb Frank Schäfer: Am 20.08.2013 15:38, schrieb Laurent Pinchart: Hi Mauro, On Sunday 18 August 2013 12:20:08 Mauro Carvalho Chehab wrote: Em Sun, 18 Aug 2013 13:40:25 +0200 Frank Schäfer escreveu: Am 17.08.2013 12:51, schrieb Guennadi Liakhovetski: Hi Frank, As I mentioned on the list, I'm currently on a holiday, so, replying briefly. Sorry, I missed that (can't read all mails on the list). Since em28xx is a USB device, I conclude, that it's supplying clock to its components including the ov2640 sensor. So, yes, I think the driver should export a V4L2 clock. Could you please test this patch series http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/68510 to see whether it fixes this your problem? Thanks for the patches. Unfortunately, I'm traveling this week and can't test them before Monday, sorry. :( But I've put I on my ToDo list. Please be patient. Regards, Frank Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Agenda for the Edinburgh mini-summit
On 08/30/2013 03:21 PM, Oliver Schinagl wrote: On 30-08-13 15:01, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. What about a hardware accelerated decoding API/framework? Is there a proper framework for this at all? I see the broadcom module is still in staging and may never come out of it, but how are other video decoding engines handled that don't have cameras or displays. Reason for asking is that we from linux-sunxi have made some positive progress in Reverse engineering the video decoder blob of the Allwinner A10 and this knowledge will need a kernel side driver in some framework. I looked at the exynos video decoders and googling for linux-media hardware accelerated decoding doesn't yield much either. Anyway, just a thought; if you think it's the wrong place for it to be discussed, that's ok :) No, this is the right place. See http://hverkuil.home.xs4all.nl/spec/media.html#codec for more information. For the longest time that section in the spec said that that interface was 'Suspended'. That was only corrected in 3.10 or 3.11 even though actual codec support has been around for much longer. There are many v4l2 drivers today that do this. Just grep for V4L2_CAP_VIDEO_M2M in drivers/media. Codec drivers are really just a video node that can capture and output at the same time, and has a lot of codec controls (http://hverkuil.home.xs4all.nl/spec/media.html#mpeg-controls) to tweak codec parameters. Just post any questions you have regarding this to the linux-media mailinglist, we're happy to help out. Regards, Hans oliver Note: my email availability will be limited in the next three weeks, especially next week, as I am travelling a lot. 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 -- 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: Linux Media mini-summit in Edinburgh
Hi Mauro On Fri, 30 Aug 2013, Mauro Carvalho Chehab wrote: Hi media developers, This year, we're planning to do a media mini-summit together with the conferences that will be hosted in Edinburgh (LinuxCon EU/ELCE/KS/...), at the Oct 21-25 week. We don't have the specific days for the event yet (we're still closing it with Linux Foundation). Yet, I'd like to know who is interested on participate on the event, and ask for the theme proposals for the discussions. As we're doing over the last years, we'll be using the media-works...@linuxtv.org mailing list for such discussions. I'll be there for the ELCE / KS time-frame, i.e. 24, 25.10. IIUC, the mini-summit should be on one of those days, but if it falls e.g. on 23rd, I could try to adjust my itinerary. Thanks Guennadi Thank you! -- Cheers, Mauro --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Media mini-summit in Edinburgh on Oct 23
Em Fri, 30 Aug 2013 16:32:14 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro On Fri, 30 Aug 2013, Mauro Carvalho Chehab wrote: Hi media developers, This year, we're planning to do a media mini-summit together with the conferences that will be hosted in Edinburgh (LinuxCon EU/ELCE/KS/...), at the Oct 21-25 week. We don't have the specific days for the event yet (we're still closing it with Linux Foundation). Yet, I'd like to know who is interested on participate on the event, and ask for the theme proposals for the discussions. As we're doing over the last years, we'll be using the media-works...@linuxtv.org mailing list for such discussions. I'll be there for the ELCE / KS time-frame, i.e. 24, 25.10. IIUC, the mini-summit should be on one of those days, but if it falls e.g. on 23rd, I could try to adjust my itinerary. Just got a confirmation: It will be on Oct 23 (I updated the subject on this thread). Regards, Mauro Thanks Guennadi Thank you! -- Cheers, Mauro --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] Agenda for the Edinburgh mini-summit
Hi Mauro, On Friday 30 August 2013 10:31:23 Mauro Carvalho Chehab wrote: Em Fri, 30 Aug 2013 15:21:05 +0200 Oliver Schinagl escreveu: On 30-08-13 15:01, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input- infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. From my side, I'd like to discuss about a better integration between DVB and V4L2, including starting using the media controller API on DVB side too. Btw, it would be great if we could get a status about the media controller API usage on ALSA. I'm planning to work at such integration soon. What about a hardware accelerated decoding API/framework? Is there a proper framework for this at all? I see the broadcom module is still in staging and may never come out of it, but how are other video decoding engines handled that don't have cameras or displays. Reason for asking is that we from linux-sunxi have made some positive progress in Reverse engineering the video decoder blob of the Allwinner A10 and this knowledge will need a kernel side driver in some framework. I looked at the exynos video decoders and googling for linux-media hardware accelerated decoding doesn't yield much either. Anyway, just a thought; if you think it's the wrong place for it to be discussed, that's ok :) Well, the mem2mem V4L2 devices should provide all that would be needed for accelerated encoders/decoders. If not, then feel free to propose extensions to fit your needs. Two comments regarding this: - V4L2 mem-to-mem is great for frame-based codecs, but SoCs sometimes only implement part of the codec in hardware, leaving the rest to the software. Encoded bistream parsing is one of those areas that are left to the CPU, for instance on some ST SoCs (CC'ing Benjamin Gaignard). - http://www.linuxplumbersconf.org/2013/ocw/sessions/1605 -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [media] uvcvideo: quirk PROBE_DEF for Dell SP2008WFP monitor.
Hi Greg, On Friday 30 August 2013 09:39:58 Greg KH wrote: On Fri, Aug 30, 2013 at 12:28:16PM +0200, Laurent Pinchart wrote: On Thursday 29 August 2013 21:00:21 Greg KH wrote: On Fri, Aug 30, 2013 at 02:41:17AM +0200, Laurent Pinchart wrote: On Thursday 29 August 2013 11:17:41 Joseph Salisbury wrote: BugLink: http://bugs.launchpad.net/bugs/1217957 Add quirk for Dell SP2008WFP monitor: 05a9:2641 Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com Tested-by: Christopher Townsend christopher.towns...@canonical.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: sta...@vger.kernel.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've applied it to my tree. Given that we're too close to the v3.12 merge window I will push it for v3.13. A quirk has to wait that long? That's not ok, they should go in much sooner than that... Can such a patch get merged during the -rc phase ? If so I will push it to v3.12. Yes it can, OK, I'll send a pull request to Mauro right after the v3.12 merge window closes, as he's pretty busy with pending pull requests for v3.12 at the moment. and it should also be merged to stable releases, as the cc: stable shows. Sure, that was my plan. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4.1 3/3] v4l: Add V4L2_BUF_FLAG_TIMESTAMP_SOF and use it
Hi Laurent, On Fri, Aug 30, 2013 at 01:31:44PM +0200, Laurent Pinchart wrote: Hi Sakari, On Thursday 29 August 2013 14:33:39 Sakari Ailus wrote: On Thu, Aug 29, 2013 at 01:25:05AM +0200, Laurent Pinchart wrote: On Wednesday 28 August 2013 19:39:19 Sakari Ailus wrote: On Wed, Aug 28, 2013 at 06:14:44PM +0200, Laurent Pinchart wrote: ... UVC devices timestamp frames when the frame is captured, not when the first pixel is transmitted. I.e. we shouldn't set the SOF flag? When the frame is captured doesn't say much, or almost anything in terms of *when*. The frames have exposure time and rolling shutter makes a difference, too. The UVC 1.1 specification defines the timestamp as The source clock time in native deviceclock units when the raw frame capture begins. What devices do in practice may differ :-) I think that this should mean start-of-frame - exposure time. I'd really wonder if any practical implementation does that however. It's start-of-frame - exposure time - internal delays (UVC webcams are supposed to report their internal delay value as well). Do they report it? How about the exposure time? It's supposed to be configurable. Is the exposure reported with the frame so it could be used to construct the per-frame SOF timestamp? If you know them all you can calculate the SOF timestamp. The fewer timestamps are available for user programs the better. It's another matter then if there are webcams that report these values wrong. There most probably are :-) Then you could get timestamps that are complete garbage. But I guess you could compare them to the current monotonic timestamp and detect such cases. What's your suggestion; should we use the SOF flag for this or do you prefer the end-of-frame timestamp instead? I think it'd be quite nice for drivers to know which one is which without having to guess, and based on the above start-of-frame comes as close to that definition as is meaningful. SOF is better than EOF. Do we need a start-of-capture flag, or could we document SOF as meaning start-of-capture or start-of-reception depending on what the device can do ? One possibility is to dedicate a few flags for this; by using three bits we'd get eight different timestamps already. But I have to say that fewer is better. :-) Does it really need to be a per-buffer flag ? This seems to be a driver-wide (or at least device-wide) behaviour to me. Same goes for timestamp clock sources. It was concluded to use buffer flags for those as well. Using a control for the purpose would however require quite non-zero amount of initialisation code from each driver so that would probably need to be sorted out first. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
davinci vpif_capture
I am working on an application involving the davinci using the vpif. My
board file has the inputs configured to use VPIF_IF_RAW_BAYER if_type.
When my application starts up, I have it enumerate the formats
(VIDIOC_ENUM_FMT) and it indicates that the only available format is
YCbCr4:2:2 YC Planar (from vpif_enum_fmt_vid_cap). It looks to me
that the culprit is vpif_open().
struct channel_obj.vpifparams.iface is initialized at vpif_probe() time
in the function vpif_set_input. Open the device file (/dev/video0)
overwrites this. I suspect that it is __not__ supposed to do this,
since I don't see any method for restoring the iface.
I'm using linux-3.10.4, but the problem appears in 3.10.9, 3.11.rc7 and
a version I checked out at
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git.
I have supplied a patch for 3.10.9.
diff -pubwr
linux-3.10.9-pristine/drivers/media/platform/davinci/vpif_capture.c
linux-3.10.9/drivers/media/platform/davinci/vpif_capture.c
--- linux-3.10.9-pristine/drivers/media/platform/davinci/vpif_capture.c
2013-08-20 17:40:47.0 -0500
+++ linux-3.10.9/drivers/media/platform/davinci/vpif_capture.c
2013-08-30 11:18:29.0 -0500
@@ -914,9 +914,11 @@ static int vpif_open(struct file *filep)
fh-initialized = 0;
/* If decoder is not initialized. initialize it */
if (!ch-initialized) {
+struct vpif_interface iface = ch-vpifparams.iface;
fh-initialized = 1;
ch-initialized = 1;
memset((ch-vpifparams), 0, sizeof(struct vpif_params));
+ch-vpifparams.iface = iface;
}
/* Increment channel usrs counter */
ch-usrs++;
--
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] [media] uvcvideo: quirk PROBE_DEF for Dell SP2008WFP monitor.
On Fri, Aug 30, 2013 at 12:28:16PM +0200, Laurent Pinchart wrote: Hi Greg, On Thursday 29 August 2013 21:00:21 Greg KH wrote: On Fri, Aug 30, 2013 at 02:41:17AM +0200, Laurent Pinchart wrote: On Thursday 29 August 2013 11:17:41 Joseph Salisbury wrote: BugLink: http://bugs.launchpad.net/bugs/1217957 Add quirk for Dell SP2008WFP monitor: 05a9:2641 Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com Tested-by: Christopher Townsend christopher.towns...@canonical.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: sta...@vger.kernel.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've applied it to my tree. Given that we're too close to the v3.12 merge window I will push it for v3.13. A quirk has to wait that long? That's not ok, they should go in much sooner than that... Can such a patch get merged during the -rc phase ? If so I will push it to v3.12. Yes it can, and it should also be merged to stable releases, as the cc: stable shows. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx lock debug *** DEADLOCK ***
Mauro,
I was thinking you already fixed that one, but I just meet it with
latest media tree 3.11.0-rc2+ when I unplugged device ?
regards
Antti
[ 1464.238906] usb 2-2: USB disconnect, device number 2
[ 1464.242123] em28178 #0: disconnecting em28178 #0 video
[ 1464.242254]
[ 1464.242261] ==
[ 1464.242265] [ INFO: possible circular locking dependency detected ]
[ 1464.242272] 3.11.0-rc2+ #61 Tainted: G C O
[ 1464.242277] ---
[ 1464.242283] khubd/46 is trying to acquire lock:
[ 1464.242288] (em28xx_devlist_mutex){+.+.+.}, at: [a04b1c8d]
em28xx_close_extension+0x1d/0x70 [em28xx]
[ 1464.242316]
[ 1464.242316] but task is already holding lock:
[ 1464.242322] (dev-lock){+.+.+.}, at: [a04af7a9]
em28xx_usb_disconnect+0x99/0x140 [em28xx]
[ 1464.242342]
[ 1464.242342] which lock already depends on the new lock.
[ 1464.242342]
[ 1464.242349]
[ 1464.242349] the existing dependency chain (in reverse order) is:
[ 1464.242354]
[ 1464.242354] - #1 (dev-lock){+.+.+.}:
[ 1464.242365][810c27be] lock_acquire+0x8e/0x130
[ 1464.242376][8168dc25] mutex_lock_nested+0x85/0x390
[ 1464.242386][a050c659] em28xx_dvb_init+0x79/0x1c60
[em28xx_dvb]
[ 1464.242396][a04afa68]
em28xx_register_extension+0x58/0xa0 [em28xx]
[ 1464.242410][a0514010] 0xa0514010
[ 1464.242429][810002fa] do_one_initcall+0xfa/0x1b0
[ 1464.242439][810d1166] load_module+0x1de6/0x2760
[ 1464.242447][810d1bb7] SyS_init_module+0xd7/0x120
[ 1464.242455][8169c5d4] tracesys+0xdd/0xe2
[ 1464.242465]
[ 1464.242465] - #0 (em28xx_devlist_mutex){+.+.+.}:
[ 1464.242475][810c2060] __lock_acquire+0x1db0/0x1ea0
[ 1464.242483][810c27be] lock_acquire+0x8e/0x130
[ 1464.242490][8168dc25] mutex_lock_nested+0x85/0x390
[ 1464.242498][a04b1c8d]
em28xx_close_extension+0x1d/0x70 [em28xx]
[ 1464.242513][a04af7c3]
em28xx_usb_disconnect+0xb3/0x140 [em28xx]
[ 1464.242525][814939e3] usb_unbind_interface+0x63/0x1b0
[ 1464.242536][814035af] __device_release_driver+0x7f/0xf0
[ 1464.242545][8140390e] device_release_driver+0x2e/0x40
[ 1464.242554][81403040] bus_remove_device+0x110/0x190
[ 1464.242563][813ffefd] device_del+0x13d/0x1d0
[ 1464.242570][814912e0] usb_disable_device+0xb0/0x270
[ 1464.242579][81487655] usb_disconnect+0xb5/0x1d0
[ 1464.242589][81488e69]
hub_port_connect_change+0xc9/0xad0
[ 1464.242598][81489b68] hub_events+0x2f8/0x940
[ 1464.242607][8148a1e5] hub_thread+0x35/0x190
[ 1464.242616][8107f99d] kthread+0xed/0x100
[ 1464.242625][8169c31c] ret_from_fork+0x7c/0xb0
[ 1464.242635]
[ 1464.242635] other info that might help us debug this:
[ 1464.242635]
[ 1464.242642] Possible unsafe locking scenario:
[ 1464.242642]
[ 1464.242647]CPU0CPU1
[ 1464.242651]
[ 1464.242655] lock(dev-lock);
[ 1464.242663]lock(em28xx_devlist_mutex);
[ 1464.242669]lock(dev-lock);
[ 1464.242676] lock(em28xx_devlist_mutex);
[ 1464.242683]
[ 1464.242683] *** DEADLOCK ***
[ 1464.242683]
[ 1464.242691] 4 locks held by khubd/46:
[ 1464.242695] #0: (__lockdep_no_validate__){..}, at:
[81489924] hub_events+0xb4/0x940
[ 1464.242713] #1: (__lockdep_no_validate__){..}, at:
[81487606] usb_disconnect+0x66/0x1d0
[ 1464.242730] #2: (__lockdep_no_validate__){..}, at:
[81403906] device_release_driver+0x26/0x40
[ 1464.242746] #3: (dev-lock){+.+.+.}, at: [a04af7a9]
em28xx_usb_disconnect+0x99/0x140 [em28xx]
[ 1464.242767]
[ 1464.242767] stack backtrace:
[ 1464.242777] CPU: 3 PID: 46 Comm: khubd Tainted: G C O
3.11.0-rc2+ #61
[ 1464.242783] Hardware name: System manufacturer System Product
Name/M5A78L-M/USB3, BIOS 150311/14/2012
[ 1464.242788] 8227a650 88030dbf7858 8168a207
0007
[ 1464.242800] 8227a650 88030dbf78a8 81684141
88030dbd2bc8
[ 1464.242811] 88030dbf7938 88030dbf78a8 88030dbd2b90
0af05782bc9fa503
[ 1464.242823] Call Trace:
[ 1464.242836] [8168a207] dump_stack+0x55/0x76
[ 1464.242846] [81684141] print_circular_bug+0x1fb/0x20c
[ 1464.242857] [810c2060] __lock_acquire+0x1db0/0x1ea0
[ 1464.242866] [810c06e0] ? __lock_acquire+0x430/0x1ea0
[ 1464.242878] [81693500] ? _raw_spin_unlock_irq+0x30/0x50
[ 1464.242887] [810c27be] lock_acquire+0x8e/0x130
[ 1464.242902] [a04b1c8d] ? em28xx_close_extension+0x1d/0x70
[em28xx]
[ 1464.242911]
[PATCH 3/3] gspca-stk1135: Add variable resolution support
Add variable resolution support to Syntek STK1135 subdriver.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/media/usb/gspca/stk1135.c | 68 ++--
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/media/usb/gspca/stk1135.c
b/drivers/media/usb/gspca/stk1135.c
index 5a6ed49..8add2f7 100644
--- a/drivers/media/usb/gspca/stk1135.c
+++ b/drivers/media/usb/gspca/stk1135.c
@@ -48,42 +48,11 @@ struct sd {
};
static const struct v4l2_pix_format stk1135_modes[] = {
- {160, 120, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 160,
- .sizeimage = 160 * 120,
- .colorspace = V4L2_COLORSPACE_SRGB},
- {176, 144, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 176,
- .sizeimage = 176 * 144,
- .colorspace = V4L2_COLORSPACE_SRGB},
- {320, 240, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 320,
- .sizeimage = 320 * 240,
- .colorspace = V4L2_COLORSPACE_SRGB},
- {352, 288, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 352,
- .sizeimage = 352 * 288,
- .colorspace = V4L2_COLORSPACE_SRGB},
+ /* default mode (this driver supports variable resolution) */
{640, 480, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
.bytesperline = 640,
.sizeimage = 640 * 480,
.colorspace = V4L2_COLORSPACE_SRGB},
- {720, 576, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 720,
- .sizeimage = 720 * 576,
- .colorspace = V4L2_COLORSPACE_SRGB},
- {800, 600, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 800,
- .sizeimage = 800 * 600,
- .colorspace = V4L2_COLORSPACE_SRGB},
- {1024, 768, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 1024,
- .sizeimage = 1024 * 768,
- .colorspace = V4L2_COLORSPACE_SRGB},
- {1280, 1024, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
- .bytesperline = 1280,
- .sizeimage = 1280 * 1024,
- .colorspace = V4L2_COLORSPACE_SRGB},
};
/* -- read a register -- */
@@ -349,14 +318,14 @@ static void stk1135_configure_mt9m112(struct gspca_dev
*gspca_dev)
/* set output size */
width = gspca_dev-pixfmt.width;
height = gspca_dev-pixfmt.height;
- if (width = 640) { /* use context A (half readout speed by default) */
+ if (width = 640 height = 512) { /* context A (half readout speed)*/
sensor_write(gspca_dev, 0x1a7, width);
sensor_write(gspca_dev, 0x1aa, height);
/* set read mode context A */
sensor_write(gspca_dev, 0x0c8, 0x);
/* set resize, read mode, vblank, hblank context A */
sensor_write(gspca_dev, 0x2c8, 0x);
- } else { /* use context B (full readout speed by default) */
+ } else { /* context B (full readout speed) */
sensor_write(gspca_dev, 0x1a1, width);
sensor_write(gspca_dev, 0x1a4, height);
/* set read mode context B */
@@ -643,6 +612,35 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
return 0;
}
+void stk1135_try_fmt(struct gspca_dev *gspca_dev, struct v4l2_format *fmt)
+{
+ fmt-fmt.pix.width = clamp(fmt-fmt.pix.width, 32U, 1280U);
+ fmt-fmt.pix.height = clamp(fmt-fmt.pix.height, 32U, 1024U);
+ /* round up to even numbers */
+ fmt-fmt.pix.width += (fmt-fmt.pix.width 1);
+ fmt-fmt.pix.height += (fmt-fmt.pix.height 1);
+
+ fmt-fmt.pix.bytesperline = fmt-fmt.pix.width;
+ fmt-fmt.pix.sizeimage = fmt-fmt.pix.width * fmt-fmt.pix.height;
+}
+
+int stk1135_enum_framesizes(struct gspca_dev *gspca_dev,
+ struct v4l2_frmsizeenum *fsize)
+{
+ if (fsize-index != 0 || fsize-pixel_format != V4L2_PIX_FMT_SBGGR8)
+ return -EINVAL;
+
+ fsize-type = V4L2_FRMSIZE_TYPE_STEPWISE;
+ fsize-stepwise.min_width = 32;
+ fsize-stepwise.min_height = 32;
+ fsize-stepwise.max_width = 1280;
+ fsize-stepwise.max_height = 1024;
+ fsize-stepwise.step_width = 2;
+ fsize-stepwise.step_height = 2;
+
+ return 0;
+}
+
/* sub-driver description */
static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -653,6 +651,8 @@ static const struct sd_desc sd_desc = {
.stopN = sd_stopN,
.pkt_scan = sd_pkt_scan,
.dq_callback = stk1135_dq_callback,
+ .try_fmt = stk1135_try_fmt,
+ .enum_framesizes = stk1135_enum_framesizes,
};
/* -- module initialisation -- */
--
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
[PATCH 1/3] gspca: store current mode instead of individual parameters
Store complete current mode (struct v4l2_pix_format) in struct gspca_dev
instead of separate pixfmt, width and height parameters.
This is a preparation for variable resolution support.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/media/usb/gspca/conex.c |3 +-
drivers/media/usb/gspca/cpia1.c |4 +-
drivers/media/usb/gspca/gspca.c | 30 +
drivers/media/usb/gspca/gspca.h |4 +-
drivers/media/usb/gspca/jeilinj.c|5 +-
drivers/media/usb/gspca/jl2005bcd.c |2 +-
drivers/media/usb/gspca/m5602/m5602_mt9m111.c|2 +-
drivers/media/usb/gspca/mars.c |7 ++-
drivers/media/usb/gspca/mr97310a.c |6 +-
drivers/media/usb/gspca/nw80x.c | 11 +++--
drivers/media/usb/gspca/ov519.c | 51 --
drivers/media/usb/gspca/ov534.c |5 +-
drivers/media/usb/gspca/pac207.c |4 +-
drivers/media/usb/gspca/pac7311.c|6 +-
drivers/media/usb/gspca/se401.c |6 +-
drivers/media/usb/gspca/sn9c20x.c|6 +-
drivers/media/usb/gspca/sonixb.c |2 +-
drivers/media/usb/gspca/sonixj.c |3 +-
drivers/media/usb/gspca/spca1528.c |3 +-
drivers/media/usb/gspca/spca500.c|3 +-
drivers/media/usb/gspca/sq905c.c |2 +-
drivers/media/usb/gspca/sq930x.c |3 +-
drivers/media/usb/gspca/stk014.c |5 +-
drivers/media/usb/gspca/stk1135.c|8 ++--
drivers/media/usb/gspca/stv06xx/stv06xx.c|2 +-
drivers/media/usb/gspca/stv06xx/stv06xx_pb0100.c |2 +-
drivers/media/usb/gspca/sunplus.c|3 +-
drivers/media/usb/gspca/topro.c | 13 +++---
drivers/media/usb/gspca/tv8532.c |7 ++-
drivers/media/usb/gspca/vicam.c |8 ++--
drivers/media/usb/gspca/w996Xcf.c| 28 ++--
drivers/media/usb/gspca/xirlink_cit.c| 34 +++---
drivers/media/usb/gspca/zc3xx.c |3 +-
33 files changed, 145 insertions(+), 136 deletions(-)
diff --git a/drivers/media/usb/gspca/conex.c b/drivers/media/usb/gspca/conex.c
index 38714df..2e15c80 100644
--- a/drivers/media/usb/gspca/conex.c
+++ b/drivers/media/usb/gspca/conex.c
@@ -783,7 +783,8 @@ static int sd_start(struct gspca_dev *gspca_dev)
struct sd *sd = (struct sd *) gspca_dev;
/* create the JPEG header */
- jpeg_define(sd-jpeg_hdr, gspca_dev-height, gspca_dev-width,
+ jpeg_define(sd-jpeg_hdr, gspca_dev-pixfmt.height,
+ gspca_dev-pixfmt.width,
0x22); /* JPEG 411 */
jpeg_set_qual(sd-jpeg_hdr, QUALITY);
diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
index 064b530..f23df4a 100644
--- a/drivers/media/usb/gspca/cpia1.c
+++ b/drivers/media/usb/gspca/cpia1.c
@@ -1553,9 +1553,9 @@ static int sd_start(struct gspca_dev *gspca_dev)
sd-params.format.videoSize = VIDEOSIZE_CIF;
sd-params.roi.colEnd = sd-params.roi.colStart +
- (gspca_dev-width 3);
+ (gspca_dev-pixfmt.width 3);
sd-params.roi.rowEnd = sd-params.roi.rowStart +
- (gspca_dev-height 2);
+ (gspca_dev-pixfmt.height 2);
/* And now set the camera to a known state */
ret = do_command(gspca_dev, CPIA_COMMAND_SetGrabMode,
diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index b7ae872..9ffcce6 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -504,8 +504,7 @@ static int frame_alloc(struct gspca_dev *gspca_dev, struct
file *file,
unsigned int frsz;
int i;
- i = gspca_dev-curr_mode;
- frsz = gspca_dev-cam.cam_mode[i].sizeimage;
+ frsz = gspca_dev-pixfmt.sizeimage;
PDEBUG(D_STREAM, frame alloc frsz: %d, frsz);
frsz = PAGE_ALIGN(frsz);
if (count = GSPCA_MAX_FRAMES)
@@ -627,16 +626,14 @@ static struct usb_host_endpoint *alt_xfer(struct
usb_host_interface *alt,
static u32 which_bandwidth(struct gspca_dev *gspca_dev)
{
u32 bandwidth;
- int i;
/* get the (max) image size */
- i = gspca_dev-curr_mode;
- bandwidth = gspca_dev-cam.cam_mode[i].sizeimage;
+ bandwidth = gspca_dev-pixfmt.sizeimage;
/* if the image is compressed, estimate its mean size */
if (!gspca_dev-cam.needs_full_bandwidth
- bandwidth gspca_dev-cam.cam_mode[i].width *
- gspca_dev-cam.cam_mode[i].height)
+ bandwidth gspca_dev-pixfmt.width *
+
[PATCH 2/3] gspca: Support variable resolution
Add variable resolution support to gspca by allowing subdrivers to
specify try_fmt and enum_framesizes functions.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/media/usb/gspca/gspca.c | 20 ++--
drivers/media/usb/gspca/gspca.h |6 ++
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index 9ffcce6..423c7c8 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -1133,6 +1133,12 @@ static int try_fmt_vid_cap(struct gspca_dev *gspca_dev,
mode = mode2;
}
fmt-fmt.pix = gspca_dev-cam.cam_mode[mode];
+ if (gspca_dev-sd_desc-try_fmt) {
+ /* pass original resolution to subdriver try_fmt */
+ fmt-fmt.pix.width = w;
+ fmt-fmt.pix.height = h;
+ gspca_dev-sd_desc-try_fmt(gspca_dev, fmt);
+ }
/* some drivers use priv internally, zero it before giving it to
userspace */
fmt-fmt.pix.priv = 0;
@@ -1171,17 +1177,16 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void
*priv,
goto out;
}
- if (ret == gspca_dev-curr_mode) {
- ret = 0;
- goto out; /* same mode */
- }
-
if (gspca_dev-streaming) {
ret = -EBUSY;
goto out;
}
gspca_dev-curr_mode = ret;
- gspca_dev-pixfmt = gspca_dev-cam.cam_mode[ret];
+ if (gspca_dev-sd_desc-try_fmt)
+ /* subdriver try_fmt can modify format parameters */
+ gspca_dev-pixfmt = fmt-fmt.pix;
+ else
+ gspca_dev-pixfmt = gspca_dev-cam.cam_mode[ret];
ret = 0;
out:
@@ -1196,6 +1201,9 @@ static int vidioc_enum_framesizes(struct file *file, void
*priv,
int i;
__u32 index = 0;
+ if (gspca_dev-sd_desc-enum_framesizes)
+ return gspca_dev-sd_desc-enum_framesizes(gspca_dev, fsize);
+
for (i = 0; i gspca_dev-cam.nmodes; i++) {
if (fsize-pixel_format !=
gspca_dev-cam.cam_mode[i].pixelformat)
diff --git a/drivers/media/usb/gspca/gspca.h b/drivers/media/usb/gspca/gspca.h
index 0f3d150..300642d 100644
--- a/drivers/media/usb/gspca/gspca.h
+++ b/drivers/media/usb/gspca/gspca.h
@@ -88,6 +88,10 @@ typedef void (*cam_pkt_op) (struct gspca_dev *gspca_dev,
typedef int (*cam_int_pkt_op) (struct gspca_dev *gspca_dev,
u8 *data,
int len);
+typedef void (*cam_format_op) (struct gspca_dev *gspca_dev,
+ struct v4l2_format *fmt);
+typedef int (*cam_frmsize_op) (struct gspca_dev *gspca_dev,
+ struct v4l2_frmsizeenum *fsize);
/* subdriver description */
struct sd_desc {
@@ -109,6 +113,8 @@ struct sd_desc {
cam_set_jpg_op set_jcomp;
cam_streamparm_op get_streamparm;
cam_streamparm_op set_streamparm;
+ cam_format_op try_fmt;
+ cam_frmsize_op enum_framesizes;
#ifdef CONFIG_VIDEO_ADV_DEBUG
cam_set_reg_op set_register;
cam_get_reg_op get_register;
--
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: [media-workshop] Agenda for the Edinburgh mini-summit
Hi Pawel, On Saturday 31 August 2013 08:58:41 Pawel Osciak wrote: On Sat, Aug 31, 2013 at 1:54 AM, Laurent Pinchart wrote: On Friday 30 August 2013 10:31:23 Mauro Carvalho Chehab wrote: Em Fri, 30 Aug 2013 15:21:05 +0200 Oliver Schinagl escreveu: On 30-08-13 15:01, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input- infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. From my side, I'd like to discuss about a better integration between DVB and V4L2, including starting using the media controller API on DVB side too. Btw, it would be great if we could get a status about the media controller API usage on ALSA. I'm planning to work at such integration soon. What about a hardware accelerated decoding API/framework? Is there a proper framework for this at all? I see the broadcom module is still in staging and may never come out of it, but how are other video decoding engines handled that don't have cameras or displays. Reason for asking is that we from linux-sunxi have made some positive progress in Reverse engineering the video decoder blob of the Allwinner A10 and this knowledge will need a kernel side driver in some framework. I looked at the exynos video decoders and googling for linux-media hardware accelerated decoding doesn't yield much either. Anyway, just a thought; if you think it's the wrong place for it to be discussed, that's ok :) Well, the mem2mem V4L2 devices should provide all that would be needed for accelerated encoders/decoders. If not, then feel free to propose extensionsto fit your needs. Two comments regarding this: - V4L2 mem-to-mem is great for frame-based codecs, but SoCs sometimes only implement part of the codec in hardware, leaving the rest to the software. Encoded bistream parsing is one of those areas that are left to the CPU, for instance on some ST SoCs (CC'ing Benjamin Gaignard). This is an interesting topic for me as well, although I'm still not sure if I can make it to the workshop. Would it make sense to have v4l parser plugins hook up to qbuf and do the parsing there? Do you mean in libv4l ? - http://www.linuxplumbersconf.org/2013/ocw/sessions/1605 -- 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: WARNINGS
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: Sat Aug 31 04:00:14 CEST 2013 git branch: test git hash: 26a20eb09d44dc064c4f5d1f024bd501c09edb4b gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 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: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11-rc1-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK 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-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11-rc1-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK 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 apps: WARNINGS spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
