Media entity configuration
Hi, I was wondering if the media pad configuration could be hard fixed in the kernel sources, so an userspace application could directly capture some frames from the CCDC output ( /dev/video2 ). Thank you -- 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: [RFCv1 PATCH 4/9] v4l2-ctrls: add per-control events.
Hi Hans,
Thanks for the patchset! This looks really nice!
Hans Verkuil wrote:
Whenever a control changes value an event is sent to anyone that subscribed
to it.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 59 ++
drivers/media/video/v4l2-event.c | 126
+++---
drivers/media/video/v4l2-fh.c|4 +-
include/linux/videodev2.h| 17 +-
include/media/v4l2-ctrls.h |9 +++
include/media/v4l2-event.h |2 +
6 files changed, 177 insertions(+), 40 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c
index f75a1d4..163f412 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -23,6 +23,7 @@
#include media/v4l2-ioctl.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
#include media/v4l2-dev.h
/* Internal temporary helper struct, one for each v4l2_ext_control */
@@ -537,6 +538,16 @@ static bool type_is_int(const struct v4l2_ctrl *ctrl)
}
}
+static void send_event(struct v4l2_ctrl *ctrl, struct v4l2_event *ev)
+{
+ struct v4l2_ctrl_fh *pos;
+
+ ev-id = ctrl-id;
+ list_for_each_entry(pos, ctrl-fhs, node) {
+ v4l2_event_queue_fh(pos-fh, ev);
+ }
No need for braces here.
+}
+
/* Helper function: copy the current control value back to the caller */
static int cur_to_user(struct v4l2_ext_control *c,
struct v4l2_ctrl *ctrl)
@@ -626,20 +637,38 @@ static int new_to_user(struct v4l2_ext_control *c,
/* Copy the new value to the current value. */
static void new_to_cur(struct v4l2_ctrl *ctrl)
{
+ struct v4l2_event ev;
+ bool changed = false;
+
if (ctrl == NULL)
return;
switch (ctrl-type) {
+ case V4L2_CTRL_TYPE_BUTTON:
+ changed = true;
+ ev.u.ctrl_ch_value.value = 0;
+ break;
case V4L2_CTRL_TYPE_STRING:
/* strings are always 0-terminated */
+ changed = strcmp(ctrl-string, ctrl-cur.string);
strcpy(ctrl-cur.string, ctrl-string);
+ ev.u.ctrl_ch_value.value64 = 0;
break;
case V4L2_CTRL_TYPE_INTEGER64:
+ changed = ctrl-val64 != ctrl-cur.val64;
ctrl-cur.val64 = ctrl-val64;
+ ev.u.ctrl_ch_value.value64 = ctrl-val64;
break;
default:
+ changed = ctrl-val != ctrl-cur.val;
ctrl-cur.val = ctrl-val;
+ ev.u.ctrl_ch_value.value = ctrl-val;
break;
}
+ if (changed) {
+ ev.type = V4L2_EVENT_CTRL_CH_VALUE;
+ ev.u.ctrl_ch_value.type = ctrl-type;
+ send_event(ctrl, ev);
+ }
}
/* Copy the current value to the new value */
@@ -784,6 +813,7 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
{
struct v4l2_ctrl_ref *ref, *next_ref;
struct v4l2_ctrl *ctrl, *next_ctrl;
+ struct v4l2_ctrl_fh *ctrl_fh, *next_ctrl_fh;
if (hdl == NULL || hdl-buckets == NULL)
return;
@@ -797,6 +827,10 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler
*hdl)
/* Free all controls owned by the handler */
list_for_each_entry_safe(ctrl, next_ctrl, hdl-ctrls, node) {
list_del(ctrl-node);
+ list_for_each_entry_safe(ctrl_fh, next_ctrl_fh, ctrl-fhs,
node) {
+ list_del(ctrl_fh-node);
+ kfree(ctrl_fh);
+ }
kfree(ctrl);
}
kfree(hdl-buckets);
@@ -1003,6 +1037,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
}
INIT_LIST_HEAD(ctrl-node);
+ INIT_LIST_HEAD(ctrl-fhs);
ctrl-handler = hdl;
ctrl-ops = ops;
ctrl-id = id;
@@ -1888,3 +1923,27 @@ int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val)
return set_ctrl(ctrl, val);
}
EXPORT_SYMBOL(v4l2_ctrl_s_ctrl);
+
+void v4l2_ctrl_add_fh(struct v4l2_ctrl *ctrl, struct v4l2_ctrl_fh *ctrl_fh)
+{
+ v4l2_ctrl_lock(ctrl);
+ list_add_tail(ctrl_fh-node, ctrl-fhs);
+ v4l2_ctrl_unlock(ctrl);
+}
+EXPORT_SYMBOL(v4l2_ctrl_add_fh);
+
+void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct v4l2_fh *fh)
+{
+ struct v4l2_ctrl_fh *pos;
+
+ v4l2_ctrl_lock(ctrl);
+ list_for_each_entry(pos, ctrl-fhs, node) {
+ if (pos-fh == fh) {
+ list_del(pos-node);
+ kfree(pos);
+ break;
+ }
+ }
+ v4l2_ctrl_unlock(ctrl);
+}
+EXPORT_SYMBOL(v4l2_ctrl_del_fh);
diff --git a/drivers/media/video/v4l2-event.c
b/drivers/media/video/v4l2-event.c
index 69fd343..c9251a5 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -25,10 +25,13 @@
Re: Media entity configuration
Hi Loïc, On Monday 11 April 2011 09:24:49 Loïc Akue wrote: Hi, I was wondering if the media pad configuration could be hard fixed in the kernel sources, so an userspace application could directly capture some frames from the CCDC output ( /dev/video2 ). How do you mean ? Hard fixed to what ? -- 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/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
Hi Guennadi,
Thanks for the RFC! I have a few comments below.
Guennadi Liakhovetski wrote:
A possibility to preallocate and initialise buffers of different sizes
in V4L2 is required for an efficient implementation of asnapshot mode.
This patch adds three new ioctl()s: VIDIOC_CREATE_BUFS,
VIDIOC_DESTROY_BUFS, and VIDIOC_SUBMIT_BUF and defines respective data
structures.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/v4l2-compat-ioctl32.c |3 ++
drivers/media/video/v4l2-ioctl.c | 43
+
include/linux/videodev2.h | 24
include/media/v4l2-ioctl.h|3 ++
4 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 7c26947..d71b289 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -922,6 +922,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_DQEVENT:
case VIDIOC_SUBSCRIBE_EVENT:
case VIDIOC_UNSUBSCRIBE_EVENT:
+ case VIDIOC_CREATE_BUFS:
+ case VIDIOC_DESTROY_BUFS:
+ case VIDIOC_SUBMIT_BUF:
ret = do_video_ioctl(file, cmd, arg);
break;
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index a01ed39..b80a211 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -259,6 +259,9 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_DQEVENT)] = VIDIOC_DQEVENT,
[_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = VIDIOC_SUBSCRIBE_EVENT,
[_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = VIDIOC_UNSUBSCRIBE_EVENT,
+ [_IOC_NR(VIDIOC_CREATE_BUFS)] = VIDIOC_CREATE_BUFS,
+ [_IOC_NR(VIDIOC_DESTROY_BUFS)] = VIDIOC_DESTROY_BUFS,
+ [_IOC_NR(VIDIOC_SUBMIT_BUF)] = VIDIOC_SUBMIT_BUF,
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
@@ -2184,6 +2187,46 @@ static long __video_do_ioctl(struct file *file,
dbgarg(cmd, type=0x%8.8x, sub-type);
break;
}
+ case VIDIOC_CREATE_BUFS:
+ {
+ struct v4l2_create_buffers *create = arg;
+
+ if (!ops-vidioc_create_bufs)
+ break;
+ ret = check_fmt(ops, create-format.type);
+ if (ret)
+ break;
+
+ if (create-size)
+ CLEAR_AFTER_FIELD(create, count);
+
+ ret = ops-vidioc_create_bufs(file, fh, create);
+
+ dbgarg(cmd, count=%d\n, create-count);
+ break;
+ }
+ case VIDIOC_DESTROY_BUFS:
+ {
+ struct v4l2_buffer_span *span = arg;
+
+ if (!ops-vidioc_destroy_bufs)
+ break;
+
+ ret = ops-vidioc_destroy_bufs(file, fh, span);
+
+ dbgarg(cmd, count=%d, span-count);
+ break;
+ }
+ case VIDIOC_SUBMIT_BUF:
+ {
+ unsigned int *i = arg;
+
+ if (!ops-vidioc_submit_buf)
+ break;
+ ret = ops-vidioc_submit_buf(file, fh, *i);
+ dbgarg(cmd, index=%d, *i);
+ break;
+ }
default:
{
bool valid_prio = true;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..b6ef46e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1847,6 +1847,26 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
+/* VIDIOC_DESTROY_BUFS */
+struct v4l2_buffer_span {
+ __u32 index; /* output: buffers index...index +
count - 1 have been created */
+ __u32 count;
+ __u32 reserved[2];
+};
+
+/* struct v4l2_createbuffers::flags */
+#define V4L2_BUFFER_FLAG_NO_CACHE_INVALIDATE (1 0)
+
+/* VIDIOC_CREATE_BUFS */
+struct v4l2_create_buffers {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ __u32 flags; /* V4L2_BUFFER_FLAG_* */
+ enum v4l2_memorymemory;
+ __u32 size; /* Explicit size, e.g., for
compressed streams */
+ struct v4l2_format format; /* type is used always, the
rest if size == 0 */
+};
This assumes that the buffer indices that are returned by these ioctls
will be incremented beyond V4L2_MAX_FRAME. Don't you think this is an issue?
Proper handling of this still requires that once the count reaches
UINT_MAX, you do check that the buffer indices actually are available.
This might not be easier than keeping the range as contiguous as
possible and returning a set of
[PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..0918c48 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -376,6 +376,9 @@ static int soc_camera_set_fmt(struct soc_camera_device *icd,
dev_dbg(icd-dev, S_FMT(%c%c%c%c, %ux%u)\n,
pixfmtstr(pix-pixelformat), pix-width, pix-height);
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
/* We always call try_fmt() before set_fmt() or set_crop() */
ret = ici-ops-try_fmt(icd, f);
if (ret 0)
@@ -391,6 +394,17 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
return -EINVAL;
}
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ ret = soc_mbus_bytes_per_line(pix-width,
+
icd-current_fmt-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
icd-user_width = pix-width;
icd-user_height= pix-height;
icd-bytesperline = pix-bytesperline;
--
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 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
On Mon, 11 Apr 2011, Janusz Krzysztofik wrote: Dnia niedziela 10 kwiecień 2011 o 18:00:14 Guennadi Liakhovetski napisał(a): Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Wasn't it already unified before commit in question? Please test the patch, I've sent a minute ago. Thanks Guennadi Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Perhaps I could, as soon as I found some spare time, but first I'd have to really understand why we need bytesperline or sizeimage handling being changed from how they worked before commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a was introduced. I never had a need to customize bytesperline or sizeimage calculations in my driver. But even then, I think these new patches would rather qualify for next merge window, while the OMAP1 driver case is just a regression, caused by an alredy applied, unrelated change to the underlying framework, and requires a fix if that change is not going to be reverted. Maybe the author of the change, Sergio Aguirre form TI (CCing him), could rework his patch in a way which wouldn't impose, as a side effect, the new requirement of those structure members being passed from host drivers? Thanks, Janusz --- 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
[PATCH 0/4] s5p-fimc driver fixes for 2.6.39
Hello, the following are a few bugfix patches for s5p-fimc driver. After recent rename of the s5pv310 SoC series to Exynos4 it is necessary to change the variant name in the driver, what the first patch does. The second patch corrects the S_FMT ioctl handler to forbid the format change as soon as buffers were allocated. The changset also correct the bytesperline and plane buffer size which were incorrect in case of the multi-planar formats. Finally it adds buffer timestamp and the sequence support in the camera capture driver. The change set contains: [PATCH 1/4] s5p-fimc: Fix FIMC3 pixel limits on Exynos4 [PATCH 2/4] s5p-fimc: Do not allow changing format after REQBUFS [PATCH 3/4] s5p-fimc: Fix bytesperline and plane payload setup [PATCH 4/4] s5p-fimc: Add support for the buffer timestamps and sequence -- Regards, Sylwester Nawrocki Samsung Poland RD Center -- 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] s5p-fimc: Fix FIMC3 pixel limits on Exynos4
Correct pixel limits for the fourth FIMC entity on Exynos4 SoCs.
FIMC3 only supports the writeback input from the LCD mixer.
Also rename s5pv310 variant to exynos4 which is needed after
renaming s5pv310 series to Exynos4.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 30 +++---
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 6c919b3..d54e6d85 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1750,7 +1750,7 @@ static int __devexit fimc_remove(struct platform_device
*pdev)
}
/* Image pixel limits, similar across several FIMC HW revisions. */
-static struct fimc_pix_limit s5p_pix_limit[3] = {
+static struct fimc_pix_limit s5p_pix_limit[4] = {
[0] = {
.scaler_en_w= 3264,
.scaler_dis_w = 8192,
@@ -1775,6 +1775,14 @@ static struct fimc_pix_limit s5p_pix_limit[3] = {
.out_rot_en_w = 1280,
.out_rot_dis_w = 1920,
},
+ [3] = {
+ .scaler_en_w= 1920,
+ .scaler_dis_w = 8192,
+ .in_rot_en_h= 1366,
+ .in_rot_dis_w = 8192,
+ .out_rot_en_w = 1366,
+ .out_rot_dis_w = 1920,
+ },
};
static struct samsung_fimc_variant fimc0_variant_s5p = {
@@ -1827,7 +1835,7 @@ static struct samsung_fimc_variant fimc2_variant_s5pv210
= {
.pix_limit = s5p_pix_limit[2],
};
-static struct samsung_fimc_variant fimc0_variant_s5pv310 = {
+static struct samsung_fimc_variant fimc0_variant_exynos4 = {
.pix_hoff= 1,
.has_inp_rot = 1,
.has_out_rot = 1,
@@ -1840,7 +1848,7 @@ static struct samsung_fimc_variant fimc0_variant_s5pv310
= {
.pix_limit = s5p_pix_limit[1],
};
-static struct samsung_fimc_variant fimc2_variant_s5pv310 = {
+static struct samsung_fimc_variant fimc2_variant_exynos4 = {
.pix_hoff= 1,
.has_cistatus2 = 1,
.has_mainscaler_ext = 1,
@@ -1848,7 +1856,7 @@ static struct samsung_fimc_variant fimc2_variant_s5pv310
= {
.min_out_pixsize = 16,
.hor_offs_align = 1,
.out_buf_count = 32,
- .pix_limit = s5p_pix_limit[2],
+ .pix_limit = s5p_pix_limit[3],
};
/* S5PC100 */
@@ -1874,12 +1882,12 @@ static struct samsung_fimc_driverdata
fimc_drvdata_s5pv210 = {
};
/* S5PV310, S5PC210 */
-static struct samsung_fimc_driverdata fimc_drvdata_s5pv310 = {
+static struct samsung_fimc_driverdata fimc_drvdata_exynos4 = {
.variant = {
- [0] = fimc0_variant_s5pv310,
- [1] = fimc0_variant_s5pv310,
- [2] = fimc0_variant_s5pv310,
- [3] = fimc2_variant_s5pv310,
+ [0] = fimc0_variant_exynos4,
+ [1] = fimc0_variant_exynos4,
+ [2] = fimc0_variant_exynos4,
+ [3] = fimc2_variant_exynos4,
},
.num_entities = 4,
.lclk_frequency = 16600UL,
@@ -1893,8 +1901,8 @@ static struct platform_device_id fimc_driver_ids[] = {
.name = s5pv210-fimc,
.driver_data= (unsigned long)fimc_drvdata_s5pv210,
}, {
- .name = s5pv310-fimc,
- .driver_data= (unsigned long)fimc_drvdata_s5pv310,
+ .name = exynos4-fimc,
+ .driver_data= (unsigned long)fimc_drvdata_exynos4,
},
{},
};
--
1.7.4.3
--
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] s5p-fimc: Do not allow changing format after REQBUFS
Protecting the color format with vb2_is_streaming() is not sufficient
as this prevents changing the format only after VIDIOC_STREAMON.
To prevent the color format reconfiguration as soon as buffers
are allocated use vb2_is_busy() instead.
Also make the videobuf queue ops structure static.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |2 +-
drivers/media/video/s5p-fimc/fimc-core.c|4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 95f8b4e1..00c561c 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -527,7 +527,7 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
if (ret)
return ret;
- if (vb2_is_streaming(fimc-vid_cap.vbq) || fimc_capture_active(fimc))
+ if (vb2_is_busy(fimc-vid_cap.vbq) || fimc_capture_active(fimc))
return -EBUSY;
frame = ctx-d_frame;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index d54e6d85..115a1e0 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -758,7 +758,7 @@ static void fimc_unlock(struct vb2_queue *vq)
mutex_unlock(ctx-fimc_dev-lock);
}
-struct vb2_ops fimc_qops = {
+static struct vb2_ops fimc_qops = {
.queue_setup = fimc_queue_setup,
.buf_prepare = fimc_buf_prepare,
.buf_queue = fimc_buf_queue,
@@ -965,7 +965,7 @@ static int fimc_m2m_s_fmt_mplane(struct file *file, void
*priv,
vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
- if (vb2_is_streaming(vq)) {
+ if (vb2_is_busy(vq)) {
v4l2_err(fimc-m2m.v4l2_dev, queue (%d) busy\n, f-type);
return -EBUSY;
}
--
1.7.4.3
--
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] s5p-fimc: Fix bytesperline and plane payload setup
Make sure the sizeimage for 3-planar color formats is
width * height * 3/2 and the bytesperline is same for each
plane in case of a multi-planar format.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |6 +++-
drivers/media/video/s5p-fimc/fimc-core.c| 30 ++
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 00c561c..d142b40 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -539,8 +539,10 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
return -EINVAL;
}
- for (i = 0; i frame-fmt-colplanes; i++)
- frame-payload[i] = pix-plane_fmt[i].bytesperline *
pix-height;
+ for (i = 0; i frame-fmt-colplanes; i++) {
+ frame-payload[i] =
+ (pix-width * pix-height * frame-fmt-depth[i]) 3;
+ }
/* Output DMA frame pixel size and offsets. */
frame-f_width = pix-plane_fmt[0].bytesperline * 8
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 115a1e0..ef4e3f6 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -927,23 +927,23 @@ int fimc_vidioc_try_fmt_mplane(struct file *file, void
*priv,
pix-num_planes = fmt-memplanes;
pix-colorspace = V4L2_COLORSPACE_JPEG;
- for (i = 0; i pix-num_planes; ++i) {
- int bpl = pix-plane_fmt[i].bytesperline;
- dbg([%d] bpl: %d, depth: %d, w: %d, h: %d,
- i, bpl, fmt-depth[i], pix-width, pix-height);
+ for (i = 0; i pix-num_planes; ++i) {
+ u32 bpl = pix-plane_fmt[i].bytesperline;
+ u32 *sizeimage = pix-plane_fmt[i].sizeimage;
- if (!bpl || (bpl * 8 / fmt-depth[i]) pix-width)
- bpl = (pix-width * fmt-depth[0]) 3;
+ if (fmt-colplanes 1 (bpl == 0 || bpl pix-width))
+ bpl = pix-width; /* Planar */
- if (!pix-plane_fmt[i].sizeimage)
- pix-plane_fmt[i].sizeimage = pix-height * bpl;
+ if (fmt-colplanes == 1 /* Packed */
+ (bpl == 0 || ((bpl * 8) / fmt-depth[i]) pix-width))
+ bpl = (pix-width * fmt-depth[0]) / 8;
- pix-plane_fmt[i].bytesperline = bpl;
+ if (i == 0) /* Same bytesperline for each plane. */
+ mod_x = bpl;
- dbg([%d]: bpl: %d, sizeimage: %d,
- i, pix-plane_fmt[i].bytesperline,
- pix-plane_fmt[i].sizeimage);
+ pix-plane_fmt[i].bytesperline = mod_x;
+ *sizeimage = (pix-width * pix-height * fmt-depth[i]) / 8;
}
return 0;
@@ -985,8 +985,10 @@ static int fimc_m2m_s_fmt_mplane(struct file *file, void
*priv,
if (!frame-fmt)
return -EINVAL;
- for (i = 0; i frame-fmt-colplanes; i++)
- frame-payload[i] = pix-plane_fmt[i].bytesperline *
pix-height;
+ for (i = 0; i frame-fmt-colplanes; i++) {
+ frame-payload[i] =
+ (pix-width * pix-height * frame-fmt-depth[i]) / 8;
+ }
frame-f_width = pix-plane_fmt[0].bytesperline * 8 /
frame-fmt-depth[0];
--
1.7.4.3
--
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] s5p-fimc: Add support for the buffer timestamps and sequence
Add support for buffer timestamps and the sequence number in
the video capture driver.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index ef4e3f6..dc91a85 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -361,10 +361,20 @@ static void fimc_capture_irq_handler(struct fimc_dev
*fimc)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_vid_buffer *v_buf;
+ struct timeval *tv;
+ struct timespec ts;
if (!list_empty(cap-active_buf_q)
test_bit(ST_CAPT_RUN, fimc-state)) {
+ ktime_get_real_ts(ts);
+
v_buf = active_queue_pop(cap);
+
+ tv = v_buf-vb.v4l2_buf.timestamp;
+ tv-tv_sec = ts.tv_sec;
+ tv-tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ v_buf-vb.v4l2_buf.sequence = cap-frame_count++;
+
vb2_buffer_done(v_buf-vb, VB2_BUF_STATE_DONE);
}
--
1.7.4.3
--
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: mt9t111 sensor on Beagleboard xM
Hi Laurent, Adding pad-level operations will not break any existing driver, as long as you keep the existing operations functional. Is it really possible to have a sensor driver supporting soc-camera, v4l2-subdev and pad-level operations? I've been reviewing the code of mt9t112 and I'm not very sure soc-camera code can be easily isolated. What is the future of soc-camera anyway? Since it seems v4l2-subdev and media-controller clearly make it deprecated. Wouldn't it be more suitable to just develop a separate mt9t112 driver which includes v4l2-subdev and pad-level operations without soc-camera? Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
dibusb device with lock problems
Hi list, as a follow-up to http://www.spinics.net/lists/linux-media/msg30930.html: I have the Odys Easy TV Model X820001 (http://www.dooyoo.co.uk/tv-cards/odys-easy-tv-dvbt-usb-box/) which also is a dib3000mb device but it isn't mentioned yet in the list at http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices/Full. I recently updated from Debian Lenny (where the box worked flawlessly) to Squeeze and now I don't get any station tuned. Is there any fix in sight? Thanks and regards, 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
Re: [PATCH 0/2] V4L: Extended crop/compose API, ver2
Hans Verkuil wrote:
Hi Tomasz!
Some comments below...
On Wednesday, April 06, 2011 10:44:17 Tomasz Stanislawski wrote:
Hello everyone,
This patch-set introduces new ioctls to V4L2 API. The new method for
configuration of cropping and composition is presented.
This is the second version of extcrop RFC. It was enriched with new features
like additional hint flags, and a support for auxiliary crop/compose
rectangles.
There is some confusion in understanding of a cropping in current version of
V4L2. For CAPTURE devices cropping refers to choosing only a part of input
data stream and processing it and storing it in a memory buffer. The buffer is
fully filled by data. It is not possible to choose only a part of a buffer for
being updated by hardware.
In case of OUTPUT devices, the whole content of a buffer is passed by hardware
to output display. Cropping means selecting only a part of an output
display/signal. It is not possible to choose only a part for a memory buffer
to be processed.
The overmentioned flaws in cropping API were discussed in post:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/28945
A solution was proposed during brainstorming session in Warsaw.
1. Data structures.
The structure v4l2_crop used by current API lacks any place for further
extensions. Therefore new structure is proposed.
struct v4l2_selection {
u32 type;
u32 target;
struct v4l2_rect r;
u32 flags;
u32 reserved[9];
};
Where,
type - type of buffer queue: V4L2_BUF_TYPE_VIDEO_CAPTURE,
V4L2_BUF_TYPE_VIDEO_OUTPUT, etc.
target - choose one of cropping/composing rectangles
r- selection rectangle
flags- control over coordinates adjustments
reserved - place for further extensions, adjust struct size to 64 bytes
At first, the distinction between cropping and composing was stated. The
cropping operation means choosing only part of input data bounding it by a
cropping rectangle. All other data must be discarded. On the other hand,
composing means pasting processed data into rectangular part of data sink. The
sink may be output device, user buffer, etc.
2. Crop/Compose ioctl.
Four new ioctls would be added to V4L2.
Name
VIDIOC_S_EXTCROP - set cropping rectangle on an input of a device
Synopsis
int ioctl(fd, VIDIOC_S_EXTCROP, struct v4l2_selection *s)
Description:
The ioctl is used to configure:
- for input devices, a part of input data that is processed in hardware
- for output devices, a part of a data buffer to be passed to hardware
Drivers may adjust a cropping area. The adjustment can be controlled
by v4l2_selection::flags. Please refer to Hints section.
- an adjusted crop rectangle is returned in v4l2_selection::r
Return value
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
ERANGE - failed to find a rectangle that satisfy all constraints
EINVAL - incorrect buffer type, incorrect target, cropping not supported
-
Name
VIDIOC_G_EXTCROP - get cropping rectangle on an input of a device
Synopsis
int ioctl(fd, VIDIOC_G_EXTCROP, struct v4l2_selection *s)
Description:
The ioctl is used to query:
- for input devices, a part of input data that is processed in hardware
Other crop rectangles might be examined using this ioctl.
Please refer to Targets section.
- for output devices, a part of data buffer to be passed to hardware
Return value
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
EINVAL - incorrect buffer type, incorrect target, cropping not supported
-
Name
VIDIOC_S_COMPOSE - set destination rectangle on an output of a device
Synopsis
int ioctl(fd, VIDIOC_S_COMPOSE, struct v4l2_selection *s)
Description:
The ioctl is used to configure:
- for input devices, a part of a data buffer that is filled by hardware
- for output devices, a area on output device where image is inserted
Drivers may adjust a composing area. The adjustment can be controlled
by v4l2_selection::flags. Please refer to Hints section.
- an adjusted composing rectangle is returned in v4l2_selection::r
Return value
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
ERANGE - failed to find a rectangle that satisfy all constraints
EINVAL - incorrect buffer type, incorrect target, composing not
supported
-
Name
VIDIOC_G_COMPOSE - get destination rectangle on an output of a device
Synopsis
int ioctl(fd, VIDIOC_G_COMPOSE, struct v4l2_selection *s)
Description:
The ioctl
Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
Hi Hans,
Hans Verkuil wrote:
Hi Hans,
On Thursday 07 April 2011 09:50:13 Hans Verkuil wrote:
On Thu, 7 Apr 2011, Hans Verkuil wrote:
[snip]
Regarding DESTROY_BUFS: perhaps we should just skip this for now and
wait
for the first use-case. That way we don't need to care about holes. I
don't like artificial restrictions like 'no holes'. If someone has a
good
use-case for selectively destroying buffers, then we need to look at
this
again.
Sorry, skip what? skip the ioctl completely and rely on REQBUFS(0) /
close()?
Yes.
I don't really like that as it would mix CREATE and REQBUFS calls.
Applications should either use the old API (REQBUFS) or the new one, but
not
mix both.
That's a completely unnecessary limitation. And from the point of view of
vb2 it shouldn't even matter.
If calls to {CREATE,DESTROY}_BUF and REQBUFS are allowed to be mixed, it
would be nice to define the API so that one could implement REQBUFS
using CREATE_BUFS and DESTROY_BUFS. Then, drivers would not need to
implement REQBUFS separately which would still be used by majority of
applications. And Videobuf2 wouldn't need to implement REQBUFS at all.
Would this require more than to require buffer indices starting from
zero and be contiguous when there are no existing allocations?
The spec says under VIDIOC_QBUF that Valid index numbers range from
zero to the number of buffers allocated with VIDIOC_REQBUFS (struct
v4l2_requestbuffers count) minus one.
The fact that freeing arbitrary spans of buffers gives us uneasy feelings
might be a sign that the CREATE/DESTROY API is not mature enough. I'd
rather
try to solve the issue now instead of postponing it for later and discover
that our CREATE API should have been different.
What gives me an uneasy feeling is prohibiting freeing arbitrary spans of
buffers. I rather choose not to implement the DESTROY ioctl instead of
implementing a limited version of it, also because we do not have proper
use cases yet. But I have no problems with the CREATE/DESTROY API as such.
What would you think about using an array of index numbers rather than a
range for both? One must manage index number allocation even when using
a range and it might not be easier than to allocate all buffers from a
relatively small range (e.g. index numbers from 0 to 63), whose
implementation could be a bit field.
Cheers,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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: mt9t111 sensor on Beagleboard xM
Hi Javier, On Monday 11 April 2011 11:11:06 javier Martin wrote: Hi Laurent, Adding pad-level operations will not break any existing driver, as long as you keep the existing operations functional. Is it really possible to have a sensor driver supporting soc-camera, v4l2-subdev and pad-level operations? Probably. Guennadi should be able to help you some more with that, he's the soc-camera expert. I've been reviewing the code of mt9t112 and I'm not very sure soc-camera code can be easily isolated. What is the future of soc-camera anyway? Since it seems v4l2-subdev and media-controller clearly make it deprecated. My understanding is that soc-camera will stay, but sensor drivers will likely not depend on soc-camera anymore. soc-camera will use pad-level operations, as well as a bus configuration ioctl that has been proposed on the list (but not finalized yet). Guennadi, can you share some information about this ? Wouldn't it be more suitable to just develop a separate mt9t112 driver which includes v4l2-subdev and pad-level operations without soc-camera? I don't think duplicate drivers will be accepted for mainline. -- 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 2.6.39] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Mon 11 Apr 2011 at 02:42:13 Mauro Carvalho Chehab wrote:
Em 10-04-2011 19:47, Janusz Krzysztofik escreveu:
After switching from mem-dma_handle to virt_to_phys(mem-vaddr)
used for obtaining page frame number passed to remap_pfn_range()
(commit 35d9f510b67b10338161aba6229d4f55b4000f5b),
videobuf-dma-contig stopped working on my ARM based board. The ARM
architecture maintainer, Russell King, confirmed that using
something like
virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can
be broken on other architectures as well. The author of the
change, Jiri Slaby, also confirmed that his code may not work on
all architectures.
The patch takes two different countermeasures against this
regression:
1. On architectures which provide dma_mmap_coherent() function (ARM for
now), use it instead of just remap_pfn_range(). The code is
stollen from sound/core/pcm_native.c:snd_pcm_default_mmap().
Set vma-vm_pgoff to 0 before calling dma_mmap_coherent(), or it
fails.
2. On other architectures, use virt_to_phys(bus_to_virt(mem-dma_handle))
instead of problematic virt_to_phys(mem-vaddr). This should
work even if those translations would occure inaccurate for DMA
addresses, since possible errors introduced by both
calculations, performed in opposite directions, should
compensate.
...
+#ifndef ARCH_HAS_DMA_MMAP_COHERENT
+/* This should be defined / handled globally! */
+#ifdef CONFIG_ARM
+#define ARCH_HAS_DMA_MMAP_COHERENT
+#endif
+#endif
+
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
Hmm... IMHO, this seems too confusing. Why not use just something
like:
#if defined(CONFIG_ARM) || defined(ARCH_HAS_DMA_MMAP_COHERENT)
Better yet: why should CONFIG_ARM should explicitly be checked here?
Is it the only architecture where this would fail?dma_mmap_coherent
Hmm...
$ git grep ARCH_HAS_DMA_MMAP_COHERENT arch
arch/powerpc/include/asm/dma-mapping.h:#define ARCH_HAS_DMA_MMAP_COHERENT
My fault, I've just missed the fact that PPC also provides
dma_mmap_coherent() AND, unlike ARM, defines ARCH_HAS_DMA_MMAP_COHERENT
as well. Then, I would drop all above ifdefery except the last '#ifdef
ARCH_HAS_DMA_MMAP_COHERENT', and also submit a separate patch against
arch/arm/include/asm/dma-mapping.h for it to define
ARCH_HAS_DMA_MMAP_COHERENT, OK?
The code is saying that dma_mmap_coherent should be used only on ARM
and PPC architectures, and remap_pfn_range should be used otherwise.
Yes, because only these two architectures provide this function:
$ grep -r EXPORT_SYMBOL.*(dma_mmap_coherent) arch
arch/powerpc/kernel/dma.c:EXPORT_SYMBOL_GPL(dma_mmap_coherent);
arch/arm/mm/dma-mapping.c:EXPORT_SYMBOL(dma_mmap_coherent);
Other must keep using remap_pfn_range(), as they used to before.
Are you sure that this will work on the other architectures?
If you mean using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of
that problematic virt_to_phys(mem-vaddr) - yes, I think this should
work not any worth than before, and shouldn't break anything on any
architecture, including those not suffering from the problem.
What I'm not sure about is if this really helps on all those affected
architectures (if still any) which don't provide their
dma_mmap_coherent() implementation yet. I can only confirm this helps on
my ARM.
I've already asked for testing to get an idea which architectures those
could be
(http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/047701.html),
but haven't received any response yet.
I really prefer to have one standard way for doing it, that would
be architecture-independent. Media drivers or core should not have
arch-dependent code inside.
Sure, but here we have a choice between the still working but
depreciated usage of bus_to_virt() for tranlating a DMA bus address, and
a new way of doing things with dma_mmap_coherent(), which is not (yet)
widely supported. If you think we should limit our choice to the
depreciated way, please tell me, I'll modify the patch the way you like
it.
Thanks,
Janusz
+ vma-vm_pgoff = 0;
+ retval = dma_mmap_coherent(q-dev, vma, mem-vaddr, mem-dma_handle,
+ mem-size);
+#else
size = vma-vm_end - vma-vm_start;
size = (size mem-size) ? size : mem-size;
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-PFN_DOWN(virt_to_phys(mem-vaddr)),
-size, vma-vm_page_prot);
+ PFN_DOWN(virt_to_phys(bus_to_virt(mem-dma_handle))),
+ size, vma-vm_page_prot);
+#endif
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
dma_free_coherent(q-dev, mem-size,
--
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
Re: mt9t111 sensor on Beagleboard xM
On Mon, 11 Apr 2011, Laurent Pinchart wrote: Hi Javier, On Monday 11 April 2011 11:11:06 javier Martin wrote: Hi Laurent, Adding pad-level operations will not break any existing driver, as long as you keep the existing operations functional. Is it really possible to have a sensor driver supporting soc-camera, v4l2-subdev and pad-level operations? Probably. Guennadi should be able to help you some more with that, he's the soc-camera expert. I'm afraid, I'm not sufficiently familiar with the (current state of) pad-level ops:-) I don't think, it is a very good idea to support two APIs in sensor drivers: pad-level for reuse with ISP and other compatible drivers and subdev / soc-camera for soc-camera hosts. I've tried pad-level ops as I played with the beagleboard-xM and an mt9p031 camera module. At that time to use the OMAP3 camera framework you had to use MC-aware applications. Standard V4L2 applications had no chance. I am not sure, whether this is a limitation of the ISP implementation or of the MC / pad APIs themselves. If this is still the case and if this backwards-compatible V4L2 mode is indeed difficult to implement with MC / pad, then soc-camera cannot migrate to that API atm. So, ideally, what should happen, I think, is the following: 1. we make sure, that the new APIs seamlessly support a classic V4L2 fallback mode. 2. migrate (respective parts of) soc-camera to pad-level 3. enable driver reuse, for which, I think, two more things will have to be done: (a) create and switch to a unified way to pass driver platform data to subdev drivers (soc-camera is currently using struct soc_camera_link for this), (b) solve the bus configuration problem. I've been reviewing the code of mt9t112 and I'm not very sure soc-camera code can be easily isolated. What is the future of soc-camera anyway? Since it seems v4l2-subdev and media-controller clearly make it deprecated. My understanding is that soc-camera will stay, but sensor drivers will likely not depend on soc-camera anymore. soc-camera will use pad-level operations, as well as a bus configuration ioctl that has been proposed on the list (but not finalized yet). Guennadi, can you share some information about this ? We want to reuse sensor drivers, yes:-) Wouldn't it be more suitable to just develop a separate mt9t112 driver which includes v4l2-subdev and pad-level operations without soc-camera? I don't think duplicate drivers will be accepted for mainline. +1 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: mt9t111 sensor on Beagleboard xM
Hi Guennadi,
On Monday 11 April 2011 14:16:49 Guennadi Liakhovetski wrote:
On Mon, 11 Apr 2011, Laurent Pinchart wrote:
On Monday 11 April 2011 11:11:06 javier Martin wrote:
Adding pad-level operations will not break any existing driver, as
long as you keep the existing operations functional.
Is it really possible to have a sensor driver supporting soc-camera,
v4l2-subdev and pad-level operations?
Probably. Guennadi should be able to help you some more with that, he's
the soc-camera expert.
I'm afraid, I'm not sufficiently familiar with the (current state of)
pad-level ops:-)
I don't think, it is a very good idea to support two APIs in sensor drivers:
pad-level for reuse with ISP and other compatible drivers and subdev / soc-
camera for soc-camera hosts.
I've tried pad-level ops as I played with the beagleboard-xM and an mt9p031
camera module. At that time to use the OMAP3 camera framework you had to use
MC-aware applications. Standard V4L2 applications had no chance. I am not
sure, whether this is a limitation of the ISP implementation or of the MC /
pad APIs themselves.
It's a limitation of the OMAP3 ISP driver. Pad-level operations are very
similar to the mbus format operations, with the major difference being that
they take an additional pad number argument.
If this is still the case and if this backwards-compatible V4L2 mode is
indeed difficult to implement with MC / pad, then soc-camera cannot migrate
to that API atm.
It's not a compatibility mode per se. The V4L2 API is implemented by the
bridge driver, no the subdevs. The bridge driver will call subdev ops. In the
OMAP3 ISP case, those subdev ops must be called by userspace, but that's
specific to the OMAP3 ISP.
So, ideally, what should happen, I think, is the following:
1. we make sure, that the new APIs seamlessly support a classic V4L2
fallback mode.
The old API is
int (*g_mbus_fmt)(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *fmt);
int (*try_mbus_fmt)(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *fmt);
int (*s_mbus_fmt)(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *fmt);
The corresponding pad-level API is
int (*get_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_format *format);
int (*set_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_format *format);
struct v4l2_subdev_format is defined as
struct v4l2_subdev_format {
__u32 which;
__u32 pad;
struct v4l2_mbus_framefmt format;
__u32 reserved[8];
};
g_mbus_fmt(fmt) and s_mbus_fmt(fmt) calls are thus translated to get_fmt(NULL,
{V4L2_SUBDEV_FORMAT_ACTIVE, 0, fmt}) and set_fmt(NULL,
{V4L2_SUBDEV_FORMAT_ACTIVE, 0, fmt}). It's quite straightforward.
try_mbus_fmt(fmt) is translated to set_fmt(fh, {V4L2_SUBDEV_FORMAT_TRY, 0,
fmt}), but the issue is that we have no file handle. We need to decide on the
best option (pass a fake fh, support it explicitly in sensor drivers, ...).
2. migrate (respective parts of) soc-camera to pad-level
3. enable driver reuse, for which, I think, two more things will have to
be done: (a) create and switch to a unified way to pass driver platform
data to subdev drivers (soc-camera is currently using struct
soc_camera_link for this), (b) solve the bus configuration problem.
Those two steps are independent of each other, and independent of 1. and 2.,
so we could start working on them now.
I've been reviewing the code of mt9t112 and I'm not very sure
soc-camera code can be easily isolated.
What is the future of soc-camera anyway? Since it seems v4l2-subdev and
media-controller clearly make it deprecated.
My understanding is that soc-camera will stay, but sensor drivers will
likely not depend on soc-camera anymore. soc-camera will use pad-level
operations, as well as a bus configuration ioctl that has been proposed
on the list (but not finalized yet). Guennadi, can you share some
information about this ?
We want to reuse sensor drivers, yes:-)
Wouldn't it be more suitable to just develop a separate mt9t112 driver
which includes v4l2-subdev and pad-level operations without soc-camera?
I don't think duplicate drivers will be accepted for mainline.
+1
--
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 1/3] v4l: add macro for 1080p59_54 preset
The 1080p59_94 is supported in latest Samusng SoC.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-common.c |1 +
include/linux/videodev2.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 06b9f9f..003e648 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -582,6 +582,7 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
{ 1920, 1080, 1080p@30 }, /* V4L2_DV_1080P30 */
{ 1920, 1080, 1080p@50 }, /* V4L2_DV_1080P50 */
{ 1920, 1080, 1080p@60 }, /* V4L2_DV_1080P60 */
+ { 1920, 1080, 1080p@59.94 }, /* V4L2_DV_1080P59_94 */
};
if (info == NULL || preset = ARRAY_SIZE(dv_presets))
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..cb0393a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -867,6 +867,7 @@ struct v4l2_dv_enum_preset {
#defineV4L2_DV_1080P30 16 /* SMPTE 296M */
#defineV4L2_DV_1080P50 17 /* BT.1120 */
#defineV4L2_DV_1080P60 18 /* BT.1120 */
+#defineV4L2_DV_1080P59_94 19
/*
* D V B T T I M I N G S
--
1.7.4.3
--
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/3] v4l: add g_tvnorms callback to V4L2 subdev
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/v4l2-subdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1562c4f..4206e97 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -261,6 +261,7 @@ struct v4l2_subdev_video_ops {
int (*s_crystal_freq)(struct v4l2_subdev *sd, u32 freq, u32 flags);
int (*s_std_output)(struct v4l2_subdev *sd, v4l2_std_id std);
int (*querystd)(struct v4l2_subdev *sd, v4l2_std_id *std);
+ int (*g_tvnorms)(struct v4l2_subdev *sd, v4l2_std_id *std);
int (*g_input_status)(struct v4l2_subdev *sd, u32 *status);
int (*s_stream)(struct v4l2_subdev *sd, int enable);
int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
--
1.7.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v3 0/3] TV driver for Samsung Exynos4 platform (media part)
Hello,
I would like to present the 3rd version of TV drivers for EXYNOS4 (former
S5PV310) platform. The most recent changes are:
1. Added SDO driver. Now analog TV is supported.
- add VIDIOC_{S/G/ENUM}_OUTPUT ioctls family
- add VIDIOC_S_STD to configure analog standard
2. Driver upgrades
- support for interlaced format on a mixer's output
- forcing YUV422 on HDMI output
- revision of perset configuration in HDMI driver
- abandoned TV platform data
- separated platform and board changes to separate patches
- new g_tvnorms callback to v4l2_subdev
- SYSMMU was substituted by the DMA-IOMMU allocator driver.
3. Plaftorm upgrades - moved to separate patch set
- fix regulators' naming and management
- add set rate for fout_vpll clock
- add phy and regulators for SDO (analog TV)
- please refer to post:
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/4604
4. Bugs and other fixes:
- fix chroma distortions in 1080p mode
- fix power management
- fix computation of plane size
- updated RFC with SDO stuff
Updated RFC for TV driver:
==
Introduction
==
The purpose of this RFC is to discuss the driver for a TV output interface
available in upcoming Samsung SoC. The HW is able to generate digital and
analog signals. Current version of the driver supports only digital output.
Internally the driver uses videobuf2 framework, and DMA-IOMMU memory allocator.
Not all of them are merged by now, but I decided to post the sources to start
discussion driver's design.
==
Hardware description
==
The SoC contains a few HW sub-blocks:
1. Video Processor (VP). It is used for processing of NV12 data. An image
stored in RAM is accessed by DMA. Pixels are cropped, scaled. Additionally,
post processing operations like brightness, sharpness and contrast adjustments
could be performed. The output in YCbCr444 format is send to Mixer.
2. Mixer (MXR). The piece of hardware responsible for mixing and blending
multiple data inputs before passing it to an output device. The MXR is capable
of handling up to three image layers. One is the output of VP. Other two are
images in RGB format (multiple variants are supported). The layers are scaled,
cropped and blended with background color. The blending factor, and layers'
priority are controlled by MXR's registers. The output is passed either to HDMI
or SDO.
3. HDMI. The piece of HW responsible for generation of HDMI packets. It takes
pixel data from mixer and transforms it into data frames. The output is send
to HDMIPHY interface.
4. HDMIPHY. Physical interface for HDMI. Its duties are sending HDMI packets to
HDMI connector. Basically, it contains a PLL that produces source clock for
Mixer, VP and HDMI during streaming.
5. SDO. Generation of TV analog signal. The alternative output for the Mixer.
It receives data and passes it to VideoDAC. The SDO is responsible for timing
generation of analog TV signal. It supports multiple standards.
6. VideoDAC. Modulator for TVOUT signal. Receives data from SDO. Converts
it to analog domain. Next, the signal is modulated to CVBS format, amplified
and sent to Comosite Connector.
The diagram below depicts connection between all HW pieces.
+---+
NV12 data ---dma---| Video |
| Processor |
+---+
|
V
+---+
RGB data ---dma---| |
| Mixer |
RGB data ---dma---| |
+---+
|
* dmux
/
+-* *--+
||
VV
+---++---+
|HDMI ||SDO|
+---++---+
||
VV
+---++---+
| HDMIPHY || VideoDAC |
+---++---+
||
VV
HDMI Composite
connector connector
==
Driver interface
==
The posted driver implements three V4L2 nodes. Every video node implements V4L2
output buffer. One of nodes corresponds to input of Video Processor. The other
two nodes correspond to RGB inputs of Mixer. All nodes share the same output.
It is one of the Mixer's outputs: SDO or HDMI. Changing output in one layer
using S_OUTPUT would change outputs of all other video nodes. The same thing
happens if one try to reconfigure output i.e. by calling S_DV_PRESET. However
it not possible to change or reconfigure the output while streaming. To sum up,
all features in posted version of driver goes as follows:
1. QUERYCAP
2. S_FMT, G_FMT - single and multiplanar API
Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia poniedziałek 11 kwiecień 2011 o 10:58:26 Guennadi Liakhovetski napisał(a): A recent patch has given individual soc-camera host drivers a possibility to calculate .sizeimage and .bytesperline pixel format fields internally, however, some drivers relied on the core calculating these values for them, following a default algorithm. This patch restores the default calculation for such drivers. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Hi Guennadi, Works for me on my OMAP1 camera (Amstrad Delta, 2.6.39-rc2). You can add my Tested-by: if you like. Thanks, Janusz -- 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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
Hi Guennadi,
On Mon, Apr 11, 2011 at 3:58 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 4628448..0918c48 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -376,6 +376,9 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
dev_dbg(icd-dev, S_FMT(%c%c%c%c, %ux%u)\n,
pixfmtstr(pix-pixelformat), pix-width, pix-height);
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
/* We always call try_fmt() before set_fmt() or set_crop() */
ret = ici-ops-try_fmt(icd, f);
if (ret 0)
@@ -391,6 +394,17 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
return -EINVAL;
}
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ ret = soc_mbus_bytes_per_line(pix-width,
+
icd-current_fmt-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
Shouldn't all this be better done in try_fmt?
Not _better_. We might choose to additionally do it for try_fmt too. But
1. we didn't do it before, applications don't seem to care.
2. you cannot store / reuse those .sizeimage .bytesperline values - this
is just a try
3. it would be a bit difficult to realise - we need a struct
soc_mbus_pixelfmt to call soc_mbus_bytes_per_line(), which we don't have,
so, we'd need to obtain it using soc_camera_xlate_by_fourcc().
This all would work, but in any case it would be an enhancement, but not a
regression fix.
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
[PATCH] v4l: Don't register media entities for subdev device nodes
Subdevs already have their own entity, don't register as second one when
registering the subdev device node.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-dev.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 498e674..6dc7196 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -389,7 +389,8 @@ static int v4l2_open(struct inode *inode, struct file *filp)
video_get(vdev);
mutex_unlock(videodev_lock);
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev) {
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV) {
entity = media_entity_get(vdev-entity);
if (!entity) {
ret = -EBUSY;
@@ -415,7 +416,8 @@ err:
/* decrease the refcount in case of an error */
if (ret) {
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev)
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV)
media_entity_put(entity);
#endif
video_put(vdev);
@@ -437,7 +439,8 @@ static int v4l2_release(struct inode *inode, struct file
*filp)
mutex_unlock(vdev-lock);
}
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev)
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV)
media_entity_put(vdev-entity);
#endif
/* decrease the refcount unconditionally since the release()
@@ -686,7 +689,8 @@ int __video_register_device(struct video_device *vdev, int
type, int nr,
#if defined(CONFIG_MEDIA_CONTROLLER)
/* Part 5: Register the entity. */
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev) {
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
vdev-entity.v4l.major = VIDEO_MAJOR;
@@ -733,7 +737,8 @@ void video_unregister_device(struct video_device *vdev)
return;
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev)
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV)
media_device_unregister_entity(vdev-entity);
#endif
--
1.7.3.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: [RFCv1 PATCH 3/9] v4l2-ioctl: add ctrl_handler to v4l2_fh
Hi Hans, On Friday 08 April 2011 17:39:01 Hans Verkuil wrote: On Friday, April 08, 2011 17:10:32 Laurent Pinchart wrote: On Monday 04 April 2011 13:51:48 Hans Verkuil wrote: From: Hans Verkuil hverk...@xs4all.nl This is required to implement control events and is also needed to allow for per-filehandle control handlers. Thanks for the patch. Shouldn't you modify v4l2-subdev.c similarly ? Good question. Does it make sense to have per-filehandle controls for a sub-device? On the other hand, does it make sense NOT to have it? Yes, I think it does. I wrote support for per-file handler controls for subdevs and submitted an RFC patch to the list some time ago to implement bandwidth managemeng in the OMAP3 ISP driver (this has been put on hold due to missing information about the OMAP3 ISP though). I'm inclined to add this functionality if nobody objects. Although a use-case for this would be nice bonus. -- 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: [RFCv1 PATCH 4/9] v4l2-ctrls: add per-control events.
Hi Hans,
Thanks for the patchset! This looks really nice!
Hans Verkuil wrote:
Whenever a control changes value an event is sent to anyone that
subscribed
to it.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 59 ++
drivers/media/video/v4l2-event.c | 126
+++---
drivers/media/video/v4l2-fh.c|4 +-
include/linux/videodev2.h| 17 +-
include/media/v4l2-ctrls.h |9 +++
include/media/v4l2-event.h |2 +
6 files changed, 177 insertions(+), 40 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c
index f75a1d4..163f412 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -23,6 +23,7 @@
#include media/v4l2-ioctl.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
#include media/v4l2-dev.h
/* Internal temporary helper struct, one for each v4l2_ext_control */
@@ -537,6 +538,16 @@ static bool type_is_int(const struct v4l2_ctrl
*ctrl)
}
}
+static void send_event(struct v4l2_ctrl *ctrl, struct v4l2_event *ev)
+{
+struct v4l2_ctrl_fh *pos;
+
+ev-id = ctrl-id;
+list_for_each_entry(pos, ctrl-fhs, node) {
+v4l2_event_queue_fh(pos-fh, ev);
+}
No need for braces here.
+}
+
/* Helper function: copy the current control value back to the caller
*/
static int cur_to_user(struct v4l2_ext_control *c,
struct v4l2_ctrl *ctrl)
@@ -626,20 +637,38 @@ static int new_to_user(struct v4l2_ext_control *c,
/* Copy the new value to the current value. */
static void new_to_cur(struct v4l2_ctrl *ctrl)
{
+struct v4l2_event ev;
+bool changed = false;
+
if (ctrl == NULL)
return;
switch (ctrl-type) {
+case V4L2_CTRL_TYPE_BUTTON:
+changed = true;
+ev.u.ctrl_ch_value.value = 0;
+break;
case V4L2_CTRL_TYPE_STRING:
/* strings are always 0-terminated */
+changed = strcmp(ctrl-string, ctrl-cur.string);
strcpy(ctrl-cur.string, ctrl-string);
+ev.u.ctrl_ch_value.value64 = 0;
break;
case V4L2_CTRL_TYPE_INTEGER64:
+changed = ctrl-val64 != ctrl-cur.val64;
ctrl-cur.val64 = ctrl-val64;
+ev.u.ctrl_ch_value.value64 = ctrl-val64;
break;
default:
+changed = ctrl-val != ctrl-cur.val;
ctrl-cur.val = ctrl-val;
+ev.u.ctrl_ch_value.value = ctrl-val;
break;
}
+if (changed) {
+ev.type = V4L2_EVENT_CTRL_CH_VALUE;
+ev.u.ctrl_ch_value.type = ctrl-type;
+send_event(ctrl, ev);
+}
}
/* Copy the current value to the new value */
@@ -784,6 +813,7 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler
*hdl)
{
struct v4l2_ctrl_ref *ref, *next_ref;
struct v4l2_ctrl *ctrl, *next_ctrl;
+struct v4l2_ctrl_fh *ctrl_fh, *next_ctrl_fh;
if (hdl == NULL || hdl-buckets == NULL)
return;
@@ -797,6 +827,10 @@ void v4l2_ctrl_handler_free(struct
v4l2_ctrl_handler *hdl)
/* Free all controls owned by the handler */
list_for_each_entry_safe(ctrl, next_ctrl, hdl-ctrls, node) {
list_del(ctrl-node);
+list_for_each_entry_safe(ctrl_fh, next_ctrl_fh, ctrl-fhs,
node) {
+list_del(ctrl_fh-node);
+kfree(ctrl_fh);
+}
kfree(ctrl);
}
kfree(hdl-buckets);
@@ -1003,6 +1037,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
}
INIT_LIST_HEAD(ctrl-node);
+INIT_LIST_HEAD(ctrl-fhs);
ctrl-handler = hdl;
ctrl-ops = ops;
ctrl-id = id;
@@ -1888,3 +1923,27 @@ int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32
val)
return set_ctrl(ctrl, val);
}
EXPORT_SYMBOL(v4l2_ctrl_s_ctrl);
+
+void v4l2_ctrl_add_fh(struct v4l2_ctrl *ctrl, struct v4l2_ctrl_fh
*ctrl_fh)
+{
+v4l2_ctrl_lock(ctrl);
+list_add_tail(ctrl_fh-node, ctrl-fhs);
+v4l2_ctrl_unlock(ctrl);
+}
+EXPORT_SYMBOL(v4l2_ctrl_add_fh);
+
+void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct v4l2_fh *fh)
+{
+struct v4l2_ctrl_fh *pos;
+
+v4l2_ctrl_lock(ctrl);
+list_for_each_entry(pos, ctrl-fhs, node) {
+if (pos-fh == fh) {
+list_del(pos-node);
+kfree(pos);
+break;
+}
+}
+v4l2_ctrl_unlock(ctrl);
+}
+EXPORT_SYMBOL(v4l2_ctrl_del_fh);
diff --git a/drivers/media/video/v4l2-event.c
b/drivers/media/video/v4l2-event.c
index 69fd343..c9251a5 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -25,10 +25,13 @@
#include media/v4l2-dev.h
#include media/v4l2-fh.h
#include
Re: [RFC v2] V4L2 API for flash devices
Hi Sakari,
On Saturday 09 April 2011 18:17:34 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Wednesday 06 April 2011 11:25:56 Sakari Ailus wrote:
Nayden Kanchev wrote:
On 04/06/2011 11:10 AM, Sakari Ailus wrote:
- Added an open question on a new control:
V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE.
snip
2. External strobe edge / level
---
No use is seen currently for this, but it may well appear, and the
hardware supports this. Level based trigger should be used since it is
more precise.
V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE
Whether the flash controller considers external strobe as edge, when
the only limit of the strobe is the timeout on flash controller, or
level, when the flash strobe will last as long as the strobe signal,
or as long until the timeout expires.
enum v4l2_flash_external_strobe_whence {
V4L2_CID_FLASH_EXTERNAL_STROBE_LEVEL,
V4L2_CID_FLASH_EXTERNAL_STROBE_EDGE,
};
Removed CID_:
enum v4l2_flash_external_strobe_whence {
V4L2_FLASH_EXTERNAL_STROBE_LEVEL,
V4L2_FLASH_EXTERNAL_STROBE_EDGE,
};
I guess this should be an rw menu control for LED flash?
I agree that control over the strobe usage (level/edge) is required.
Although we have some bad experience will lack of detailed information
how exactly the flash chip will use those signals.
For example with AS3645A flash driver strobing by edge produced really
strange flash output - light intensity was changing during the process
and flash was stopped before the HW timeout.
On the other hand strobing by level didn't cause problems.
So even if HW supports some functionally we should prevent such
malfunctioning by adding some restrictions in the board code also.
I agree.
The control should be probably exposed to tell which kind of
functionality does the flash chip provide, even if the menu has just one
option in it.
I would also rename xxx_STROBE_WHENCE to xxx_STROBE_TYPE but it is just
a suggestion :)
Sounds good to me.
V4L2_CID_FLASH_STROBE_MODE should be renamed to
V4L2_CID_FLASH_STROBE_WHENCE. That proper use of whence IMO. :-)
Does this really need to be exposed to userspace ? Shouldn't it just be
static information coming from platform data ?
If the sensor is expected to set the strobe length, the value needs to
be programmed to the sensor. The sensor driver should be able to do this
as it has all the timing related information on the sensor state.
What if the user wants to expose more than one frame with flash?
The sensor should be able to export the total required exposure time of
the full frame. The exposure of each line begins at different time so
the exposure time of the full frame exceeds the exposure time of a
single pixel --- it may be almost double.
The user must be able to know that the exposure time required to expose
the frame is smaller or equal to the maximum possible exposure time of
the flash.
I think I now understand your point. You want to let the user select between a
sensor-controlled duration and a user-controlled duration. Is that correct ?
In that case I would rename the control to make that more explicit. Edge/level
triggers sound like something that should be hidden from the user and handled
in the drivers, with help from platform data and board code.
To the user there is no significant difference between the two. There
may be effects on the following frames beyond the one(s) exposed with
flash.
I agree we could omit this, at least for now.
--
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 2.6.39] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Mon 11 Apr 2011 at 02:42:13 Mauro Carvalho Chehab wrote: Em 10-04-2011 19:47, Janusz Krzysztofik escreveu: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig stopped working on my ARM based board. The ARM architecture maintainer, Russell King, confirmed that using something like virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be broken on other architectures as well. The author of the change, Jiri Slaby, also confirmed that his code may not work on all architectures. The patch takes two different countermeasures against this regression: 1. On architectures which provide dma_mmap_coherent() function (ARM for now), use it instead of just remap_pfn_range(). The code is stollen from sound/core/pcm_native.c:snd_pcm_default_mmap(). Set vma-vm_pgoff to 0 before calling dma_mmap_coherent(), or it fails. 2. On other architectures, use virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). This should work even if those translations would occure inaccurate for DMA addresses, since possible errors introduced by both calculations, performed in opposite directions, should compensate. Both solutions tested on ARM OMAP1 based Amstrad Delta board. ... The code is saying that dma_mmap_coherent should be used only on ARM and PPC architectures, and remap_pfn_range should be used otherwise. Are you sure that this will work on the other architectures? I really prefer to have one standard way for doing it, that would be architecture-independent. Media drivers or core should not have arch-dependent code inside. More looking at this and making more tests, I found that the dma_mmap_coherent() method, working correctly on OMAP1 which has no countermeasures against unpredictable dma_alloc_coherent() runtime behaviour implemented, may not be compatible with all those dma_declare_coherent_memory() and alike workarounds, still being used, more or less successfully, on other ARM platforms/machines/boards. Under such circumstances, I'd opt for choosing the depreciated, but hopefully working, bi-directional translation method, ie. virt_to_phys(bus_to_virt(mem-dma_handle)), as the regression fix. Thanks, Janusz -- 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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Hi Guennadi,
On Mon, Apr 11, 2011 at 8:23 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
Hi Guennadi,
On Mon, Apr 11, 2011 at 3:58 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 4628448..0918c48 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -376,6 +376,9 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
dev_dbg(icd-dev, S_FMT(%c%c%c%c, %ux%u)\n,
pixfmtstr(pix-pixelformat), pix-width, pix-height);
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
/* We always call try_fmt() before set_fmt() or set_crop() */
ret = ici-ops-try_fmt(icd, f);
if (ret 0)
@@ -391,6 +394,17 @@ static int soc_camera_set_fmt(struct
soc_camera_device
*icd,
return -EINVAL;
}
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ ret = soc_mbus_bytes_per_line(pix-width,
+
icd-current_fmt-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
Shouldn't all this be better done in try_fmt?
Not _better_. We might choose to additionally do it for try_fmt too. But
1. we didn't do it before, applications don't seem to care.
2. you cannot store / reuse those .sizeimage .bytesperline values - this
is just a try
3. it would be a bit difficult to realise - we need a struct
soc_mbus_pixelfmt to call soc_mbus_bytes_per_line(), which we don't have,
so, we'd need to obtain it using soc_camera_xlate_by_fourcc().
This all would work, but in any case it would be an enhancement, but not a
regression fix.
Ok. And how about the attached patch? Would that work?
Regards,
Sergio
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
From 5442074c7760429c06f62917503c1d8a2f79cd21 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Based on initial patch by Guennadi Liakhovetski, found here:
http://www.spinics.net/lists/linux-media/msg31282.html
Except that this covers try_fmt aswell.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c | 41 -
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..875842a 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,6 +136,43 @@ unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
}
EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+ struct v4l2_format *f)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct v4l2_pix_format *pix = f-fmt.pix;
+ int ret;
+
+ dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+ pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
+ ret = ici-ops-try_fmt(icd, f);
+ if (ret 0)
+ return ret;
+
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ const struct soc_camera_format_xlate *xlate;
+
+ xlate = soc_camera_xlate_by_fourcc(icd, pix-pixelformat);
+ if (!xlate)
+return -EINVAL;
+
+ ret = soc_mbus_bytes_per_line(pix-width,
+ xlate-host_fmt);
+ if (ret 0)
+pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
+ return 0;
+}
+
static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
@@ -149,7 +186,7 @@ static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
return -EINVAL;
/* limit format to hardware capabilities */
- return
Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Sun, 10 Apr 2011, Andy Walls wrote: On Wed, 2011-04-06 at 13:28 -0400, Eric B Munson wrote: On Tue, Apr 5, 2011 at 10:58 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 14:36 -0400, Eric B Munson wrote: On Mon, Apr 4, 2011 at 11:16 AM, Eric B Munson emun...@mgebm.net wrote: On Mon, Apr 4, 2011 at 9:12 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 08:20 -0400, Eric B Munson wrote: I the above mentioned capture card and the digital side of the card works well. However, when I try to get video from the analog side of the card, all I get is a red screen and no sound regardless of channel requested. This is a problem I see in 2.6.39-rc1 though I typically run the ubuntu 10.10 kernel with the newest drivers built from source. Is there something in setup or configuration that I may be missing? Eric, You are likely missing the last 3 fixes here: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/cx18_39 (one of which is critical for analog to work). Also check the ivtv-users and ivtv-devel list for past discussions on the red screen showing up for known well supported models and what to try. Thanks, I will try hand applying these. I don't have a red screen anymore, now all get from analog static and mythtv's digital channel scanner now seems broken. Hmmm. 1. Please provide the output of dmesg when the cx18 driver loads. [332935.115343] cx18: Start initialization, version 1.4.1 [332935.115385] cx18-0: Initializing card 0 [332935.115389] cx18-0: Autodetected Hauppauge card [332935.115449] cx18 :04:01.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [332935.127005] cx18-0: cx23418 revision 0101 (B) [332935.342426] tveeprom 0-0050: Hauppauge model 74351, rev F1F5, serial# 7384278 [332935.342432] tveeprom 0-0050: MAC address is 00:0d:fe:70:ac:d6 [332935.342437] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54) [332935.342443] tveeprom 0-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) [332935.342448] tveeprom 0-0050: audio processor is CX23418 (idx 38) [332935.342453] tveeprom 0-0050: decoder processor is CX23418 (idx 31) [332935.342457] tveeprom 0-0050: has no radio [332935.342460] cx18-0: Autodetected Hauppauge HVR-1600 [332935.392016] cx18-0: Simultaneous Digital and Analog TV capture supported [332935.497007] tuner 1-0042: Tuner -1 found with type(s) Radio TV. [332935.501259] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [332935.548567] tda829x 1-0042: setting tuner address to 60 [332935.572554] tda18271 1-0060: creating new instance [332935.612568] TDA18271HD/C2 detected @ 1-0060 [332936.676587] tda18271: performing RF tracking filter calibration [332950.816567] tda18271: RF tracking filter calibration complete [332950.864571] tda829x 1-0042: type set to tda8295+18271 [332951.569137] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB) [332951.569143] DVB: registering new adapter (cx18) [332951.672187] tda18271 0-0060: creating new instance [332951.678691] TDA18271HD/C2 detected @ 0-0060 [332951.737797] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) [332951.876157] cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 bytes) [332951.882195] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) [332951.984040] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [332951.984208] cx18-0: DVB Frontend registered [332951.984214] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB) [332951.984268] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB) [332951.984320] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes) [332951.984367] cx18-0: Registered device video24 for encoder PCM audio (256 x 4.00 kB) [332951.984372] cx18-0: Initialized card: Hauppauge HVR-1600 [332951.984415] cx18: End initialization [332951.994916] cx18-alsa: module loading... [332952.733994] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes) [332952.753703] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes) 3. Please provide the relevant portion of the mythbackend log where where the digital scanner starts and then fails. So the Digital scanner doesn't fail per se, it just doesn't pick up most of the digital channels available. The same is true of scan, it seems to find only 1 channel when I know that I have access to 18. Make sure it's not a signal integrity problem: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality wild speculation: If the analog tuner driver init failed, maybe that is having some bad EMI efect on the digital tuner I'm assumiong you got more than the 1 channel before trying to enable analog tuning.A That is true, when I was running the backported drivers on the Ubuntu 10.10
Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, Apr 11, 2011 at 12:32 PM, Eric B Munson emun...@mgebm.net wrote: Can you tune to other known digital channels? I will have to see if I can set one up by hand and try it. I will get back to you when I am able to do this (should be later today). Let me know if you need anything else. Are you tuning digital cable (North American QAM) or digital Over The Air (ATSC)? I am using digital cable (NA QAM). This is going to seem a little nuts, but just as a test could you try sticking the card into a different machine (with a different motherboard)? I heard something a few months ago about an issue related to the power sequencing that only occurred with a specific motherboard. Using any other motherboard resulted in success. It would be useful if we could rule that out. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, Apr 11, 2011 at 12:42 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Apr 11, 2011 at 12:32 PM, Eric B Munson emun...@mgebm.net wrote: Can you tune to other known digital channels? I will have to see if I can set one up by hand and try it. I will get back to you when I am able to do this (should be later today). Let me know if you need anything else. Are you tuning digital cable (North American QAM) or digital Over The Air (ATSC)? I am using digital cable (NA QAM). This is going to seem a little nuts, but just as a test could you try sticking the card into a different machine (with a different motherboard)? I heard something a few months ago about an issue related to the power sequencing that only occurred with a specific motherboard. Using any other motherboard resulted in success. It would be useful if we could rule that out. Devin This will be a little more difficult, I should be able to make it happen this week though. -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
Hi Guennadi,
On Mon, Apr 11, 2011 at 8:23 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
Hi Guennadi,
On Mon, Apr 11, 2011 at 3:58 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
A recent patch has given individual soc-camera host drivers a
possibility
to calculate .sizeimage and .bytesperline pixel format fields
internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 4628448..0918c48 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -376,6 +376,9 @@ static int soc_camera_set_fmt(struct
soc_camera_device
*icd,
dev_dbg(icd-dev, S_FMT(%c%c%c%c, %ux%u)\n,
pixfmtstr(pix-pixelformat), pix-width, pix-height);
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
/* We always call try_fmt() before set_fmt() or set_crop() */
ret = ici-ops-try_fmt(icd, f);
if (ret 0)
@@ -391,6 +394,17 @@ static int soc_camera_set_fmt(struct
soc_camera_device
*icd,
return -EINVAL;
}
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ ret = soc_mbus_bytes_per_line(pix-width,
+
icd-current_fmt-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline *
pix-height;
+ }
+
Shouldn't all this be better done in try_fmt?
Not _better_. We might choose to additionally do it for try_fmt too. But
1. we didn't do it before, applications don't seem to care.
2. you cannot store / reuse those .sizeimage .bytesperline values - this
is just a try
3. it would be a bit difficult to realise - we need a struct
soc_mbus_pixelfmt to call soc_mbus_bytes_per_line(), which we don't have,
so, we'd need to obtain it using soc_camera_xlate_by_fourcc().
This all would work, but in any case it would be an enhancement, but not a
regression fix.
Ok. And how about the attached patch? Would that work?
Please, post patches inline.
Yes, I think, ot would work too, only the call to
soc_camera_xlate_by_fourcc() in the S_FMT case is superfluous, after
ici-ops-set_fmt() we already have it in icd-current_fmt-host_fmt.
Otherwise - yes, we could do it this way too. Janusz, could you test,
please?
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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
On Mon, Apr 11, 2011 at 11:58 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
Hi Guennadi,
On Mon, Apr 11, 2011 at 8:23 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
Hi Guennadi,
On Mon, Apr 11, 2011 at 3:58 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
A recent patch has given individual soc-camera host drivers a
possibility
to calculate .sizeimage and .bytesperline pixel format fields
internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 4628448..0918c48 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -376,6 +376,9 @@ static int soc_camera_set_fmt(struct
soc_camera_device
*icd,
dev_dbg(icd-dev, S_FMT(%c%c%c%c, %ux%u)\n,
pixfmtstr(pix-pixelformat), pix-width, pix-height);
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
/* We always call try_fmt() before set_fmt() or set_crop() */
ret = ici-ops-try_fmt(icd, f);
if (ret 0)
@@ -391,6 +394,17 @@ static int soc_camera_set_fmt(struct
soc_camera_device
*icd,
return -EINVAL;
}
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ ret = soc_mbus_bytes_per_line(pix-width,
+
icd-current_fmt-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline *
pix-height;
+ }
+
Shouldn't all this be better done in try_fmt?
Not _better_. We might choose to additionally do it for try_fmt too. But
1. we didn't do it before, applications don't seem to care.
2. you cannot store / reuse those .sizeimage .bytesperline values - this
is just a try
3. it would be a bit difficult to realise - we need a struct
soc_mbus_pixelfmt to call soc_mbus_bytes_per_line(), which we don't have,
so, we'd need to obtain it using soc_camera_xlate_by_fourcc().
This all would work, but in any case it would be an enhancement, but not a
regression fix.
Ok. And how about the attached patch? Would that work?
Please, post patches inline.
Ok, sorry.
Yes, I think, ot would work too, only the call to
soc_camera_xlate_by_fourcc() in the S_FMT case is superfluous, after
ici-ops-set_fmt() we already have it in icd-current_fmt-host_fmt.
Well, the difference is that, after my patch, this is called after
ici-ops-try_fmt, so
icd-current_fmt-host_fmt doesn't match the intended format to try, as it's not
stored as a current_fmt.
Unless i'm getting confused with something...
Regards,
Sergio
Otherwise - yes, we could do it this way too. Janusz, could you test,
please?
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: dvb-apps: charset support
Hi Mauro,
I added some patches to dvb-apps/util/scan.c in order to properly support
EN 300 468 charsets.
Before the patch, scan were producing invalid UTF-8 codes here, for
ISO-8859-15 charsets, as
scan were simply filling service/provider name with whatever non-control
characters that were
there. So, if your computer uses the same character as your service
provider, you're lucky.
Otherwise, invalid characters will appear at the scan tables.
After the changes, scan gets the locale environment charset, and use it as
the output charset
on the output files.
This implementation in scan expects the environment settings to be
'language_country.encoding', but i think the more general way is
'language_country.encoding@variant'.
i get the following error from scan, because iconv doesnt know
'ISO-8859-15@euro'.
snip
WARNING: Conversion from ISO-8859-9 to ISO-8859-15@euro not supported
WARNING: Conversion from ISO-8859-9 to ISO-8859-15@euro not supported
...
WARNING: Conversion from ISO-8859-15 to ISO-8859-15@euro not supported
WARNING: Conversion from ISO-8859-15 to ISO-8859-15@euro not supported
/snap
I suggest to change scan.c as follows:
--- dvb-apps-5e68946b0e0d_orig/util/scan/scan.c 2011-04-10 20:22:52.0
+0200
+++ dvb-apps-5e68946b0e0d/util/scan/scan.c 2011-04-11 19:41:21.46060
+0200
@@ -2570,14 +2570,14 @@
if ((charset = getenv(LC_ALL)) ||
(charset = getenv(LC_CTYPE)) ||
(charset = getenv (LANG))) {
- while (*charset != '.' *charset)
- charset++;
- if (*charset == '.')
- charset++;
- if (*charset)
- output_charset = charset;
- else
- output_charset = nl_langinfo(CODESET);
+ // assuming 'language_country.encoding@variant'
+ char * p;
+
+ if ((p = strchr(charset, '.')))
+ charset = p + 1;
+ if ((p = strchr(charset, '@')))
+ *p = 0;
+ output_charset = charset;
} else
output_charset = nl_langinfo(CODESET);
This cuts the '@variant' part from charset, so that iconv will find its way.
cheers,
Winfried
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
--
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: dvb-apps: charset support
Em 11-04-2011 14:48, handygewinnsp...@gmx.de escreveu:
Hi Mauro,
I added some patches to dvb-apps/util/scan.c in order to properly support
EN 300 468 charsets.
Before the patch, scan were producing invalid UTF-8 codes here, for
ISO-8859-15 charsets, as
scan were simply filling service/provider name with whatever non-control
characters that were
there. So, if your computer uses the same character as your service
provider, you're lucky.
Otherwise, invalid characters will appear at the scan tables.
After the changes, scan gets the locale environment charset, and use it as
the output charset
on the output files.
This implementation in scan expects the environment settings to be
'language_country.encoding', but i think the more general way is
'language_country.encoding@variant'.
i get the following error from scan, because iconv doesnt know
'ISO-8859-15@euro'.
Ah, ok. I never saw such syntax. Thanks for pinging me about that!
snip
WARNING: Conversion from ISO-8859-9 to ISO-8859-15@euro not supported
WARNING: Conversion from ISO-8859-9 to ISO-8859-15@euro not supported
...
WARNING: Conversion from ISO-8859-15 to ISO-8859-15@euro not supported
WARNING: Conversion from ISO-8859-15 to ISO-8859-15@euro not supported
/snap
I suggest to change scan.c as follows:
--- dvb-apps-5e68946b0e0d_orig/util/scan/scan.c 2011-04-10 20:22:52.0
+0200
+++ dvb-apps-5e68946b0e0d/util/scan/scan.c 2011-04-11 19:41:21.46060
+0200
@@ -2570,14 +2570,14 @@
if ((charset = getenv(LC_ALL)) ||
(charset = getenv(LC_CTYPE)) ||
(charset = getenv (LANG))) {
- while (*charset != '.' *charset)
- charset++;
- if (*charset == '.')
- charset++;
- if (*charset)
- output_charset = charset;
- else
- output_charset = nl_langinfo(CODESET);
+ // assuming 'language_country.encoding@variant'
+ char * p;
+
+ if ((p = strchr(charset, '.')))
+ charset = p + 1;
+ if ((p = strchr(charset, '@')))
+ *p = 0;
+ output_charset = charset;
This will fail if LANG=C
Basically, if charset doesn't contain '.', this block should not set
output_charset.
} else
output_charset = nl_langinfo(CODESET);
This cuts the '@variant' part from charset, so that iconv will find its way.
cheers,
Winfried
--
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] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Apr 11 19:00:29 CEST 2011 git hash:d9954d8547181f9a6a23f835cc1413732700b785 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Sun, 10 Apr 2011, Andy Walls wrote: 3. Please provide the relevant portion of the mythbackend log where where the digital scanner starts and then fails. So the Digital scanner doesn't fail per se, it just doesn't pick up most of the digital channels available. The same is true of scan, it seems to find only 1 channel when I know that I have access to 18. Make sure it's not a signal integrity problem: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality wild speculation: If the analog tuner driver init failed, maybe that is having some bad EMI efect on the digital tuner I'm assumiong you got more than the 1 channel before trying to enable analog tuning. I don't think there is a digital problem after all, the scanner doesn't seem to be picking up all the channels (meaning there were entries for most, but much off the data about the channel was missing in channels.conf). When I hand add the 2 that were missing and fill in the rest of the missing data, all of it works. I can tune to any of the listed channels and watch them with mplayer. I am going to take the digital TV side up with the MythTV folks. signature.asc Description: Digital signature
Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia poniedziałek 11 kwiecień 2011 o 18:58:51 Guennadi Liakhovetski napisał(a): On Mon, 11 Apr 2011, Aguirre, Sergio wrote: Ok. And how about the attached patch? Would that work? Yes, I think, ot would work too, only the call to soc_camera_xlate_by_fourcc() in the S_FMT case is superfluous, after ici-ops-set_fmt() we already have it in icd-current_fmt-host_fmt. Otherwise - yes, we could do it this way too. Janusz, could you test, please? Looks like not based on the current mainline (-rc2) tree: CHECK drivers/media/video/soc_camera.c drivers/media/video/soc_camera.c:146:9: error: undefined identifier 'pixfmtstr' CC drivers/media/video/soc_camera.o drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt': drivers/media/video/soc_camera.c:146: error: implicit declaration of function 'pixfmtstr' drivers/media/video/soc_camera.c:146: warning: too few arguments for format drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt_vid_cap': drivers/media/video/soc_camera.c:180: warning: unused variable 'ici' Thanks, Janusz -- 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: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, Apr 11, 2011 at 3:29 PM, Eric B Munson emun...@mgebm.net wrote: On Mon, 11 Apr 2011, Devin Heitmueller wrote: On Mon, Apr 11, 2011 at 3:24 PM, Eric B Munson emun...@mgebm.net wrote: I mean the /usr/bin/scan tool. Most of the channels seem to be missing the EIT information and two channels were missing completely. The two missing channels could be a result of poor signal quality (the wiring here is not the best but as it is university housing there isn't much I can do). Wait a second: you're on ClearQAM, right? You're lucky if you are receiving any EIT data at all. Many cable providers strip out the PSIP info on ClearQAM broadcasts, and non-OTA equivalent stations are unlikely to have any PSIP data at all (the ATSC A/65c spec provides the capability, but cable settop boxes typically use an out-of-band tuner instead). Are you comparing the tuning results against some other tuner product? Or is this based entirely on what you know should be there in terms of the scan results? I just must be lucky for the one channel that gets it. I am comparing the list to what I know should be there, not the output of someother product. Adding linux-media back onto the cc: as I did not intend to remove it (and the information could be useful for others participating on the thread). Indeed, it's entirely likely that the channels.conf will contain just a frequency and video/audio pids, while not containing any of the identifying information for the channel such as the callsign. Also, you will likely also get encrypted channels in your results, so you will try to tune, it will lock successfully, but then mplayer won't show you video on any of the PIDs. We really should add some additional logic to /usr/bin/scan to filter out encrypted channels (or at least put something in the name that makes it clear they aren't going to work). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
On Mon, Apr 11, 2011 at 1:40 PM, Janusz Krzysztofik
jkrzy...@tis.icnet.pl wrote:
Dnia poniedziałek 11 kwiecień 2011 o 18:58:51 Guennadi Liakhovetski
napisał(a):
On Mon, 11 Apr 2011, Aguirre, Sergio wrote:
Ok. And how about the attached patch? Would that work?
Yes, I think, ot would work too, only the call to
soc_camera_xlate_by_fourcc() in the S_FMT case is superfluous, after
ici-ops-set_fmt() we already have it in icd-current_fmt-host_fmt.
Otherwise - yes, we could do it this way too. Janusz, could you test,
please?
Looks like not based on the current mainline (-rc2) tree:
CHECK drivers/media/video/soc_camera.c
drivers/media/video/soc_camera.c:146:9: error: undefined identifier
'pixfmtstr'
CC drivers/media/video/soc_camera.o
drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt':
drivers/media/video/soc_camera.c:146: error: implicit declaration of function
'pixfmtstr'
drivers/media/video/soc_camera.c:146: warning: too few arguments for format
drivers/media/video/soc_camera.c: In function 'soc_camera_try_fmt_vid_cap':
drivers/media/video/soc_camera.c:180: warning: unused variable 'ici'
Oops, my bad.
Please find below a refreshed patch, which should be based on mainline commit:
b42282e pci: fix PCI bus allocation alignment handling
Thanks,
Janusz
From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage
in soc_camera.c
A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Based on initial patch by Guennadi Liakhovetski, found here:
http://www.spinics.net/lists/linux-media/msg31282.html
Except that this covers try_fmt aswell.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c | 48 +
1 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..dcc6623 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,11 +136,50 @@ unsigned long
soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
}
EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
+#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16) 0xff, \
+ ((x) 24) 0xff
+
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+ struct v4l2_format *f)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct v4l2_pix_format *pix = f-fmt.pix;
+ int ret;
+
+ dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+ pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
+ ret = ici-ops-try_fmt(icd, f);
+ if (ret 0)
+ return ret;
+
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ const struct soc_camera_format_xlate *xlate;
+
+ xlate = soc_camera_xlate_by_fourcc(icd,
pix-pixelformat);
+ if (!xlate)
+ return -EINVAL;
+
+ ret = soc_mbus_bytes_per_line(pix-width,
+ xlate-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
+ return 0;
+}
+
static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct soc_camera_device *icd = file-private_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
WARN_ON(priv != file-private_data);
@@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file
*file, void *priv,
return -EINVAL;
/* limit format to hardware capabilities */
- return ici-ops-try_fmt(icd, f);
+ return soc_camera_try_fmt(icd, f);
}
static int soc_camera_enum_input(struct file *file, void *priv,
@@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct
soc_camera_device *icd)
icd-user_formats = NULL;
}
-#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16) 0xff, \
- ((x) 24) 0xff
-
/* Called with .vb_lock held, or from the first open(2), see comment there */
static int soc_camera_set_fmt(struct soc_camera_device *icd,
struct v4l2_format *f)
@@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct
Re: [PATCH] libv4lconvert-priv.h: indent with tabs, not spaces
Thanks, applied. On 04/07/2011 05:57 PM, Antonio Ospite wrote: Indent wrapped lines with tabs, just like it is done for the other functions in the same file. Signed-off-by: Antonio Ospiteosp...@studenti.unina.it --- lib/libv4lconvert/libv4lconvert-priv.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/libv4lconvert/libv4lconvert-priv.h b/lib/libv4lconvert/libv4lconvert-priv.h index 30d1cfe..84c706e 100644 --- a/lib/libv4lconvert/libv4lconvert-priv.h +++ b/lib/libv4lconvert/libv4lconvert-priv.h @@ -131,7 +131,7 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest, int width, int height); void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest, -const struct v4l2_format *src_fmt); + const struct v4l2_format *src_fmt); void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest, int width, int height); -- 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] libv4lconvert: Add support for Y10B grey format (V4L2_PIX_FMT_Y10BPACK)
Hi,
On 04/07/2011 06:16 PM, Antonio Ospite wrote:
Y10B is a 10 bits per pixel greyscale format in a bit-packed array
representation. Such pixel format is supplied for instance by the Kinect
sensor device.
Signed-off-by: Antonio Ospiteosp...@studenti.unina.it
---
Hi,
this is a very first attempt about supporting Y10B in libv4lconvert, the
doubts I have are about the conversion routines which need to unpack a frame
before doing the actual pixelformat conversion, and maybe this can be handled
in some conversion layer in libv4l.
I don't know libv4l yet, so I am asking for advice providing some code to
discuss on; looking at the last hunk of the patch: can I allocate a temporary
buffer only once per device (and not per frame as I am horribly doing now) and
reuse it in the conversion routines?
libv4l has a mechanism for doing this, you can simply do:
unpacked_buffer = v4lconvert_alloc_buffer(width * height * sizeof(unsigned
short),
data-convert_pixfmt_buf,
data-convert_pixfmt_buf_size);
v4lconvert_alloc_buffer will remember the buffer (and its size) and return the
same buffer each call. Freeing it on closing of the device is also taken care
of. You should still check for a NULL return.
What has me worried more, is how libv4l will decide between asking
Y10B grey versus raw bayer from the device when an app is asking for say RGB24.
libv4l normally does this automatically on a best match basis (together with
preferring compressed formats over uncompressed for high resolutions). But this
won't work in the kinect case. If we prioritize one over the other we will
always end up giving the app the one we prioritize.
The only thing I can think of is adding a v4l2 control (like a brightness
control) for choosing which format to prioritize...
Suggestions ?
Regards,
Hans
Or is the unpacking better be done even
before conversion, feeding the conversion routines with already unpacked
buffers?
Thanks,
Antonio Ospite
http://ao2.it
include/linux/videodev2.h |3 +
lib/libv4lconvert/libv4lconvert-priv.h |6 +++
lib/libv4lconvert/libv4lconvert.c | 20
lib/libv4lconvert/rgbyuv.c | 76
4 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 51788a6..559d5f3 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -289,6 +289,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale
*/
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
+/* Grey bit-packed formats */
+#define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10
Greyscale bit-packed */
+
/* Palette formats */
#define V4L2_PIX_FMT_PAL8v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit
palette */
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 84c706e..470a869 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -133,6 +133,12 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_y10b_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_y10b_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt);
+
void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index e4863fd..631d912 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -48,6 +48,7 @@ static const struct v4lconvert_pixfmt supported_src_pixfmts[]
= {
{ V4L2_PIX_FMT_YVYU, 0 },
{ V4L2_PIX_FMT_UYVY, 0 },
{ V4L2_PIX_FMT_RGB565, 0 },
+ { V4L2_PIX_FMT_Y10BPACK, 0 },
{ V4L2_PIX_FMT_SN9C20X_I420, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SBGGR8, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SGBRG8, V4LCONVERT_NEEDS_CONVERSION },
@@ -862,6 +863,25 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
result = -1;
}
break;
+
+ case V4L2_PIX_FMT_Y10BPACK:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_y10b_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+
Re: [stable] [PATCH] media/radio/wl1273: fix build errors
On Thu, Mar 31, 2011 at 08:09:57PM -0400, Mike Frysinger wrote: On Sun, Feb 27, 2011 at 12:51, Randy Dunlap wrote: From: Randy Dunlap randy.dun...@oracle.com RADIO_WL1273 needs to make sure that the mfd core is built to avoid build errors: ERROR: mfd_add_devices [drivers/mfd/wl1273-core.ko] undefined! ERROR: mfd_remove_devices [drivers/mfd/wl1273-core.ko] undefined! 2.6.38 stable worthy ? now in mainline as 1b149bbe9156d2eb2afd5a072bd61ad0d4bfaca7 ... Now queued up, 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
Re: [PATCH] tm6000: fix vbuf may be used uninitialized
On Mar 24, 2011, at 6:05 PM, Jarod Wilson wrote: On Thu, Mar 24, 2011 at 11:31:08PM +0300, Dan Carpenter wrote: On Thu, Mar 24, 2011 at 04:07:00PM -0400, Jarod Wilson wrote: Signed-off-by: Jarod Wilson ja...@redhat.com Jarod, there is a lot of information missing from your change log... :/ Hrm, I'm building the media stack with all warnings fatal, so this was just a quick fix to silence the compiler warning, didn't really look into it at all. CC: de...@driverdev.osuosl.org --- drivers/staging/tm6000/tm6000-video.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c index c80a316..bfebedd 100644 --- a/drivers/staging/tm6000/tm6000-video.c +++ b/drivers/staging/tm6000/tm6000-video.c @@ -228,7 +228,7 @@ static int copy_streams(u8 *data, unsigned long len, unsigned long header = 0; int rc = 0; unsigned int cmd, cpysize, pktsize, size, field, block, line, pos = 0; - struct tm6000_buffer *vbuf; + struct tm6000_buffer *vbuf = NULL; char *voutp = NULL; unsigned int linewidth; This looks like a real bug versus just a GCC warning. It was introduced in 8aff8ba95155df [media] tm6000: add radio support to the driver. I've added Dmitri to the CC list. Thanks much, will try to pay more attention next time. ;) So I was just circling back around on this one, and took some time to read the actual code and the radio support addition. After doing so, I don't see why the patch I proposed wouldn't do. The buffer is only manipulated if !dev-radio or if vbuf is non-NULL (the memcpy call). If its initialized to NULL, it only gets used exactly as it did before 8aff8ba9 when !dev-radio, and if its not been used or its NULL following manipulations protected by !dev-radio, it doesn't get copied. What is the real bug I am missing there? (Or did I already miss a patch posted to linux-media addressing it?) Thanks much, -- Jarod Wilson ja...@wilsonet.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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio
napisał(a):
Please find below a refreshed patch, which should be based on
mainline commit:
Hi,
This version works for me, and fixes the regression.
Thanks,
Janusz
From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00
2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate
.sizeimage in soc_camera.c
A recent patch has given individual soc-camera host drivers a
possibility to calculate .sizeimage and .bytesperline pixel format
fields internally, however, some drivers relied on the core
calculating these values for them, following a default algorithm.
This patch restores the default calculation for such drivers.
Based on initial patch by Guennadi Liakhovetski, found here:
http://www.spinics.net/lists/linux-media/msg31282.html
Except that this covers try_fmt aswell.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c | 48
+ 1 files changed, 42
insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c index 4628448..dcc6623 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,11 +136,50 @@ unsigned long
soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
}
EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
+#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16)
0xff, \ + ((x) 24) 0xff
+
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+ struct v4l2_format *f)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct v4l2_pix_format *pix = f-fmt.pix;
+ int ret;
+
+ dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+ pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
+ ret = ici-ops-try_fmt(icd, f);
+ if (ret 0)
+ return ret;
+
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ const struct soc_camera_format_xlate *xlate;
+
+ xlate = soc_camera_xlate_by_fourcc(icd,
pix-pixelformat);
+ if (!xlate)
+ return -EINVAL;
+
+ ret = soc_mbus_bytes_per_line(pix-width,
+ xlate-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
+ return 0;
+}
+
static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct soc_camera_device *icd = file-private_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
WARN_ON(priv != file-private_data);
@@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file
*file, void *priv,
return -EINVAL;
/* limit format to hardware capabilities */
- return ici-ops-try_fmt(icd, f);
+ return soc_camera_try_fmt(icd, f);
}
static int soc_camera_enum_input(struct file *file, void *priv,
@@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct
soc_camera_device *icd)
icd-user_formats = NULL;
}
-#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16)
0xff, \ - ((x) 24) 0xff
-
/* Called with .vb_lock held, or from the first open(2), see comment
there */ static int soc_camera_set_fmt(struct soc_camera_device
*icd, struct v4l2_format *f)
@@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct
soc_camera_device *icd, pixfmtstr(pix-pixelformat), pix-width,
pix-height);
/* We always call try_fmt() before set_fmt() or set_crop() */
- ret = ici-ops-try_fmt(icd, f);
+ ret = soc_camera_try_fmt(icd, f);
if (ret 0)
return ret;
--
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
cx231xx: add support for Kworld..
patch to cx231xx: add support for Kworld UB430
Signed-off-by: Márcio A Alves fr...@gmail.com
diff -upr ../new_build2/linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- ../new_build2/linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-02-28 01:45:23.0 -0300
+++ linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-04-11 14:23:31.836858001 -0300
@@ -125,6 +125,7 @@
#define USB_PID_GRANDTEC_DVBT_USB_COLD 0x0fa0
#define USB_PID_GRANDTEC_DVBT_USB_WARM 0x0fa1
#define USB_PID_INTEL_CE95000x9500
+#define USB_PID_KWORLD_UB4300xe424
#define USB_PID_KWORLD_399U0xe399
#define USB_PID_KWORLD_399U_20xe400
#define USB_PID_KWORLD_395U0xe396
diff -upr ../new_build2/linux//drivers/media/video/cx231xx/cx231xx-cards.c linux//drivers/media/video/cx231xx/cx231xx-cards.c
--- ../new_build2/linux//drivers/media/video/cx231xx/cx231xx-cards.c 2011-02-25 01:45:17.0 -0300
+++ linux//drivers/media/video/cx231xx/cx231xx-cards.c 2011-04-11 15:15:42.776857999 -0300
@@ -401,6 +401,44 @@ struct cx231xx_board cx231xx_boards[] =
.gpio = NULL,
} },
},
+ [CX231XX_BOARD_KWORLD_UB430_USB_HYBRID] = {
+ .name = Kworld UB430 USB Hybrid,
+ .tuner_type = TUNER_NXP_TDA18271,
+ .tuner_addr = 0x60,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .demod_xfer_mode = 0,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x11, /* According with PV cxPolaris.inf file */
+ .tuner_sif_gpio = -1,
+ .tuner_scl_gpio = -1,
+ .tuner_sda_gpio = -1,
+ .gpio_pin_status_mask = 0x4001000,
+ .tuner_i2c_master = 2,
+ .demod_i2c_master = 1,
+ .ir_i2c_master = 2,
+ .has_dvb = 1,
+ .demod_addr = 0x10,
+ .norm = V4L2_STD_PAL_M,
+ .input = {{
+ .type = CX231XX_VMUX_TELEVISION,
+ .vmux = CX231XX_VIN_3_1,
+ .amux = CX231XX_AMUX_VIDEO,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+(CX231XX_VIN_1_2 8) |
+CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ } },
+ },
[CX231XX_BOARD_PV_PLAYTV_USB_HYBRID] = {
.name = Pixelview PlayTV USB Hybrid,
.tuner_type = TUNER_NXP_TDA18271,
@@ -500,6 +538,8 @@ struct usb_device_id cx231xx_id_table[]
.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
{USB_DEVICE(USB_VID_PIXELVIEW, 0x5014),
.driver_info = CX231XX_BOARD_PV_XCAPTURE_USB},
+ {USB_DEVICE(0x1b80, 0xe424),
+ .driver_info = CX231XX_BOARD_KWORLD_UB430_USB_HYBRID},
{},
};
@@ -534,12 +574,13 @@ int cx231xx_tuner_callback(void *ptr, in
case TDA18271_CALLBACK_CMD_AGC_ENABLE:
if (dev-model == CX231XX_BOARD_PV_PLAYTV_USB_HYBRID)
rc = cx231xx_set_agc_analog_digital_mux_select(dev, arg);
+
break;
default:
rc = -EINVAL;
break;
}
- }
+ }
return rc;
}
EXPORT_SYMBOL_GPL(cx231xx_tuner_callback);
diff -upr ../new_build2/linux//drivers/media/video/cx231xx/cx231xx-dvb.c linux//drivers/media/video/cx231xx/cx231xx-dvb.c
--- ../new_build2/linux//drivers/media/video/cx231xx/cx231xx-dvb.c 2011-01-17 01:45:24.0 -0300
+++ linux//drivers/media/video/cx231xx/cx231xx-dvb.c 2011-04-11 14:16:15.986858003 -0300
@@ -703,6 +703,30 @@ static int dvb_init(struct cx231xx *dev)
hcw_tda18271_config);
break;
+ case CX231XX_BOARD_KWORLD_UB430_USB_HYBRID:
+
+ printk(KERN_INFO %s: looking for demod on i2c bus: %d\n,
+ __func__, i2c_adapter_id(dev-i2c_bus[dev-board.tuner_i2c_master].i2c_adap));
+
+ dev-dvb-frontend = dvb_attach(mb86a20s_attach,
+ pv_mb86a20s_config,
+ dev-i2c_bus[dev-board.demod_i2c_master].i2c_adap);
+
+ if (dev-dvb-frontend == NULL) {
+ printk(DRIVER_NAME
+ : Failed to attach mb86a20s demod\n);
+ result = -EINVAL;
+ goto out_free;
+ }
+
+ /* define general-purpose callback pointer */
+ dvb-frontend-callback = cx231xx_tuner_callback;
+
+ dvb_attach(tda18271_attach, dev-dvb-frontend,
+ 0x60, dev-i2c_bus[dev-board.tuner_i2c_master].i2c_adap,
+ pv_tda18271_config);
+ break;
+
case CX231XX_BOARD_PV_PLAYTV_USB_HYBRID:
printk(KERN_INFO %s: looking for demod on i2c bus: %d\n,
diff -upr ../new_build2/linux//drivers/media/video/cx231xx/cx231xx.h linux//drivers/media/video/cx231xx/cx231xx.h
--- ../new_build2/linux//drivers/media/video/cx231xx/cx231xx.h 2011-03-11 13:25:49.0 -0300
+++ linux//drivers/media/video/cx231xx/cx231xx.h 2011-04-11 14:20:30.616858003 -0300
@@ -64,7 +64,8 @@
#define CX231XX_BOARD_HAUPPAUGE_EXETER 8
#define CX231XX_BOARD_HAUPPAUGE_USBLIVE2 9
#define CX231XX_BOARD_PV_PLAYTV_USB_HYBRID 10
-#define CX231XX_BOARD_PV_XCAPTURE_USB 11
+#define CX231XX_BOARD_KWORLD_UB430_USB_HYBRID 11
+#define CX231XX_BOARD_PV_XCAPTURE_USB 12
/* Limits minimum and default number of buffers */
#define CX231XX_MIN_BUF 4
Re - pinnacle pctv 110i remote not detected in ubuntu natty 11.04
Hi everyone My remote which used to work with older versions of ubuntu now wont work with the new natty 11.04. It used to be detected in /proc/bus/input/devices as input 5 but now i see no such entry. Is it because of move from hal to udev in new ubuntu . Please let me know what info you require.I have filed a bug on launchpad also. https://bugs.launchpad.net/ubuntu/+source/udev/+bug/748284 Any help is appreciated. warm regards rajeev -- 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: [PATCHES] Misc. trivial fixes
On Mon, 11 Apr 2011, Robby Workman wrote: Patch #1 installs udev rules files to /lib/udev/rules.d/ instead of /etc/udev/rules.d/ - see commit message for more info. Patch #2 allows override of manpage installation directory by packagers - see commit message for more info EEEK! It just occurred to me that this mailing list might possibly be used by more than one project (horrors!), so I should probably specify that the patches in the previous mail are aimed at v4l-utils. Sorry for the noise. -RW -- 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
[PATCHES] Misc. trivial fixes
Patch #1 installs udev rules files to /lib/udev/rules.d/ instead of /etc/udev/rules.d/ - see commit message for more info. Patch #2 allows override of manpage installation directory by packagers - see commit message for more info -RWFrom d3356b0cf968c41b1d44fcc682a441129d0b Mon Sep 17 00:00:00 2001 From: Robby Workman rwork...@slackware.com Date: Mon, 11 Apr 2011 20:41:28 -0500 Subject: [PATCH 1/2] Install udev rules to /lib/udev/ instead of /etc/udev In moderately recent versions of udev, packages should install rules files to /lib/udev/rules.d/ instead of /etc/udev/rules.d/, as /etc/udev/rules.d/ is now for generated rules and overrides of the packaged rules. --- utils/keytable/70-infrared.rules |4 +--- utils/keytable/Makefile |4 ++-- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/utils/keytable/70-infrared.rules b/utils/keytable/70-infrared.rules index 308a6d4..afffd95 100644 --- a/utils/keytable/70-infrared.rules +++ b/utils/keytable/70-infrared.rules @@ -1,6 +1,4 @@ # Automatically load the proper keymaps after the Remote Controller device -# creation. -# Copy this file at /etc/udev/rules.d/70-infrared.rules in order to load keytables -# during boot time. The keycode tables rules should be at /etc/rc_maps.cfg +# creation. The keycode tables rules should be at /etc/rc_maps.cfg ACTION==add, SUBSYSTEM==rc, RUN+=/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name diff --git a/utils/keytable/Makefile b/utils/keytable/Makefile index aa020ef..29a6ac4 100644 --- a/utils/keytable/Makefile +++ b/utils/keytable/Makefile @@ -37,8 +37,8 @@ install: $(TARGETS) install -m 644 -p rc_maps.cfg $(DESTDIR)/etc install -m 755 -d $(DESTDIR)/etc/rc_keymaps install -m 644 -p rc_keymaps/* $(DESTDIR)/etc/rc_keymaps - install -m 755 -d $(DESTDIR)/etc/udev/rules.d - install -m 644 -p 70-infrared.rules $(DESTDIR)/etc/udev/rules.d + install -m 755 -d $(DESTDIR)/lib/udev/rules.d + install -m 644 -p 70-infrared.rules $(DESTDIR)/lib/udev/rules.d install -m 755 -d $(DESTDIR)$(PREFIX)/share/man/man1 install -m 644 -p ir-keytable.1 $(DESTDIR)$(PREFIX)/share/man/man1 -- 1.7.4.4 From 0b5f4bc501c896155401226b188688fd3bef1f5c Mon Sep 17 00:00:00 2001 From: Robby Workman rwork...@slackware.com Date: Mon, 11 Apr 2011 20:50:18 -0500 Subject: [PATCH 2/2] Allow override of manpage installation directory This creates MANDIR in Make.rules and keeps the preexisting default of /usr/share/man, but allows packagers to easily override via e.g. make MANDIR=/usr/man --- Make.rules |1 + utils/keytable/Makefile |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Make.rules b/Make.rules index 0bb2eb8..1529ef8 100644 --- a/Make.rules +++ b/Make.rules @@ -11,6 +11,7 @@ PREFIX = /usr/local LIBDIR = $(PREFIX)/lib # subdir below LIBDIR in which to install the libv4lx libc wrappers LIBSUBDIR = libv4l +MANDIR = /usr/share/man # These ones should not be overriden from the cmdline diff --git a/utils/keytable/Makefile b/utils/keytable/Makefile index 29a6ac4..e093280 100644 --- a/utils/keytable/Makefile +++ b/utils/keytable/Makefile @@ -39,7 +39,7 @@ install: $(TARGETS) install -m 644 -p rc_keymaps/* $(DESTDIR)/etc/rc_keymaps install -m 755 -d $(DESTDIR)/lib/udev/rules.d install -m 644 -p 70-infrared.rules $(DESTDIR)/lib/udev/rules.d - install -m 755 -d $(DESTDIR)$(PREFIX)/share/man/man1 - install -m 644 -p ir-keytable.1 $(DESTDIR)$(PREFIX)/share/man/man1 + install -m 755 -d $(DESTDIR)$(MANDIR)/man1 + install -m 644 -p ir-keytable.1 $(DESTDIR)$(MANDIR)/man1 include ../../Make.rules -- 1.7.4.4
Re: [PATCH 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 -- 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
