Re: [PATCH v5 12/13] media: coda: add byte size slice limit control
Hi Philipp,
it now works properly.
On 12 September 2012 17:02, Philipp Zabel p.za...@pengutronix.de wrote:
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v4:
- Fix menu_skip_mask for V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE v4l2_ctrl.
Tested-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/coda.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 81e3401..0235f4e 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -151,6 +151,7 @@ struct coda_params {
enum v4l2_mpeg_video_multi_slice_mode slice_mode;
u32 framerate;
u16 bitrate;
+ u32 slice_max_bits;
u32 slice_max_mb;
};
@@ -1056,12 +1057,23 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
return -EINVAL;
}
- value = (ctx-params.slice_max_mb CODA_SLICING_SIZE_MASK)
CODA_SLICING_SIZE_OFFSET;
- value |= (1 CODA_SLICING_UNIT_MASK) CODA_SLICING_UNIT_OFFSET;
- if (ctx-params.slice_mode == V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_MB)
+ switch (ctx-params.slice_mode) {
+ case V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE:
+ value = 0;
+ break;
+ case V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_MB:
+ value = (ctx-params.slice_max_mb CODA_SLICING_SIZE_MASK)
CODA_SLICING_SIZE_OFFSET;
+ value |= (1 CODA_SLICING_UNIT_MASK)
CODA_SLICING_UNIT_OFFSET;
+ value |= 1 CODA_SLICING_MODE_MASK;
+ break;
+ case V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES:
+ value = (ctx-params.slice_max_bits
CODA_SLICING_SIZE_MASK) CODA_SLICING_SIZE_OFFSET;
+ value |= (0 CODA_SLICING_UNIT_MASK)
CODA_SLICING_UNIT_OFFSET;
value |= 1 CODA_SLICING_MODE_MASK;
+ break;
+ }
coda_write(dev, value, CODA_CMD_ENC_SEQ_SLICE_MODE);
- value = ctx-params.gop_size CODA_GOP_SIZE_MASK;
+ value = ctx-params.gop_size CODA_GOP_SIZE_MASK;
coda_write(dev, value, CODA_CMD_ENC_SEQ_GOP_SIZE);
if (ctx-params.bitrate) {
@@ -1308,6 +1320,9 @@ static int coda_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_MB:
ctx-params.slice_max_mb = ctrl-val;
break;
+ case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BYTES:
+ ctx-params.slice_max_bits = ctrl-val * 8;
+ break;
case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
break;
default:
@@ -1346,10 +1361,12 @@ static int coda_ctrls_setup(struct coda_ctx *ctx)
V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP, 1, 31, 1, 2);
v4l2_ctrl_new_std_menu(ctx-ctrls, coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE,
- V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_MB, 0,
- V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_MB);
+ V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES, 0x0,
+ V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE);
v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_MB, 1, 0x3fff, 1, 1);
+ v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BYTES, 1, 0x3fff, 1,
500);
v4l2_ctrl_new_std_menu(ctx-ctrls, coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_HEADER_MODE,
V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
--
1.7.10.4
--
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
Re: [PATCH v5 13/13] media: coda: set up buffers to be sized as negotiated with s_fmt
On 12 September 2012 17:02, Philipp Zabel p.za...@pengutronix.de wrote:
This fixes a failure in vb2_qbuf in user pointer mode where
__qbuf_userptr checks if the buffer queued by userspace is large
enough. The failure would happen if coda_queue_setup was called
with empty fmt (and thus set the expected buffer size to the maximum
resolution), and userspace queues buffers of smaller size -
corresponding to the negotiated dimensions - were queued.
Explicitly setting sizeimage to the value negotiated via s_fmt
fixes the issue.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Acked-by: Javier Martin javier.mar...@vista-silicon.com
drivers/media/platform/coda.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 0235f4e..0e0b4fe 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -813,18 +813,11 @@ static int coda_queue_setup(struct vb2_queue *vq,
unsigned int sizes[], void *alloc_ctxs[])
{
struct coda_ctx *ctx = vb2_get_drv_priv(vq);
+ struct coda_q_data *q_data;
unsigned int size;
- if (vq-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
- if (fmt)
- size = fmt-fmt.pix.width *
- fmt-fmt.pix.height * 3 / 2;
- else
- size = MAX_W *
- MAX_H * 3 / 2;
- } else {
- size = CODA_MAX_FRAME_SIZE;
- }
+ q_data = get_q_data(ctx, vq-type);
+ size = q_data-sizeimage;
*nplanes = 1;
sizes[0] = size;
--
1.7.10.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
--
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
Re: [PATCH v5 0/13] Initial i.MX5/CODA7 support for the CODA driver
Hi Philipp, On 12 September 2012 17:02, Philipp Zabel p.za...@pengutronix.de wrote: These patches contain initial firmware loading and encoding support for the CODA7 series VPU contained in i.MX51 and i.MX53 SoCs, and fix some multi-instance issues. Changes since v4: - Added Javier's Tested/Reviewed/Acked-by. - Fixed menu_skip_mask for V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE v4l2_ctrl. - Dropped the ARM patches, those should not go through the media tree. - Dropped the 1080p frame size limit patch for now. This v5 version it's ok with me. We've tested it with codadx6 and it works properly. Good job. I'll add support for larger than PAL sized frames properly in the next patch series, together with decoder support for i.MX5/CODA7 and i.MX6/CODA960. regards Philipp --- drivers/media/platform/Kconfig |3 +- drivers/media/platform/coda.c | 422 +--- drivers/media/platform/coda.h | 30 ++- 3 files changed, 337 insertions(+), 118 deletions(-) -- 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
Re: [PATCH v5 0/13] Initial i.MX5/CODA7 support for the CODA driver
If you want to speed up the process and you have you could send a pull request to Mauro. But be careful with the following patches that have been sent to the list after the initial support of the driver and before these series: http://patchwork.linuxtv.org/patch/14048/ https://patchwork.kernel.org/patch/1367011/ https://patchwork.kernel.org/patch/1363331/ https://patchwork.kernel.org/patch/1352551/ Regards. -- 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
Improving ov7670 sensor driver.
Hi,
our new i.MX27 based platform (Visstrim-SM20) uses an ov7675 sensor
attached to the CSI interface. Apparently, this sensor is fully
compatible with the old ov7670. For this reason, it seems rather
sensible that they should share the same driver: ov7670.c
One of the challenges we have to face is that capture video support
for our platform is mx2_camera.c, which is a soc-camera host driver;
while ov7670.c was developed for being used as part of a more complex
video card.
Here is the list of current users of ov7670:
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/ov519.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/sn9c20x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/vc032x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/via-camera.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/marvell-ccic/mcam-core.c
These are basically the improvements we need to make to this driver in
order to satisfy our needs:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
2.- Add the possibility to bypass PLL and clkrc preescaler.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
4.- Disable pixclk during horizontal blanking.
5.- min_height, min_width should be respected in try_fmt().
6.- Pass platform data when used with a soc-camera host driver.
7.- Add V4L2_CID_POWER_LINE_FREQUENCY ctrl.
I will try to summarize below why we need to accomplish each of the
previous tasks and what solution we propose for them:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
Why? Because soc-camera needs to inherit v4l2 subdevice controls in
order to expose them to user space.
How? Something like the following, incomplete, patch:
---
@@ -190,6 +196,7 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
struct ov7670_format_struct *fmt; /* Current format */
unsigned char sat; /* Saturation value */
int hue;/* Hue value */
@@ -1480,10 +1518,14 @@ static int ov7670_s_register(struct
v4l2_subdev *sd, struct v4l2_dbg_register *r
/* --- */
+static const struct v4l2_ctrl_ops ov7670_ctrl_ops = {
+ .s_ctrl = ov7670_s_ctrl,
+};
+
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl = ov7670_s_ctrl,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
.queryctrl = ov7670_queryctrl,
.reset = ov7670_reset,
.init = ov7670_init,
@@ -1551,6 +1600,16 @@ static int ov7670_probe(struct i2c_client *client,
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
+ v4l2_ctrl_handler_init(info-hdl, 1);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
...
...
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return info-hdl.error;
+ }
+ v4l2_ctrl_handler_setup(info-hdl);
+
---
2.- Add the possibility to bypass PLL and clkrc preescaler.
Why? The formula to get the desired frame rate in this chip in YUV is
the following: fps = fpclk / (2 * 510 * 784) This means that for a
desired fps = 30 we need fpclk = 24MHz. For that reason we have a
clean 24MHz xvclk input that comes from an oscillator. If we enable
the PLL it internally transforms the 24MHz in 22MHz and thus fps is
not 30 but 27. In order to get 30fps we need to bypass the PLL.
How? Defining a platform flag 'direct_clk' or similar that allows
xvclk being used directly as the pixel clock.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
Why? Currently, in the driver, for VGA, vstart = 10 and vstop = 490.
From our tests we found out that vstart = 14, vstop = 494 in order to
remove a disgusting horizontal green line in ov7675.
How? It seems these sensor aren't provided with a version register or
anything similar so I can't think of a clean solution for this yet.
Suggestions will be much appreciated.
4.- Disable pixclk during horizontal blanking.
Why? Otherwise i.MX27 will capture wrong pixels during blanking periods.
How? Through a private V4L2 control.
5.- min_height, min_width should be respected in try_fmt().
Why? Otherwise you are telling the user you are going to use a
different size than the one you are going to use.
How? With a patch similar to this:
---
@@ -759,8 +772,10 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
struct ov7670_format_struct **ret_fmt,
struct ov7670_win_size **ret_wsize)
{
- int index;
+ int
Re: Improving ov7670 sensor driver.
On Thu 13 September 2012 11:48:17 javier Martin wrote:
Hi,
our new i.MX27 based platform (Visstrim-SM20) uses an ov7675 sensor
attached to the CSI interface. Apparently, this sensor is fully
compatible with the old ov7670. For this reason, it seems rather
sensible that they should share the same driver: ov7670.c
One of the challenges we have to face is that capture video support
for our platform is mx2_camera.c, which is a soc-camera host driver;
while ov7670.c was developed for being used as part of a more complex
video card.
Here is the list of current users of ov7670:
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/ov519.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/sn9c20x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/vc032x.c
These do not actually use the ov7670 driver. They program it themselves.
It would be nice if the gspca driver would get support for subdevs, but
that's a separate topic.
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/via-camera.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/marvell-ccic/mcam-core.c
These are basically the improvements we need to make to this driver in
order to satisfy our needs:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
2.- Add the possibility to bypass PLL and clkrc preescaler.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
4.- Disable pixclk during horizontal blanking.
5.- min_height, min_width should be respected in try_fmt().
6.- Pass platform data when used with a soc-camera host driver.
7.- Add V4L2_CID_POWER_LINE_FREQUENCY ctrl.
I will try to summarize below why we need to accomplish each of the
previous tasks and what solution we propose for them:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
Why? Because soc-camera needs to inherit v4l2 subdevice controls in
order to expose them to user space.
How? Something like the following, incomplete, patch:
Luckily you didn't do too much work on this. I have old patches for this in
this tree:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl
The main reason why I never continued with this was that at the time I wrote
this I realized that the control framework needed proper support for what's
now called auto-clusters (i.e. how to handle autofoo/foo controls like autogain
and gain correctly).
I intended to pick this up at some time, but never got around to it.
I think these patches will still apply with some work, but it needs to be
converted to use the autocluster support that's now in the control framework.
---
@@ -190,6 +196,7 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
struct ov7670_format_struct *fmt; /* Current format */
unsigned char sat; /* Saturation value */
int hue;/* Hue value */
@@ -1480,10 +1518,14 @@ static int ov7670_s_register(struct
v4l2_subdev *sd, struct v4l2_dbg_register *r
/* --- */
+static const struct v4l2_ctrl_ops ov7670_ctrl_ops = {
+ .s_ctrl = ov7670_s_ctrl,
+};
+
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl = ov7670_s_ctrl,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
.queryctrl = ov7670_queryctrl,
.reset = ov7670_reset,
.init = ov7670_init,
@@ -1551,6 +1600,16 @@ static int ov7670_probe(struct i2c_client *client,
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
+ v4l2_ctrl_handler_init(info-hdl, 1);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
...
...
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return info-hdl.error;
+ }
+ v4l2_ctrl_handler_setup(info-hdl);
+
---
2.- Add the possibility to bypass PLL and clkrc preescaler.
Why? The formula to get the desired frame rate in this chip in YUV is
the following: fps = fpclk / (2 * 510 * 784) This means that for a
desired fps = 30 we need fpclk = 24MHz. For that reason we have a
clean 24MHz xvclk input that comes from an oscillator. If we enable
the PLL it internally transforms the 24MHz in 22MHz and thus fps is
not 30 but 27. In order to get 30fps we need to bypass the PLL.
How? Defining a platform flag 'direct_clk' or similar that allows
xvclk being used directly as the pixel clock.
3.- Adjust vstart/vstop in order to remove an horizontal
Re: [RFC PATCH v7] media: add v4l2 subdev driver for S5K4ECGX sensor
Hi Francesco
On 12 September 2012 19:07, Francesco Lavra francescolavra...@gmail.com wrote:
Hi Sangwook,
two remarks from my review on September 9th haven't been addressed.
Thanks for the review.
I missed those, please let me correct them and send patch again.
Regards
Sangwook
I believe those remarks are correct, but please let me know if I'm
missing something.
See below.
On 09/12/2012 01:26 PM, Sangwook Lee wrote:
+static int s5k4ecgx_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct s5k4ecgx *priv = to_s5k4ecgx(sd);
+ int ret;
+
+ v4l2_dbg(1, debug, sd, Switching %s\n, on ? on : off);
+
+ if (on) {
+ ret = __s5k4ecgx_power_on(priv);
+ if (ret 0)
+ return ret;
+ /* Time to stabilize sensor */
+ msleep(100);
+ ret = s5k4ecgx_init_sensor(sd);
+ if (ret 0)
+ __s5k4ecgx_power_off(priv);
+ else
+ priv-set_params = 1;
+ } else {
+ ret = __s5k4ecgx_power_off(priv);
+ }
+
+ return 0;
return ret;
+static int s5k4ecgx_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ int ret, i;
+ struct v4l2_subdev *sd;
+ struct s5k4ecgx *priv;
+ struct s5k4ecgx_platform_data *pdata = client-dev.platform_data;
+
+ if (pdata == NULL) {
+ dev_err(client-dev, platform data is missing!\n);
+ return -EINVAL;
+ }
+ priv = devm_kzalloc(client-dev, sizeof(struct s5k4ecgx), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ mutex_init(priv-lock);
+ priv-streaming = 0;
+
+ sd = priv-sd;
+ /* Registering subdev */
+ v4l2_i2c_subdev_init(sd, client, s5k4ecgx_ops);
+ strlcpy(sd-name, S5K4ECGX_DRIVER_NAME, sizeof(sd-name));
+
+ sd-internal_ops = s5k4ecgx_subdev_internal_ops;
+ /* Support v4l2 sub-device user space API */
+ sd-flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+ priv-pad.flags = MEDIA_PAD_FL_SOURCE;
+ sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ ret = media_entity_init(sd-entity, 1, priv-pad, 0);
+ if (ret)
+ return ret;
+
+ ret = s5k4ecgx_config_gpios(priv, pdata);
+ if (ret) {
+ dev_err(client-dev, Failed to set gpios\n);
+ goto out_err1;
+ }
+ for (i = 0; i S5K4ECGX_NUM_SUPPLIES; i++)
+ priv-supplies[i].supply = s5k4ecgx_supply_names[i];
+
+ ret = devm_regulator_bulk_get(client-dev, S5K4ECGX_NUM_SUPPLIES,
+ priv-supplies);
+ if (ret) {
+ dev_err(client-dev, Failed to get regulators\n);
+ goto out_err2;
+ }
+ ret = s5k4ecgx_init_v4l2_ctrls(priv);
+ if (ret)
+ goto out_err2;
+
+ priv-curr_pixfmt = s5k4ecgx_formats[0];
+ priv-curr_frmsize = s5k4ecgx_prev_sizes[0];
+
+ return 0;
+
+out_err2:
+ s5k4ecgx_free_gpios(priv);
+out_err1:
+ media_entity_cleanup(priv-sd.entity);
+
+ return ret;
+}
+
+static int s5k4ecgx_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct s5k4ecgx *priv = to_s5k4ecgx(sd);
+
+ mutex_destroy(priv-lock);
+ v4l2_device_unregister_subdev(sd);
+ v4l2_ctrl_handler_free(priv-handler);
+ media_entity_cleanup(sd-entity);
+
+ return 0;
s5k4ecgx_free_gpios() should be called to release the GPIOs
Thanks,
Francesco
--
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: [RFCv2 API PATCH 24/28] v4l2-dev: add new VFL_DIR_ defines.
Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:24 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com These will be used by v4l2-dev.c to improve ioctl checking. I.e. ioctls for capture should return -ENOTTY when called for an output device. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- include/media/v4l2-dev.h |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h index 6ee8897..95d1c91 100644 --- a/include/media/v4l2-dev.h +++ b/include/media/v4l2-dev.h @@ -26,6 +26,12 @@ #define VFL_TYPE_SUBDEV 3 #define VFL_TYPE_MAX 4 +/* Is this a receiver, transmitter or mem-to-mem? */ +/* Ignored for VFL_TYPE_SUBDEV. */ +#define VFL_DIR_RX 0 +#define VFL_DIR_TX 1 +#define VFL_DIR_M2M 2 + Wouldn't VFL_DIR_CAPTURE and VFL_DIR_OUTPUT sound more familiar ? struct v4l2_ioctl_callbacks; struct video_device; struct v4l2_device; @@ -105,7 +111,8 @@ struct video_device /* device info */ char name[32]; - int vfl_type; + int vfl_type; /* device type */ + int vfl_dir;/* receiver, transmitter or m2m */ Would combining vfl_dir with vfl_type using bitflags be an option ? The direction is somehow part of (or closely related to) the type. /* 'minor' is set to -1 if the registration failed */ int minor; u16 num; -- 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: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Friday 07 September 2012 15:29:12 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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: [RFCv2 API PATCH 13/28] Add V4L2_CAP_MONOTONIC_TS where applicable.
Hi Hans, On Friday 07 September 2012 15:29:13 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add the new V4L2_CAP_MONOTONIC_TS capability to those drivers that use monotomic timestamps instead of the system time. Signed-off-by: Hans Verkuil hans.verk...@cisco.com For uvcvideo, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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: [RFC 1/5] video: Add generic display panel core
Hi Sascha,
On Tuesday 04 September 2012 11:24:46 Sascha Hauer wrote:
Hi Laurent,
On Fri, Aug 17, 2012 at 02:49:39AM +0200, Laurent Pinchart wrote:
+/**
+ * panel_get_modes - Get video modes supported by the panel
+ * @panel: The panel
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The
array
+ * is owned by the panel.
+ *
+ * Return the number of supported modes on success (including 0 if no
mode is
+ * supported) or a negative error code otherwise.
+ */
+int panel_get_modes(struct panel *panel, const struct fb_videomode
**modes)
+{
+ if (!panel-ops || !panel-ops-get_modes)
+ return 0;
+
+ return panel-ops-get_modes(panel, modes);
+}
+EXPORT_SYMBOL_GPL(panel_get_modes);
You have seen my of videomode helper proposal. One result there was that
we want to have ranges for the margin/synclen fields. Does it make sense
to base this new panel framework on a more sophisticated internal
reprentation of the panel parameters?
I think it does, yes. We need a common video mode structure, and the panel
framework should use it. I'll try to rebase my patches on top of your
proposal. Have you posted the latest version ?
This could then be converted to struct fb_videomode / struct
drm_display_mode as needed. This would also make it more suitable for drm
drivers which are not interested in struct fb_videomode.
Related to this I suggest to change the API to be able to iterate over
the different modes, like:
struct videomode *panel_get_mode(struct panel *panel, int num);
This was we do not have to have an array of modes in memory, which may
be a burden for some panel drivers.
I currently have mixed feelings about this. Both approaches have pros and
cons. Iterating over the modes would be more complex for drivers that use
panels, and would be race-prone if the modes can change at runtime (OK, this
isn't supported by the current panel API proposal).
--
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: [RFCv2 API PATCH 03/28] DocBook: improve STREAMON/OFF documentation.
On Friday 07 September 2012 15:29:03 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Specify that STREAMON/OFF should return 0 if the stream is already started/stopped. The spec never specified what the correct behavior is. This ambiguity was resolved during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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 v2] media: v4l2-ctrls: add control for test pattern
Hi Sakari,
On Sunday 09 September 2012 10:40:17 Sakari Ailus wrote:
On Sat, Sep 08, 2012 at 01:11:04PM +0200, Hans Verkuil wrote:
On Fri September 7 2012 20:20:51 Sakari Ailus wrote:
Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
add V4L2_CID_TEST_PATTERN of type menu, which determines
the internal test pattern selected by the device.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rob Landley r...@landley.net
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.
Changes for v2:
1: Included display devices in the description for test pattern
as pointed by Hans.
2: In the menu replaced 'Test Pattern Disabled' by 'Disabled' as
pointed by Sylwester.
3: Removed the test patterns from menu as the are hardware specific
as pointed by Sakari.
Documentation/DocBook/media/v4l/controls.xml | 20
drivers/media/v4l2-core/v4l2-ctrls.c |8
include/linux/videodev2.h|4
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml index ad873ea..173934e
100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4311,6 +4311,26 @@ interface and may change in the future./para
/tbody
/entrytbl
/row
+ row
+ entry
spanname=idconstantV4L2_CID_TEST_PATTERN/constant/entry +
entrymenu/entry
+ /row
+ row id=v4l2-test-pattern
+ entry spanname=descr The Capture/Display/Sensors have
the
capability
+ to generate internal test patterns and this are hardware
specific. This
+ test patterns are used to test a device is properly working
and
can generate
+ the desired waveforms that
it supports./entry
+ /row
+ row
+ entrytbl spanname=descr cols=2
+ tbody valign=top
+ row
+
entryconstantV4L2_TEST_PATTERN_DISABLED/constant/entry
+ entryTest pattern generation is disabled/entry
+ /row
+ /tbody
+ /entrytbl
+ /row
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c index 8f2f40b..d731422 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -430,6 +430,10 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Advanced,
NULL,
};
+ static const char * const test_pattern[] = {
+ Disabled,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -509,6 +513,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return jpeg_chroma_subsampling;
case V4L2_CID_DPCM_PREDICTOR:
return dpcm_predictor;
+ case V4L2_CID_TEST_PATTERN:
+ return test_pattern;
I think it's not necessary to define test_pattern (nor be prepared to
return it) since the menu is going to be device specific. So the driver
is responsible for all of the menu items. Such menus are created using
v4l2_ctrl_new_custom() instead of v4l2_ctrl_new_std_menu().
Looks good to me otherwise.
I would suggest that we *do* make this a standard control, but the menu
consists of just one item: Disabled. After creating the control you can
just set the ctrl-qmenu pointer to the device-specific menu. I like
using standard controls because they guarantee standard naming and type
conventions. They are also easier to use in an application.
That's not quite enough. Also menu_skip_mask and max also need to be
replaced. In a general case min as well. It's easy to do mistakes in that
--- how about a separate function for doing that? It'd be also nice to be
able to use the existing standardised menu item strings, but that's just an
extra plus.
Agreed. A way to create a standard menu control with driver-supplied menu
items would be a good addition to the
Re: [RFCv2 API PATCH 10/28] Rename V4L2_(IN|OUT)_CAP_CUSTOM_TIMINGS.
Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:10 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com The 'custom' timings are no longer just for custom timings, but also for standard CEA/VESA timings. So rename to V4L2_IN/OUT_CAP_DV_TIMINGS. The old define is still kept for backwards compatibility. Should they be added to feature-removal-schedule.txt ? This decision was taken during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com -- 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: [Workshop-2011] Media summit/KS-2012 proposals
Hi Hans, On Wednesday 05 September 2012 10:28:30 Hans Verkuil wrote: On Wed 5 September 2012 10:04:41 Jun Nie wrote: Is there any summary for this summit or presentation material? I am looking forward for some idea on CEC. It is really complex in functionality. Maybe other guys is expecting simiar fruite from summit too. Yes, there will be a summit report. It's not quite finished yet, I think. With respect to CEC we had some useful discussions. It will have to be a new class of device (/dev/cecX), so the userspace API will be separate from drm or v4l. This is a repeat of a comment from the KS discussion: what about using the socket API instead of a device node ? And the kernel will have to take care of the core CEC protocol w.r.t. control and discovery due to the HDMI 1.4a requirements. I plan on starting work on this within 1-2 weeks. My CEC presentation can be found here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-cec.odp -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: v4l2-ctrls: add control for dpcm predictor
Hi Sakari, On Friday 07 September 2012 21:46:44 Sakari Ailus wrote: Could you replace the above with this text (with appropriate indentation etc.) while keeping the reference to Wikipedia? --8-- Differential pulse-code modulation (DPCM) compression can be used to compress the samples into fewer bits than they would otherwise require. This is done by calculating the difference between consecutive samples and outputting the difference which in average is much smaller than the values of the samples themselves since there is generally lots of correlation between adjacent pixels. In decompression the original samples are reconstructed. The process isn't lossless as the encoded sample size in bits is less than the original. Formats using DPCM compression include xref linkend=pixfmt-srggb10dpcm8 /. This control is used to select the predictor used to encode the samples. If I remember correctly this control will be used on the receiver side on DaVinci, to decode pixels not encode them. How is the predictor used in that case ? Must it match the predictor used on the encoding side ? If so I expect documentation to be available somewhere. The OMAP3 ISP supports both DPCM encoding and decoding, and documents the predictors as - The simple predictor This predictor uses only the previous same color component value as a prediction value. Therefore, only two-pixel memory is required. - The advanced predictor This predictor uses four previous pixel values, when the prediction value is evaluated. This means that also the other color component values are used, when the prediction value has been defined. It also states the the simple predictor is preferred for 10-8-10 conversion, and the advanced predictor for 10-7-10 and 10-6-10 conversion. The main difference between the simple and the advanced predictors is image quality, with advanced predictor supposed to produce better quality images as a result. Simple predictor can be used e.g. for testing purposes. --8-- -- 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 v3] media: v4l2-ctrl: add a helper function to modify the menu
Hi Prabhakar,
Thanks for the patch.
On Tuesday 11 September 2012 19:53:38 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
Add a helper function to modify the menu, max and default value
to set.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Rob Landley r...@landley.net
---
Changes for v3:
1: Fixed style/grammer issues as pointed by Hans.
Thanks Hans for providing the description.
Changes for v2:
1: Fixed review comments from Hans, to have return type as
void, add WARN_ON() for fail conditions, allow this fucntion
to modify the menu of custom controls.
Documentation/video4linux/v4l2-controls.txt | 29
drivers/media/v4l2-core/v4l2-ctrls.c| 17 +++
include/media/v4l2-ctrls.h | 11 ++
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt index 43da22b..01d0a82 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -367,6 +367,35 @@ it to 0 means that all menu items are supported.
You set this mask either through the v4l2_ctrl_config struct for a custom
control, or by calling v4l2_ctrl_new_std_menu().
+There are situations where menu items may be device specific. In such cases
the
+framework provides a helper function to change the menu:
+
+void v4l2_ctrl_modify_menu(struct v4l2_ctrl *ctrl, const char * const
*qmenu,
+ s32 max, u32 menu_skip_mask, s32 def);
Sorry if this is a stupid question, but wouldn't it be better to add a
function to create a custom menu instead of modifying it afterwards ?
+
+A good example is the test pattern control for capture/display/sensors
devices
+that have the capability to generate test patterns. These test patterns are
+hardware specific, so the contents of the menu will vary from device to
device.
+
+This helper function is used to modify the menu, max, mask and the default
+value of the control.
+
+Example:
+
+ static const char * const test_pattern[] = {
+ Disabled,
+ Vertical Bars,
+ Solid Black,
+ Solid White,
+ NULL,
+ };
+ struct v4l2_ctrl *test_pattern_ctrl =
+ v4l2_ctrl_new_std_menu(foo-ctrl_handler, foo_ctrl_ops,
+ V4L2_CID_TEST_PATTERN, V4L2_TEST_PATTERN_DISABLED, 0,
+ V4L2_TEST_PATTERN_DISABLED);
+
+ v4l2_ctrl_modify_menu(test_pattern_ctrl, test_pattern, 3, 0,
+ V4L2_TEST_PATTERN_DISABLED);
Custom Controls
===
--
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: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). +For devices without a bus it should start with the driver name, optionally +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to the structfielddriver/structfield field./entry /row row entry__u32/entry -- 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: [RFCv2 API PATCH 06/28] v4l2-core: deprecate V4L2_BUF_TYPE_PRIVATE
Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:06 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This buffer type isn't used at all, and since it is effectively undefined what it should do it is deprecated. The define still exists, but any internal support for such buffers is removed. The decisions to deprecate this was taken during the 2012 Media Workshop. What about also adding V4L2_BUF_TYPE_PRIVATE to Documentation/feature-removal- schedule.txt ? -- 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: [RFCv2 API PATCH 04/28] DocBook: make the G/S/TRY_FMT specification more strict.
On Friday 07 September 2012 15:29:04 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com - S/TRY_FMT should always succeed, unless an invalid type field is passed in. - TRY_FMT should give the same result as S_FMT, all other things being equal. - ENUMFMT may return different formats for different inputs or outputs. This was decided during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com With the typo fix reported by Sylwester, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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: [RFCv2 API PATCH 25/28] Set vfl_dir for all display or m2m drivers.
Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:25 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/pci/ivtv/ivtv-streams.c |3 +++ drivers/media/pci/zoran/zoran_card.c |4 drivers/media/platform/coda.c |1 + drivers/media/platform/davinci/vpbe_display.c |1 + drivers/media/platform/davinci/vpif_display.c |1 + drivers/media/platform/m2m-deinterlace.c |1 + drivers/media/platform/mem2mem_testdev.c |1 + drivers/media/platform/mx2_emmaprp.c |1 + drivers/media/platform/omap/omap_vout.c |1 + drivers/media/platform/omap3isp/ispvideo.c|1 + drivers/media/platform/s5p-fimc/fimc-m2m.c|1 + drivers/media/platform/s5p-g2d/g2d.c |1 + drivers/media/platform/s5p-jpeg/jpeg-core.c |1 + drivers/media/platform/s5p-mfc/s5p_mfc.c |1 + drivers/media/platform/s5p-tv/mixer_video.c |1 + drivers/media/platform/sh_vou.c |1 + drivers/media/usb/uvc/uvc_driver.c|2 ++ 17 files changed, 23 insertions(+) diff --git a/drivers/media/pci/ivtv/ivtv-streams.c b/drivers/media/pci/ivtv/ivtv-streams.c index f08ec17..1d0e04a 100644 --- a/drivers/media/pci/ivtv/ivtv-streams.c +++ b/drivers/media/pci/ivtv/ivtv-streams.c @@ -223,6 +223,9 @@ static int ivtv_prep_dev(struct ivtv *itv, int type) s-vdev-num = num; s-vdev-v4l2_dev = itv-v4l2_dev; + if (ivtv_stream_info[type].buf_type == V4L2_BUF_TYPE_VIDEO_OUTPUT || + ivtv_stream_info[type].buf_type == V4L2_BUF_TYPE_VBI_OUTPUT) + s-vdev-vfl_dir = VFL_DIR_TX; I think drivers should set VFL_DIR_RX explicitly instead of relying on it being equal to 0. If we change the value later for any reason this implementation would break. s-vdev-fops = ivtv_stream_info[type].fops; s-vdev-ctrl_handler = itv-v4l2_dev.ctrl_handler; s-vdev-release = video_device_release; -- 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 4/5] video:omap3isp:fix up ENOIOCTLCMD error handling
Hi Wanlong, Thanks for the patch. On Monday 27 August 2012 15:23:15 Wanlong Gao wrote: At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be translated as ENOTTY to user mode. Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com --- drivers/media/video/omap3isp/ispvideo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/omap3isp/ispvideo.c b/drivers/media/video/omap3isp/ispvideo.c index b37379d..2dd982e 100644 --- a/drivers/media/video/omap3isp/ispvideo.c +++ b/drivers/media/video/omap3isp/ispvideo.c @@ -337,7 +337,7 @@ __isp_video_get_format(struct isp_video *video, struct v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt); if (ret == -ENOIOCTLCMD) - ret = -EINVAL; + ret = -ENOTTY; I don't think this location should be changed. __isp_video_get_format() is called by isp_video_check_format() only, which in turn is called by isp_video_streamon() only. A failure to retrieve the format in __isp_video_get_format() does not really mean the VIDIOC_STREAMON is not supported. I'll apply hunks 2 to 5 and drop hunk 1 if that's fine with you. mutex_unlock(video-mutex); @@ -723,7 +723,7 @@ isp_video_try_format(struct file *file, void *fh, struct v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt); if (ret) - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; isp_video_mbus_to_pix(video, fmt.format, format-fmt.pix); return 0; @@ -744,7 +744,7 @@ isp_video_cropcap(struct file *file, void *fh, struct v4l2_cropcap *cropcap) ret = v4l2_subdev_call(subdev, video, cropcap, cropcap); mutex_unlock(video-mutex); - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; } static int @@ -771,7 +771,7 @@ isp_video_get_crop(struct file *file, void *fh, struct v4l2_crop *crop) format.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, format); if (ret 0) - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; crop-c.left = 0; crop-c.top = 0; @@ -796,7 +796,7 @@ isp_video_set_crop(struct file *file, void *fh, struct v4l2_crop *crop) ret = v4l2_subdev_call(subdev, video, s_crop, crop); mutex_unlock(video-mutex); - return ret == -ENOIOCTLCMD ? -EINVAL : ret; + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; } static int -- 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: [RFCv2 API PATCH 14/28] DocBook: clarify that sequence is also set for output devices.
Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:14 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com It was not entirely obvious that the sequence count should also be set for output devices. Also made it more explicit that this sequence counter counts frames, not fields. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index b680d66..d1c2369 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -617,8 +617,8 @@ field is independent of the structfieldtimestamp/structfield and entry__u32/entry entrystructfieldsequence/structfield/entry entry/entry - entrySet by the driver, counting the frames in the -sequence./entry + entrySet by the driver, counting the frames (not fields!) in the +sequence. This field is set for both input and output devices./entry Nitpicking, s/in the sequence/in sequence/ ? /row row entry spanname=hspanparaIn link -- 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: [RFCv2 API PATCH 15/28] DocBook: Mark CROPCAP as optional instead of as compulsory.
Hi Hans,
Thanks for the patch.
On Friday 07 September 2012 15:29:15 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
While the documentation says that VIDIOC_CROPCAP is compulsory for
all video capture and output devices, in practice VIDIOC_CROPCAP is
only implemented for devices that can do cropping and/or scaling.
Update the documentation to no longer require VIDIOC_CROPCAP if the
driver does not support cropping or scaling or non-square pixels.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/DocBook/media/v4l/common.xml | 145 -
Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 10 +-
2 files changed, 75 insertions(+), 80 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/common.xml
b/Documentation/DocBook/media/v4l/common.xml index 9378d7b..454258b 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -628,7 +628,7 @@ are available for the device./para
if (-1 == ioctl (fd, VIDIOC-G-STD;, amp;std_id)) {
/* Note when VIDIOC_ENUMSTD always returns EINVAL this
is no video device or it falls under the USB exception,
-and VIDIOC_G_STD returning EINVAL is no error. */
+and VIDIOC_G_STD returning ENOTTY is no error. */
perror (VIDIOC_G_STD);
exit (EXIT_FAILURE);
Would this hunk make more sense in patch 11/28 ?
--
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 4/5] video:omap3isp:fix up ENOIOCTLCMD error handling
On 09/13/2012 12:03 PM, Laurent Pinchart wrote: Hi Wanlong, Thanks for the patch. On Monday 27 August 2012 15:23:15 Wanlong Gao wrote: At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be translated as ENOTTY to user mode. Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com --- drivers/media/video/omap3isp/ispvideo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/omap3isp/ispvideo.c b/drivers/media/video/omap3isp/ispvideo.c index b37379d..2dd982e 100644 --- a/drivers/media/video/omap3isp/ispvideo.c +++ b/drivers/media/video/omap3isp/ispvideo.c @@ -337,7 +337,7 @@ __isp_video_get_format(struct isp_video *video, struct v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt); if (ret == -ENOIOCTLCMD) -ret = -EINVAL; +ret = -ENOTTY; I don't think this location should be changed. __isp_video_get_format() is called by isp_video_check_format() only, which in turn is called by isp_video_streamon() only. A failure to retrieve the format in __isp_video_get_format() does not really mean the VIDIOC_STREAMON is not supported. I'll apply hunks 2 to 5 and drop hunk 1 if that's fine with you. Fine, I defer to your great knowledge in this. Thanks, Wanlong Gao -- 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: [Workshop-2011] Media summit/KS-2012 proposals
On Thu 13 September 2012 03:01:34 Laurent Pinchart wrote: Hi Hans, On Wednesday 05 September 2012 10:28:30 Hans Verkuil wrote: On Wed 5 September 2012 10:04:41 Jun Nie wrote: Is there any summary for this summit or presentation material? I am looking forward for some idea on CEC. It is really complex in functionality. Maybe other guys is expecting simiar fruite from summit too. Yes, there will be a summit report. It's not quite finished yet, I think. With respect to CEC we had some useful discussions. It will have to be a new class of device (/dev/cecX), so the userspace API will be separate from drm or v4l. This is a repeat of a comment from the KS discussion: what about using the socket API instead of a device node ? What benefit would that give me? I frankly don't think it maps that well to a socket API. Some parts of the CEC protocol are more or less network like, but others are point-to-point. Basically CEC is a mess, protocol-wise, and I much prefer a char-device where you have more flexibility. Regards, Hans And the kernel will have to take care of the core CEC protocol w.r.t. control and discovery due to the HDMI 1.4a requirements. I plan on starting work on this within 1-2 weeks. My CEC presentation can be found here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-cec.odp -- 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: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). I thought about that, but should that be defined in the spec? I'm not sure if that's the right place. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 06/28] v4l2-core: deprecate V4L2_BUF_TYPE_PRIVATE
On Thu 13 September 2012 04:21:14 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:06 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This buffer type isn't used at all, and since it is effectively undefined what it should do it is deprecated. The define still exists, but any internal support for such buffers is removed. The decisions to deprecate this was taken during the 2012 Media Workshop. What about also adding V4L2_BUF_TYPE_PRIVATE to Documentation/feature-removal- schedule.txt ? I don't think it is important enough to do that. Removing it in the future may cause application breakage, and frankly, perhaps we might need it again at some time. Unlikely, but you'll never know. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 10/28] Rename V4L2_(IN|OUT)_CAP_CUSTOM_TIMINGS.
On Thu 13 September 2012 04:22:52 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:10 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com The 'custom' timings are no longer just for custom timings, but also for standard CEA/VESA timings. So rename to V4L2_IN/OUT_CAP_DV_TIMINGS. The old define is still kept for backwards compatibility. Should they be added to feature-removal-schedule.txt ? That might be a good idea. The old defines are basically only used on embedded systems, so we can probably remove them by 3.9 or so. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving ov7670 sensor driver.
Hi Hans,
thank you for your response.
On 13 September 2012 12:07, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu 13 September 2012 11:48:17 javier Martin wrote:
Hi,
our new i.MX27 based platform (Visstrim-SM20) uses an ov7675 sensor
attached to the CSI interface. Apparently, this sensor is fully
compatible with the old ov7670. For this reason, it seems rather
sensible that they should share the same driver: ov7670.c
One of the challenges we have to face is that capture video support
for our platform is mx2_camera.c, which is a soc-camera host driver;
while ov7670.c was developed for being used as part of a more complex
video card.
Here is the list of current users of ov7670:
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/ov519.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/sn9c20x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/vc032x.c
These do not actually use the ov7670 driver. They program it themselves.
It would be nice if the gspca driver would get support for subdevs, but
that's a separate topic.
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/via-camera.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/marvell-ccic/mcam-core.c
These are basically the improvements we need to make to this driver in
order to satisfy our needs:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
2.- Add the possibility to bypass PLL and clkrc preescaler.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
4.- Disable pixclk during horizontal blanking.
5.- min_height, min_width should be respected in try_fmt().
6.- Pass platform data when used with a soc-camera host driver.
7.- Add V4L2_CID_POWER_LINE_FREQUENCY ctrl.
I will try to summarize below why we need to accomplish each of the
previous tasks and what solution we propose for them:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
Why? Because soc-camera needs to inherit v4l2 subdevice controls in
order to expose them to user space.
How? Something like the following, incomplete, patch:
Luckily you didn't do too much work on this. I have old patches for this in
this tree:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl
Great. This is the reason why I like to always ask first.
The main reason why I never continued with this was that at the time I wrote
this I realized that the control framework needed proper support for what's
now called auto-clusters (i.e. how to handle autofoo/foo controls like
autogain
and gain correctly).
I intended to pick this up at some time, but never got around to it.
I think these patches will still apply with some work, but it needs to be
converted to use the autocluster support that's now in the control framework.
---
@@ -190,6 +196,7 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
struct ov7670_format_struct *fmt; /* Current format */
unsigned char sat; /* Saturation value */
int hue;/* Hue value */
@@ -1480,10 +1518,14 @@ static int ov7670_s_register(struct
v4l2_subdev *sd, struct v4l2_dbg_register *r
/* ---
*/
+static const struct v4l2_ctrl_ops ov7670_ctrl_ops = {
+ .s_ctrl = ov7670_s_ctrl,
+};
+
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl = ov7670_s_ctrl,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
.queryctrl = ov7670_queryctrl,
.reset = ov7670_reset,
.init = ov7670_init,
@@ -1551,6 +1600,16 @@ static int ov7670_probe(struct i2c_client *client,
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
+ v4l2_ctrl_handler_init(info-hdl, 1);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
...
...
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return info-hdl.error;
+ }
+ v4l2_ctrl_handler_setup(info-hdl);
+
---
2.- Add the possibility to bypass PLL and clkrc preescaler.
Why? The formula to get the desired frame rate in this chip in YUV is
the following: fps = fpclk / (2 * 510 * 784) This means that for a
desired fps = 30 we need fpclk = 24MHz. For that reason we have a
clean 24MHz xvclk input that comes from an oscillator. If we enable
the PLL it internally transforms the 24MHz in 22MHz and thus fps is
not 30 but 27. In order to get 30fps we need to bypass the PLL.
How?
Re: [RFCv2 API PATCH 14/28] DocBook: clarify that sequence is also set for output devices.
On Thu 13 September 2012 04:28:41 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:14 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com It was not entirely obvious that the sequence count should also be set for output devices. Also made it more explicit that this sequence counter counts frames, not fields. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index b680d66..d1c2369 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -617,8 +617,8 @@ field is independent of the structfieldtimestamp/structfield and entry__u32/entry entrystructfieldsequence/structfield/entry entry/entry - entrySet by the driver, counting the frames in the -sequence./entry + entrySet by the driver, counting the frames (not fields!) in the +sequence. This field is set for both input and output devices./entry Nitpicking, s/in the sequence/in sequence/ ? Will fix. Regards, Hans /row row entry spanname=hspanparaIn link -- 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: [RFCv2 API PATCH 24/28] v4l2-dev: add new VFL_DIR_ defines.
On Thu 13 September 2012 04:36:27 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:24 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com These will be used by v4l2-dev.c to improve ioctl checking. I.e. ioctls for capture should return -ENOTTY when called for an output device. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- include/media/v4l2-dev.h |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h index 6ee8897..95d1c91 100644 --- a/include/media/v4l2-dev.h +++ b/include/media/v4l2-dev.h @@ -26,6 +26,12 @@ #define VFL_TYPE_SUBDEV3 #define VFL_TYPE_MAX 4 +/* Is this a receiver, transmitter or mem-to-mem? */ +/* Ignored for VFL_TYPE_SUBDEV. */ +#define VFL_DIR_RX 0 +#define VFL_DIR_TX 1 +#define VFL_DIR_M2M2 + Wouldn't VFL_DIR_CAPTURE and VFL_DIR_OUTPUT sound more familiar ? That was my first choice as well, but that terminology didn't make that much sense for a radio device. struct v4l2_ioctl_callbacks; struct video_device; struct v4l2_device; @@ -105,7 +111,8 @@ struct video_device /* device info */ char name[32]; - int vfl_type; + int vfl_type; /* device type */ + int vfl_dir;/* receiver, transmitter or m2m */ Would combining vfl_dir with vfl_type using bitflags be an option ? The direction is somehow part of (or closely related to) the type. They are two different things: the type determines the name of the device node (video, vbi, radio, v4l-subdev), the dir determines what you can do with the device node: read, write or both. It's awkward if you have to mask out things all the time. It might make sense to change the type from int to short to save some space. /* 'minor' is set to -1 if the registration failed */ int minor; u16 num; Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 25/28] Set vfl_dir for all display or m2m drivers.
On Thu 13 September 2012 04:37:27 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:25 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/pci/ivtv/ivtv-streams.c |3 +++ drivers/media/pci/zoran/zoran_card.c |4 drivers/media/platform/coda.c |1 + drivers/media/platform/davinci/vpbe_display.c |1 + drivers/media/platform/davinci/vpif_display.c |1 + drivers/media/platform/m2m-deinterlace.c |1 + drivers/media/platform/mem2mem_testdev.c |1 + drivers/media/platform/mx2_emmaprp.c |1 + drivers/media/platform/omap/omap_vout.c |1 + drivers/media/platform/omap3isp/ispvideo.c|1 + drivers/media/platform/s5p-fimc/fimc-m2m.c|1 + drivers/media/platform/s5p-g2d/g2d.c |1 + drivers/media/platform/s5p-jpeg/jpeg-core.c |1 + drivers/media/platform/s5p-mfc/s5p_mfc.c |1 + drivers/media/platform/s5p-tv/mixer_video.c |1 + drivers/media/platform/sh_vou.c |1 + drivers/media/usb/uvc/uvc_driver.c|2 ++ 17 files changed, 23 insertions(+) diff --git a/drivers/media/pci/ivtv/ivtv-streams.c b/drivers/media/pci/ivtv/ivtv-streams.c index f08ec17..1d0e04a 100644 --- a/drivers/media/pci/ivtv/ivtv-streams.c +++ b/drivers/media/pci/ivtv/ivtv-streams.c @@ -223,6 +223,9 @@ static int ivtv_prep_dev(struct ivtv *itv, int type) s-vdev-num = num; s-vdev-v4l2_dev = itv-v4l2_dev; + if (ivtv_stream_info[type].buf_type == V4L2_BUF_TYPE_VIDEO_OUTPUT || + ivtv_stream_info[type].buf_type == V4L2_BUF_TYPE_VBI_OUTPUT) + s-vdev-vfl_dir = VFL_DIR_TX; I think drivers should set VFL_DIR_RX explicitly instead of relying on it being equal to 0. If we change the value later for any reason this implementation would break. I can do that for those drivers like ivtv where you have output and input devices, but I'm not going to change this for all drivers, because that would be a substantial amount of work for little gain. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving ov7670 sensor driver.
On Thu 13 September 2012 12:47:53 javier Martin wrote:
Hi Hans,
thank you for your response.
On 13 September 2012 12:07, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu 13 September 2012 11:48:17 javier Martin wrote:
Hi,
our new i.MX27 based platform (Visstrim-SM20) uses an ov7675 sensor
attached to the CSI interface. Apparently, this sensor is fully
compatible with the old ov7670. For this reason, it seems rather
sensible that they should share the same driver: ov7670.c
One of the challenges we have to face is that capture video support
for our platform is mx2_camera.c, which is a soc-camera host driver;
while ov7670.c was developed for being used as part of a more complex
video card.
Here is the list of current users of ov7670:
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/ov519.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/sn9c20x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/vc032x.c
These do not actually use the ov7670 driver. They program it themselves.
It would be nice if the gspca driver would get support for subdevs, but
that's a separate topic.
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/via-camera.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/marvell-ccic/mcam-core.c
These are basically the improvements we need to make to this driver in
order to satisfy our needs:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
2.- Add the possibility to bypass PLL and clkrc preescaler.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
4.- Disable pixclk during horizontal blanking.
5.- min_height, min_width should be respected in try_fmt().
6.- Pass platform data when used with a soc-camera host driver.
7.- Add V4L2_CID_POWER_LINE_FREQUENCY ctrl.
I will try to summarize below why we need to accomplish each of the
previous tasks and what solution we propose for them:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
Why? Because soc-camera needs to inherit v4l2 subdevice controls in
order to expose them to user space.
How? Something like the following, incomplete, patch:
Luckily you didn't do too much work on this. I have old patches for this in
this tree:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl
Great. This is the reason why I like to always ask first.
The main reason why I never continued with this was that at the time I wrote
this I realized that the control framework needed proper support for what's
now called auto-clusters (i.e. how to handle autofoo/foo controls like
autogain
and gain correctly).
I intended to pick this up at some time, but never got around to it.
I think these patches will still apply with some work, but it needs to be
converted to use the autocluster support that's now in the control
framework.
---
@@ -190,6 +196,7 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
struct ov7670_format_struct *fmt; /* Current format */
unsigned char sat; /* Saturation value */
int hue;/* Hue value */
@@ -1480,10 +1518,14 @@ static int ov7670_s_register(struct
v4l2_subdev *sd, struct v4l2_dbg_register *r
/*
--- */
+static const struct v4l2_ctrl_ops ov7670_ctrl_ops = {
+ .s_ctrl = ov7670_s_ctrl,
+};
+
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl = ov7670_s_ctrl,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
.queryctrl = ov7670_queryctrl,
.reset = ov7670_reset,
.init = ov7670_init,
@@ -1551,6 +1600,16 @@ static int ov7670_probe(struct i2c_client *client,
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
+ v4l2_ctrl_handler_init(info-hdl, 1);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
...
...
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return info-hdl.error;
+ }
+ v4l2_ctrl_handler_setup(info-hdl);
+
---
2.- Add the possibility to bypass PLL and clkrc preescaler.
Why? The formula to get the desired frame rate in this chip in YUV is
the following: fps = fpclk / (2 * 510 * 784) This means that for a
desired fps = 30 we need fpclk = 24MHz. For that reason we have a
clean 24MHz xvclk input
[RFC PATCH v8] media: add v4l2 subdev driver for S5K4ECGX sensor
This patch adds driver for S5K4ECGX sensor with embedded ISP SoC, S5K4ECGX, which is a 5M CMOS Image sensor from Samsung The driver implements preview mode of the S5K4ECGX sensor. capture (snapshot) operation, face detection are missing now. Following controls are supported: contrast/saturation/brightness/sharpness Signed-off-by: Sangwook Lee sangwook@linaro.org Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Cc: Francesco Lavra francescolavra...@gmail.com Cc: Scott Bambrough scott.bambro...@linaro.org Cc: Homin Lee suap...@insignal.co.kr --- Changes since v7: - added gpio free function - fixed return value of power function Changes since v6: - fixed alignment issue from Francesco, Sylwester Changes since v5: - deleted dummy lines - fixed pointer errors in handling firmware - updated comments - added le32_to_cpu,le16_to_cpu Changes since v4: - replaced register tables with the function from Sylwester - updated firmware parsing function with CRC32 check firmware generator from user space: git://git.linaro.org/people/sangwook/fimc-v4l2-app.git Changes since v3: - used request_firmware to configure initial settings - added parsing functions to read initial settings - updated regulator API - reduced preview setting tables by experiment Changes since v2: - added GPIO (reset/stby) and regulators - updated I2C read/write, based on s5k6aa datasheet - fixed set_fmt errors - reduced register tables a bit - removed vmalloc Changes since v1: - fixed s_stream(0) when it called twice - changed mutex_X position to be used when strictly necessary - add additional s_power(0) in case that error happens - update more accurate debugging statements - remove dummy else drivers/media/i2c/Kconfig|7 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4ecgx.c | 1017 ++ include/media/s5k4ecgx.h | 37 ++ 4 files changed, 1062 insertions(+) create mode 100644 drivers/media/i2c/s5k4ecgx.c create mode 100644 include/media/s5k4ecgx.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 9a5a059..55b3bbb 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -484,6 +484,13 @@ config VIDEO_S5K6AA This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M camera sensor with an embedded SoC image signal processor. +config VIDEO_S5K4ECGX +tristate Samsung S5K4ECGX sensor support +depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API +---help--- + This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M + camera sensor with an embedded SoC image signal processor. + source drivers/media/i2c/smiapp/Kconfig comment Flash devices diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 088a460..a720812 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -55,6 +55,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o +obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c new file mode 100644 index 000..7b455e1 --- /dev/null +++ b/drivers/media/i2c/s5k4ecgx.c @@ -0,0 +1,1017 @@ +/* + * Driver for s5k4ecgx (5MP Camera) from Samsung + * a quarter-inch optical format 1.4 micron 5 megapixel (Mp) + * CMOS image sensor. + * + * Copyright (C) 2012, Linaro, Sangwook Lee sangwook@linaro.org + * Copyright (C) 2012, Insignal Co,. Ltd, Homin Lee suap...@insignal.co.kr + * + * Based on s5k6aa, noon010pc30 driver + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include linux/clk.h +#include linux/crc32.h +#include linux/ctype.h +#include linux/delay.h +#include linux/firmware.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/module.h +#include linux/regulator/consumer.h +#include linux/slab.h +#include asm/unaligned.h + +#include media/media-entity.h +#include media/s5k4ecgx.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-mediabus.h +#include media/v4l2-subdev.h + +static int debug; +module_param(debug, int, 0644); + +#define S5K4ECGX_DRIVER_NAME s5k4ecgx +#define S5K4ECGX_FIRMWARE s5k4ecgx.bin + +/* Firmware revision information */ +#define REG_FW_REVISION0x71a6 +#define REG_FW_VERSION 0x71a4 +#define S5K4ECGX_REVISION_1_1 0x11 +#define S5K4ECGX_FW_VERSION0x4ec0 + +/*
Re: Improving ov7670 sensor driver.
On 13 September 2012 13:00, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu 13 September 2012 12:47:53 javier Martin wrote:
Hi Hans,
thank you for your response.
On 13 September 2012 12:07, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu 13 September 2012 11:48:17 javier Martin wrote:
Hi,
our new i.MX27 based platform (Visstrim-SM20) uses an ov7675 sensor
attached to the CSI interface. Apparently, this sensor is fully
compatible with the old ov7670. For this reason, it seems rather
sensible that they should share the same driver: ov7670.c
One of the challenges we have to face is that capture video support
for our platform is mx2_camera.c, which is a soc-camera host driver;
while ov7670.c was developed for being used as part of a more complex
video card.
Here is the list of current users of ov7670:
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/ov519.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/sn9c20x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/vc032x.c
These do not actually use the ov7670 driver. They program it themselves.
It would be nice if the gspca driver would get support for subdevs, but
that's a separate topic.
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/via-camera.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/marvell-ccic/mcam-core.c
These are basically the improvements we need to make to this driver in
order to satisfy our needs:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
2.- Add the possibility to bypass PLL and clkrc preescaler.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
4.- Disable pixclk during horizontal blanking.
5.- min_height, min_width should be respected in try_fmt().
6.- Pass platform data when used with a soc-camera host driver.
7.- Add V4L2_CID_POWER_LINE_FREQUENCY ctrl.
I will try to summarize below why we need to accomplish each of the
previous tasks and what solution we propose for them:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
Why? Because soc-camera needs to inherit v4l2 subdevice controls in
order to expose them to user space.
How? Something like the following, incomplete, patch:
Luckily you didn't do too much work on this. I have old patches for this in
this tree:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl
Great. This is the reason why I like to always ask first.
The main reason why I never continued with this was that at the time I
wrote
this I realized that the control framework needed proper support for what's
now called auto-clusters (i.e. how to handle autofoo/foo controls like
autogain
and gain correctly).
I intended to pick this up at some time, but never got around to it.
I think these patches will still apply with some work, but it needs to be
converted to use the autocluster support that's now in the control
framework.
---
@@ -190,6 +196,7 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
struct ov7670_format_struct *fmt; /* Current format */
unsigned char sat; /* Saturation value */
int hue;/* Hue value */
@@ -1480,10 +1518,14 @@ static int ov7670_s_register(struct
v4l2_subdev *sd, struct v4l2_dbg_register *r
/*
--- */
+static const struct v4l2_ctrl_ops ov7670_ctrl_ops = {
+ .s_ctrl = ov7670_s_ctrl,
+};
+
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl = ov7670_s_ctrl,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
.queryctrl = ov7670_queryctrl,
.reset = ov7670_reset,
.init = ov7670_init,
@@ -1551,6 +1600,16 @@ static int ov7670_probe(struct i2c_client *client,
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
+ v4l2_ctrl_handler_init(info-hdl, 1);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
...
...
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return info-hdl.error;
+ }
+ v4l2_ctrl_handler_setup(info-hdl);
+
---
2.- Add the possibility to bypass PLL and clkrc preescaler.
Why? The formula to get the desired frame rate in this chip in YUV is
the following: fps = fpclk / (2 * 510 * 784) This means that for a
desired fps = 30 we need
Re: [PATCH v5 0/13] Initial i.MX5/CODA7 support for the CODA driver
Am Donnerstag, den 13.09.2012, 09:51 +0200 schrieb javier Martin: If you want to speed up the process and you have you could send a pull request to Mauro. Should I include the four patches below in the pull request, or wait for them to hit staging/for_v3.7 ? But be careful with the following patches that have been sent to the list after the initial support of the driver and before these series: http://patchwork.linuxtv.org/patch/14048/ https://patchwork.kernel.org/patch/1367011/ https://patchwork.kernel.org/patch/1363331/ https://patchwork.kernel.org/patch/1352551/ regards Philipp -- 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 1/5] video: Add generic display panel core
On Thu, Sep 13, 2012 at 03:40:40AM +0200, Laurent Pinchart wrote:
Hi Sascha,
+int panel_get_modes(struct panel *panel, const struct fb_videomode
**modes)
+{
+ if (!panel-ops || !panel-ops-get_modes)
+ return 0;
+
+ return panel-ops-get_modes(panel, modes);
+}
+EXPORT_SYMBOL_GPL(panel_get_modes);
You have seen my of videomode helper proposal. One result there was that
we want to have ranges for the margin/synclen fields. Does it make sense
to base this new panel framework on a more sophisticated internal
reprentation of the panel parameters?
I think it does, yes. We need a common video mode structure, and the panel
framework should use it. I'll try to rebase my patches on top of your
proposal. Have you posted the latest version ?
V2 is the newest version. I'd like to implement ranges for the display
timings which then makes for a new common video mode structure, which
then could be used by drm and fbdev, probably with helper functions to
convert from common videomode to drm/fbdev specific variants.
This could then be converted to struct fb_videomode / struct
drm_display_mode as needed. This would also make it more suitable for drm
drivers which are not interested in struct fb_videomode.
Related to this I suggest to change the API to be able to iterate over
the different modes, like:
struct videomode *panel_get_mode(struct panel *panel, int num);
This was we do not have to have an array of modes in memory, which may
be a burden for some panel drivers.
I currently have mixed feelings about this. Both approaches have pros and
cons. Iterating over the modes would be more complex for drivers that use
panels, and would be race-prone if the modes can change at runtime (OK, this
isn't supported by the current panel API proposal).
I just remember that the array approach was painful when I worked on an
fbdev driver some time ago. There some possible modes came from platform_data,
other modes were default modes in the driver and all had to be merged
into a single array. I don't remember the situation exactly, but it
would have been simpler if it had been a list instead of an array.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 v5 0/13] Initial i.MX5/CODA7 support for the CODA driver
Hi Philipp, On 13 September 2012 13:24, Philipp Zabel p.za...@pengutronix.de wrote: Am Donnerstag, den 13.09.2012, 09:51 +0200 schrieb javier Martin: If you want to speed up the process and you have you could send a pull request to Mauro. Should I include the four patches below in the pull request, or wait for them to hit staging/for_v3.7 ? I think you should include them. In fact it could be more comfortable for you to apply them before your series and rebase those trivial patches instead of doing the opposite. Unless you have developed your series on top of the four patches below, which I think you didn't. Or maybe a rebase isn't necessary and the patches apply cleanly. I haven't tried. But be careful with the following patches that have been sent to the list after the initial support of the driver and before these series: http://patchwork.linuxtv.org/patch/14048/ https://patchwork.kernel.org/patch/1367011/ https://patchwork.kernel.org/patch/1363331/ https://patchwork.kernel.org/patch/1352551/ regards Philipp -- 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
Re: Improving ov7670 sensor driver.
On Thu 13 September 2012 13:19:14 javier Martin wrote: On 13 September 2012 13:00, Hans Verkuil hverk...@xs4all.nl wrote: On Thu 13 September 2012 12:47:53 javier Martin wrote: 3.- Adjust vstart/vstop in order to remove an horizontal green line. Why? Currently, in the driver, for VGA, vstart = 10 and vstop = 490. From our tests we found out that vstart = 14, vstop = 494 in order to remove a disgusting horizontal green line in ov7675. How? It seems these sensor aren't provided with a version register or anything similar so I can't think of a clean solution for this yet. Suggestions will be much appreciated. Using platform_data for this is what springs to mind. I had thought about it too but, there Unfinished sentence? Yes. Sorry :) I meant that I had thought about it too but there are one pair of vstart,vstop values for each supported resolution: VGA, QVGA, CIF, QCIF. I could add 'vstart_vga', 'vstop_vga' as platform_data but in the future someone could want to add the same values for the other ones and I don't know if that would be acceptable. Another solution I just came up with would be adding a flag 'version' where we could indicate if we are dealing with an ov7670 or an ov7675 and change those 'vstart', 'vstop' values internally based on this. This could be useful for some other issues in the future. You can actually add support for a ov7675 to the ov7670 driver itself by adding a ov7675 entry to the ov7670_id table. See for example the i2c/saa7127.c driver on how to do that. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: v4l2-ctrl: add a helper function to modify the menu
Hi Laurent,
Thanks for the review.
On Thursday 13 September 2012 06:45 AM, Laurent Pinchart wrote:
Hi Prabhakar,
Thanks for the patch.
On Tuesday 11 September 2012 19:53:38 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
Add a helper function to modify the menu, max and default value
to set.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Rob Landley r...@landley.net
---
Changes for v3:
1: Fixed style/grammer issues as pointed by Hans.
Thanks Hans for providing the description.
Changes for v2:
1: Fixed review comments from Hans, to have return type as
void, add WARN_ON() for fail conditions, allow this fucntion
to modify the menu of custom controls.
Documentation/video4linux/v4l2-controls.txt | 29
drivers/media/v4l2-core/v4l2-ctrls.c| 17 +++
include/media/v4l2-ctrls.h | 11 ++
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt index 43da22b..01d0a82 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -367,6 +367,35 @@ it to 0 means that all menu items are supported.
You set this mask either through the v4l2_ctrl_config struct for a custom
control, or by calling v4l2_ctrl_new_std_menu().
+There are situations where menu items may be device specific. In such cases
the
+framework provides a helper function to change the menu:
+
+void v4l2_ctrl_modify_menu(struct v4l2_ctrl *ctrl, const char * const
*qmenu,
+s32 max, u32 menu_skip_mask, s32 def);
Sorry if this is a stupid question, but wouldn't it be better to add a
function to create a custom menu instead of modifying it afterwards ?
Create a custom menu? eventually everything boils down to modifying the
menu itself.
Regards,
--Prabhakar Lad
+
+A good example is the test pattern control for capture/display/sensors
devices
+that have the capability to generate test patterns. These test patterns are
+hardware specific, so the contents of the menu will vary from device to
device.
+
+This helper function is used to modify the menu, max, mask and the default
+value of the control.
+
+Example:
+
+static const char * const test_pattern[] = {
+Disabled,
+Vertical Bars,
+Solid Black,
+Solid White,
+NULL,
+};
+struct v4l2_ctrl *test_pattern_ctrl =
+v4l2_ctrl_new_std_menu(foo-ctrl_handler, foo_ctrl_ops,
+V4L2_CID_TEST_PATTERN, V4L2_TEST_PATTERN_DISABLED, 0,
+V4L2_TEST_PATTERN_DISABLED);
+
+v4l2_ctrl_modify_menu(test_pattern_ctrl, test_pattern, 3, 0,
+V4L2_TEST_PATTERN_DISABLED);
Custom Controls
===
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: v4l2-ctrl: add a helper function to modify the menu
On Thu 13 September 2012 13:43:36 Prabhakar Lad wrote:
Hi Laurent,
Thanks for the review.
On Thursday 13 September 2012 06:45 AM, Laurent Pinchart wrote:
Hi Prabhakar,
Thanks for the patch.
On Tuesday 11 September 2012 19:53:38 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
Add a helper function to modify the menu, max and default value
to set.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Rob Landley r...@landley.net
---
Changes for v3:
1: Fixed style/grammer issues as pointed by Hans.
Thanks Hans for providing the description.
Changes for v2:
1: Fixed review comments from Hans, to have return type as
void, add WARN_ON() for fail conditions, allow this fucntion
to modify the menu of custom controls.
Documentation/video4linux/v4l2-controls.txt | 29
drivers/media/v4l2-core/v4l2-ctrls.c| 17 +++
include/media/v4l2-ctrls.h | 11 ++
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt index 43da22b..01d0a82 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -367,6 +367,35 @@ it to 0 means that all menu items are supported.
You set this mask either through the v4l2_ctrl_config struct for a custom
control, or by calling v4l2_ctrl_new_std_menu().
+There are situations where menu items may be device specific. In such
cases
the
+framework provides a helper function to change the menu:
+
+void v4l2_ctrl_modify_menu(struct v4l2_ctrl *ctrl, const char * const
*qmenu,
+ s32 max, u32 menu_skip_mask, s32 def);
Sorry if this is a stupid question, but wouldn't it be better to add a
function to create a custom menu instead of modifying it afterwards ?
Create a custom menu? eventually everything boils down to modifying the
menu itself.
Laurent, the reason we went for modifying a standard control is that that
ensures that the control name and type is all standardized. The only thing
that can be changed later is the menu contents.
Regards,
Hans
Regards,
--Prabhakar Lad
+
+A good example is the test pattern control for capture/display/sensors
devices
+that have the capability to generate test patterns. These test patterns
are
+hardware specific, so the contents of the menu will vary from device to
device.
+
+This helper function is used to modify the menu, max, mask and the default
+value of the control.
+
+Example:
+
+ static const char * const test_pattern[] = {
+ Disabled,
+ Vertical Bars,
+ Solid Black,
+ Solid White,
+ NULL,
+ };
+ struct v4l2_ctrl *test_pattern_ctrl =
+ v4l2_ctrl_new_std_menu(foo-ctrl_handler, foo_ctrl_ops,
+ V4L2_CID_TEST_PATTERN, V4L2_TEST_PATTERN_DISABLED, 0,
+ V4L2_TEST_PATTERN_DISABLED);
+
+ v4l2_ctrl_modify_menu(test_pattern_ctrl, test_pattern, 3, 0,
+ V4L2_TEST_PATTERN_DISABLED);
Custom Controls
===
--
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 scan files
Done. [ actually you're lucky - my low-priority RTT is in the range of months atm ... ] Christoph 2012/9/9 Hernán Rossetto hmronl...@gmail.com: It seems these were not added to the dvb-apps mercurial repo. Is this the way to submit these files ? If not, please let me know and I'll follow the right procedure. Thanks again, Hernán.- On Sat, Sep 8, 2012 at 3:54 PM, Ezequiel Garcia elezegar...@gmail.com wrote: Great! On Sat, Sep 8, 2012 at 12:48 AM, Hernán Rossetto hmronl...@gmail.com wrote: Please add the attached files for Argentina and Brazil to the DVB-T scan list. You will notice they have the same content already published here http://www.linuxtv.org/wiki/index.php/ISDB-T_Frequency_Table Muchas gracias! Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pac7302-webcams and libv4lconvert interaction
Hi, On 09/12/2012 04:36 PM, Frank Schäfer wrote: snip And a negative side effect is, that unknown pac7302 devices (with no V4LCONTROL_ROTATED_90_JPEG entry in libv4lconvert) do not work. With a consistent API behavior, they would work fine (output a rotated image). Users would at least know that their device is working and most of them know what to do next. For image rotation, we still need to add an entry to libv4lconvert and to modify it to invert the width and height values in v4l2_pix_format in this case. That is a good point, unfortunately we are stuck with how we are doing things now, since changing things would break the kernel ABI. Also ... The device I have here is a good example: many people reported this device as not working years ago, one of them even got a hint in a forum that this could be a pac7302 device 2 years ago. But with the gpsca-pac7302 driver, he got no picture and gave up. And if I had not started q4vl2 from the terminal and had noticed the error message from libv4lconvert, I would have needed much more time to find out what's wrong... True, OTOH just having this fixed won't help a regular user, as he/she would still need to first add the new usb-id to the pac7302 driver... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving ov7670 sensor driver.
Hi Javier,
I'm not too familiar with soc_camera and ov7670 drivers, so my comments
reflects my understanding of the question, without taking into account
drivers specifics.
Em 13-09-2012 06:48, javier Martin escreveu:
Hi,
our new i.MX27 based platform (Visstrim-SM20) uses an ov7675 sensor
attached to the CSI interface. Apparently, this sensor is fully
compatible with the old ov7670. For this reason, it seems rather
sensible that they should share the same driver: ov7670.c
One of the challenges we have to face is that capture video support
for our platform is mx2_camera.c, which is a soc-camera host driver;
while ov7670.c was developed for being used as part of a more complex
video card.
Here is the list of current users of ov7670:
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/ov519.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/sn9c20x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/gspca/vc032x.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/via-camera.c
http://lxr.linux.no/#linux+v3.5.3/drivers/media/video/marvell-ccic/mcam-core.c
In order to avoid breakages on those drivers, we need to be sure that
none of the changes will alter the register settings used there.
(C/C Hans de Goede, as he is the gspca maintainer)
These are basically the improvements we need to make to this driver in
order to satisfy our needs:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
2.- Add the possibility to bypass PLL and clkrc preescaler.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
4.- Disable pixclk during horizontal blanking.
5.- min_height, min_width should be respected in try_fmt().
6.- Pass platform data when used with a soc-camera host driver.
7.- Add V4L2_CID_POWER_LINE_FREQUENCY ctrl.
Doing one patch per change helps to review the changes individually.
I suspect that it will needed to be tested with the above drivers,
anyway.
I will try to summarize below why we need to accomplish each of the
previous tasks and what solution we propose for them:
1.- Adapt v4l2 controls to the subvevice control framework, with a
proper ctrl handler, etc...
Why? Because soc-camera needs to inherit v4l2 subdevice controls in
order to expose them to user space.
How? Something like the following, incomplete, patch:
---
@@ -190,6 +196,7 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
struct ov7670_format_struct *fmt; /* Current format */
unsigned char sat; /* Saturation value */
int hue;/* Hue value */
@@ -1480,10 +1518,14 @@ static int ov7670_s_register(struct
v4l2_subdev *sd, struct v4l2_dbg_register *r
/* --- */
+static const struct v4l2_ctrl_ops ov7670_ctrl_ops = {
+ .s_ctrl = ov7670_s_ctrl,
+};
+
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl = ov7670_s_ctrl,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
.queryctrl = ov7670_queryctrl,
.reset = ov7670_reset,
.init = ov7670_init,
@@ -1551,6 +1600,16 @@ static int ov7670_probe(struct i2c_client *client,
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
+ v4l2_ctrl_handler_init(info-hdl, 1);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
...
...
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return info-hdl.error;
+ }
+ v4l2_ctrl_handler_setup(info-hdl);
+
---
Tests are required here, but I don't think this would break anything.
2.- Add the possibility to bypass PLL and clkrc preescaler.
Why? The formula to get the desired frame rate in this chip in YUV is
the following: fps = fpclk / (2 * 510 * 784) This means that for a
desired fps = 30 we need fpclk = 24MHz. For that reason we have a
clean 24MHz xvclk input that comes from an oscillator. If we enable
the PLL it internally transforms the 24MHz in 22MHz and thus fps is
not 30 but 27. In order to get 30fps we need to bypass the PLL.
How? Defining a platform flag 'direct_clk' or similar that allows
xvclk being used directly as the pixel clock.
As this should be a new platform data, provided that the old behavior
is to use the old formula, this shouldn't break anything.
3.- Adjust vstart/vstop in order to remove an horizontal green line.
Why? Currently, in the driver, for VGA, vstart = 10 and vstop = 490.
From our tests we found out that
[PATCH 1/4] v4l: vb2: add prepare/finish callbacks to allocators
This patch adds support for prepare/finish callbacks in VB2 allocators.
These callback are used for buffer flushing.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Federico Vaga federico.v...@gmail.com
---
drivers/media/v4l2-core/videobuf2-core.c | 11 +++
include/media/videobuf2-core.h | 7 +++
2 file modificati, 18 inserzioni(+)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 4da3df6..079fa79 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -790,6 +790,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
{
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+ unsigned int plane;
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -800,6 +801,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
dprintk(4, Done processing on buffer %d, state: %d\n,
vb-v4l2_buf.index, vb-state);
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, finish, vb-planes[plane].mem_priv);
+
/* Add the buffer to the done buffers list */
spin_lock_irqsave(q-done_lock, flags);
vb-state = state;
@@ -975,9 +980,15 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const struct
v4l2_buffer *b)
static void __enqueue_in_driver(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb-vb2_queue;
+ unsigned int plane;
vb-state = VB2_BUF_STATE_ACTIVE;
atomic_inc(q-queued_count);
+
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, prepare, vb-planes[plane].mem_priv);
+
q-ops-buf_queue(vb);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8dd9b6c..f374f99 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -41,6 +41,10 @@ struct vb2_fileio_data;
* argument to other ops in this structure
* @put_userptr: inform the allocator that a USERPTR buffer will no longer
* be used
+ * @prepare: called everytime the buffer is passed from userspace to the
+ * driver, usefull for cache synchronisation, optional
+ * @finish:called everytime the buffer is passed back from the driver
+ * to the userspace, also optional
* @vaddr: return a kernel virtual address to a given memory buffer
* associated with the passed private structure or NULL if no
* such mapping exists
@@ -65,6 +69,9 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
+ void(*prepare)(void *buf_priv);
+ void(*finish)(void *buf_priv);
+
void*(*vaddr)(void *buf_priv);
void*(*cookie)(void *buf_priv);
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] adv7180: remove {query/g_/s_}ctrl
Signed-off-by: Federico Vaga federico.v...@gmail.com
---
drivers/media/i2c/adv7180.c | 3 ---
1 file modificato, 3 rimozioni(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 45ecf8d..43bc2b9 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -402,9 +402,6 @@ static const struct v4l2_subdev_video_ops adv7180_video_ops
= {
static const struct v4l2_subdev_core_ops adv7180_core_ops = {
.g_chip_ident = adv7180_g_chip_ident,
.s_std = adv7180_s_std,
- .queryctrl = v4l2_subdev_queryctrl,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
};
static const struct v4l2_subdev_ops adv7180_ops = {
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
Signed-off-by: Federico Vaga federico.v...@gmail.com
---
drivers/media/v4l2-core/Kconfig | 5 +
drivers/media/v4l2-core/Makefile | 1 +
drivers/media/v4l2-core/videobuf2-dma-streaming.c | 205 ++
include/media/videobuf2-dma-streaming.h | 24 +++
4 file modificati, 235 inserzioni(+)
create mode 100644 drivers/media/v4l2-core/videobuf2-dma-streaming.c
create mode 100644 include/media/videobuf2-dma-streaming.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 0c54e19..60548a7 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -79,3 +79,8 @@ config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+
+config VIDEOBUF2_DMA_STREAMING
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index c2d61d4..0b2756f 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_DMA_STREAMING) += videobuf2-dma-streaming.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/v4l2-core/videobuf2-dma-streaming.c
b/drivers/media/v4l2-core/videobuf2-dma-streaming.c
new file mode 100644
index 000..23475a6
--- /dev/null
+++ b/drivers/media/v4l2-core/videobuf2-dma-streaming.c
@@ -0,0 +1,205 @@
+/*
+ * videobuf2-dma-streaming.c - DMA streaming memory allocator for videobuf2
+ *
+ * Copyright (C) 2012 Federico Vaga federico.v...@gmail.com
+ * *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/pagemap.h
+#include linux/dma-mapping.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-streaming.h
+#include media/videobuf2-memops.h
+
+struct vb2_streaming_conf {
+ struct device *dev;
+};
+struct vb2_streaming_buf {
+ struct vb2_streaming_conf *conf;
+ void*vaddr;
+
+ dma_addr_t dma_handle;
+
+ unsigned long size;
+ struct vm_area_struct *vma;
+
+ atomic_trefcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_dma_streaming_put(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(buf-refcount)) {
+ dma_unmap_single(buf-conf-dev, buf-dma_handle, buf-size,
+DMA_FROM_DEVICE);
+ free_pages_exact(buf-vaddr, buf-size);
+ kfree(buf);
+ }
+
+}
+
+static void *vb2_dma_streaming_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_streaming_conf *conf = alloc_ctx;
+ struct vb2_streaming_buf *buf;
+ int err;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+ buf-vaddr = alloc_pages_exact(size, GFP_KERNEL | GFP_DMA);
+ if (!buf-vaddr) {
+ err = -ENOMEM;
+ goto out;
+ }
+ buf-dma_handle = dma_map_single(conf-dev, buf-vaddr, size,
+DMA_FROM_DEVICE);
+ err = dma_mapping_error(conf-dev, buf-dma_handle);
+ if (err) {
+ dev_err(conf-dev, dma_map_single failed\n);
+
+ free_pages_exact(buf-vaddr, size);
+ buf-vaddr = NULL;
+ goto out_pages;
+ }
+ buf-conf = conf;
+ buf-size = size;
+ buf-handler.refcount = buf-refcount;
+ buf-handler.put = vb2_dma_streaming_put;
+ buf-handler.arg = buf;
+
+ atomic_inc(buf-refcount);
+ return buf;
+
+out_pages:
+ free_pages_exact(buf-vaddr, buf-size);
+out:
+ kfree(buf);
+ return ERR_PTR(err);
+}
+
+static void *vb2_dma_streaming_cookie(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ return (void *)buf-dma_handle;
+}
+
+static void *vb2_dma_streaming_vaddr(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ if (!buf)
+ return NULL;
+ return buf-vaddr;
+}
+
+static unsigned int vb2_dma_streaming_num_users(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ return atomic_read(buf-refcount);
+}
+
+static int vb2_dma_streaming_mmap(void *buf_priv, struct vm_area_struct *vma)
+{
+ struct vb2_streaming_buf
[PATCH 4/4] sta2x11_vip: convert to videobuf2 and control framework
Signed-off-by: Federico Vaga federico.v...@gmail.com
Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com
---
drivers/media/pci/sta2x11/Kconfig |2 +-
drivers/media/pci/sta2x11/sta2x11_vip.c | 1235 ++-
2 file modificati, 411 inserzioni(+), 826 rimozioni(-)
diff --git a/drivers/media/pci/sta2x11/Kconfig
b/drivers/media/pci/sta2x11/Kconfig
index 6749f67..654339f 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -2,7 +2,7 @@ config STA2X11_VIP
tristate STA2X11 VIP Video For Linux
depends on STA2X11
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
- select VIDEOBUF_DMA_CONTIG
+ select VIDEOBUF2_DMA_STREAMING
depends on PCI VIDEO_V4L2 VIRT_TO_BUS
help
Say Y for support for STA2X11 VIP (Video Input Port) capture
diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c
b/drivers/media/pci/sta2x11/sta2x11_vip.c
index 4c10205..93d56da 100644
--- a/drivers/media/pci/sta2x11/sta2x11_vip.c
+++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
@@ -1,6 +1,7 @@
/*
* This is the driver for the STA2x11 Video Input Port.
*
+ * Copyright (C) 2012 ST Microelectronics
* Copyright (C) 2010 WindRiver Systems, Inc.
*
* This program is free software; you can redistribute it and/or modify it
@@ -19,36 +20,30 @@
* The full GNU General Public License is included in this distribution in
* the file called COPYING.
*
- * Author: Andreas Kies andreas.k...@windriver.com
- * Vlad Lungu vlad.lu...@windriver.com
- *
*/
#include linux/types.h
#include linux/kernel.h
#include linux/module.h
#include linux/init.h
-#include linux/vmalloc.h
-
#include linux/videodev2.h
-
#include linux/kmod.h
-
#include linux/pci.h
#include linux/interrupt.h
-#include linux/mutex.h
#include linux/io.h
#include linux/gpio.h
#include linux/i2c.h
#include linux/delay.h
#include media/v4l2-common.h
#include media/v4l2-device.h
+#include media/v4l2-ctrls.h
#include media/v4l2-ioctl.h
-#include media/videobuf-dma-contig.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
+#include media/videobuf2-dma-streaming.h
#include sta2x11_vip.h
-#define DRV_NAME sta2x11_vip
#define DRV_VERSION 1.3
#ifndef PCI_DEVICE_ID_STMICRO_VIP
@@ -63,8 +58,8 @@
#define DVP_TFS0x08
#define DVP_BFO0x0C
#define DVP_BFS0x10
-#define DVP_VTP 0x14
-#define DVP_VBP 0x18
+#define DVP_VTP0x14
+#define DVP_VBP0x18
#define DVP_VMP0x1C
#define DVP_ITM0x98
#define DVP_ITS0x9C
@@ -84,44 +79,24 @@
#define DVP_HLFLN_SD 0x0001
-#define REG_WRITE(vip, reg, value) iowrite32((value), (vip-iomem)+(reg))
-#define REG_READ(vip, reg) ioread32((vip-iomem)+(reg))
-
#define SAVE_COUNT 8
#define AUX_COUNT 3
#define IRQ_COUNT 1
-/**
- * struct sta2x11_vip - All internal data for one instance of device
- * @v4l2_dev: device registered in v4l layer
- * @video_dev: properties of our device
- * @pdev: PCI device
- * @adapter: contains I2C adapter information
- * @register_save_area: All relevant register are saved here during suspend
- * @decoder: contains information about video DAC
- * @format: pixel format, fixed UYVY
- * @std: video standard (e.g. PAL/NTSC)
- * @input: input line for video signal ( 0 or 1 )
- * @users: Number of open of device ( max. 1 )
- * @disabled: Device is in power down state
- * @mutex: ensures exclusive opening of device
- * @slock: for excluse acces of registers
- * @vb_vidq: queue maintained by videobuf layer
- * @capture: linked list of capture buffer
- * @active: struct videobuf_buffer currently beingg filled
- * @started: device is ready to capture frame
- * @closing: device will be shut down
- * @tcount: Number of top frames
- * @bcount: Number of bottom frames
- * @overflow: Number of FIFO overflows
- * @mem_spare: small buffer of unused frame
- * @dma_spare: dma addres of mem_spare
- * @iomem: hardware base address
- * @config: I2C and gpio config from platform
- *
- * All non-local data is accessed via this structure.
- */
+struct vip_buffer {
+ struct vb2_buffer vb;
+ struct list_headlist;
+ dma_addr_t dma;
+};
+static inline struct vip_buffer *to_vip_buffer(struct vb2_buffer *vb2)
+{
+ return container_of(vb2, struct vip_buffer, vb);
+}
+
+struct sta2x11_vip_fh {
+ struct v4l2_fh fh;
+};
struct sta2x11_vip {
struct v4l2_device v4l2_dev;
struct video_device *video_dev;
@@ -129,21 +104,27 @@ struct sta2x11_vip {
struct i2c_adapter *adapter;
unsigned int register_save_area[IRQ_COUNT + SAVE_COUNT + AUX_COUNT];
struct v4l2_subdev *decoder;
- struct v4l2_pix_format format;
- v4l2_std_id std;
- unsigned int input;
- int users;
- int disabled;
- struct mutex mutex; /* exclusive access
RE: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
Hello,
On Thursday, September 13, 2012 3:53 PM Federico Vaga wrote:
Signed-off-by: Federico Vaga federico.v...@gmail.com
A few words explaining why this memory handling module is required or
beneficial will
definitely improve the commit :)
---
drivers/media/v4l2-core/Kconfig | 5 +
drivers/media/v4l2-core/Makefile | 1 +
drivers/media/v4l2-core/videobuf2-dma-streaming.c | 205
++
include/media/videobuf2-dma-streaming.h | 24 +++
4 file modificati, 235 inserzioni(+)
create mode 100644 drivers/media/v4l2-core/videobuf2-dma-streaming.c
create mode 100644 include/media/videobuf2-dma-streaming.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 0c54e19..60548a7 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -79,3 +79,8 @@ config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+
+config VIDEOBUF2_DMA_STREAMING
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
diff --git a/drivers/media/v4l2-core/Makefile
b/drivers/media/v4l2-core/Makefile
index c2d61d4..0b2756f 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_DMA_STREAMING) += videobuf2-dma-streaming.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/v4l2-core/videobuf2-dma-streaming.c
b/drivers/media/v4l2-
core/videobuf2-dma-streaming.c
new file mode 100644
index 000..23475a6
--- /dev/null
+++ b/drivers/media/v4l2-core/videobuf2-dma-streaming.c
@@ -0,0 +1,205 @@
+/*
+ * videobuf2-dma-streaming.c - DMA streaming memory allocator for videobuf2
+ *
+ * Copyright (C) 2012 Federico Vaga federico.v...@gmail.com
+ * *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/pagemap.h
+#include linux/dma-mapping.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-streaming.h
+#include media/videobuf2-memops.h
+
+struct vb2_streaming_conf {
+ struct device *dev;
+};
+struct vb2_streaming_buf {
+ struct vb2_streaming_conf *conf;
+ void*vaddr;
+
+ dma_addr_t dma_handle;
+
+ unsigned long size;
+ struct vm_area_struct *vma;
+
+ atomic_trefcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_dma_streaming_put(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(buf-refcount)) {
+ dma_unmap_single(buf-conf-dev, buf-dma_handle, buf-size,
+ DMA_FROM_DEVICE);
+ free_pages_exact(buf-vaddr, buf-size);
+ kfree(buf);
+ }
+
+}
+
+static void *vb2_dma_streaming_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_streaming_conf *conf = alloc_ctx;
+ struct vb2_streaming_buf *buf;
+ int err;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+ buf-vaddr = alloc_pages_exact(size, GFP_KERNEL | GFP_DMA);
+ if (!buf-vaddr) {
+ err = -ENOMEM;
+ goto out;
+ }
+ buf-dma_handle = dma_map_single(conf-dev, buf-vaddr, size,
+ DMA_FROM_DEVICE);
+ err = dma_mapping_error(conf-dev, buf-dma_handle);
+ if (err) {
+ dev_err(conf-dev, dma_map_single failed\n);
+
+ free_pages_exact(buf-vaddr, size);
+ buf-vaddr = NULL;
+ goto out_pages;
+ }
+ buf-conf = conf;
+ buf-size = size;
+ buf-handler.refcount = buf-refcount;
+ buf-handler.put = vb2_dma_streaming_put;
+ buf-handler.arg = buf;
+
+ atomic_inc(buf-refcount);
+ return buf;
+
+out_pages:
+ free_pages_exact(buf-vaddr, buf-size);
+out:
+ kfree(buf);
+ return ERR_PTR(err);
+}
+
+static void *vb2_dma_streaming_cookie(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ return (void *)buf-dma_handle;
+}
Please change this function to:
static void *vb2_dma_streaming_cookie(void *buf_priv)
{
struct vb2_streaming_buf *buf = buf_priv;
return buf-dma_handle;
}
and add a following static inline to
Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
On Thu 13 September 2012 15:52:47 Federico Vaga wrote:
Signed-off-by: Federico Vaga federico.v...@gmail.com
---
drivers/media/v4l2-core/Kconfig | 5 +
drivers/media/v4l2-core/Makefile | 1 +
drivers/media/v4l2-core/videobuf2-dma-streaming.c | 205
++
include/media/videobuf2-dma-streaming.h | 24 +++
4 file modificati, 235 inserzioni(+)
create mode 100644 drivers/media/v4l2-core/videobuf2-dma-streaming.c
create mode 100644 include/media/videobuf2-dma-streaming.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 0c54e19..60548a7 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -79,3 +79,8 @@ config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+
+config VIDEOBUF2_DMA_STREAMING
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
diff --git a/drivers/media/v4l2-core/Makefile
b/drivers/media/v4l2-core/Makefile
index c2d61d4..0b2756f 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_DMA_STREAMING) += videobuf2-dma-streaming.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/v4l2-core/videobuf2-dma-streaming.c
b/drivers/media/v4l2-core/videobuf2-dma-streaming.c
new file mode 100644
index 000..23475a6
--- /dev/null
+++ b/drivers/media/v4l2-core/videobuf2-dma-streaming.c
@@ -0,0 +1,205 @@
+/*
+ * videobuf2-dma-streaming.c - DMA streaming memory allocator for videobuf2
+ *
+ * Copyright (C) 2012 Federico Vaga federico.v...@gmail.com
+ * *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/pagemap.h
+#include linux/dma-mapping.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-streaming.h
+#include media/videobuf2-memops.h
+
+struct vb2_streaming_conf {
+ struct device *dev;
+};
+struct vb2_streaming_buf {
+ struct vb2_streaming_conf *conf;
+ void*vaddr;
+
+ dma_addr_t dma_handle;
+
+ unsigned long size;
+ struct vm_area_struct *vma;
+
+ atomic_trefcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_dma_streaming_put(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(buf-refcount)) {
+ dma_unmap_single(buf-conf-dev, buf-dma_handle, buf-size,
+ DMA_FROM_DEVICE);
+ free_pages_exact(buf-vaddr, buf-size);
+ kfree(buf);
+ }
+
+}
+
+static void *vb2_dma_streaming_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_streaming_conf *conf = alloc_ctx;
+ struct vb2_streaming_buf *buf;
+ int err;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+ buf-vaddr = alloc_pages_exact(size, GFP_KERNEL | GFP_DMA);
+ if (!buf-vaddr) {
+ err = -ENOMEM;
+ goto out;
+ }
+ buf-dma_handle = dma_map_single(conf-dev, buf-vaddr, size,
+ DMA_FROM_DEVICE);
+ err = dma_mapping_error(conf-dev, buf-dma_handle);
+ if (err) {
+ dev_err(conf-dev, dma_map_single failed\n);
+
+ free_pages_exact(buf-vaddr, size);
+ buf-vaddr = NULL;
+ goto out_pages;
+ }
+ buf-conf = conf;
+ buf-size = size;
+ buf-handler.refcount = buf-refcount;
+ buf-handler.put = vb2_dma_streaming_put;
+ buf-handler.arg = buf;
+
+ atomic_inc(buf-refcount);
+ return buf;
+
+out_pages:
+ free_pages_exact(buf-vaddr, buf-size);
+out:
+ kfree(buf);
+ return ERR_PTR(err);
+}
+
+static void *vb2_dma_streaming_cookie(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ return (void *)buf-dma_handle;
+}
+
+static void *vb2_dma_streaming_vaddr(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ if (!buf)
+ return NULL;
+ return buf-vaddr;
+}
+
+static unsigned int vb2_dma_streaming_num_users(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ return atomic_read(buf-refcount);
+}
+
+static int
[PATCH] dvb_frontend: Multistream support
Multistream support for DVBAPI. Version increased to 5.8.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index bb51edf..a6a6839 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -62,6 +62,7 @@ typedef enum fe_caps {
FE_CAN_8VSB = 0x20,
FE_CAN_16VSB= 0x40,
FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace
for newer APIs, indicate this. */
+ FE_CAN_MULTISTREAM = 0x400, /* frontend supports
multistream filtering */
FE_CAN_TURBO_FEC= 0x800, /* frontend supports
turbo fec modulation */
FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd
generation modulation (DVB-S2) */
FE_NEEDS_BENDING= 0x2000, /* not supported anymore,
don't use (frontend requires frequency bending) */
@@ -338,9 +339,9 @@ struct dvb_frontend_event {
#define DTV_ISDBT_LAYER_ENABLED41
-#define DTV_ISDBS_TS_ID42
-
-#define DTV_DVBT2_PLP_ID 43
+#define DTV_STREAM_ID 42
+#define DTV_ISDBS_TS_ID_LEGACY DTV_STREAM_ID
+#define DTV_DVBT2_PLP_ID_LEGACY43
#define DTV_ENUM_DELSYS44
@@ -436,6 +437,7 @@ enum atscmh_rs_code_mode {
ATSCMH_RSCODE_RES= 3,
};
+#define NO_STREAM_ID_FILTER(~0U)
struct dtv_cmds_h {
char*name; /* A display name for debugging purposes */
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index db309db..33996a0 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -370,11 +370,8 @@ struct dtv_frontend_properties {
u8 interleaving;
} layer[3];
- /* ISDB-T specifics */
- u32 isdbs_ts_id;
-
- /* DVB-T2 specifics */
- u32 dvbt2_plp_id;
+ /* Multistream specifics */
+ u32 stream_id;
/* ATSC-MH specifics */
u8 atscmh_fic_ver;
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index aa4d4d8..fc0c0ca 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -946,8 +946,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
c-layer[i].segment_count = 0;
}
- c-isdbs_ts_id = 0;
- c-dvbt2_plp_id = 0;
+ c-stream_id = NO_STREAM_ID_FILTER;
switch (c-delivery_system) {
case SYS_DVBS:
@@ -1018,8 +1017,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
_DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
- _DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
- _DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
+ _DTV_CMD(DTV_STREAM_ID, 1, 0),
+ _DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),
/* Get */
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1387,11 +1386,11 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
tvp-u.data = c-layer[2].interleaving;
break;
- case DTV_ISDBS_TS_ID:
- tvp-u.data = c-isdbs_ts_id;
- break;
- case DTV_DVBT2_PLP_ID:
- tvp-u.data = c-dvbt2_plp_id;
+
+ /* Multistream support */
+ case DTV_STREAM_ID:
+ case DTV_DVBT2_PLP_ID_LEGACY:
+ tvp-u.data = c-stream_id;
break;
/* ATSC-MH */
@@ -1779,11 +1778,11 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
c-layer[2].interleaving = tvp-u.data;
break;
- case DTV_ISDBS_TS_ID:
- c-isdbs_ts_id = tvp-u.data;
- break;
- case DTV_DVBT2_PLP_ID:
- c-dvbt2_plp_id = tvp-u.data;
+
+ /* Multistream support */
+ case DTV_STREAM_ID:
+ case DTV_DVBT2_PLP_ID_LEGACY:
+ c-stream_id = tvp-u.data;
break;
/* ATSC-MH */
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 70c2c7e..20e5eac 100644
--- a/include/linux/dvb/version.h
+++ b/include/linux/dvb/version.h
@@ -24,6 +24,6 @@
#define _DVBVERSION_H_
#define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 7
+#define DVB_API_VERSION_MINOR 8
#endif /*_DVBVERSION_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
[PATCH] stv090x: Multistream support
Multistream support for stv090x
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/dvb-frontends/stv090x.c
b/drivers/media/dvb-frontends/stv090x.c
index ea86a56..13caec0 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -3425,6 +3425,33 @@ err:
return -1;
}
+static int stv090x_set_mis(struct stv090x_state *state, int mis)
+{
+ u32 reg;
+
+ if (mis 0 || mis 255) {
+ dprintk(FE_DEBUG, 1, Disable MIS filtering);
+ reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+ STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x00);
+ if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) 0)
+ goto err;
+ } else {
+ dprintk(FE_DEBUG, 1, Enable MIS filtering - %d, mis);
+ reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+ STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x01);
+ if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) 0)
+ goto err;
+ if (STV090x_WRITE_DEMOD(state, ISIENTRY, mis) 0)
+ goto err;
+ if (STV090x_WRITE_DEMOD(state, ISIBITENA, 0xff) 0)
+ goto err;
+ }
+ return 0;
+err:
+ dprintk(FE_ERROR, 1, I/O error);
+ return -1;
+}
+
static enum dvbfe_search stv090x_search(struct dvb_frontend *fe)
{
struct stv090x_state *state = fe-demodulator_priv;
@@ -3447,6 +3474,8 @@ static enum dvbfe_search stv090x_search(struct
dvb_frontend *fe)
state-search_range = 500;
}
+ stv090x_set_mis(state, props-stream_id);
+
if (stv090x_algo(state) == STV090x_RANGEOK) {
dprintk(FE_DEBUG, 1, Search success!);
return DVBFE_ALGO_SEARCH_SUCCESS;
@@ -4798,6 +4827,9 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
}
}
+ if (state-internal-dev_ver = 0x30)
+ state-frontend.ops.info.caps |= FE_CAN_MULTISTREAM;
+
/* workaround for stuck DiSEqC output */
if (config-diseqc_envelope_mode)
stv090x_send_diseqc_burst(state-frontend, SEC_MINI_A);
--
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] va1j5jf8007s: Multistream support
Update multistream support.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/pci/pt1/va1j5jf8007s.c
b/drivers/media/pci/pt1/va1j5jf8007s.c
index d980dfb..1b637b7 100644
--- a/drivers/media/pci/pt1/va1j5jf8007s.c
+++ b/drivers/media/pci/pt1/va1j5jf8007s.c
@@ -329,8 +329,8 @@ va1j5jf8007s_set_ts_id(struct va1j5jf8007s_state *state)
u8 buf[3];
struct i2c_msg msg;
- ts_id = state-fe.dtv_property_cache.isdbs_ts_id;
- if (!ts_id)
+ ts_id = state-fe.dtv_property_cache.stream_id;
+ if (!ts_id || ts_id == NO_STREAM_ID_FILTER)
return 0;
buf[0] = 0x8f;
@@ -356,8 +356,8 @@ va1j5jf8007s_check_ts_id(struct va1j5jf8007s_state *state,
int *lock)
struct i2c_msg msgs[2];
u32 ts_id;
- ts_id = state-fe.dtv_property_cache.isdbs_ts_id;
- if (!ts_id) {
+ ts_id = state-fe.dtv_property_cache.stream_id;
+ if (!ts_id || ts_id == NO_STREAM_ID_FILTER) {
*lock = 1;
return 0;
}
@@ -587,7 +587,8 @@ static struct dvb_frontend_ops va1j5jf8007s_ops = {
.frequency_stepsize = 1000,
.caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO |
FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO |
- FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
+ FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO |
+ FE_CAN_MULTISTREAM,
},
.read_snr = va1j5jf8007s_read_snr,
--
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] DocBook: Multistream support
Multistream support for DVBAPI. If my english bad - please fix it somebody :)
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index d188be9..c7c14be 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -793,15 +793,16 @@ typedef enum fe_hierarchy {
} fe_hierarchy_t;
/programlisting
/section
- section id=DTV-ISDBS-TS-ID
- titleconstantDTV_ISDBS_TS_ID/constant/title
- paraCurrently unused./para
+ section id=DTV-STREAM-ID
+ titleconstantDTV_STREAM_ID/constant/title
+ paraDVB-S2/T2, ISDB-S supports transmission several streams via a
single carrier.
+ Depend from standards can be used for many purposes. This
property enable
+ substream filtering. For DVB-S2/T2 valid substream id from 0 to
255, for ISDB from 1 to 65535.
+ Anoter id values disable filtering (better use special define
NO_STREAM_ID_FILTER)./para
/section
- section id=DTV-DVBT2-PLP-ID
- titleconstantDTV_DVBT2_PLP_ID/constant/title
- paraDVB-T2 supports Physical Layer Pipes (PLP) to allow
transmission of
- many data types via a single multiplex. The API will
soon support this
- at which point this section will be expanded./para
+ section id=DTV-DVBT2-PLP-ID-LEGACY
+ titleconstantDTV_DVBT2_PLP_ID_LEGACY/constant/title
+ paraObsolete, replaced with DTV_STREAM_ID./para
/section
section id=DTV-ENUM-DELSYS
titleconstantDTV_ENUM_DELSYS/constant/title
@@ -869,7 +870,7 @@ enum fe_interleaving {
listitemparalink
linkend=DTV-GUARD-INTERVALconstantDTV_GUARD_INTERVAL/constant/link/para/listitem
listitemparalink
linkend=DTV-TRANSMISSION-MODEconstantDTV_TRANSMISSION_MODE/constant/link/para/listitem
listitemparalink
linkend=DTV-HIERARCHYconstantDTV_HIERARCHY/constant/link/para/listitem
- listitemparalink
linkend=DTV-DVBT2-PLP-IDconstantDTV_DVBT2_PLP_ID/constant/link/para/listitem
+ listitemparalink
linkend=DTV-STREAM-IDconstantDTV_STREAM_ID/constant/link/para/listitem
/itemizedlist
/section
section id=isdbt
@@ -1048,6 +1049,7 @@ enum fe_interleaving {
listitemparalink
linkend=DTV-MODULATIONconstantDTV_MODULATION/constant/link/para/listitem
listitemparalink
linkend=DTV-PILOTconstantDTV_PILOT/constant/link/para/listitem
listitemparalink
linkend=DTV-ROLLOFFconstantDTV_ROLLOFF/constant/link/para/listitem
+ listitemparalink
linkend=DTV-STREAM-IDconstantDTV_STREAM_ID/constant/link/para/listitem
/itemizedlist
/section
section id=turbo-params
@@ -1070,7 +1072,7 @@ enum fe_interleaving {
listitemparalink
linkend=DTV-SYMBOL-RATEconstantDTV_SYMBOL_RATE/constant/link/para/listitem
listitemparalink
linkend=DTV-INNER-FECconstantDTV_INNER_FEC/constant/link/para/listitem
listitemparalink
linkend=DTV-VOLTAGEconstantDTV_VOLTAGE/constant/link/para/listitem
- listitemparalink
linkend=DTV-ISDBS-TS-IDconstantDTV_ISDBS_TS_ID/constant/link/para/listitem
+ listitemparalink
linkend=DTV-STREAM-IDconstantDTV_STREAM_ID/constant/link/para/listitem
/itemizedlist
/section
/section
diff --git a/Documentation/DocBook/media/dvb/frontend.xml
b/Documentation/DocBook/media/dvb/frontend.xml
index 950bdfb..426c252 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -101,6 +101,7 @@ a specific frontend type./para
FE_CAN_8VSB = 0x20,
FE_CAN_16VSB = 0x40,
FE_HAS_EXTENDED_CAPS = 0x80,
+ FE_CAN_MULTISTREAM= 0x400,
FE_CAN_TURBO_FEC = 0x800,
FE_CAN_2G_MODULATION = 0x1000,
FE_NEEDS_BENDING = 0x2000,
diff --git a/Documentation/DocBook/media/dvb/intro.xml
b/Documentation/DocBook/media/dvb/intro.xml
index 170064a..2048b53 100644
--- a/Documentation/DocBook/media/dvb/intro.xml
+++ b/Documentation/DocBook/media/dvb/intro.xml
@@ -205,7 +205,7 @@ a partial path like:/para
additional include file emphasis
role=ttlinux/dvb/version.h/emphasis exists, which defines the
constant emphasis role=ttDVB_API_VERSION/emphasis. This document
-describes emphasis role=ttDVB_API_VERSION 5.4/emphasis.
+describes emphasis role=ttDVB_API_VERSION 5.8/emphasis.
/para
/section
--
To unsubscribe from this list: send the line
[PATCH] s5p-csis: Add transmission errors logging
Add hardware event/error counters which can be dumped into the kernel
log through VIDIOC_LOG_STATUS ioctl. The counters are reset in each
s_stream(1) call. Any errors are logged after streaming is turned off.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/mipi-csis.c | 159
1 file changed, 139 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 2f73d9e..3bfee3a 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -31,7 +31,7 @@
static int debug;
module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, Debug level (0-1));
+MODULE_PARM_DESC(debug, Debug level (0-2));
/* Register map definition */
@@ -60,10 +60,38 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
#define S5PCSIS_CFG_FMT_MASK (0x3f 2)
#define S5PCSIS_CFG_NR_LANE_MASK 3
-/* Interrupt mask. */
+/* Interrupt mask */
#define S5PCSIS_INTMSK 0x10
-#define S5PCSIS_INTMSK_EN_ALL 0xf03f
+#define S5PCSIS_INTMSK_EN_ALL 0xf000103f
+#define S5PCSIS_INTMSK_EVEN_BEFORE (1 31)
+#define S5PCSIS_INTMSK_EVEN_AFTER (1 30)
+#define S5PCSIS_INTMSK_ODD_BEFORE (1 29)
+#define S5PCSIS_INTMSK_ODD_AFTER (1 28)
+#define S5PCSIS_INTMSK_ERR_SOT_HS (1 12)
+#define S5PCSIS_INTMSK_ERR_LOST_FS (1 5)
+#define S5PCSIS_INTMSK_ERR_LOST_FE (1 4)
+#define S5PCSIS_INTMSK_ERR_OVER(1 3)
+#define S5PCSIS_INTMSK_ERR_ECC (1 2)
+#define S5PCSIS_INTMSK_ERR_CRC (1 1)
+#define S5PCSIS_INTMSK_ERR_UNKNOWN (1 0)
+
+/* Interrupt source */
#define S5PCSIS_INTSRC 0x14
+#define S5PCSIS_INTSRC_EVEN_BEFORE (1 31)
+#define S5PCSIS_INTSRC_EVEN_AFTER (1 30)
+#define S5PCSIS_INTSRC_EVEN(0x3 30)
+#define S5PCSIS_INTSRC_ODD_BEFORE (1 29)
+#define S5PCSIS_INTSRC_ODD_AFTER (1 28)
+#define S5PCSIS_INTSRC_ODD (0x3 28)
+#define S5PCSIS_INTSRC_NON_IMAGE_DATA (0xff 28)
+#define S5PCSIS_INTSRC_ERR_SOT_HS (0xf 12)
+#define S5PCSIS_INTSRC_ERR_LOST_FS (1 5)
+#define S5PCSIS_INTSRC_ERR_LOST_FE (1 4)
+#define S5PCSIS_INTSRC_ERR_OVER(1 3)
+#define S5PCSIS_INTSRC_ERR_ECC (1 2)
+#define S5PCSIS_INTSRC_ERR_CRC (1 1)
+#define S5PCSIS_INTSRC_ERR_UNKNOWN (1 0)
+#define S5PCSIS_INTSRC_ERRORS 0xf03f
/* Pixel resolution */
#define S5PCSIS_RESOL 0x2c
@@ -93,6 +121,29 @@ enum {
ST_SUSPENDED= 4,
};
+struct s5pcsis_event {
+ u32 mask;
+ const char * const name;
+ unsigned int counter;
+};
+
+static const struct s5pcsis_event s5pcsis_events[] = {
+ /* Errors */
+ { S5PCSIS_INTSRC_ERR_SOT_HS,SOT Error },
+ { S5PCSIS_INTSRC_ERR_LOST_FS, Lost Frame Start Error },
+ { S5PCSIS_INTSRC_ERR_LOST_FE, Lost Frame End Error },
+ { S5PCSIS_INTSRC_ERR_OVER, FIFO Overflow Error },
+ { S5PCSIS_INTSRC_ERR_ECC, ECC Error },
+ { S5PCSIS_INTSRC_ERR_CRC, CRC Error },
+ { S5PCSIS_INTSRC_ERR_UNKNOWN, Unknown Error },
+ /* Non-image data receive events */
+ { S5PCSIS_INTSRC_EVEN_BEFORE, Non-image data before even frame },
+ { S5PCSIS_INTSRC_EVEN_AFTER,Non-image data after even frame },
+ { S5PCSIS_INTSRC_ODD_BEFORE,Non-image data before odd frame },
+ { S5PCSIS_INTSRC_ODD_AFTER, Non-image data after odd frame },
+};
+#define S5PCSIS_NUM_EVENTS ARRAY_SIZE(s5pcsis_events)
+
/**
* struct csis_state - the driver's internal state data structure
* @lock: mutex serializing the subdev and power management operations,
@@ -101,11 +152,14 @@ enum {
* @sd: v4l2_subdev associated with CSIS device instance
* @pdev: CSIS platform device
* @regs: mmaped I/O registers memory
+ * @supplies: CSIS regulator supplies
* @clock: CSIS clocks
* @irq: requested s5p-mipi-csis irq number
* @flags: the state variable for power and streaming control
* @csis_fmt: current CSIS pixel format
* @format: common media bus format for the source and sink pad
+ * @slock: spinlock protecting structure members below
+ * @events: MIPI-CSIS event (error) counters
*/
struct csis_state {
struct mutex lock;
@@ -119,6 +173,9 @@ struct csis_state {
u32 flags;
const struct csis_pix_format *csis_fmt;
struct v4l2_mbus_framefmt format;
+
+ struct spinlock slock;
+ struct s5pcsis_event events[S5PCSIS_NUM_EVENTS];
};
/**
@@ -292,17 +349,6 @@ err:
return -ENXIO;
}
-static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
-{
- struct csis_state *state = sd_to_csis_state(sd);
- struct device *dev = state-pdev-dev;
-
- if (on)
- return pm_runtime_get_sync(dev);
-
- return
Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
typo: steaming - streaming :-) fixed The header and esp. the source could really do with more documentation. It is not at all clear from the code what the dma-streaming allocator does and how it differs from other allocators. The other allocators are not documented and to understand them I read the code. All the memory allocators reflect a kind of DMA interface: SG for scatter/gather, contig for choerent and (now) streaming for streaming. So, I'm not sure to understand what do you think is the correct way to document a memory allocator; I can write one or two lines of comment to summarize each function. what do you think? -- Federico Vaga -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
On Thursday, September 13, 2012 3:53 PM Federico Vaga wrote:
Signed-off-by: Federico Vaga federico.v...@gmail.com
A few words explaining why this memory handling module is required or
beneficial will definitely improve the commit :)
ok, I will write some lines
+static void *vb2_dma_streaming_cookie(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ return (void *)buf-dma_handle;
+}
Please change this function to:
static void *vb2_dma_streaming_cookie(void *buf_priv)
{
struct vb2_streaming_buf *buf = buf_priv;
return buf-dma_handle;
}
and add a following static inline to
include/media/videobuf2-dma-streaming.h:
static inline dma_addr_t
vb2_dma_streaming_plane_paddr(struct vb2_buffer *vb, unsigned int
plane_no) {
dma_addr_t *dma_addr = vb2_plane_cookie(vb, plane_no);
return *dma_addr;
}
Do not use 'cookie' callback directly in the driver, the driver should
use the above proxy.
The buf-dma_handle workaround is required for some possible
configurations with 64bit dma addresses, see commit 472af2b05bdefc.
ACK.
--
Federico Vaga
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Initial i.MX5/CODA7 support for the CODA driver
Hi Mauro, please pull the following patches that fix a few issues in the coda driver and add initial firmware loading and encoding support for the CODA7 series VPU contained in i.MX51 and i.MX53 SoCs. The following changes since commit 79e8c7bebb467bbc3f2514d75bba669a3f354324: Merge tag 'v3.6-rc3' into staging/for_v3.7 (2012-08-24 11:25:10 -0300) are available in the git repository at: http://git.pengutronix.de/git/pza/linux.git coda/for_v3.7 for you to fetch changes up to b50252c494ad56b88904811b1ac2d4fee1972446: media: coda: set up buffers to be sized as negotiated with s_fmt (2012-09-13 17:14:36 +0200) Ezequiel Garcia (1): coda: Remove unneeded struct vb2_queue clear on queue_init() Ezequiel García (1): coda: Don't check vb2_queue_init() return value Philipp Zabel (13): media: coda: firmware loading for 64-bit AXI bus width media: coda: add i.MX53 / CODA7541 platform support media: coda: fix IRAM/AXI handling for i.MX53 media: coda: allocate internal framebuffers separately from v4l2 buffers media: coda: ignore coda busy status in coda_job_ready media: coda: keep track of active instances media: coda: stop all queues in case of lockup media: coda: enable user pointer support media: coda: wait for picture run completion in start/stop_streaming media: coda: fix sizeimage setting in try_fmt media: coda: add horizontal / vertical flipping support media: coda: add byte size slice limit control media: coda: set up buffers to be sized as negotiated with s_fmt Richard Zhao (1): media: coda: remove duplicated call of fh_to_ctx in vidioc_s_fmt_vid_out Sylwester Nawrocki (1): coda: Add V4L2_CAP_VIDEO_M2M capability flag drivers/media/platform/Kconfig |3 +- drivers/media/platform/coda.c | 442 +--- drivers/media/platform/coda.h | 30 ++- 3 files changed, 348 insertions(+), 127 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bt8xx: Add video4linux control V4L2_CID_COLOR_KILLER.
Added V4L2_CID_COLOR_KILLER control to the bt8xx driver.
The control V4L2_CID_PRIVATE_CHROMA_AGC was changed too because
with this change the bttv driver must touch two bits in the
SC Loop Control Registers, for controls V4L2_CID_COLOR_KILLER
and V4L2_CID_PRIVATE_CHROMA_AGC.
---
Documentation/video4linux/bttv/Insmod-options | 1 +
drivers/media/video/bt8xx/bttv-driver.c | 36 ---
drivers/media/video/bt8xx/bttvp.h | 1 +
3 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/Documentation/video4linux/bttv/Insmod-options
b/Documentation/video4linux/bttv/Insmod-options
index 14c065fa..089e961 100644
--- a/Documentation/video4linux/bttv/Insmod-options
+++ b/Documentation/video4linux/bttv/Insmod-options
@@ -53,6 +53,7 @@ bttv.o
quality which leading to unwanted sound
dropouts.
chroma_agc=0/1 AGC of chroma signal, off by default.
+ color_killer=0/1 Low color detection and removal, off by
default
adc_crush=0/1 Luminance ADC crush, on by default.
i2c_udelay= Allow reduce I2C speed. Default is 5 usecs
(meaning 66,67 Kbps). The default is the
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index e581b37..7208d5a 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -93,6 +93,7 @@ static unsigned int combfilter;
static unsigned int lumafilter;
static unsigned int automute= 1;
static unsigned int chroma_agc;
+static unsigned int color_killer;
static unsigned int adc_crush = 1;
static unsigned int whitecrush_upper = 0xCF;
static unsigned int whitecrush_lower = 0x7F;
@@ -125,6 +126,7 @@ module_param(combfilter,int, 0444);
module_param(lumafilter,int, 0444);
module_param(automute, int, 0444);
module_param(chroma_agc,int, 0444);
+module_param(color_killer, int, 0444);
module_param(adc_crush, int, 0444);
module_param(whitecrush_upper, int, 0444);
module_param(whitecrush_lower, int, 0444);
@@ -151,6 +153,7 @@ MODULE_PARM_DESC(reset_crop,reset cropping parameters at
open(), default
is 1 (yes) for compatibility with older applications);
MODULE_PARM_DESC(automute,mute audio on bad/missing video signal, default is
1 (yes));
MODULE_PARM_DESC(chroma_agc,enables the AGC of chroma signal, default is 0
(no));
+MODULE_PARM_DESC(color_killer,enables the low color detector and removal,
default is 0 (no));
MODULE_PARM_DESC(adc_crush,enables the luminance ADC crush, default is 1
(yes));
MODULE_PARM_DESC(whitecrush_upper,sets the white crush upper value, default
is 207);
MODULE_PARM_DESC(whitecrush_lower,sets the white crush lower value, default
is 127);
@@ -674,6 +677,12 @@ static const struct v4l2_queryctrl bttv_ctls[] = {
.default_value = 32768,
.type = V4L2_CTRL_TYPE_INTEGER,
},{
+ .id= V4L2_CID_COLOR_KILLER,
+ .name = Color killer,
+ .minimum = 0,
+ .maximum = 1,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ },{
.id= V4L2_CID_HUE,
.name = Hue,
.minimum = 0,
@@ -1412,6 +1421,8 @@ static void init_bt848(struct bttv *btv)
BT848_GPIO_DMA_CTL);
val = btv-opt_chroma_agc ? BT848_SCLOOP_CAGC : 0;
+ if (btv-opt_color_killer)
+ val |= BT848_SCLOOP_CKILL;
btwrite(val, BT848_E_SCLOOP);
btwrite(val, BT848_O_SCLOOP);
@@ -1475,6 +1486,9 @@ static int bttv_g_ctrl(struct file *file, void *priv,
case V4L2_CID_SATURATION:
c-value = btv-saturation;
break;
+ case V4L2_CID_COLOR_KILLER:
+ c-value = btv-opt_color_killer;
+ break;
case V4L2_CID_AUDIO_MUTE:
case V4L2_CID_AUDIO_VOLUME:
@@ -1527,7 +1541,6 @@ static int bttv_s_ctrl(struct file *file, void *f,
struct v4l2_control *c)
{
int err;
- int val;
struct bttv_fh *fh = f;
struct bttv *btv = fh-btv;
@@ -1548,6 +1561,16 @@ static int bttv_s_ctrl(struct file *file, void *f,
case V4L2_CID_SATURATION:
bt848_sat(btv, c-value);
break;
+ case V4L2_CID_COLOR_KILLER:
+ btv-opt_color_killer = c-value;
+ if (btv-opt_color_killer) {
+ btor(BT848_SCLOOP_CKILL, BT848_E_SCLOOP);
+ btor(BT848_SCLOOP_CKILL, BT848_O_SCLOOP);
+ } else {
+ btand(~BT848_SCLOOP_CKILL, BT848_E_SCLOOP);
+ btand(~BT848_SCLOOP_CKILL, BT848_O_SCLOOP);
+ }
+ break;
case
Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
On Thu, 13 Sep 2012 17:46:32 +0200 Federico Vaga federico.v...@gmail.com wrote: A few words explaining why this memory handling module is required or beneficial will definitely improve the commit :) ok, I will write some lines In general, all of these patches need *much* better changelogs (i.e. they need changelogs). What are you doing, and *why* are you doing it? The future will want to know. I'm going to try to look at the actual code, but time isn't something I have a lot of, still... Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
On Thu, 13 Sep 2012 17:42:33 +0200 Federico Vaga federico.v...@gmail.com wrote: The header and esp. the source could really do with more documentation. It is not at all clear from the code what the dma-streaming allocator does and how it differs from other allocators. The other allocators are not documented and to understand them I read the code. All the memory allocators reflect a kind of DMA interface: SG for scatter/gather, contig for choerent and (now) streaming for streaming. So, I'm not sure to understand what do you think is the correct way to document a memory allocator; I can write one or two lines of comment to summarize each function. what do you think? Well, there is some documentation here: https://lwn.net/Articles/447435/ This reminds me that I've always meant to turn it into something to put into Documentation/. I'll try to get to that soon. In general, the fact that a subsystem is insufficiently documented is not a good reason to add more poorly-documented code. We are, after all, trying to make the kernel better over time... Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
Well, there is some documentation here: https://lwn.net/Articles/447435/ I know this, I learned from this page :) What I'm saying is that I don't know what to write inside the code to make it clearer than now. I think is clear, because if you know the videobuf2, you know what I'm doing in each vb2_mem_ops. I suppose that this is the reason why there are no comments inside the other memory allocator. Maybe I am wrong. -- Federico Vaga -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator
In data giovedì 13 settembre 2012 11:45:31, Jonathan Corbet ha scritto: On Thu, 13 Sep 2012 17:46:32 +0200 Federico Vaga federico.v...@gmail.com wrote: A few words explaining why this memory handling module is required or beneficial will definitely improve the commit :) ok, I will write some lines In general, all of these patches need *much* better changelogs (i.e. they need changelogs). What are you doing, and *why* are you doing it? The future will want to know. I can improve the comment about the ADV7180: it is not clear why I'm removing that functions. (and the memory allocator commit is also in the todo list). The STA2X11_VIP commit, I think is clear, I convert it to use videobu2 and control framework. I can add some extra lines to explain why: because videobuf is obsolete I'm going to try to look at the actual code, but time isn't something I have a lot of, still... The actual code is the same of the previous one with yours (plural) suggestions from the RFC submission (few week ago). I did not write anything else. -- Federico Vaga -- 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: hdpvr and HD PVR 2 Gaming Edition from Haoppauge
On 12-09-2012 17:56, Devin Heitmueller wrote: On Wed, Sep 12, 2012 at 11:37 AM, Thomas Seilund t...@netmaster.dk wrote: Hi All, I just bought the HD PVR 2 Gaming Edition from Hauppauge. It there any change this device will be supported by the hdpvr kernel driver. (Or any other driver for that matter!) No. It is a totally different hardware design and will need an entirely new driver. Devin Thanks Do you know if anybody plans to make a driver? I would love to contribute but my skills are not quite there! I have looked at the code for hdpvr kernel driver and I will try to pick up more knowledge from the internet. Do you have any hints on where to look? Thanks Thomas S -- 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: use of timestamp/sequence in v4l2_buffer
Hi Hans, Thanks for the RFC! On Tue, Sep 04, 2012 at 12:38:06PM +0200, Hans Verkuil wrote: Hi all, During the Media Workshop last week we discussed how the timestamp and sequence fields in struct v4l2_buffer should be used. While trying to document the exact behavior I realized that there are a few missing pieces. Open questions with regards to the sequence field: 1) Should the first frame that was captured or displayed after starting streaming for the first time always start with sequence index 0? In my opinion it should. I agree. 2) Should the sequence counter be reset to 0 after a STREAMOFF? Or should it only be reset to 0 after REQBUFS/CREATE_BUFS is called? Definitely not after CREATE_BUFS. Streaming may be ongoing when the IOCTL is called, and this will cause a great deal of trouble. I'd propose resetting it to zero at streamon (or streamoff) time. 3) Should the sequence counter behave differently for mem2mem devices? With the current definition both the capture and display sides of a mem2mem device just have their own independent sequence counter. 4) If frames are skipped, should the sequence counter skip as well? In my opinion it shouldn't. Do you mean skipping incrementing the counter, or skipping the frame number? :-) In my opinion the sequence number must be increased in this case. Not doing so would make it difficult to figure out frames have been skipped in the first place. That may be important in some cases. I can't think of any adverse effects this could result; the OMAP 3 ISP driver does so, for example. On the side of additional positive effects, consider the following quite realistic scenario: A frame is skipped on a single buffer queue of a device producing two streams of the same source, e.g. a sensor, whereas no frame is skipped on the second video buffer queue. Not incrementing the sequence would make the sequence numbers out-of-sync, and the situation would even be difficult to detect from the user space --- frame sequence numbers are important in associating buffers from different streams to the same original captured image. 5) Should the sequence counter always be monotonically increasing? I think it should. With the exception of the above, in my opinion yes. I.e. you're not supposed to have a decrease in field_count until it wraps around. Open questions with regards to the timestamp field: 6) For output devices the timestamp field can be used to determine when to transmit the frame. In practice there are no output drivers that support this. It is also unclear how this would work: if the timestamp is 1 hour into the future, should the driver hold on to that frame for one hour? If another frame is queued with a timestamp that's earlier than the previous frame, should that frame be output first? I am inclined to drop this behavior from the spec. Should we get drivers that actually implement this, then we need to clarify the spec and add a new capability flag somewhere to tell userspace that you can actually use the timestamp for this purpose. 7) Should the timestamp field always be monotonically increasing? Or it is possible to get timestamps that jump around? This makes sense for encoders that create B-frames referring to frames captured earlier than an I-frame. And for decoders that need to hold a key frame longer than others. (Or to save system memory resources, return it to the user space with the proposed READ_ONLY flag not agreed on yet.) Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nommu: remap_pfn_range: fix addr parameter check
On Thu, 13 Sep 2012 10:40:57 +0800
Bob Liu lliu...@gmail.com wrote:
The addr parameter may not page aligned eg. when it's come from
vfb_mmap():vma-vm_start in video driver.
This patch fix the check in remap_pfn_range() else some driver like v4l2 will
fail in this function while calling mmap() on nommu arch like blackfin and st.
Reported-by: Bhupesh SHARMA bhupesh.sha...@st.com
Reported-by: Scott Jiang scott.jiang.li...@gmail.com
Signed-off-by: Bob Liu lliu...@gmail.com
---
mm/nommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index d4b0c10..5d6068b 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1819,7 +1819,7 @@ struct page *follow_page(struct vm_area_struct *vma,
unsigned long address,
int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t prot)
{
- if (addr != (pfn PAGE_SHIFT))
+ if ((addr PAGE_MASK) != (pfn PAGE_SHIFT))
return -EINVAL;
vma-vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;
hm, what is the right thing to do here?
Yes, the MMU version of remap_pfn_range() does permit non-page-aligned
`addr' (at least, if the userspace maaping is a non-COW one). But I
suspect that was an implementation accident - it is a nonsensical thing
to do, isn't it? The MMU cannot map a bunch of kernel pages onto a
non-page-aligned userspace address.
So I'm thinking that we should declare ((addr ~PAGE_MASK) != 0) to be
a caller bug, and fix up this regrettably unidentified v4l driver?
--
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 1/5] video: Add generic display panel core
On Thu, Sep 13, 2012 at 01:29:54PM +0200, Sascha Hauer wrote: You have seen my of videomode helper proposal. One result there was that we want to have ranges for the margin/synclen fields. Does it make sense to base this new panel framework on a more sophisticated internal reprentation of the panel parameters? I think it does, yes. We need a common video mode structure, and the panel framework should use it. I'll try to rebase my patches on top of your proposal. Have you posted the latest version ? V2 is the newest version. I'd like to implement ranges for the display timings which then makes for a new common video mode structure, which then could be used by drm and fbdev, probably with helper functions to convert from common videomode to drm/fbdev specific variants. Steffen has a reworked series with the latest changes and will post them soon. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: hdpvr and HD PVR 2 Gaming Edition from Haoppauge
On Thu, Sep 13, 2012 at 2:28 PM, Thomas Seilund t...@netmaster.dk wrote: Do you know if anybody plans to make a driver? I have not heard of any such plans. It's a brand new device though, so it's possible that somebody will step up to do such (especially if the original HD-PVR stops being sold). I would love to contribute but my skills are not quite there! I have looked at the code for hdpvr kernel driver and I will try to pick up more knowledge from the internet. Do you have any hints on where to look? The Linuxtv.org wiki has some docs on creating Linux USB drivers (techniques for reverse engineering Windows drivers, collecting USB bus traces, etc). Normally I might suggest that you try to find the datasheets for all the chips involved, but I can tell you that you won't find them publicly available. 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
[PATCH] omap3isp: Use monotonic timestamps for statistics buffers
V4L2 buffers use the monotonic clock, while statistics buffers use wall
time. This makes it difficult to correlate video frames and statistics.
Switch statistics buffers to the monotonic clock to fix this.
Reported-by: Antoine Reversat a.rever...@gmail.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispstat.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispstat.c
b/drivers/media/platform/omap3isp/ispstat.c
index b8640be..52263cc 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -253,10 +253,14 @@ isp_stat_buf_find_oldest_or_empty(struct ispstat *stat)
static int isp_stat_buf_queue(struct ispstat *stat)
{
+ struct timespec ts;
+
if (!stat-active_buf)
return STAT_NO_BUF;
- do_gettimeofday(stat-active_buf-ts);
+ ktime_get_ts(ts);
+ stat-active_buf-ts.tv_sec = ts.tv_sec;
+ stat-active_buf-ts.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
stat-active_buf-buf_size = stat-buf_size;
if (isp_stat_buf_check_magic(stat, stat-active_buf)) {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Sep 13 19:00:21 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
[PATCH] [media] DocBook: Fix docbook compilation
changeset 1248c7cb66d734b60efed41be7c7b86909812c0e broke html compilation: Documentation/DocBook/v4l2.xml:584: parser error : Entity 'sub-subdev-g-edid' not defined Documentation/DocBook/v4l2.xml:626: parser error : chunk is not well balanced Documentation/DocBook/media_api.xml:74: parser error : Failure to process entity sub-v4l2 Documentation/DocBook/media_api.xml:74: parser error : Entity 'sub-v4l2' not defined I suspect that one file was simply missed at the patch. Yet, keeping it broken is a very bad idea, so we should either remove the broken patch or to remove just the invalid include. Let's take the latter approach. Due to that, a warning is now produced: Error: no ID for constraint linkend: v4l2-subdev-edid. Cc: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- Documentation/DocBook/media/v4l/v4l2.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 10ccde9..0292ed1 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -581,7 +581,6 @@ and discussions on the V4L mailing list./revremark sub-subdev-enum-frame-size; sub-subdev-enum-mbus-code; sub-subdev-g-crop; -sub-subdev-g-edid; sub-subdev-g-fmt; sub-subdev-g-frame-interval; sub-subdev-g-selection; -- 1.7.11.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: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
Hi Hans, Thanks for the patch! On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. If we'd make it configurable (applications would still get the wallclock time unless they ask for monotonic time), we'd have a chance to add more precision by using struct timespec (ns precision) instead of struct timeval (us precision). struct timespec is also used by V4L2 events. Adding support for CLOCK_MONOTONIC_RAW would also be a non-issue. Additional helper function could be used to generate the timestamp of the desired type. What do you think? Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
Hi Sakari, On Thursday 13 September 2012 23:38:14 Sakari Ailus wrote: On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. Or a buffer flag. I will need something similar to select device-specific timestamps. However, for wall clock vs. monotonic clock, I don't think there's a reason to let applications decide to use the wall clock. It would be a broken use case. I don't think we should let applications decide in this case. On the other hand, reporting a timespec instead of a timeval would be a good idea. I'm tempted. If we'd make it configurable (applications would still get the wallclock time unless they ask for monotonic time), we'd have a chance to add more precision by using struct timespec (ns precision) instead of struct timeval (us precision). struct timespec is also used by V4L2 events. Adding support for CLOCK_MONOTONIC_RAW would also be a non-issue. Additional helper function could be used to generate the timestamp of the desired type. What do you think? -- 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: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Thu September 13 2012 22:50:32 Laurent Pinchart wrote: Hi Sakari, On Thursday 13 September 2012 23:38:14 Sakari Ailus wrote: On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. Or a buffer flag. I will need something similar to select device-specific timestamps. However, for wall clock vs. monotonic clock, I don't think there's a reason to let applications decide to use the wall clock. It would be a broken use case. I don't think we should let applications decide in this case. I agree. On the other hand, reporting a timespec instead of a timeval would be a good idea. I'm tempted. Microsecond precision seems more than sufficient to me for video frames. I see no good reason for messing around with the v4l2_buffer struct just to get a timespec in. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] DocBook: Fix docbook compilation
On Thu September 13 2012 22:11:40 Mauro Carvalho Chehab wrote: changeset 1248c7cb66d734b60efed41be7c7b86909812c0e broke html compilation: Documentation/DocBook/v4l2.xml:584: parser error : Entity 'sub-subdev-g-edid' not defined Documentation/DocBook/v4l2.xml:626: parser error : chunk is not well balanced Documentation/DocBook/media_api.xml:74: parser error : Failure to process entity sub-v4l2 Documentation/DocBook/media_api.xml:74: parser error : Entity 'sub-v4l2' not defined I suspect that one file was simply missed at the patch. Indeed. The missing vidioc-subdev-g-edid.xml file is here: https://patchwork.kernel.org/patch/1209461/ I forgot to do a git add when I made the RFCv3, but that documentation file hasn't changed since RFCv2, so you can just use the one from RFCv2 and revert this patch. My apologies, I haven't found a good way yet to check that I didn't forgot to add a file. Regards, Hans Yet, keeping it broken is a very bad idea, so we should either remove the broken patch or to remove just the invalid include. Let's take the latter approach. Due to that, a warning is now produced: Error: no ID for constraint linkend: v4l2-subdev-edid. Cc: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- Documentation/DocBook/media/v4l/v4l2.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 10ccde9..0292ed1 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -581,7 +581,6 @@ and discussions on the V4L mailing list./revremark sub-subdev-enum-frame-size; sub-subdev-enum-mbus-code; sub-subdev-g-crop; -sub-subdev-g-edid; sub-subdev-g-fmt; sub-subdev-g-frame-interval; sub-subdev-g-selection; -- 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: ITE9135 on AMD SB700 - ehci_hcd bug
On Wed, 2012-09-12 at 08:32 +0200, Marx wrote: Hello I'm trying to use dual DVB-T tuner based on ITE9135 tuner. I use Debian kernel 3.5-trunk-686-pae. My motherboard is AsRock E350M1 (no USB3 ports). Tuner is detected ok, see log at the end of post. When I try to scan channels, bug happens: Sep 11 17:16:31 wuwek kernel: [ 209.291329] ehci_hcd :00:13.2: force halt; handshake f821a024 4000 - -110 Sep 11 17:16:31 wuwek kernel: [ 209.291401] ehci_hcd :00:13.2: HC died; cleaning up Sep 11 17:16:31 wuwek kernel: [ 209.291606] usb 2-3: USB disconnect, device number 2 Sep 11 17:16:41 wuwek kernel: [ 219.312848] dvb-usb: error while stopping stream. Sep 11 17:16:41 wuwek kernel: [ 219.320585] dvb-usb: ITE 9135(9006) Generic successfully deinitialized and disconnected. After trying many ways I've read about problems with ehci on SB700 based boards and switched off ehci via command sh -c 'echo -n :00:13.2 unbind' and now ehci bug doesn't happen. Of course I can see only one tuner and in slower USB mode (see log at the end). But now I can scan succesfully without any errors. Of course it isn't acceptable fix for my problem. Drivers for ITE9135 seems ok, but there is a problem with ehci_hcd on my motherboard. I would like to know what can I do to fix my problem. Hi Marx The only thing I can think of is the firmware for dual ite 9135(9006) chip version 1 may be different. Make sure you only scan on adapter 0 on ehci. If you want to send me privately a copy of the IT9135BDA.sys file from /WINDOWS/system32/drivers directory. I can extract and test that firmware against the devices I have and eliminate the Linux driver. Regards Malcolm -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3isp: Use monotonic timestamps for statistics buffers
Hi Laurent,
Thanks for the patch!
On Thu, Sep 13, 2012 at 09:53:23PM +0200, Laurent Pinchart wrote:
V4L2 buffers use the monotonic clock, while statistics buffers use wall
time. This makes it difficult to correlate video frames and statistics.
Switch statistics buffers to the monotonic clock to fix this.
Reported-by: Antoine Reversat a.rever...@gmail.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispstat.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispstat.c
b/drivers/media/platform/omap3isp/ispstat.c
index b8640be..52263cc 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -253,10 +253,14 @@ isp_stat_buf_find_oldest_or_empty(struct ispstat *stat)
static int isp_stat_buf_queue(struct ispstat *stat)
{
+ struct timespec ts;
+
if (!stat-active_buf)
return STAT_NO_BUF;
- do_gettimeofday(stat-active_buf-ts);
+ ktime_get_ts(ts);
+ stat-active_buf-ts.tv_sec = ts.tv_sec;
+ stat-active_buf-ts.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
stat-active_buf-buf_size = stat-buf_size;
if (isp_stat_buf_check_magic(stat, stat-active_buf)) {
I didn't think wall clock timestamps were used for statistics. This change
is sure going to affect anyone using them --- which likely equates to no-one
since I can hardly see use for wall clock timestams in such use.
How about using struct timespec instead?
Regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Add a codec driver for SI476X MFD
This commit add a sound codec driver for Silicon Laboratories 476x
series of AM/FM radio chips.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/si476x.c | 346 +
3 files changed, 352 insertions(+)
create mode 100644 sound/soc/codecs/si476x.c
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 9f8e859..71ab390 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -70,6 +70,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
select SND_SOC_WL1273 if MFD_WL1273_CORE
+ select SND_SOC_SI476X if MFD_SI476X_CORE
select SND_SOC_WM1250_EV1 if I2C
select SND_SOC_WM2000 if I2C
select SND_SOC_WM2200 if I2C
@@ -326,6 +327,9 @@ config SND_SOC_UDA1380
config SND_SOC_WL1273
tristate
+config SND_SOC_SI476X
+ tristate
+
config SND_SOC_WM1250_EV1
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 34148bb..aecf09b 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -61,6 +61,7 @@ snd-soc-twl6040-objs := twl6040.o
snd-soc-uda134x-objs := uda134x.o
snd-soc-uda1380-objs := uda1380.o
snd-soc-wl1273-objs := wl1273.o
+snd-soc-si476x-objs := si476x.o
snd-soc-wm1250-ev1-objs := wm1250-ev1.o
snd-soc-wm2000-objs := wm2000.o
snd-soc-wm2200-objs := wm2200.o
@@ -177,6 +178,7 @@ obj-$(CONFIG_SND_SOC_TWL6040) += snd-soc-twl6040.o
obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o
obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o
obj-$(CONFIG_SND_SOC_WL1273) += snd-soc-wl1273.o
+obj-$(CONFIG_SND_SOC_SI476X) += snd-soc-si476x.o
obj-$(CONFIG_SND_SOC_WM1250_EV1) += snd-soc-wm1250-ev1.o
obj-$(CONFIG_SND_SOC_WM2000) += snd-soc-wm2000.o
obj-$(CONFIG_SND_SOC_WM2200) += snd-soc-wm2200.o
diff --git a/sound/soc/codecs/si476x.c b/sound/soc/codecs/si476x.c
new file mode 100644
index 000..beea2ca
--- /dev/null
+++ b/sound/soc/codecs/si476x.c
@@ -0,0 +1,346 @@
+#include linux/module.h
+#include linux/slab.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/initval.h
+
+#include linux/mfd/si476x-core.h
+
+#define SI476X_AUDIO_VOLUME0x0300
+#define SI476X_AUDIO_MUTE 0x0301
+#define SI476X_DIGITAL_IO_OUTPUT_FORMAT0x0203
+#define SI476X_DIGITAL_IO_OUTPUT_SAMPLE_RATE 0x0202
+
+#define SI476X_DIGITAL_IO_OUTPUT_WIDTH_MASK~((0b111 11) | (0b111 8))
+#define SI476X_DIGITAL_IO_OUTPUT_FORMAT_MASK ~(0b110)
+
+
+/* codec private data */
+struct si476x_codec {
+ struct si476x_core *core;
+};
+
+static unsigned int si476x_codec_read(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+ int err;
+ struct si476x_codec *si476x = snd_soc_codec_get_drvdata(codec);
+ struct si476x_core *core = si476x-core;
+
+ si476x_core_lock(core);
+ err = si476x_core_cmd_get_property(core, reg);
+ si476x_core_unlock(core);
+
+ return err;
+}
+
+static int si476x_codec_write(struct snd_soc_codec *codec,
+ unsigned int reg, unsigned int val)
+{
+ int err;
+ struct si476x_codec *si476x = snd_soc_codec_get_drvdata(codec);
+ struct si476x_core *core = si476x-core;
+
+ si476x_core_lock(core);
+ err = si476x_core_cmd_set_property(core, reg, val);
+ si476x_core_unlock(core);
+
+ return err;
+}
+
+
+
+static int si476x_codec_set_daudio_params(struct snd_soc_codec *codec,
+ int width, int rate)
+{
+ int err;
+ u16 digital_io_output_format = \
+ snd_soc_read(codec,
+SI476X_DIGITAL_IO_OUTPUT_FORMAT);
+
+ if ((rate 32000) || (rate 48000)) {
+ dev_dbg(codec-dev, Rate: %d is not supported\n, rate);
+ return -EINVAL;
+ }
+
+ err = snd_soc_write(codec, SI476X_DIGITAL_IO_OUTPUT_SAMPLE_RATE,
+ rate);
+ if (err 0) {
+ dev_err(codec-dev, Failed to set sample rate\n);
+ return err;
+ }
+
+ digital_io_output_format = SI476X_DIGITAL_IO_OUTPUT_WIDTH_MASK;
+ digital_io_output_format |= (width 11) | (width 8);
+
+ return snd_soc_write(codec, SI476X_DIGITAL_IO_OUTPUT_FORMAT,
+digital_io_output_format);
+}
+
+static int si476x_codec_volume_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+
+ ucontrol-value.integer.value[0] =
+ snd_soc_read(codec, SI476X_AUDIO_VOLUME);
+ return 0;
+}
+
+static int si476x_codec_volume_put(struct snd_kcontrol *kcontrol,
+
[PATCH 0/3] A driver for Si476x series of chips
This patchset contains a driver for a Silicon Laboratories 476x series of radio tuners. The driver itself is implemented as an MFD devices comprised of three parts: 1. Core device that provides all the other devices with basic functionality and locking scheme. 2. Radio device that translates between V4L2 subsystem requests into Core device commands. 3. Codec device that does similar to the earlier described task, but for ALSA SoC subsystem. This driver has been tested to work in two different sytems: 1. A custom Tegra-based ARM board(design is based on Harmony board) running linux kernel 3.1.10 kernel 2. A standalone USB-connected board that has a dedicated Cortex M3 working as a transparent USB to I2C bridge which was connected to a off-the-shelf x86-64 laptop running Ubuntu with 3.2.0 kernel. As far as SubmitChecklist is concerned following criteria should be satisfied: 2b, 3, 5, 7, 9, 10 Andrey Smirnov (3): Add a core driver for SI476x MFD Add a V4L2 driver for SI476X MFD Add a codec driver for SI476X MFD drivers/media/radio/Kconfig| 17 + drivers/media/radio/radio-si476x.c | 1307 +++ drivers/mfd/Kconfig| 14 + drivers/mfd/Makefile |3 + drivers/mfd/si476x-cmd.c | 1509 drivers/mfd/si476x-i2c.c | 1033 drivers/mfd/si476x-prop.c | 477 include/linux/mfd/si476x-core.h| 532 + include/media/si476x.h | 461 +++ sound/soc/codecs/Kconfig |4 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/si476x.c | 346 + 12 files changed, 5705 insertions(+) create mode 100644 drivers/media/radio/radio-si476x.c create mode 100644 drivers/mfd/si476x-cmd.c create mode 100644 drivers/mfd/si476x-i2c.c create mode 100644 drivers/mfd/si476x-prop.c create mode 100644 include/linux/mfd/si476x-core.h create mode 100644 include/media/si476x.h create mode 100644 sound/soc/codecs/si476x.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Add a V4L2 driver for SI476X MFD
This commit adds a driver that exposes all the radio related
functionality of the Si476x series of chips via the V4L2 subsystem.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/media/radio/Kconfig| 17 +
drivers/media/radio/radio-si476x.c | 1307
2 files changed, 1324 insertions(+)
create mode 100644 drivers/media/radio/radio-si476x.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 8090b87..3c79d09 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -16,6 +16,23 @@ config RADIO_SI470X
bool Silicon Labs Si470x FM Radio Receiver support
depends on VIDEO_V4L2
+config RADIO_SI476X
+ tristate Silicon Laboratories Si476x I2C FM Radio
+ depends on I2C VIDEO_V4L2
+ select MFD_CORE
+ select MFD_SI476X_CORE
+ select SND_SOC_SI476X
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to v4l2 programs may be found at
+ file:Documentation/video4linux/API.html.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-si476x.
+
source drivers/media/radio/si470x/Kconfig
config USB_MR800
diff --git a/drivers/media/radio/radio-si476x.c
b/drivers/media/radio/radio-si476x.c
new file mode 100644
index 000..f313005
--- /dev/null
+++ b/drivers/media/radio/radio-si476x.c
@@ -0,0 +1,1307 @@
+#include linux/module.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/slab.h
+#include linux/atomic.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+
+#include linux/mfd/si476x-core.h
+
+#define FM_FREQ_RANGE_LOW 6400
+#define FM_FREQ_RANGE_HIGH 10800
+
+#define AM_FREQ_RANGE_LOW52
+#define AM_FREQ_RANGE_HIGH 3000
+
+#define PWRLINEFLTR (1 8)
+
+#define FREQ_MUL (1000 / 625)
+
+#define DRIVER_NAME si476x-radio
+#define DRIVER_CARD SI476x AM/FM Receiver
+
+static const char * const deemphasis[] = {
+ 75 us,
+ 50 us,
+};
+
+static const char * const grid_frequency[] = {
+ 50 Hz,
+ 60 Hz,
+};
+
+#define PRIVATE_CTL_IDX(x) (x - V4L2_CID_PRIVATE_BASE)
+
+static const struct v4l2_queryctrl si476x_ctrls[] = {
+ /*
+ Tuning parameters
+ 'max tune errors' is shared for both AM/FM mode of operation
+ */
+ {
+ .id = SI476X_CID_RSSI_THRESHOLD,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = valid rssi threshold,
+ .minimum= -128,
+ .maximum= 127,
+ .step = 1,
+ },
+ {
+ .id = SI476X_CID_SNR_THRESHOLD,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = valid snr threshold,
+ .minimum= -128,
+ .maximum= 127,
+ .step = 1,
+ },
+ {
+ .id = SI476X_CID_MAX_TUNE_ERROR,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = max tune errors,
+ .minimum= 0,
+ .maximum= 126 * 2,
+ .step = 2,
+ },
+ /*
+ Region specific parameters
+ */
+ {
+ .id = SI476X_CID_GRID_FREQUENCY,
+ .type = V4L2_CTRL_TYPE_MENU,
+ .name = power grid frequency,
+ .minimum= 0,
+ .maximum= ARRAY_SIZE(grid_frequency) - 1,
+ .step = 1,
+ },
+ {
+ .id = SI476X_CID_HARMONICS_COUNT,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = # of harmonics to reject,
+ .minimum= 0,
+ .maximum= 20,
+ .step = 1,
+ },
+ {
+ .id = SI476X_CID_SEEK_SPACING,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = seek frequency spacing,
+ .minimum= 0,
+ .maximum= 0x,
+ .step = 1,
+ },
+ {
+ .id = SI476X_CID_SEEK_BAND_TOP,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = seek band top,
+ .minimum= 0,
+ .maximum= 0x,
+ .step = 1,
+ },
+ {
+ .id = SI476X_CID_SEEK_BAND_BOTTOM,
+ .type =
Re: [GIT PULL] ViewCast O820E capture support added
Em 13-09-2012 20:19, Mauro Carvalho Chehab escreveu: Em Sat, 18 Aug 2012 11:48:52 -0400 Steven Toth st...@kernellabs.com escreveu: Mauro, please read below, a new set of patches I'm submitting for merge. On Thu, Aug 16, 2012 at 2:49 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu August 16 2012 19:39:51 Steven Toth wrote: So, I've ran v4l2-compliance and it pointed out a few things that I've fixed, but it also does a few things that (for some reason) I can't seem to catch. One particular test is on (iirc) s_fmt. It attempts to set ATSC but by ioctl callback never receives ATSC in the norm/id arg, it actually receives 0x0. This feels more like a bug in the test. Either way, I have some if (std ATSC) return -EINVAL, but it still appears to fail the test. Oddly enough. If I set tvnorms to something valid, then compliance passes but gstreamer fails to run, looks like some kind of confusion about either the current established norm, or a failure to establish a norm. For the time being I've set tvnorms to 0 (with a comment) and removed current_norm. Well, this needs to be sorted, because something is clearly amiss. Agreed. I just can't see what's wrong. I may need your advise / eyeballs on this. I'd be willing to provide logs that show gstreamer accessing the driver and exiting. It needs fixed, I've tried, I just can't see why gstreamer fails. On the main topic of merge As promised, I spent quite a bit of time this week reworking the code based on the feedback. I also flattened all of these patches into a single patchset and upgraded to the latest re-org tree. The source notes describe in a little more detail the major changes: http://git.kernellabs.com/?p=stoth/media_tree.git;a=commit;h=f295dd63e2f7027e327daad730eb86f2c17e3b2c Mauro, so, I hereby submit for your review/merge again, the updated patchset. *** Please comment. *** I'll comment patch by patch. Let's hope the ML will get this email. Not sure, as it tends to discard big emails like that. This is the comment of patch 1/4. Patch 2 is trivial. It is obviously OK. Patch 3 also looked OK on my eyes. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-apps scan files
Thank you Christoph! So is this (emailing you) the right way to get stuff added to the mercurial repo ? Please let me know so I know how to proceed in the future. Thanks again, Hernán.- On Thu, Sep 13, 2012 at 9:03 AM, Christoph Pfister christophpfis...@gmail.com wrote: Done. [ actually you're lucky - my low-priority RTT is in the range of months atm ... ] Christoph 2012/9/9 Hernán Rossetto hmronl...@gmail.com: It seems these were not added to the dvb-apps mercurial repo. Is this the way to submit these files ? If not, please let me know and I'll follow the right procedure. Thanks again, Hernán.- On Sat, Sep 8, 2012 at 3:54 PM, Ezequiel Garcia elezegar...@gmail.com wrote: Great! On Sat, Sep 8, 2012 at 12:48 AM, Hernán Rossetto hmronl...@gmail.com wrote: Please add the attached files for Argentina and Brazil to the DVB-T scan list. You will notice they have the same content already published here http://www.linuxtv.org/wiki/index.php/ISDB-T_Frequency_Table Muchas gracias! Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ViewCast O820E capture support added
Em Thu, 13 Sep 2012 20:23:42 -0300
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Em 13-09-2012 20:19, Mauro Carvalho Chehab escreveu:
Em Sat, 18 Aug 2012 11:48:52 -0400
Steven Toth st...@kernellabs.com escreveu:
Mauro, please read below, a new set of patches I'm submitting for merge.
On Thu, Aug 16, 2012 at 2:49 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu August 16 2012 19:39:51 Steven Toth wrote:
So, I've ran v4l2-compliance and it pointed out a few things that I've
fixed, but it also does a few things that (for some reason) I can't
seem to catch. One particular test is on (iirc) s_fmt. It attempts to
set ATSC but by ioctl callback never receives ATSC in the norm/id arg,
it actually receives 0x0. This feels more like a bug in the test.
Either way, I have some if (std ATSC) return -EINVAL, but it still
appears to fail the test.
Oddly enough. If I set tvnorms to something valid, then compliance
passes but gstreamer
fails to run, looks like some kind of confusion about either the
current established
norm, or a failure to establish a norm.
For the time being I've set tvnorms to 0 (with a comment) and removed
current_norm.
Well, this needs to be sorted, because something is clearly amiss.
Agreed. I just can't see what's wrong. I may need your advise /
eyeballs on this. I'd be willing to provide logs that show gstreamer
accessing the driver and exiting. It needs fixed, I've tried, I just
can't see why gstreamer fails.
On the main topic of merge As promised, I spent quite a bit of
time this week reworking the code based on the feedback. I also
flattened all of these patches into a single patchset and upgraded to
the latest re-org tree.
The source notes describe in a little more detail the major changes:
http://git.kernellabs.com/?p=stoth/media_tree.git;a=commit;h=f295dd63e2f7027e327daad730eb86f2c17e3b2c
Mauro, so, I hereby submit for your review/merge again, the updated
patchset. *** Please comment. ***
I'll comment patch by patch. Let's hope the ML will get this email. Not
sure,
as it tends to discard big emails like that.
This is the comment of patch 1/4.
Patch 2 is trivial. It is obviously OK.
Patch 3 also looked OK on my eyes.
Patch 4 will very likely be discarded by vger server, if everything is
added there. So, I'll drop the parts that weren't commented.
Anyway:
Subject: [media] vc8x0: Adding support for the ViewCast O820E Capture Card.
Cc: Linux Media Mailing List linux-media@vger.kernel.org
A dual channel 1920x1080p60 PCIe x4 capture card, two DVI
inputs capable of capturing DVI/HDMI, Component, Svideo, Composite
and some VGA resolutions.
...
+#include vc8x0.h
+
+static unsigned int audio_debug;
+module_param(audio_debug, int, 0644);
+MODULE_PARM_DESC(audio_debug, enable debug messages [audio]);
+
+static unsigned int audio_alsa_during_irq = 1;
+module_param(audio_alsa_during_irq, int, 0644);
+MODULE_PARM_DESC(audio_alsa_during_irq, feed alsa during the irq handler,
not via a dpc [audio]);
+
+#define dprintk(level, fmt, arg...)\
+ do {\
+ if (audio_debug = level)\
+ pr_err(%s/0: fmt, \
+ channel-dev-name, ## arg);\
+ } while (0)
+
+#define MIXER_RCA_JACKS 1
+
+/* Repack 24 bit audio samples (in 32bit alignment)
+ * into 16bit samples within the same buffer, and
+ * return the new buffer length in bytes.
+ *
+ * Input Sample:
+ * LEFT RIGHT
+ * 00 B0 B1 B2 00 B1 B1 B2
+
+ * Output Sample:
+ * LEFT RIGHT
+ * B1 B2 B1 B2
+ */
+static int repack_24_to_16(u8 *buf, int len)
+{
+ int i;
+ u8 *dst = buf;
+ u8 *src = buf + 2;
+
+ /* For each 24 bit sample */
+ for (i = 0; i (len / 4); i++) {
+ *(dst) = *(src);
+ *(dst + 1) = *(src + 1);
+ dst += 2;
+ src += 4;
+ }
+
+ return (len / 4) * 2;
+}
Why is it needed? It would be better to let ALSA userspace to handle
it.
+ dprintk(3,
+ %s() %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x
%02x %02x %02x %02x %02x\n,
+ __func__, *(buf-cpu + 0), *(buf-cpu + 1), *(buf-cpu + 2),
+ *(buf-cpu + 3), *(buf-cpu + 4), *(buf-cpu + 5),
+ *(buf-cpu + 6), *(buf-cpu + 7), *(buf-cpu + 8),
+ *(buf-cpu + 9), *(buf-cpu + 10), *(buf-cpu + 11),
+ *(buf-cpu + 12), *(buf-cpu + 13), *(buf-cpu + 14),
+ *(buf-cpu + 15)
+ );
FYI, there's now a new printk syntax to print buffer dumps like
that, where you pass the buffer and the length, and printk does the
rest.
+ spin_unlock(channel-dma_buffers_full_lock);
+ spin_unlock_irqrestore(channel-dma_buffers_dpc_lock, flags);
+
+ /* BAM! The interrupt handler is now free to move on */
+ /* BAM! The interrupt handler is now free to move on */
+ /* BAM! The interrupt handler is
Re: [GIT PULL] ViewCast O820E capture support added
Em 13-09-2012 21:59, Mauro Carvalho Chehab escreveu:
Em Thu, 13 Sep 2012 20:23:42 -0300
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Em 13-09-2012 20:19, Mauro Carvalho Chehab escreveu:
Em Sat, 18 Aug 2012 11:48:52 -0400
Steven Toth st...@kernellabs.com escreveu:
Mauro, please read below, a new set of patches I'm submitting for merge.
On Thu, Aug 16, 2012 at 2:49 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu August 16 2012 19:39:51 Steven Toth wrote:
So, I've ran v4l2-compliance and it pointed out a few things that I've
fixed, but it also does a few things that (for some reason) I can't
seem to catch. One particular test is on (iirc) s_fmt. It attempts to
set ATSC but by ioctl callback never receives ATSC in the norm/id arg,
it actually receives 0x0. This feels more like a bug in the test.
Either way, I have some if (std ATSC) return -EINVAL, but it still
appears to fail the test.
Oddly enough. If I set tvnorms to something valid, then compliance
passes but gstreamer
fails to run, looks like some kind of confusion about either the
current established
norm, or a failure to establish a norm.
For the time being I've set tvnorms to 0 (with a comment) and removed
current_norm.
Well, this needs to be sorted, because something is clearly amiss.
Agreed. I just can't see what's wrong. I may need your advise /
eyeballs on this. I'd be willing to provide logs that show gstreamer
accessing the driver and exiting. It needs fixed, I've tried, I just
can't see why gstreamer fails.
On the main topic of merge As promised, I spent quite a bit of
time this week reworking the code based on the feedback. I also
flattened all of these patches into a single patchset and upgraded to
the latest re-org tree.
The source notes describe in a little more detail the major changes:
http://git.kernellabs.com/?p=stoth/media_tree.git;a=commit;h=f295dd63e2f7027e327daad730eb86f2c17e3b2c
Mauro, so, I hereby submit for your review/merge again, the updated
patchset. *** Please comment. ***
I'll comment patch by patch. Let's hope the ML will get this email. Not
sure,
as it tends to discard big emails like that.
This is the comment of patch 1/4.
Patch 2 is trivial. It is obviously OK.
Patch 3 also looked OK on my eyes.
Patch 4 will very likely be discarded by vger server, if everything is
added there. So, I'll drop the parts that weren't commented.
Anyway:
Subject: [media] vc8x0: Adding support for the ViewCast O820E Capture Card.
Cc: Linux Media Mailing List linux-media@vger.kernel.org
A dual channel 1920x1080p60 PCIe x4 capture card, two DVI
inputs capable of capturing DVI/HDMI, Component, Svideo, Composite
and some VGA resolutions.
...
+#include vc8x0.h
+
+static unsigned int audio_debug;
+module_param(audio_debug, int, 0644);
+MODULE_PARM_DESC(audio_debug, enable debug messages [audio]);
+
+static unsigned int audio_alsa_during_irq = 1;
+module_param(audio_alsa_during_irq, int, 0644);
+MODULE_PARM_DESC(audio_alsa_during_irq, feed alsa during the irq handler,
not via a dpc [audio]);
+
+#define dprintk(level, fmt, arg...)\
+do {\
+if (audio_debug = level)\
+pr_err(%s/0: fmt, \
+channel-dev-name, ## arg);\
+} while (0)
+
+#define MIXER_RCA_JACKS 1
+
+/* Repack 24 bit audio samples (in 32bit alignment)
+ * into 16bit samples within the same buffer, and
+ * return the new buffer length in bytes.
+ *
+ * Input Sample:
+ * LEFT RIGHT
+ * 00 B0 B1 B2 00 B1 B1 B2
+
+ * Output Sample:
+ * LEFT RIGHT
+ * B1 B2 B1 B2
+ */
+static int repack_24_to_16(u8 *buf, int len)
+{
+int i;
+u8 *dst = buf;
+u8 *src = buf + 2;
+
+/* For each 24 bit sample */
+for (i = 0; i (len / 4); i++) {
+*(dst) = *(src);
+*(dst + 1) = *(src + 1);
+dst += 2;
+src += 4;
+}
+
+return (len / 4) * 2;
+}
Why is it needed? It would be better to let ALSA userspace to handle
it.
+dprintk(3,
+%s() %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x
%02x %02x %02x %02x %02x\n,
+__func__, *(buf-cpu + 0), *(buf-cpu + 1), *(buf-cpu + 2),
+*(buf-cpu + 3), *(buf-cpu + 4), *(buf-cpu + 5),
+*(buf-cpu + 6), *(buf-cpu + 7), *(buf-cpu + 8),
+*(buf-cpu + 9), *(buf-cpu + 10), *(buf-cpu + 11),
+*(buf-cpu + 12), *(buf-cpu + 13), *(buf-cpu + 14),
+*(buf-cpu + 15)
+);
FYI, there's now a new printk syntax to print buffer dumps like
that, where you pass the buffer and the length, and printk does the
rest.
+spin_unlock(channel-dma_buffers_full_lock);
+spin_unlock_irqrestore(channel-dma_buffers_dpc_lock, flags);
+
+/* BAM! The interrupt handler is now free to move on */
+/* BAM! The interrupt handler is now free to move on */
+/* BAM! The interrupt handler is now free to
