Re: [RFC 09/17] v4l: Add pad op for pipeline validation
Hi Sakari,
Thanks for the patch.
On Tuesday 20 December 2011 21:28:01 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
smiapp_pad_ops.validate_pipeline is intended to validate the full pipeline
which is implemented by the driver to which the subdev implementing this op
belongs to.
Should this be documented in Documentation/video4linux/v4l2-framework.txt ?
The validate_pipeline op must also call validate_pipeline on any external
entity which is linked to its sink pads.
I'm uncertain about this. Subdev drivers would then have to implement the
pipeline walk logic, resulting in duplicate code. Our current situation isn't
optimal either: walking the pipeline should be implemented in the media code.
Would it suit your needs if the validate_pipeline operation was replaced by a
validate_link operation, with a media_pipeline_validate() function in the
media core to walk the pipeline and call validate_link in each pad (or maybe
each sink pad) ?
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
include/media/v4l2-subdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 26eeaa4..a5ebe86 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -470,6 +470,7 @@ struct v4l2_subdev_pad_ops {
struct v4l2_subdev_selection *sel);
int (*set_selection)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_selection *sel);
+ int (*validate_pipeline)(struct v4l2_subdev *sd);
};
struct v4l2_subdev_ops {
--
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 01/17] v4l: Introduce integer menu controls
Hi Laurent,
Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patch.
Thanks for the review!
On Tuesday 20 December 2011 21:27:53 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
controls are just like menu controls but the menu items are 64-bit integers
rather than strings.
[snip]
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c index 0f415da..083bb79 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1775,16 +1797,22 @@ int v4l2_querymenu(struct v4l2_ctrl_handler *hdl,
struct v4l2_querymenu *qm)
qm-reserved = 0;
/* Sanity checks */
You should return -EINVAL here if the control is not of a menu type. It was
done implictly before by the ctrl-qmenu == NULL check, but that's now
conditioned to the control type being V4L2_CTRL_TYPE_MENU.
Good point. Fixed.
-if (ctrl-qmenu == NULL ||
+if ((ctrl-type == V4L2_CTRL_TYPE_MENU ctrl-qmenu == NULL) ||
+(ctrl-type == V4L2_CTRL_TYPE_INTEGER_MENU
+ ctrl-qmenu_int == NULL) ||
i ctrl-minimum || i ctrl-maximum)
return -EINVAL;
/* Use mask to see if this menu item should be skipped */
if (ctrl-menu_skip_mask (1 i))
return -EINVAL;
/* Empty menu items should also be skipped */
-if (ctrl-qmenu[i] == NULL || ctrl-qmenu[i][0] == '\0')
-return -EINVAL;
-strlcpy(qm-name, ctrl-qmenu[i], sizeof(qm-name));
+if (ctrl-type == V4L2_CTRL_TYPE_MENU) {
+if (ctrl-qmenu[i] == NULL || ctrl-qmenu[i][0] == '\0')
+return -EINVAL;
+strlcpy(qm-name, ctrl-qmenu[i], sizeof(qm-name));
+} else if (ctrl-type == V4L2_CTRL_TYPE_INTEGER_MENU) {
And you can then replace the else if by an else.
As well as this one.
+qm-value = ctrl-qmenu_int[i];
+}
return 0;
}
EXPORT_SYMBOL(v4l2_querymenu);
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/17] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
Thanks for the patch.
On Tuesday 20 December 2011 21:28:05 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
Configure CSI-2 phy based on platform data in the ISP driver rather than in
platform code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.c | 38 --
drivers/media/video/omap3isp/isp.h |3 -
drivers/media/video/omap3isp/ispcsiphy.c | 83 +++
drivers/media/video/omap3isp/ispcsiphy.h |4 ++
4 files changed, 111 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c index b818cac..6020fd7 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -737,7 +737,7 @@ static int isp_pipeline_enable(struct isp_pipeline
*pipe, struct isp_device *isp = pipe-output-isp;
struct media_entity *entity;
struct media_pad *pad;
- struct v4l2_subdev *subdev;
+ struct v4l2_subdev *subdev = NULL, *prev_subdev;
unsigned long flags;
int ret;
@@ -759,11 +759,41 @@ static int isp_pipeline_enable(struct isp_pipeline
*pipe, break;
entity = pad-entity;
+ prev_subdev = subdev;
subdev = media_entity_to_v4l2_subdev(entity);
- ret = v4l2_subdev_call(subdev, video, s_stream, mode);
- if (ret 0 ret != -ENOIOCTLCMD)
- return ret;
+ /* Configure CSI-2 receiver based on sensor format. */
+ if (prev_subdev == isp-isp_csi2a.subdev
+ || prev_subdev == isp-isp_csi2c.subdev) {
+ struct v4l2_subdev_format fmt;
+
+ fmt.pad = pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(subdev, pad, get_fmt,
+NULL, fmt);
+ if (ret 0)
+ return -EPIPE;
+
+ ret = omap3isp_csiphy_config(
+ isp, prev_subdev, subdev,
+ fmt.format);
+ if (ret 0)
+ return -EPIPE;
+
+ /* Start CSI-2 after configuration. */
+ ret = v4l2_subdev_call(prev_subdev, video,
+s_stream, mode);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
+
+ /* Start any other subdev except the CSI-2 receivers. */
+ if (subdev != isp-isp_csi2a.subdev
+ subdev != isp-isp_csi2c.subdev) {
+ ret = v4l2_subdev_call(subdev, video, s_stream, mode);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
What about moving this to the CSI2 s_stream subdev operation ?
if (subdev == isp-isp_ccdc.subdev) {
v4l2_subdev_call(isp-isp_aewb.subdev, video,
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h index 705946e..c5935ae 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,9 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes);
void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..f027ece 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include ../../../../arch/arm/mach-omap2/control.h
+
#include mach/control.h
(untested) ?
#include isp.h
#include ispreg.h
#include ispcsiphy.h
@@ -138,15 +140,78 @@ static void csiphy_dphy_config(struct isp_csiphy
*phy) isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
}
-static int csiphy_config(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes)
+/*
+ * TCLK values are OK at their reset values
+ */
+#define TCLK_TERM0
+#define TCLK_MISS1
+#define TCLK_SETTLE 14
+
+int omap3isp_csiphy_config(struct isp_device *isp,
+struct v4l2_subdev *csi2_subdev,
+struct v4l2_subdev *sensor,
+struct v4l2_mbus_framefmt *sensor_fmt)
{
+ struct isp_v4l2_subdevs_group *subdevs = sensor-host_priv;
+ struct
Re: [RFC 12/17] omap3isp: Add lane configuration to platform data
Hi Sakari,
Thanks for the patch.
On Tuesday 20 December 2011 21:28:04 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
Add lane configuration (order of clock and data lane) to platform data on
both CCP2 and CSI-2.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispcsiphy.h | 15 ++-
include/media/omap3isp.h | 15 +++
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispcsiphy.h
b/drivers/media/video/omap3isp/ispcsiphy.h index 9596dc6..e93a661 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.h
+++ b/drivers/media/video/omap3isp/ispcsiphy.h
@@ -27,22 +27,11 @@
#ifndef OMAP3_ISP_CSI_PHY_H
#define OMAP3_ISP_CSI_PHY_H
+#include media/omap3isp.h
+
struct isp_csi2_device;
struct regulator;
-struct csiphy_lane {
- u8 pos;
- u8 pol;
-};
-
-#define ISP_CSIPHY2_NUM_DATA_LANES 2
-#define ISP_CSIPHY1_NUM_DATA_LANES 1
-
-struct isp_csiphy_lanes_cfg {
- struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
- struct csiphy_lane clk;
-};
-
struct isp_csiphy_dphy_cfg {
u8 ths_term;
u8 ths_settle;
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index e917b1d..8fe0bdf 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -86,6 +86,19 @@ enum {
ISP_CCP2_MODE_CCP2 = 1,
};
+struct csiphy_lane {
+ u8 pos;
+ u8 pol;
+};
+
+#define ISP_CSIPHY2_NUM_DATA_LANES 2
+#define ISP_CSIPHY1_NUM_DATA_LANES 1
+
+struct isp_csiphy_lanes_cfg {
+ struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
+ struct csiphy_lane clk;
+};
Could you please document the two structures using kerneldoc ?
+
/**
* struct isp_ccp2_platform_data - CCP2 interface platform data
* @strobe_clk_pol: Strobe/clock polarity
@@ -105,6 +118,7 @@ struct isp_ccp2_platform_data {
unsigned int ccp2_mode:1;
unsigned int phy_layer:1;
unsigned int vpclk_div:2;
+ struct isp_csiphy_lanes_cfg *lanecfg;
Lane configuration is mandatory, what about embedding struct
isp_csiphy_lanes_cfg inside struct isp_ccp2_platform instead of having a
pointer ?
};
/**
@@ -115,6 +129,7 @@ struct isp_ccp2_platform_data {
struct isp_csi2_platform_data {
unsigned crc:1;
unsigned vpclk_div:2;
+ struct isp_csiphy_lanes_cfg *lanecfg;
Same here.
};
struct isp_subdev_i2c_board_info {
--
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 02/17] v4l: Document integer menu controls
Hi Laurent, Laurent Pinchart wrote: Hi Sakari, Thanks for the patch. On Tuesday 20 December 2011 21:27:54 Sakari Ailus wrote: From: Sakari Ailus sakari.ai...@iki.fi Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/compat.xml | 10 + Documentation/DocBook/media/v4l/v4l2.xml |7 .../DocBook/media/v4l/vidioc-queryctrl.xml | 39 +++- 3 files changed, 54 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.3/title Seems it will be for 3.4 :-) Same for Documentation/DocBook/media/v4l/v4l2.xml Right. I'll make the change for now but I don't of course mind if we get this to 3.3 already. However, if we want a driver using this go in at the same time, the smia++ driver for almost certain is not going to be 3.3 since it depends on a large set of other patches. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 14/17] omap3isp: Use pixelrate from sensor media bus frameformat
Hi Sakari,
Thanks for the patch.
On Tuesday 20 December 2011 21:28:06 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
Configure the ISP based on the pixelrate in media bus frame format.
Previously the same was configured from the board code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.c | 24 +---
drivers/media/video/omap3isp/isp.h |1 -
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c index 6020fd7..92f9716 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -749,10 +749,14 @@ static int isp_pipeline_enable(struct isp_pipeline
*pipe,
entity = pipe-output-video.entity;
while (1) {
- pad = entity-pads[0];
- if (!(pad-flags MEDIA_PAD_FL_SINK))
+ /*
+ * Is this an external subdev connected to us? If so,
+ * we're done.
+ */
+ if (subdev subdev-host_priv)
break;
This doesn't seem to be related to the patch title. Should it be moved to a
separate patch ? You could also move the check to the bottom of the while
loop, it would allow you to remove the first part of the condition as subdev
will always be non-NULL then (or even possible as the while() condition).
+ pad = entity-pads[0];
pad = media_entity_remote_source(pad);
if (pad == NULL ||
media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
@@ -762,6 +766,21 @@ static int isp_pipeline_enable(struct isp_pipeline
*pipe, prev_subdev = subdev;
subdev = media_entity_to_v4l2_subdev(entity);
+ /* Configure CCDC pixel clock */
+ if (subdev-host_priv) {
+ struct v4l2_subdev_format fmt;
+
+ fmt.pad = pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(subdev, pad, get_fmt,
+NULL, fmt);
+ if (ret 0)
+ return -EINVAL;
+
+ isp_set_pixel_clock(isp,
+ fmt.format.pixelrate * 1000);
+ }
+
/* Configure CSI-2 receiver based on sensor format. */
if (prev_subdev == isp-isp_csi2a.subdev
|| prev_subdev == isp-isp_csi2c.subdev) {
@@ -2102,7 +2121,6 @@ static int isp_probe(struct platform_device *pdev)
isp-autoidle = autoidle;
isp-platform_cb.set_xclk = isp_set_xclk;
- isp-platform_cb.set_pixel_clock = isp_set_pixel_clock;
mutex_init(isp-isp_mutex);
spin_lock_init(isp-stat_lock);
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h index c5935ae..7d73a39 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,7 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
/*
--
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 03/17] vivi: Add an integer menu test control
Hi Laurent,
Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patch.
Thanks for the review!
On Tuesday 20 December 2011 21:27:55 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
Add an integer menu test control for the vivi driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/vivi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 7d754fb..763ec23 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -177,6 +177,7 @@ struct vivi_dev {
struct v4l2_ctrl *menu;
struct v4l2_ctrl *string;
struct v4l2_ctrl *bitmask;
+struct v4l2_ctrl *int_menu;
spinlock_t slock;
struct mutex mutex;
@@ -503,6 +504,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
vivi_buffer *buf) dev-boolean-cur.val,
dev-menu-qmenu[dev-menu-cur.val],
dev-string-cur.string);
+snprintf(str, sizeof(str), integer_menu %s, value %lld ,
+dev-int_menu-qmenu[dev-int_menu-cur.val],
Shouldn't you print the content of qmenu_int as a 64-bit integer instead ?
Oh, yes; I should. Also the value would be wrong, as well as the menu
item array --- should be the int one.
+dev-int64-cur.val64);
Shouldn't this be dev-int_menu-cur.val ?
+gen_text(dev, vbuf, line++ * 16, 16, str);
mutex_unlock(dev-ctrl_handler.lock);
gen_text(dev, vbuf, line++ * 16, 16, str);
if (dev-button_pressed) {
@@ -1183,6 +1188,22 @@ static const struct v4l2_ctrl_config
vivi_ctrl_bitmask = { .step = 0,
};
+static const s64 * const vivi_ctrl_int_menu_values[] = {
+1, 1, 2, 3, 5, 8, 13, 21, 42,
+};
+
+static const struct v4l2_ctrl_config vivi_ctrl_string = {
+.ops = vivi_ctrl_ops,
+.id = VIDI_CID_CUSTOM_BASE + 7
+.name = Integer menu,
+.type = V4L2_CTRL_TYPE_INTEGER_MENU,
+.min = 1,
+.max = 8,
There are 9 values in your vivi_ctrl_int_menu_values array. Is 8 on purpose
here ?
I put it there to limit the maximum to 8 instead of 9, but 9 would be
equally good. I'll change it.
+.def = 4,
+.menu_skip_mask = 0x02,
+.qmenu_int = vivi_ctrl_int_menu_values,
+};
+
static const struct v4l2_file_operations vivi_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 17/17] rm680: Add camera init
Hi Sakari,
Thanks for the patch.
On Tuesday 20 December 2011 21:28:09 Sakari Ailus wrote:
This currently introduces an extra file to the arch/arm/mach-omap2
directory: board-rm680-camera.c. Keeping the device tree in mind, the
context of the file could be represented as static data with one exception:
the external clock to the sensor.
This external clock is provided by the OMAP 3 SoC and required by the
sensor. The issue is that the clock originates from the ISP and not from
PRCM block as the other clocks and thus is not supported by the clock
framework. Otherwise the sensor driver could just clk_get() and
clk_enable() it, just like the regulators and gpios.
This will hopefully be fixable with the new generic clock struct. Have you had
a look at it lately BTW ?
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/board-rm680-camera.c | 408
++ arch/arm/mach-omap2/board-rm680.c|
42 +++
3 files changed, 452 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rm680-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..1444bc5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -201,7 +201,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA) +=
board-omap3pandora.o obj-$(CONFIG_MACH_OMAP_3430SDP) +=
board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
-sdram-nokia.o
+sdram-nokia.o \
+board-rm680-camera.o
obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o \
sdram-nokia.o \
board-rx51-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rm680-camera.c
b/arch/arm/mach-omap2/board-rm680-camera.c new file mode 100644
index 000..4cc1ced
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rm680-camera.c
@@ -0,0 +1,408 @@
+/**
+ * arch/arm/mach-omap2/board-rm680-camera.c
+ *
+ * Copyright (C) 2010--2011 Nokia Corporation
2012 ? :-)
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * Based on board-rx71-camera.c by Vimarsh Zutshi
This one isn't upstream, I'm not sure if it's worth mentioning it.
+ * Based on board-rx51-camera.c by Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/delay.h
+#include linux/mm.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+
+#include linux/gpio.h
+#include plat/omap-pm.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
What do we still miss in media/omap3isp.h ?
+#include media/omap3isp.h
+#include media/smiapp.h
+#include asm/mach-types.h
+
+#include ../../../drivers/media/video/smiapp.h
Time to create media/smiapp.h ?
+
+#include devices.h
+
+#define SEC_CAMERA_RESET_GPIO97
+
+#define RM680_PRI_SENSOR 1
+#define RM680_PRI_LENS 2
+#define RM680_SEC_SENSOR 3
+#define MAIN_CAMERA_XCLK ISP_XCLK_A
+#define SEC_CAMERA_XCLK ISP_XCLK_B
+
+/*
+ *
+ * HW initialization
+ *
+ *
+ */
+static int __init rm680_sec_camera_init(void)
+{
+ if (gpio_request(SEC_CAMERA_RESET_GPIO, sec_camera reset) != 0) {
+ printk(KERN_INFO %s: unable to acquire secondary
+camera reset gpio\n, __func__);
+ return -ENODEV;
+ }
+
+ /* XSHUTDOWN off, reset */
+ gpio_direction_output(SEC_CAMERA_RESET_GPIO, 0);
+ gpio_set_value(SEC_CAMERA_RESET_GPIO, 0);
gpio_request_one() would be helpful here (and possibly in other locations in
this file).
+
+ return 0;
+}
+
+static int __init rm680_camera_hw_init(void)
+{
+ return rm680_sec_camera_init();
Maybe you could merge the two functions ?
+}
+
+/*
+ *
+ * Main Camera Module EXTCLK
+ * Used by the sensor and the actuator driver.
+ *
+ */
+static struct camera_xclk {
+ u32 hz;
+ u32 lock;
+ u8 xclksel;
+} cameras_xclk;
+
+static DEFINE_MUTEX(lock_xclk);
+
+static int rm680_update_xclk(struct
Re: [RFC 03/17] vivi: Add an integer menu test control
Sakari Ailus wrote: ... I put it there to limit the maximum to 8 instead of 9, but 9 would be equally good. I'll change it. Or not. 8 is still the index of the last value. min is one to start the menu from the second item. Would you like that to be changed to zero? -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pause/Resume and flush for V4L2 codec drivers.
On Friday, January 06, 2012 03:31:37 vka...@codeaurora.org wrote: Hi I am trying to implement v4l2 driver for video decoders. The problem I am facing is how to send pause/resume and flush commands from user-space to v4l2 driver. I am thinking of using controls for this. Has anyone done this before or if anyone has any ideas please let me know. Appreciate your help. See this patch series: http://www.mail-archive.com/linux-media@vger.kernel.org/msg40516.html Does this give you what you need? Regards, Hans Thanks Vinay -- 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: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
Hi Laurent,
Thanks for the comments!
Laurent Pinchart wrote:
On Tuesday 20 December 2011 21:27:56 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
As those ioctls are experimental, should we deprecate them ?
I'm also in favour of doing that. But I'll make it a separate patch.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/v4l2-subdev.c | 26 -
include/linux/v4l2-subdev.h | 45 ++
include/media/v4l2-subdev.h |5
3 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c index 65ade5f..e8ae098 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
struct v4l2_subdev *sd) {
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
/* Allocate try format and crop in the same memory block */
-fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop))
+fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop)
+ + sizeof(*fh-try_compose))
* sd-entity.num_pads, GFP_KERNEL);
Could you check how the 3 structures are aligned on 64-bit platforms ? I'm a
bit worried about the compiler expecting a 64-bit alignment for one of them,
and getting only a 32-bit alignment in the end.
What about using kcalloc ?
kcalloc won't make a difference --- see the implementation. Do you think
this is really an issue in practice?
If we want to ensure alignment I'd just allocate them separately. Or
create a struct out of them locally, and get the pointers from that
struct --- then the alignment would be the same as if those were part of
a single struct. That achieves the desired result and also keeps error
handling trivial.
I wouldn't want to start relying on the alignment based on the sizes of
these structures.
if (fh-try_fmt == NULL)
return -ENOMEM;
fh-try_crop = (struct v4l2_rect *)
(fh-try_fmt + sd-entity.num_pads);
+
+fh-try_compose = (struct v4l2_rect *)
+(fh-try_crop + sd-entity.num_pads);
#endif
return 0;
}
@@ -281,6 +285,26 @@ static long subdev_do_ioctl(struct file *file,
unsigned int cmd, void *arg) return v4l2_subdev_call(sd, pad,
enum_frame_interval, subdev_fh, fie);
}
+
+case VIDIOC_SUBDEV_G_SELECTION: {
+struct v4l2_subdev_selection *sel = arg;
Shouldn't you check sel-which ?
Yes.
+if (sel-pad = sd-entity.num_pads)
+return -EINVAL;
+
+return v4l2_subdev_call(
+sd, pad, get_selection, subdev_fh, sel);
+}
+
+case VIDIOC_SUBDEV_S_SELECTION: {
+struct v4l2_subdev_selection *sel = arg;
And here too ?
Yes.
+if (sel-pad = sd-entity.num_pads)
+return -EINVAL;
+
+return v4l2_subdev_call(
+sd, pad, set_selection, subdev_fh, sel);
+}
#endif
default:
return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
index ed29cbb..d53d775 100644
--- a/include/linux/v4l2-subdev.h
+++ b/include/linux/v4l2-subdev.h
@@ -123,6 +123,47 @@ struct v4l2_subdev_frame_interval_enum {
__u32 reserved[9];
};
+#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE(1 0)
+#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE(1 1)
+#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG(1 2)
+
+/* active cropping area */
+#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE 0
+/* default cropping area */
+#define V4L2_SUBDEV_SEL_TGT_CROP_DEFAULT1
+/* cropping bounds */
+#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS 2
+/* current composing area */
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE 256
+/* default composing area */
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_DEFAULT 257
+/* composing bounds */
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 258
+
+
+/**
+ * struct v4l2_subdev_selection - selection info
+ *
+ * @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
+ * @pad: pad number, as reported by the media API
+ * @target: selection target, used to choose one of possible rectangles
+ * @flags: constraints flags
+ * @r: coordinates of selection window
+ * @reserved: for future use, rounds structure size to 64 bytes, set to
zero + *
+ * Hardware may use multiple helper window to process a video stream.
Re: [RFC 06/17] v4l: Add selections documentation.
Hi Sakari, Thanks for the patch. On Tuesday 20 December 2011 21:27:58 Sakari Ailus wrote: [snip] diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml b/Documentation/DocBook/media/v4l/dev-subdev.xml index 0916a73..722db60 100644 --- a/Documentation/DocBook/media/v4l/dev-subdev.xml +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml [snip] @@ -288,26 +288,81 @@ [snip] + paraScaling operation changes the size of the image by scaling + it to new dimensions. Some sub-devices support it. The scaled + size (width and height) is represented by v4l2-rect;. In the + case of scaling, top and left will always be zero. Scaling is + configured using sub-subdev-g-selection; and + constantV4L2_SUBDEV_SEL_COMPOSE_ACTIVE/constant selection + target on the sink pad of the subdev. The scaling is performed + related to the width and height of the crop rectangle on the + subdev's sink pad./para + + paraAs for pad formats, drivers store try and active + rectangles for the selection targets of ACTIVE type xref + linkend=v4l2-subdev-selection-targets./xref/para + + paraOn sink pads, cropping is applied relatively to the + current pad format. The pad format represents the image size as + received by the sub-device from the previous block in the + pipeline, and the crop rectangle represents the sub-image that + will be transmitted further inside the sub-device for + processing./para + + paraOn source pads, cropping is similar to sink pads, with the + exception that the source size from which the cropping is + performed, is the COMPOSE rectangle on the sink pad. In both + sink and source pads, the crop rectangle must be entirely + containted inside the source image size for the crop + operation./para + + paraThe drivers should always use the closest possible + rectangle the user requests on all selection targets, unless + specificly told otherwisexref + linkend=v4l2-subdev-selection-flags./xref/para +/section This sounds a bit confusing to me. One issue is that composing is not formally defined. I think it would help if you could draw a diagram that shows how the operations are applied, and modify the text to describe the diagram, using the natural order of the compose and crop operations on sink and source pads. +section + titleOrder of configuration and format propagation/title + + paraThe order of image processing steps will always be from + the sink pad towards the source pad. This is also reflected in + the order in which the configuration must be performed by the + user. The format is propagated within the subdev along the later + processing steps. For example, setting the sink pad format + causes all the selection rectangles and the source pad format to + be set to sink pad format --- if allowed by the hardware, and if + not, then closest possible. The coordinates to a step always + refer to the active size of the previous step./para This also sounds a bit ambiguous if I try to ignore the fact that I know how it works :-) You should at least make it explicit that propagation inside subdevs is performed by the driver(s), and that propagation outside subdevs is to be handled by userspace. + orderedlist + listitemSink pad format. The user configures the sink pad + format. This format defines the parameters of the image the + entity receives through the pad for further processing./listitem - paraCropping behaviour on output pads is not defined./para + listitemSink pad active crop selection. The sink pad crop + defines the performed to the sink pad format./listitem + listitemSink pad active compose selection. The sink pad compose + rectangle defines the scaling ratio compared to the size of + the sink pad crop rectangle./listitem + + listitemSource pad active crop selection. Crop on the source + pad defines crop performed to the image scaled according to + the sink pad compose rectangle./listitem + + listitemSource pad active compose selection. The source pad + compose defines the size and location of the compose + rectangle./listitem + + listitemSource pad format. The source pad format defines the + output pixel format of the subdev, as well as the other + parameters with the exception of the image width and + height./listitem + + /orderedlist /section + /section sub-subdev-formats; [snip] diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml new file mode 100644 index 000..5fbcd65 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml @@ -0,0 +1,226 @@ [snip] + refsect1 +titleDescription/title +
Re: [RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
Hi Sakari,
On Friday 06 January 2012 12:27:03 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Tuesday 20 December 2011 21:27:56 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@iki.fi
Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
As those ioctls are experimental, should we deprecate them ?
I'm also in favour of doing that. But I'll make it a separate patch.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/v4l2-subdev.c | 26 -
include/linux/v4l2-subdev.h | 45
++ include/media/v4l2-subdev.h |
5
3 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c index 65ade5f..e8ae098 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
struct v4l2_subdev *sd) {
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
/* Allocate try format and crop in the same memory block */
- fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop))
+ fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop)
+ + sizeof(*fh-try_compose))
* sd-entity.num_pads, GFP_KERNEL);
Could you check how the 3 structures are aligned on 64-bit platforms ?
I'm a bit worried about the compiler expecting a 64-bit alignment for
one of them, and getting only a 32-bit alignment in the end.
What about using kcalloc ?
kcalloc won't make a difference --- see the implementation. Do you think
this is really an issue in practice?
It won't make a difference for the alignment, it's just that we allocate an
array, so kcalloc seemed right.
If we want to ensure alignment I'd just allocate them separately. Or
create a struct out of them locally, and get the pointers from that
struct --- then the alignment would be the same as if those were part of
a single struct. That achieves the desired result and also keeps error
handling trivial.
I wouldn't want to start relying on the alignment based on the sizes of
these structures.
Sounds good to me. Allocating them as part of a bigger structure internally
could be more efficient than separate allocations, but I'm fine with both.
--
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: Using OMAP3 ISP live display and snapshot sample applications
Hi James, On Wednesday 04 January 2012 08:07:23 James wrote: On Tue, Jan 3, 2012 at 7:17 PM, Laurent Pinchart wrote: On Tuesday 03 January 2012 10:40:10 James wrote: Hi Laurent, Happy New Year!! Thank you. Happy New Year to you as well. May 2012 bring you a workable OMAP3 ISP solution ;-) Yeah! that's on #1 of my 2012 wishlist!! (^^) But, it start off with a disappointment on the quest to get gst-launch v4l2src to work.. http://patches.openembedded.org/patch/8895/ Saw reported success in get v4l2src to work with MT9V032 by applying the hack but no luck with my Y12 monochrome sensor. (-.-) I saw that there is a simple viewfinder in your repo for OMAP3 and wish to know more about it. http://git.ideasonboard.org/?p=omap3-isp-live.git;a=summary I intend to test it with my 12-bit (Y12) monochrome camera sensor driver, running on top of Gumstix's (Steve v3.0) kernel. Is it workable at the moment? The application is usable but supports raw Bayer sensors only at the moment. It requires a frame buffer and an omap_vout device (both should be located automatically) and configures the OMAP3 ISP pipeline automatically to produce the display resolution. Will there be a need to patch for Y12 support or workable out-of-the-box? It will work out of the box when someone implements support for Y12 :-) Likely your previous notes, I know that 12-bit Y12 to the screen is an overkill but will it be able to capture Y12 from CCDC output and then output to the screen? Y12 sensor- CCDC - CCDC output - screen The omap_vout driver supports V4L2_PIX_FMT_RGB565, V4L2_PIX_FMT_RGB32, V4L2_PIX_FMT_RGB24, V4L2_PIX_FMT_YUYV and V4L2_PIX_FMT_UYVY only. To display Y12 data you will need to convert them to 10 bits in the CCDC (that's already implemented) and then to YUYV in the preview engine (that's not implemented yet). I've one board connected to a LCD monitor via a DVI chip using GS's Tobi board as reference and another via 4.3 LG LCD Touchscreen using GS's Chestnut board as reference. Many thanks in adv -- 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: Using OMAP3 ISP live display and snapshot sample applications
Hi James, On Friday 06 January 2012 07:24:54 James wrote: [snip] After googling for the warning, I proceed with the following steps to make the application on Steve's GNOME-R13 image from this site as it has all the tools for native-compilation on the Tobi board. 1) Inside /usr/src/linux, run make headers_install ARCH=arm and my /usr/include is now populated with lots of files. omap3-isp-live requires recent kernel headers that are not shipped by distributions yet, so you need to install them to some location first. make headers_install ARCH=arm should install them to /usr/src/linux/usr/include, not /usr/include. 2) Inside omap3-isp-live, I ran make KDIR=/usr/src/linux CROSS_COMPILE=arm-angstrom-linux-gnueabi-. This gave me an error about not finding linux/omap3isp.h file. Thus, I modified the 2 Makefile and replaced -I$(KDIR)/usr/include with -I$(KDIR)/include That's weird. The make headers_install step above should have installed the headers in /usr/src/linux/usr/include, so the makefile should be correct. Ran make KDIR=/usr/src/linux CROSS_COMPILE=arm-angstrom-linux-gnueabi- again and it compiled nicely without warnings about using kernel headers from user space. Only 3 warnings about a) omap3isp.c:271:13: warning: 'omap3_isp_pool_free_buffers' defined but not used Fixed in the latest version. b) omap3isp.c:329:15: warning: 'nbufs' may be used uninitialized in this function Fixed in the latest version as well. c) subdev.c:49:20: warning: 'pixelcode_to_string' defined but not used I'll fix that, but it's harmless. Hope I got it right compiling it this time!! (^^) 3) Copied isp/libomap3isp.so to /usr/lib/ directory when this message appeared when I ran ./live -h ./live: error while loading shared libraries: libomap3isp.so: cannot open shared object file: No such file or directory 4) Ran ./live again and got this error message unable to find video output device That should be fixed in the latest version. Could you please upgrade ? overo: setting xclk to 2500 hz Device /dev/videovero: setting xclk to 0 hz o6 opened: OMAP3 ISP resizer output (media). viewfinder configured for 2011 1024x768 error: unable to find video output device The output of the DVI goes 'blue' and nothing shown. What is missing? lsmod shows the list of modules loaded. Module Size Used by fuse 59943 3 bufferclass_ti 4976 0 omaplfb 8025 0 pvrsrvkm 146868 2 bufferclass_ti,omaplfb mt9v032 5958 1 omap3_isp 104303 0 v4l2_common 8543 2 mt9v032,omap3_isp videodev 78271 3 mt9v032,omap3_isp,v4l2_common libertas_sdio 14871 0 media 11885 3 mt9v032,omap3_isp,videodev libertas 92472 1 libertas_sdio cfg80211 157222 1 libertas lib802115291 1 libertas firmware_class 6269 2 libertas_sdio,libertas ads784610331 0 ipv6 226224 18 5) Ran ./snapshot and it continues till Ctrl+C. Does it has any output others then those messages? Many thanks in adv. -- 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/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control
Hi Sakari, On 01/04/2012 03:04 PM, Sakari Ailus wrote: On 01/02/2012 12:16 PM, Laurent Pinchart wrote: * controls for starting/stopping auto focusing (V4L2_CID_FOCUS_AUTO == false) V4L2_CID_START_AUTO_FOCUS (button) - start auto focusing, V4L2_CID_STOP_AUTO_FOCUS (button) - stop auto focusing (might be also useful in V4L2_FOCUS_AUTO == true), Maybe V4L2_CID_AUTO_FOCUS_START and V4L2_CID_AUTO_FOCUS_STOP to be consistent with the other proposed controls ? Yes, you're right, I'll change them to make consistent with others. I've noticed that too, but a little bit too late:) * auto focus status V4L2_CID_AUTO_FOCUS_STATUS (menu, read-only) - whether focusing is in progress or not, possible entries: - V4L2_AUTO_FOCUS_STATUS_IDLE,// auto focusing not enabled or force stopped - V4L2_AUTO_FOCUS_STATUS_BUSY,// focusing in progress - V4L2_AUTO_FOCUS_STATUS_SUCCESS, // single-shot auto focusing succeed // or continuous AF in progress - V4L2_AUTO_FOCUS_STATUS_FAIL,// auto focusing failed * V4L2_CID_FOCUS_AUTO would retain its current semantics: V4L2_CID_FOCUS_AUTO (boolean) - selects auto/manual focus false - manual true - auto continuous * AF algorithm scan range, V4L2_CID_FOCUS_AUTO_SCAN_RANGE with choices: - V4L2_AUTO_FOCUS_SCAN_RANGE_NORMAL, - V4L2_AUTO_FOCUS_SCAN_RANGE_MACRO, - V4L2_AUTO_FOCUS_SCAN_RANGE_INFINITY ... * select auto focus mode V4L2_CID_AUTO_FOCUS_MODE V4L2_AUTO_FOCUS_MODE_NORMAL - normal auto focus (whole frame?) V4L2_AUTO_FOCUS_MODE_SPOT - spot location passed with other controls or selection API V4L2_AUTO_FOCUS_MODE_RECTANGLE - rectangle passed with other controls or selection API Soudns good to me. parameter. We also need to discuss how the af statistics window configuration is done. I'm not certain there could even be a standardised Do we need multiple windows for AF statistics ? If not, I'm inclined to use four separate controls for window configuration. (X, Y, WIDTH, HEIGHT). This was Hans' preference in previous discussions [1]. For the OMAP3 ISP we need multiple statistics windows. AEWB can use more than 32 windows. Having separate controls for that wouldn't be practical. OK, so the control API in current form doesn't seem capable of setting up the statistics windows. There is also little space in struct v4l2_ext_control for any major extensions. We might need to define dedicated set of selection targets in the selection API for handling multiple windows. Yet, to avoid forcing applications to use the selection API where rectangles aren't needed - only single spot coordinates, how about defining following two controls ? * AF spot coordinates when focus mode is set to V4L2_AUTO_FOCUS_MODE_SPOT - V4L2_CID_AUTO_FOCUS_POSITION_X - horizontal position in pixels relative to the left of frame - V4L2_CID_AUTO_FOCUS_POSITION_Y - vertical position in pixels relative to the top of frame What's a spot focus mode? Any AF statistics from a single pixel have no meaning, so there has to be more. It sounds like a small rectangle to me. :-) Yes, it must be a small rectangle. But there may be no way to configure or read this rectangle's parameters, hence this menu option. If some hardware doesn't implement such feature it can just skip the spot focus menu item. And in case camera doesn't provide any interface for AF statistics windows configuration I don't see a good reason to use the selection API. But being able to provide more windows would be rather important. You don't need to look at too special cameras before you can have seven or so focus windows. The selection API could be used for this, as proposed already. We could have a new V4L2_(SUBDEV_)SELECTION_STAT_AF target to configure windows. We could add an id field to define the window ID to struct v4l2_(subdev_)selection. One control would be required to tell how many statistics windows do you have. Yeah, sounds good to me, better than defining selection target base and the target pool size. :) Ack. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH FOR 3.3] VIDIOC_LOG_STATUS support for sub-devices
On 31-12-2011 09:15, Sylwester Nawrocki wrote: Hi Mauro, The following changes since commit 3220eb73c5647af4c1f18e32c12dccb8adbac59d: s5p-fimc: Add support for alpha component configuration (2011-12-20 19:46:55 +0100) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_mbus This one patch enables VIDIOC_LOG_STATUS on subdev nodes. Sylwester Nawrocki (1): v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes Weird... when trying to pull from your tree, several other patches appeared. After removing the ones that seemed to be already applied, there are still those that seemed to still apply: Nov,17 2011: s5p-fimc: Prevent lock up caused by incomplete H/W initialization Oct, 1 2011: v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes Dec, 9 2011: v4l: Add new framesamples field to struct v4l2_mbus_framefmt Dec,15 2011: v4l: Update subdev drivers to handle framesamples parameter Dec,12 2011: m5mols: Add buffer size configuration support for compressed streams Nov,21 2011: s5p-fimc: Add media bus framesamples support Could you please double-check and, if possible, rebase your tree, to avoid the risk of applying something that is not ok yet, nor to miss something? Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sveon stv40 usb stick
Hi again! following the thread em28xx: new board id [eb1a:5051] between Reuben and Gareth I was able to advance a little: 1) I opened the usn stick and my chipsets are: - USB interface: em2860 - Audio ADC: emp202 - Video ADC: saa7118h (philips) 2) I confirm that the stock em28xx driver can recognize the usb stick but needs to specify a card manually as an option. 3) Using modprobe em18xx card=19 (which corresponds to EM2860/SAA711X Reference Design) I can go so far as to get a /dev/video0, but the preview is black no matter what i do. 4) I was able to eventually compile the v4l drivers but, as soon as I inject the driver, I get a kernel oops (attached). I made no change to the code obtained with git. I won't even mind to write some code myself, but I really have no idea where to begin with! Thanks in advance for any help you might provide, Best, Mario On 3 January 2012 20:44, Mario Ceresa mrcer...@gmail.com wrote: Hello everybody! I recently bougth a Sveon STV40 usb stick to capture analogic video (http://www.sveon.com/fichaSTV40.html) I can use it in windows but my linux box (Fedora 16 - 3.1.6-1.fc16.x86_64 - gcc 4.6.2) can't recognize it. Is there any way I can fix this? These are the results of my investigation so far: 1) It is identified by lsusb as an Afatech board (1b80:e309) with an Empia 2861 chip (from dmesg and windows driver inf file) 2) I experimented with em28xx because the chipset was empia and with af9015 because I found that the stv22 was supported (http://linuxtv.org/wiki/index.php/Afatech_AF9015). In both cases after I manually added the vendor:id to /sys/bus/usb/drivers/ driver started but in the end I was not able to succeed. With em28xx I could go as far as having a /dev/video0 device but with no signal and the dmesg log said to ask here for help :) . With the af9015 I had an early stop. 3) Both the logs are attached. 4) I used the driver shipped with the fedora stock kernel because I can't compile the ones that I get from git://linuxtv.org/media_build.git. I have an error at: CC [M] media_build/v4l/as3645a.o media_build/v4l/as3645a.c: In function 'as3645a_probe': media_build/v4l/as3645a.c:815:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/as3645a.c:815:8: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors Thank you in advance for any help you might provide on this issue! ,Best regards Mario -- 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 9/9] [media] firedtv: handle errors from dvb_net_init
On 31-12-2011 10:19, Jonathan Nieder wrote: It is not common for dvb_net_init to fail, but after the patch dvb_net_init: return -errno on error it can fail due to running out of memory. Handle this. From an audit of dvb_net_init callers. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- That's the end of the series, though it would have been nice to also check the error handling in dvb/mantis/mantis_dvb.c dvb/ngene/ngene-core.c (which looks a little strange) dvb/pluto2/pluto2.c dvb/pt1/pt1.c dvb/ttpci/av7110.c dvb/ttpci/budget-core.c dvb/ttusb-dec/ttusb_dec.c video/au0828/au0828-dvb.c video/cx18/cx18-dvb.c video/cx231xx/cx231xx-dvb.c video/em28xx/em28xx-dvb.c video/pvrusb2/pvrusb2-dvb.c video/saa7164/saa7164-dvb.c It would be good if you could take a look on them and send us patches for them if needed ;) Hopefully this gives the idea, anyway. Patch 2 is the important one, and the patches after that are just toys to show off patch 1. Warning: the patches are _completely_ _untested_. Test results (perhaps from provoking artificial failures in dvb_net_init), just like other comments, would be very welcome. 'night, Jonathan drivers/media/dvb/firewire/firedtv-dvb.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/firewire/firedtv-dvb.c b/drivers/media/dvb/firewire/firedtv-dvb.c index fd8bbbfa5c59..eb7496eab130 100644 --- a/drivers/media/dvb/firewire/firedtv-dvb.c +++ b/drivers/media/dvb/firewire/firedtv-dvb.c @@ -203,7 +203,9 @@ int fdtv_dvb_register(struct firedtv *fdtv, const char *name) if (err) goto fail_rem_frontend; - dvb_net_init(fdtv-adapter, fdtv-dvbnet, fdtv-demux.dmx); + err = dvb_net_init(fdtv-adapter, fdtv-dvbnet, fdtv-demux.dmx); + if (err) + goto fail_disconnect_frontend; fdtv_frontend_init(fdtv, name); err = dvb_register_frontend(fdtv-adapter, fdtv-fe); @@ -218,6 +220,7 @@ int fdtv_dvb_register(struct firedtv *fdtv, const char *name) fail_net_release: dvb_net_release(fdtv-dvbnet); +fail_disconnect_frontend: fdtv-demux.dmx.close(fdtv-demux.dmx); fail_rem_frontend: fdtv-demux.dmx.remove_frontend(fdtv-demux.dmx, fdtv-frontend); -- 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 17/17] rm680: Add camera init
Hi Sakari,
On 12/20/2011 09:28 PM, Sakari Ailus wrote:
+
+static int rm680_sec_camera_set_xshutdown(struct v4l2_subdev *subdev, u8 set)
It may be more efficient to just use u32.
+{
+ gpio_set_value(SEC_CAMERA_RESET_GPIO, !!set);
+ return 0;
+}
+
...
+void __init rm680_camera_init(void)
+{
+ struct isp_platform_data *pdata;
+ int rval;
+
+ rval = rm680_camera_hw_init();
+ if (rval) {
+ printk(KERN_WARNING %s: unable to initialise camera\n,
pr_warn is preferred for new code.
+ __func__);
+ return;
+ }
+
+ if (board_is_rm680())
+ pdata =rm680_isp_platform_data;
+ else
+ pdata =rm696_isp_platform_data;
+
+ if (omap3_init_camera(pdata) 0)
+ printk(KERN_WARNING
pr_warn
+ %s: unable to register camera platform device\n,
+ __func__);
+}
...
+static struct regulator_consumer_supply rm680_vaux2_consumers[] = {
+ REGULATOR_SUPPLY(VDD_CSIPHY1, omap3isp),/* OMAP ISP */
+ REGULATOR_SUPPLY(VDD_CSIPHY2, omap3isp),/* OMAP ISP */
+ {
+ .supply = vaux2,
+ },
Could also be
REGULATOR_SUPPLY(vaux2, NULL),
+};
+REGULATOR_INIT_DATA_FIXED(rm680_vaux2, 180);
+
+static struct regulator_consumer_supply rm680_vaux3_consumers[] = {
+ REGULATOR_SUPPLY(VANA, 2-0037), /* Main Camera Sensor */
+ REGULATOR_SUPPLY(VANA, 2-000e), /* Main Camera Lens */
+ REGULATOR_SUPPLY(VANA, 2-0010), /* Front Camera */
+ {
+ .supply = vaux3,
+ },
and REGULATOR_SUPPLY(vaux3, NULL),
+};
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git
Mauro, Some changes to allow the querying of the NO_SIGNAL status feature on the cx25840 video decoder. The following changes since commit 45447e1e18131590203dba83f9044d6c48448e54: [media] cx25840: Added g_std support to the video decoder driver (2012-01-04 19:16:15 -0500) are available in the git repository at: git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git staging/for_v3.3 Steven Toth (2): [media] cx25840: Add support for g_input_status [media] cx23885: Query the CX25840 during enum_input for status drivers/media/video/cx23885/cx23885-video.c | 9 + drivers/media/video/cx25840/cx25840-core.c | 16 2 files changed, 25 insertions(+), 0 deletions(-) Many thanks, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em2874 bulk endpoint support
Am 06.01.2012 01:52, schrieb Devin Heitmueller: On Thu, Jan 5, 2012 at 6:16 PM, Dmitriy Fitisovdmit...@radier.ca wrote: Hello everyone, I know, Devin Heitmueller was about to add support for em2874 bulk endpoint. Is that still in plans? The project that I was slated to do this work for got cancelled, and the only device I know of that requires bulk support is an obscure K-world product. It just didn't make any sense to waste the time for one unpopular stick. The Speedlink webcam Vicious And Devine - Laplace (em2765) would require bulk support, too: http://www.vicious-and-divine.com/vicious/laplace.html http://linuxtv.org/wiki/index.php/VAD_Laplace Regards, Frank -- 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: [PATCHv4 1/2] v4l: Add new framesamples field to struct v4l2_mbus_framefmt
Hi Sylwester,
On Wed, Jan 04, 2012 at 11:51:00PM +0100, Sylwester Nawrocki wrote:
On 01/04/2012 01:21 PM, Sakari Ailus wrote:
On Sun, Jan 01, 2012 at 07:56:03PM +0100, Sylwester Nawrocki wrote:
On 12/31/2011 02:16 PM, Sakari Ailus wrote:
Something else that should probably belong there is information on the
frame
format: contrary to what I've previously thought, the sensor metadata is
often sent as part of the same CSI-2 channel. There also can be other
types
of data, such as dummy data and data for black level calibration. I
wouldn't
want to export all this to the user space --- it shouldn't probably
need to
care about it.
The transmitter of the data (sensor) has this information and the CSI-2
receiver needs it. Same for the framesamples, as far as I understand.
We could try to design some standard data structure for frame metadata -
that's how I understood the meaning of struct v4l2_mbus_framedesc.
But I doubt such attempts will be sucessful. And how can we distinguish
which data is valid and applicable when there is lots of weird stuff in
one
data structure ? Using media bus pixel code only ?
I think the media bus pixel code which is exported to the user space
should
not be involved with the metadata.
Then we need to find some method to distinguish streams with metadata on
the
media bus, to be able to discard it before sending to user space.
I assume this is where struct v4l2_mbus_framedesc and related ops would
help ?
I'd think so.
Maybe we could create v4l2_mbus_framedesc with length (framesamples) member
in it and additionally 994 reserved bytes for future extensions ;-), e.g.
struct v4l2_mbus_framedesc {
unsigned int length;
unsigned int rserved[994];
};
Do we need to export this to the user space? In the first phase I'd like to
No, that wasn't my intention. The reserved field was supposed to be a joke,
we of course don't need any reserved members in the kernel space.
Oh, I have to admit I missed the joke completely. ;)
keep that static (i.e. only get op would be supported) and only visible in
the kernel. That would leave much more room for changes later on, if needed.
I'd prefer it to be R/W, i.e. having both get and set ops available. Maybe
not for all fields though.
I guess we should gather all the requirements and write and RFC based on the
findings. I know at least about three different scenarios:
- metadata as part of the image, receiver writes it to the same buffer,
- metadata as part of the image, receiver writes it to a different buffer and
- metadata arriver through a separate csi or ccp2 channel
All may include metadata at bottom and / or top of the image.
struct v4l2_subdev_pad_ops {
int get_framedesc(int pad, struct v4l2_framedesc *fdesc);
int set_framedesc(int pad, struct v4l2_framedesc fdesc);
};
This would ensure same media bus format code regardless of frame meta data
presence.
In case metadata is sent in same CSI channel, the required buffer length
might be greater than what would width/height and pixel code suggest.
Partly for this reason we have g_skip_top_lines() op in sensor ops. It
instructs the receiver to discard the metadata, and possibly other data
which isn't as interesting --- could be just dummy.
I see.
Some CSI-2 receivers are able to write this to a different memory location;
we could expose this as a different video node. I'm proposing a different
video node since this is a separate queue: the format (in-memory pixel
format and dimensions) is different, and it is beneficial to have access to
this data as soon as possible. There is a caveat, though, if we also wish to
support metadata which is appended to the frame, rather than prependeded.
I think it is recurring topic in our discussions, I guess nobody really needs
it since it haven't been implemented yet. ;)
It is needed, especially if you have camera control algorithms in the user
space. You can get around it in some cases, but the end result isn't pretty
nor reliable.
Multi-planar buffers were meant also for handling meta data, only variable
number of planes support would need to be added. For instance the driver could
pass only the buffer with meta data plane if required.
Multi-planar buffers are definitely a part of the solution when the metadata
is part of the same memory buffer.
What I think would be needed is separation of pixel formats of different
planes: we do not want to create new pixel format out of every possible
combination of metadata and pixel format.
The metadata is something that the user is likely interested only in the
form it is in the system memory. It won't be processed in any way before
it gets written to memory. The chosen mbus code may affect the format of
the
metadata, but that's something the sensor driver knows -- and I've yet to
see a case where the user could choose the
Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)
On Thursday 05 January 2012, Linus Torvalds wrote: And finally, ENOIOCTLCMD is a way to say ENOTTY in a sane manner, and will now be turned into ENOTTY for the user space return (not EINVAL - I have no idea where that idiocy came from, but it's clearly confused, although it's also clearly very old). To give some background here: While I did a lot of changes to the compat ioctl code over the years, I never touched the EINVAL/ENOTTY logic out of fear of breaking things further. Your patch is probably the right answer here and we should have done it long ago. This fixes the core files I noticed. It removes the insane complaints from the compat_ioctl() (which would complain if you returned ENOIOCTLCMD after an ioctl translation - the reason that is totally insane is that somebody might use an ioctl on the wrong kind of file descriptor, so even if it was translated perfectly fine, ENOIOCTLCMD is a perfectly fine error return and shouldn't cause warnings - and that allows us to remove stupid crap from the socket ioctl code). Now this behavior was entirely intentional. ENOIOCTLCMD was introduced explicitly so we could tell the difference between compat_ioctl handlers saying I don't know how to translate this but common code might know (ENOIOCTLCMD) and I know that this is not a valid command code here (ENOTTY plus whatever a broken driver might return). The distinction is used in two places: 1. To let device drivers return early from fops-compat_ioctl when they want to avoid the overhead from searching the COMPATIBLE_IOCTL() table and from the (formerly large) switch statement in do_ioctl_trans(), or when they want to make sure that the common translation is not called. We have some really tricky bits in the socket code where the crazy SIOCDEVPRIVATE needs to be handled specially by some drivers while the majority can use the default siocdevprivate_ioctl() function. 2. To return from do_ioctl_trans() when we know that there is no translation for the command number, so that the we can write a warning to the console (which you have now removed). This was initially more useful back when do_ioctl_trans() knew about practically all command numbers, but we have gradually moved all handlers into device drivers where they belong, and that has caused the problem that we get warnings whenever a user attempts an ioctl on a device that does not handle the command even when all the correct devices that support the command also have a compat handler. The common way we handle those is to add an IGNORE_IOCTL() entry for a command that repeatedly shows up in logs that way and is known to be handled correctly. I used to have patches to completely remove the remains of do_ioctl_trans() that can be resurrected if that helps, but it's mostly an independent issue. While I agree that the existing compat_ioctl_error() method was somewhat broken, I'd like to keep having a way to get some indication from drivers that are missing ioctl translations. Ideally, we would move all of fs/compat_ioctl.c into drivers and then just warn when we register some file_operations on a 64 bit machine that have an ioctl but no compat_ioctl function, but that would be a large amount of work. For a simpler solution, we could keep the old warning message, but change the logic from (.compat_ioctl == NULL || .compat_ioctl() == -ENOIOCTL) (no generic handler) to (.ioctl != NULL .compat_ioctl == NULL) (no generic handler). and then fix the warnings we see by adding appropriate .compat_ioctl functions. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rc-videomate-m1f.c Rename to match remote controler name
This remote was added with support for card Compro VideoMate M1F. This remote is shipped with various Compro cards, not this one only. Furthermore this remote can be bought separately under name Compro VideoMate K100. http://compro.com.tw/en/product/k100/k100.html So give it a proper name. Signed-off-by: Samuel Rakitničan samuel.rakitni...@gmail.com k100.diff Description: Binary data
[PATCH] [media] flexcop: CodingStyle fix: don't use if ((ret = foo()) 0)
Lift assignments from if conditionals for readability. No change
in functionality intended.
Suggested-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Mauro Carvalho Chehab wrote:
Subject: [media] flexcop: handle errors from dvb_net_init
[...]
[mche...@redhat.com: CodingStyle fix: don't use if ((ret = foo()) 0)]
Here's a patch to take care of the other instances of that construct
in the same file.
drivers/media/dvb/b2c2/flexcop.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/b2c2/flexcop.c b/drivers/media/dvb/b2c2/flexcop.c
index 4d3caca466fd..b1e8c99f469b 100644
--- a/drivers/media/dvb/b2c2/flexcop.c
+++ b/drivers/media/dvb/b2c2/flexcop.c
@@ -86,7 +86,8 @@ static int flexcop_dvb_init(struct flexcop_device *fc)
fc-demux.stop_feed = flexcop_dvb_stop_feed;
fc-demux.write_to_decoder = NULL;
- if ((ret = dvb_dmx_init(fc-demux)) 0) {
+ ret = dvb_dmx_init(fc-demux);
+ if (ret 0) {
err(dvb_dmx failed: error %d, ret);
goto err_dmx;
}
@@ -96,23 +97,27 @@ static int flexcop_dvb_init(struct flexcop_device *fc)
fc-dmxdev.filternum = fc-demux.feednum;
fc-dmxdev.demux = fc-demux.dmx;
fc-dmxdev.capabilities = 0;
- if ((ret = dvb_dmxdev_init(fc-dmxdev, fc-dvb_adapter)) 0) {
+ ret = dvb_dmxdev_init(fc-dmxdev, fc-dvb_adapter);
+ if (ret 0) {
err(dvb_dmxdev_init failed: error %d, ret);
goto err_dmx_dev;
}
- if ((ret = fc-demux.dmx.add_frontend(fc-demux.dmx,
fc-hw_frontend)) 0) {
+ ret = fc-demux.dmx.add_frontend(fc-demux.dmx, fc-hw_frontend);
+ if (ret 0) {
err(adding hw_frontend to dmx failed: error %d, ret);
goto err_dmx_add_hw_frontend;
}
fc-mem_frontend.source = DMX_MEMORY_FE;
- if ((ret = fc-demux.dmx.add_frontend(fc-demux.dmx,
fc-mem_frontend)) 0) {
+ ret = fc-demux.dmx.add_frontend(fc-demux.dmx, fc-mem_frontend);
+ if (ret 0) {
err(adding mem_frontend to dmx failed: error %d, ret);
goto err_dmx_add_mem_frontend;
}
- if ((ret = fc-demux.dmx.connect_frontend(fc-demux.dmx,
fc-hw_frontend)) 0) {
+ ret = fc-demux.dmx.connect_frontend(fc-demux.dmx, fc-hw_frontend);
+ if (ret 0) {
err(connect frontend failed: error %d, ret);
goto err_connect_frontend;
}
@@ -260,7 +265,8 @@ int flexcop_device_initialize(struct flexcop_device *fc)
flexcop_hw_filter_init(fc);
flexcop_smc_ctrl(fc, 0);
- if ((ret = flexcop_dvb_init(fc)))
+ ret = flexcop_dvb_init(fc);
+ if (ret)
goto error;
/* i2c has to be done before doing EEProm stuff -
@@ -278,7 +284,8 @@ int flexcop_device_initialize(struct flexcop_device *fc)
} else
warn(reading of MAC address failed.\n);
- if ((ret = flexcop_frontend_init(fc)))
+ ret = flexcop_frontend_init(fc);
+ if (ret)
goto error;
flexcop_device_name(fc,initialization of,complete);
--
1.7.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)
On Fri, Jan 6, 2012 at 8:19 AM, Arnd Bergmann a...@arndb.de wrote: For a simpler solution, we could keep the old warning message, but change the logic from (.compat_ioctl == NULL || .compat_ioctl() == -ENOIOCTL) (no generic handler) to (.ioctl != NULL .compat_ioctl == NULL) (no generic handler). and then fix the warnings we see by adding appropriate .compat_ioctl functions. So I have no problem with that. What I did have problems with was the net/socket.c kind of workarounds (which I noticed mainly because they had that whole EINVAL confusion built into them). Those were why I decided that the warning has to go. But if you can re-introduce the warning without workarounds like those, I have no problem with us reintroducing the warning, even if it is technically not really kosher and will afaik still print that warning for the case of a compat-ioctl transform that *would* have been valid, just not for that particular file descriptor. But the printout is small and not all that annoying, and explicitly limited in number, so I guess I don't mind a few false positives if it really can help find stale translation entries. Linus -- 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: sveon stv40 usb stick
Last updates. It works with em28xx module from v4l git as a card 19: # modprobe em28xx card=19 # echo 1b80 e309 /sys/bus/usb/drivers/em28xx/new_id [plugged in the usb] and $ mplayer -tv device=/dev/video0:input=1:norm=PAL:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2 tv:// But I have no audio... I will open a new thread only for the audio problem! Best, Mario On 6 January 2012 15:52, Mario Ceresa mrcer...@gmail.com wrote: Hi again! following the thread em28xx: new board id [eb1a:5051] between Reuben and Gareth I was able to advance a little: 1) I opened the usn stick and my chipsets are: - USB interface: em2860 - Audio ADC: emp202 - Video ADC: saa7118h (philips) 2) I confirm that the stock em28xx driver can recognize the usb stick but needs to specify a card manually as an option. 3) Using modprobe em18xx card=19 (which corresponds to EM2860/SAA711X Reference Design) I can go so far as to get a /dev/video0, but the preview is black no matter what i do. 4) I was able to eventually compile the v4l drivers but, as soon as I inject the driver, I get a kernel oops (attached). I made no change to the code obtained with git. I won't even mind to write some code myself, but I really have no idea where to begin with! Thanks in advance for any help you might provide, Best, Mario On 3 January 2012 20:44, Mario Ceresa mrcer...@gmail.com wrote: Hello everybody! I recently bougth a Sveon STV40 usb stick to capture analogic video (http://www.sveon.com/fichaSTV40.html) I can use it in windows but my linux box (Fedora 16 - 3.1.6-1.fc16.x86_64 - gcc 4.6.2) can't recognize it. Is there any way I can fix this? These are the results of my investigation so far: 1) It is identified by lsusb as an Afatech board (1b80:e309) with an Empia 2861 chip (from dmesg and windows driver inf file) 2) I experimented with em28xx because the chipset was empia and with af9015 because I found that the stv22 was supported (http://linuxtv.org/wiki/index.php/Afatech_AF9015). In both cases after I manually added the vendor:id to /sys/bus/usb/drivers/ driver started but in the end I was not able to succeed. With em28xx I could go as far as having a /dev/video0 device but with no signal and the dmesg log said to ask here for help :) . With the af9015 I had an early stop. 3) Both the logs are attached. 4) I used the driver shipped with the fedora stock kernel because I can't compile the ones that I get from git://linuxtv.org/media_build.git. I have an error at: CC [M] media_build/v4l/as3645a.o media_build/v4l/as3645a.c: In function 'as3645a_probe': media_build/v4l/as3645a.c:815:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/as3645a.c:815:8: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors Thank you in advance for any help you might provide on this issue! ,Best regards Mario -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx: no sound on board 1b80:e309 (sveon stv40)
Hello again! I managed to obtain a nice video input from my sveon usb stick using last em28xx v4l drivers from git and giving the module the hint card=19. But I have no audio.The card works flawlessy in windows. The internal chipsets in the card are: - USB interface: em2860 - Audio ADC: emp202 - Video ADC: saa7118h (philips) Attached is the relevant dmseg output. The usb audio card card correctly shows in pulseaudio volume control and is recognized as hw.2 by alsa: $ arecord -l List of CAPTURE Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 3/3 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 card 2: STV40 [USB 2861 Device (SVEON STV40)], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 However, I'm not able to record any sound from it and mplayer says no audio: $ mplayer -tv device=/dev/video0:input=1:norm=PAL:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2 tv:// MPlayer SVN-r33996-4.6.1 (C) 2000-2011 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) Selected device: EM2860/SAA711X Reference Design Capabilities: video capture VBI capture device audio read/write streaming supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = PAL-DK; 10 = PAL-M; 11 = PAL-N; 12 = PAL-Nc; 13 = PAL-60; 14 = SECAM; 15 = SECAM-B; 16 = SECAM-G; 17 = SECAM-H; 18 = SECAM-DK; 19 = SECAM-L; 20 = SECAM-Lc; inputs: 0 = S-Video; 1 = Composite1; Current input: 1 Current format: YUYV v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument Selected input hasn't got a tuner! == Opening video decoder: [raw] RAW Uncompressed Video Movie-Aspect is undefined - no prescaling applied. VO: [vdpau] 640x480 = 640x480 Packed YUY2 Selected video codec: [rawyuy2] vfm: raw (RAW YUY2) == Audio: no sound Starting playback... V: 2.0 52/ 52 0% 5% 0.0% 0 0 v4l2: 59 frames successfully processed, 0 frames dropped. Maybe has something to do with the last line in dmesg: [ 403.359333] ALSA sound/usb/mixer.c:845 2:1: cannot get min/max values for control 2 (id 2) Any ideas? Mario [ 389.491488] Linux video capture interface: v2.00 [ 389.491490] WARNING: You are using an experimental version of the media stack. [ 389.491491] As the driver is backported to an older kernel, it doesn't offer [ 389.491491] enough quality for its usage in production. [ 389.491492] Use it with care. [ 389.491492] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 389.491493] 1e73fa5d56333230854ae9460579eb2fcee8af02 [media] stb6100: Properly retrieve symbol rate [ 389.491494] e97a5d893fdf45c20799b72a1c11dca3b282c89c [media] fs/compat_ioctl: it needs to see the DVBv3 compat stuff [ 389.491495] 53c91373bdd74f7e11d2726046a90b986c1ed650 [media] dvb: remove the extra parameter on get_frontend [ 389.518213] usbcore: registered new interface driver em28xx [ 389.518215] em28xx driver loaded [ 401.754076] usb 1-5.3: new high speed USB device number 4 using ehci_hcd [ 401.844655] usb 1-5.3: New USB device found, idVendor=1b80, idProduct=e309 [ 401.844658] usb 1-5.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 401.844660] usb 1-5.3: Product: USB 2861 Device (SVEON STV40) [ 401.845694] em28xx: New device USB 2861 Device (SVEON STV40) @ 480 Mbps (1b80:e309, interface 0, class 0) [ 401.845828] em28xx #0: chip ID is em2860 [ 401.947993] em28xx #0: i2c eeprom 00: 1a eb 67 95 80 1b 09 e3 50 00 20 03 6a 3c 00 00 [ 401.948000] em28xx #0: i2c eeprom 10: 00 00 04 57 06 02 00 00 00 00 00 00 00 00 00 00 [ 401.948005] em28xx #0: i2c eeprom 20: 02 00 01 00 f0 00 01 00 00 00 00 00 5b 00 00 00 [ 401.948010] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 02 01 00 00 00 00 [ 401.948015] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 401.948020] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 401.948025] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 3c 03 55 00 53 00 [ 401.948030] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 36 00 31 00 20 00 44 00 [ 401.948035] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 20 00 28 00 53 00 [ 401.948040] em28xx #0: i2c eeprom 90: 56 00 45 00 4f 00 4e 00 20 00 53 00 54 00 56 00 [ 401.948045] em28xx #0: i2c eeprom a0: 34 00 30 00 29 00 00 00
[PATCH/RFC v2 0/4] JPEG codecs control class
Hello, This patch set adds new control class - V4L2_CID_JPEG_CLASS with initially four controls in it. It also adds V4L2_CID_JPEG_COMPRESSION_QUALITY control to two gspca sub-devices: sonixj and zc3xx, as these where drivers I had the hardware handy for. The gspca patches have been tested with v4l2ucp and v4l2-ctl. I could provide patches for some other drivers that currently use VIDIOC_S/G_JPEGCOMP ioctls for image quality setting only. The initial RFC can be found at http://www.mail-archive.com/linux-media@vger.kernel.org/msg39012.html Changes since v1 [1]: - renamed trailing 'S' from V4L2_CID_JPEG_ACTIVE_MARKERS; - removed V4L2_JPEG_ACTIVE_MARKER_DAC and V4L2_JPEG_ACTIVE_MARKER_DNL definitions as these are normally controlled by higher level compression attributes and shouldn't be allowed to be discarded independently; These patches are intended for v3.4. Comments are welcome. Sylwester Nawrocki (4): V4L: Add JPEG compression control class V4L: Add JPEG compression control class documentation gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support Documentation/DocBook/media/v4l/biblio.xml | 20 +++ Documentation/DocBook/media/v4l/compat.xml | 10 ++ Documentation/DocBook/media/v4l/controls.xml | 161 Documentation/DocBook/media/v4l/v4l2.xml |9 + .../DocBook/media/v4l/vidioc-g-jpegcomp.xml| 16 ++- drivers/media/video/gspca/sonixj.c | 23 +++ drivers/media/video/gspca/zc3xx.c | 54 +-- drivers/media/video/v4l2-ctrls.c | 24 +++ include/linux/videodev2.h | 24 +++ 9 files changed, 322 insertions(+), 19 deletions(-) -- Thanks, Sylwester [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg41070.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/RFC v2 4/4] gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
The JPEG compression quality control is currently done by means of the
VIDIOC_S/G_JPEGCOMP ioctls. As the quality field of struct v4l2_jpgecomp
is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY control,
so after the deprecation period VIDIOC_S/G_JPEGCOMP ioctl handlers can be
removed, leaving the control the only user interface for compression
quality configuration.
Cc: Jean-Francois Moine moin...@free.fr
Signed-off-by: Sylwester Nawrocki snj...@gmail.com
---
For completeness V4L2_CID_JPEG_ACTIVE_MARKER control might be also added.
---
drivers/media/video/gspca/zc3xx.c | 54 +---
1 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/gspca/zc3xx.c
b/drivers/media/video/gspca/zc3xx.c
index f22e02f..019a93b 100644
--- a/drivers/media/video/gspca/zc3xx.c
+++ b/drivers/media/video/gspca/zc3xx.c
@@ -46,6 +46,7 @@ enum e_ctrl {
AUTOGAIN,
LIGHTFREQ,
SHARPNESS,
+ QUALITY,
NCTRLS /* number of controls */
};
@@ -57,11 +58,6 @@ struct sd {
struct gspca_ctrl ctrls[NCTRLS];
- u8 quality; /* image quality */
-#define QUALITY_MIN 50
-#define QUALITY_MAX 80
-#define QUALITY_DEF 70
-
u8 bridge;
u8 sensor; /* Type of image sensor chip */
u16 chip_revision;
@@ -101,6 +97,12 @@ static void setexposure(struct gspca_dev *gspca_dev);
static int sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
static void setlightfreq(struct gspca_dev *gspca_dev);
static void setsharpness(struct gspca_dev *gspca_dev);
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val);
+
+/* JPEG image quality */
+#define QUALITY_MIN 50
+#define QUALITY_MAX 80
+#define QUALITY_DEF 70
static const struct ctrl sd_ctrls[NCTRLS] = {
[BRIGHTNESS] = {
@@ -188,6 +190,18 @@ static const struct ctrl sd_ctrls[NCTRLS] = {
},
.set_control = setsharpness
},
+[QUALITY] = {
+ {
+ .id = V4L2_CID_JPEG_COMPRESSION_QUALITY,
+ .type= V4L2_CTRL_TYPE_INTEGER,
+ .name= Compression Quality,
+ .minimum = QUALITY_MIN,
+ .maximum = QUALITY_MAX,
+ .step= 1,
+ .default_value = QUALITY_DEF,
+ },
+ .set = sd_setquality
+ },
};
static const struct v4l2_pix_format vga_mode[] = {
@@ -6411,7 +6425,7 @@ static int sd_config(struct gspca_dev *gspca_dev,
sd-sensor = id-driver_info;
gspca_dev-cam.ctrls = sd-ctrls;
- sd-quality = QUALITY_DEF;
+ sd-ctrls[QUALITY].val = QUALITY_DEF;
return 0;
}
@@ -6685,7 +6699,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
/* create the JPEG header */
jpeg_define(sd-jpeg_hdr, gspca_dev-height, gspca_dev-width,
0x21); /* JPEG 422 */
- jpeg_set_qual(sd-jpeg_hdr, sd-quality);
+ jpeg_set_qual(sd-jpeg_hdr, sd-ctrls[QUALITY].val);
mode = gspca_dev-cam.cam_mode[gspca_dev-curr_mode].priv;
switch (sd-sensor) {
@@ -6893,29 +6907,35 @@ static int sd_querymenu(struct gspca_dev *gspca_dev,
return -EINVAL;
}
-static int sd_set_jcomp(struct gspca_dev *gspca_dev,
- struct v4l2_jpegcompression *jcomp)
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val)
{
struct sd *sd = (struct sd *) gspca_dev;
- if (jcomp-quality QUALITY_MIN)
- sd-quality = QUALITY_MIN;
- else if (jcomp-quality QUALITY_MAX)
- sd-quality = QUALITY_MAX;
- else
- sd-quality = jcomp-quality;
+ sd-ctrls[QUALITY].val = val;
+
if (gspca_dev-streaming)
- jpeg_set_qual(sd-jpeg_hdr, sd-quality);
+ jpeg_set_qual(sd-jpeg_hdr, val);
+
return gspca_dev-usb_err;
}
+static int sd_set_jcomp(struct gspca_dev *gspca_dev,
+ struct v4l2_jpegcompression *jcomp)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ sd-ctrls[QUALITY].val = clamp_t(u8, jcomp-quality,
+ QUALITY_MIN, QUALITY_MAX);
+ return sd_setquality(gspca_dev, sd-ctrls[QUALITY].val);
+}
+
static int sd_get_jcomp(struct gspca_dev *gspca_dev,
struct v4l2_jpegcompression *jcomp)
{
struct sd *sd = (struct sd *) gspca_dev;
memset(jcomp, 0, sizeof *jcomp);
- jcomp-quality = sd-quality;
+ jcomp-quality = sd-ctrls[QUALITY].val;
jcomp-jpeg_markers = V4L2_JPEG_MARKER_DHT
| V4L2_JPEG_MARKER_DQT;
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v2 3/4] gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
The JPEG compression quality value can currently be read using the
VIDIOC_G_JPEGCOMP ioctl. As the quality field of struct v4l2_jpgecomp
is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY
control, so after the deprecation period VIDIOC_G_JPEGCOMP ioctl
handler can be removed, leaving the control the only user interface
for retrieving the compression quality.
Cc: Jean-Francois Moine moin...@free.fr
Signed-off-by: Sylwester Nawrocki snj...@gmail.com
---
For completeness V4L2_CID_JPEG_ACTIVE_MARKER control might be
also added.
---
drivers/media/video/gspca/sonixj.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index c55d667..c148081 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -45,6 +45,7 @@ enum e_ctrl {
SHARPNESS,
ILLUM,
FREQ,
+ QUALITY,
NCTRLS /* number of controls */
};
@@ -126,6 +127,7 @@ static void qual_upd(struct work_struct *work);
#define DEF_EN 0x80/* defect pixel by 0: soft, 1: hard */
/* V4L2 controls supported by the driver */
+static int getjpegqual(struct gspca_dev *gspca_dev, s32 *val);
static void setbrightness(struct gspca_dev *gspca_dev);
static void setcontrast(struct gspca_dev *gspca_dev);
static void setcolors(struct gspca_dev *gspca_dev);
@@ -286,6 +288,19 @@ static const struct ctrl sd_ctrls[NCTRLS] = {
},
.set_control = setfreq
},
+[QUALITY] = {
+ {
+ .id = V4L2_CID_JPEG_COMPRESSION_QUALITY,
+ .type= V4L2_CTRL_TYPE_INTEGER,
+ .name= Compression Quality,
+ .minimum = QUALITY_MIN,
+ .maximum = QUALITY_MAX,
+ .step= 1,
+ .default_value = QUALITY_DEF,
+ .flags = V4L2_CTRL_FLAG_READ_ONLY,
+ },
+ .get = getjpegqual
+ },
};
/* table of the disabled controls */
@@ -2960,6 +2975,14 @@ static int sd_get_jcomp(struct gspca_dev *gspca_dev,
return 0;
}
+static int getjpegqual(struct gspca_dev *gspca_dev, s32 *val)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ *val = sd-quality;
+ return 0;
+}
+
static int sd_querymenu(struct gspca_dev *gspca_dev,
struct v4l2_querymenu *menu)
{
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiple channel capture support in V4l2 layer
Thanks Laurent.Found similar type of discussion in this thread http://www.mail-archive.com/linux-media@vger.kernel.org/msg38443.html On Tue, Jan 3, 2012 at 6:44 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Dilip, On Friday 23 December 2011 19:57:22 Dilip Mannil wrote: Hi, I am trying to implement v4l2 slave driver for ML86V76654 digital video decoder that converts NTSC, PAL, SECAM analog video signals into the YCbCr standard digital format. This codec takes 4 analog inputs(2 analog camera + 2 ext video in) and encodes in to digital(only one at a time). The driver should be able to switch between capture channels upon request from user space application. I couldn't find the support for multiple capture channels on a single device in v4l2 layer. Please correct me if I am wrong. Ideally I want the v4l2 slave driver to have following feature. 1. ioctl that can be used to enumerate/get/set the capture channels on the video encoder. 2. Able to capture video from the currently set capture channel and pass to higher layers. Which is the best way to implement this support? VIDIOC_ENUMINPUT and VIDIOC_[GS]_INPUT seem to be what you're looking for. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Re: [git:v4l-dvb/for_v3.3] [media] dvb-bt8xx: handle errors from dvb_net_init
Hi Mauro,
Mauro Carvalho Chehab wrote:
Subject: [media] dvb-bt8xx: handle errors from dvb_net_init
[...]
[mchehab.redhat.com: codingstyle fix: printk() should include KERN_ facility
level]
[...]
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -782,7 +782,12 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
goto err_remove_mem_frontend;
}
- dvb_net_init(card-dvb_adapter, card-dvbnet, card-demux.dmx);
+ result = dvb_net_init(card-dvb_adapter, card-dvbnet,
card-demux.dmx);
+ if (result 0) {
+ printk(KERN_ERR,
+dvb_bt8xx: dvb_net_init failed (errno = %d)\n, result);
I think there is an extra comma here:
$ make drivers/media/dvb/bt8xx/dvb-bt8xx.o
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
CC [M] drivers/media/dvb/bt8xx/dvb-bt8xx.o
drivers/media/dvb/bt8xx/dvb-bt8xx.c: In function ‘dvb_bt8xx_load_card’:
drivers/media/dvb/bt8xx/dvb-bt8xx.c:788:10: warning: too many arguments
for format [-Wformat-extra-args]
Perhaps it would be better to add the KERN_ levels throughout the file
with a separate patch. Like this:
Jonathan Nieder (2):
[media] dvb-bt8xx: use dprintk for debug statements
[media] dvb-bt8xx: convert printks to pr_err()
drivers/media/dvb/bt8xx/dvb-bt8xx.c | 41 +--
1 files changed, 20 insertions(+), 21 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 1/2] [media] dvb-bt8xx: use dprintk for debug statements
This way, the messages will be tagged with KERN_DEBUG and not clutter the log from dmesg unless the debug module parameter is set. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- drivers/media/dvb/bt8xx/dvb-bt8xx.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c b/drivers/media/dvb/bt8xx/dvb-bt8xx.c index b9d927270318..2f38cca7604b 100644 --- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c +++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c @@ -205,7 +205,7 @@ static int cx24108_tuner_set_params(struct dvb_frontend *fe) 0x0012,0x0014}; #define XTAL 1011100 /* Hz, really 1.0111 MHz and a /10 prescaler */ - printk(cx24108 debug: entering SetTunerFreq, freq=%d\n,freq); + dprintk(cx24108 debug: entering SetTunerFreq, freq=%d\n,freq); /* This is really the bit driving the tuner chip cx24108 */ @@ -216,7 +216,7 @@ static int cx24108_tuner_set_params(struct dvb_frontend *fe) /* decide which VCO to use for the input frequency */ for(i = 1; (i ARRAY_SIZE(osci) - 1) (osci[i] freq); i++); - printk(cx24108 debug: select vco #%d (f=%d)\n,i,freq); + dprintk(cx24108 debug: select vco #%d (f=%d)\n,i,freq); band=bandsel[i]; /* the gain values must be set by SetSymbolrate */ /* compute the pll divider needed, from Conexant data sheet, @@ -232,7 +232,7 @@ static int cx24108_tuner_set_params(struct dvb_frontend *fe) ((a0x1f)11); /* everything is shifted left 11 bits to left-align the bits in the 32bit word. Output to the tuner goes MSB-aligned, after all */ - printk(cx24108 debug: pump=%d, n=%d, a=%d\n,pump,n,a); + dprintk(cx24108 debug: pump=%d, n=%d, a=%d\n,pump,n,a); cx24110_pll_write(fe,band); /* set vga and vca to their widest-band settings, as a precaution. SetSymbolrate might not be called to set this up */ -- 1.7.8.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] dvb-bt8xx: convert printks to pr_err()
This module does some printks with the loglevel missing.
pr_err() takes care of adding the KERN_ERR tag and the module name.
So we can simplify the code and add the missing printk loglevel by
using it.
Also add a #define pr_fmt() to make this work, and remove a few
unnecessary periods at the end of messages and bump the loglevel of
Unknown bttv card type from KERN_WARNING to KERN_ERR while at it.
Inspired-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
drivers/media/dvb/bt8xx/dvb-bt8xx.c | 35 +--
1 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index 2f38cca7604b..f9087a0f0cc3 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -19,6 +19,8 @@
*
*/
+#define pr_fmt(fmt) dvb_bt8xx: fmt
+
#include linux/bitops.h
#include linux/module.h
#include linux/init.h
@@ -666,7 +668,7 @@ static void frontend_init(struct dvb_bt8xx_card *card, u32
type)
/* DST is not a frontend driver !!!*/
state = kmalloc(sizeof (struct dst_state), GFP_KERNEL);
if (!state) {
- printk(dvb_bt8xx: No memory\n);
+ pr_err(No memory\n);
break;
}
/* Setup the Card */
@@ -676,7 +678,7 @@ static void frontend_init(struct dvb_bt8xx_card *card, u32
type)
state-dst_ca = NULL;
/* DST is not a frontend, attaching the ASIC */
if (dvb_attach(dst_attach, state, card-dvb_adapter) == NULL) {
- printk(%s: Could not find a Twinhan DST.\n, __func__);
+ pr_err(%s: Could not find a Twinhan DST\n, __func__);
break;
}
/* Attach other DST peripherals if any */
@@ -705,14 +707,14 @@ static void frontend_init(struct dvb_bt8xx_card *card,
u32 type)
}
if (card-fe == NULL)
- printk(dvb-bt8xx: A frontend driver was not found for device
[%04x:%04x] subsystem [%04x:%04x]\n,
+ pr_err(A frontend driver was not found for device [%04x:%04x]
subsystem [%04x:%04x]\n,
card-bt-dev-vendor,
card-bt-dev-device,
card-bt-dev-subsystem_vendor,
card-bt-dev-subsystem_device);
else
if (dvb_register_frontend(card-dvb_adapter, card-fe)) {
- printk(dvb-bt8xx: Frontend registration failed!\n);
+ pr_err(Frontend registration failed!\n);
dvb_frontend_detach(card-fe);
card-fe = NULL;
}
@@ -726,7 +728,7 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
THIS_MODULE, card-bt-dev-dev,
adapter_nr);
if (result 0) {
- printk(dvb_bt8xx: dvb_register_adapter failed (errno = %d)\n,
result);
+ pr_err(dvb_register_adapter failed (errno = %d)\n, result);
return result;
}
card-dvb_adapter.priv = card;
@@ -746,7 +748,7 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
result = dvb_dmx_init(card-demux);
if (result 0) {
- printk(dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n, result);
+ pr_err(dvb_dmx_init failed (errno = %d)\n, result);
goto err_unregister_adaptor;
}
@@ -756,7 +758,7 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
result = dvb_dmxdev_init(card-dmxdev, card-dvb_adapter);
if (result 0) {
- printk(dvb_bt8xx: dvb_dmxdev_init failed (errno = %d)\n,
result);
+ pr_err(dvb_dmxdev_init failed (errno = %d)\n, result);
goto err_dmx_release;
}
@@ -764,7 +766,7 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
result = card-demux.dmx.add_frontend(card-demux.dmx, card-fe_hw);
if (result 0) {
- printk(dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n, result);
+ pr_err(dvb_dmx_init failed (errno = %d)\n, result);
goto err_dmxdev_release;
}
@@ -772,19 +774,19 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
result = card-demux.dmx.add_frontend(card-demux.dmx, card-fe_mem);
if (result 0) {
- printk(dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n, result);
+ pr_err(dvb_dmx_init failed (errno = %d)\n, result);
goto err_remove_hw_frontend;
}
Re: em28xx: no sound on board 1b80:e309 (sveon stv40)
Ok boys: just to let you know that everything works now. thinking that the problem was with the audio input, I noticed that card=64 had an amux while card=19 no. .amux = EM28XX_AMUX_LINE_IN, So I tried this card and modified the mplayer options accordingly: mplayer -tv device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2 tv:// notice the forceaudio parameter that reads the audio even if no source is reported from v4l (The same approach with card=19 does not work) The output was a bit slugglish so I switched off pulse audio control of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and now everything is ok! I hope this will help some lonenly googlers in the future :) Regards, Mario On 6 January 2012 18:48, Mario Ceresa mrcer...@gmail.com wrote: Hello again! I managed to obtain a nice video input from my sveon usb stick using last em28xx v4l drivers from git and giving the module the hint card=19. But I have no audio.The card works flawlessy in windows. The internal chipsets in the card are: - USB interface: em2860 - Audio ADC: emp202 - Video ADC: saa7118h (philips) Attached is the relevant dmseg output. The usb audio card card correctly shows in pulseaudio volume control and is recognized as hw.2 by alsa: $ arecord -l List of CAPTURE Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 3/3 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 card 2: STV40 [USB 2861 Device (SVEON STV40)], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 However, I'm not able to record any sound from it and mplayer says no audio: $ mplayer -tv device=/dev/video0:input=1:norm=PAL:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2 tv:// MPlayer SVN-r33996-4.6.1 (C) 2000-2011 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) Selected device: EM2860/SAA711X Reference Design Capabilities: video capture VBI capture device audio read/write streaming supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = PAL-DK; 10 = PAL-M; 11 = PAL-N; 12 = PAL-Nc; 13 = PAL-60; 14 = SECAM; 15 = SECAM-B; 16 = SECAM-G; 17 = SECAM-H; 18 = SECAM-DK; 19 = SECAM-L; 20 = SECAM-Lc; inputs: 0 = S-Video; 1 = Composite1; Current input: 1 Current format: YUYV v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument Selected input hasn't got a tuner! == Opening video decoder: [raw] RAW Uncompressed Video Movie-Aspect is undefined - no prescaling applied. VO: [vdpau] 640x480 = 640x480 Packed YUY2 Selected video codec: [rawyuy2] vfm: raw (RAW YUY2) == Audio: no sound Starting playback... V: 2.0 52/ 52 0% 5% 0.0% 0 0 v4l2: 59 frames successfully processed, 0 frames dropped. Maybe has something to do with the last line in dmesg: [ 403.359333] ALSA sound/usb/mixer.c:845 2:1: cannot get min/max values for control 2 (id 2) Any ideas? Mario -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: no sound on board 1b80:e309 (sveon stv40)
On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa mrcer...@gmail.com wrote: Ok boys: just to let you know that everything works now. thinking that the problem was with the audio input, I noticed that card=64 had an amux while card=19 no. .amux = EM28XX_AMUX_LINE_IN, So I tried this card and modified the mplayer options accordingly: mplayer -tv device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2 tv:// notice the forceaudio parameter that reads the audio even if no source is reported from v4l (The same approach with card=19 does not work) The output was a bit slugglish so I switched off pulse audio control of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and now everything is ok! I hope this will help some lonenly googlers in the future :) Regards, Mario Hi Mario, Since you've spent the time to figure out the details of your particular hardware, you should really consider submitting a patch to the em28xx driver which adds your device's USB ID. That would allow others who have that hardware to have it work out of the box with no need for figuring out the correct cardid value through experimentation as you had to. Cheers, 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Jan 6 19:00:28 CET 2012 git hash:bcd158de94238d90adf7275548f0aaf2de724ab1 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS 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-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS 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-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Re: [git:v4l-dvb/for_v3.3] [media] dvb-bt8xx: handle errors from dvb_net_init
On 06-01-2012 16:25, Jonathan Nieder wrote:
Hi Mauro,
Mauro Carvalho Chehab wrote:
Subject: [media] dvb-bt8xx: handle errors from dvb_net_init
[...]
[mchehab.redhat.com: codingstyle fix: printk() should include KERN_ facility
level]
[...]
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -782,7 +782,12 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
goto err_remove_mem_frontend;
}
-dvb_net_init(card-dvb_adapter, card-dvbnet, card-demux.dmx);
+result = dvb_net_init(card-dvb_adapter, card-dvbnet,
card-demux.dmx);
+if (result 0) {
+printk(KERN_ERR,
+ dvb_bt8xx: dvb_net_init failed (errno = %d)\n, result);
I think there is an extra comma here:
Yeah, I noticed it, but only after adding it at the main repo :(
$ make drivers/media/dvb/bt8xx/dvb-bt8xx.o
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
CC [M] drivers/media/dvb/bt8xx/dvb-bt8xx.o
drivers/media/dvb/bt8xx/dvb-bt8xx.c: In function ‘dvb_bt8xx_load_card’:
drivers/media/dvb/bt8xx/dvb-bt8xx.c:788:10: warning: too many arguments
for format [-Wformat-extra-args]
Perhaps it would be better to add the KERN_ levels throughout the file
with a separate patch. Like this:
Jonathan Nieder (2):
[media] dvb-bt8xx: use dprintk for debug statements
[media] dvb-bt8xx: convert printks to pr_err()
drivers/media/dvb/bt8xx/dvb-bt8xx.c | 41
+--
1 files changed, 20 insertions(+), 21 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drxk: Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor'
On 04-01-2012 16:45, Oliver Endriss wrote: Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor' As a result of this commit, DVB-T tuning did not work anymore. Signed-off-by: Oliver Endriss o.endr...@gmx.de diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c index 36e1c82..13f22a1 100644 --- a/drivers/media/dvb/frontends/drxk_hard.c +++ b/drivers/media/dvb/frontends/drxk_hard.c @@ -6235,6 +6235,8 @@ static int drxk_set_parameters(struct dvb_frontend *fe) case SYS_DVBC_ANNEX_C: state-m_itut_annex_c = true; break; + case SYS_DVBT: + break; default: return -EINVAL; } Hi Oliver, Thanks for the patch! It become obsoleted by the patch that converted the driver to create just one frontend: http://git.linuxtv.org/media_tree.git/commitdiff/fa4b2a171d42ffc512b3a86922ad68e1355eb17a While I don't have DVB-T signal here, the logs were showing that the driver is switching properly between DVB-T and DVB-C. Yet, I'd appreciate if you could test it with a real signal, for us to be 100% sure that everything is working as expected. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: no sound on board 1b80:e309 (sveon stv40)
Hello Devin, you're right: here it goes!
Best,
Mario
On 6 January 2012 19:33, Devin Heitmueller dheitmuel...@kernellabs.com wrote:
On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa mrcer...@gmail.com wrote:
Ok boys: just to let you know that everything works now.
thinking that the problem was with the audio input, I noticed that
card=64 had an amux while card=19 no.
.amux = EM28XX_AMUX_LINE_IN,
So I tried this card and modified the mplayer options accordingly:
mplayer -tv
device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
tv://
notice the forceaudio parameter that reads the audio even if no source
is reported from v4l (The same approach with card=19 does not work)
The output was a bit slugglish so I switched off pulse audio control
of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and
now everything is ok!
I hope this will help some lonenly googlers in the future :)
Regards,
Mario
Hi Mario,
Since you've spent the time to figure out the details of your
particular hardware, you should really consider submitting a patch to
the em28xx driver which adds your device's USB ID. That would allow
others who have that hardware to have it work out of the box with no
need for figuring out the correct cardid value through
experimentation as you had to.
Cheers,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
From dd334663b202eb0569b506273c75f3a0ede6b803 Mon Sep 17 00:00:00 2001
From: Mario Ceresa mrcer...@gmail.com
Date: Fri, 6 Jan 2012 20:00:12 +0100
Subject: [PATCH] Added model Sveon STV40
---
linux/drivers/media/video/em28xx/em28xx-cards.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/linux/drivers/media/video/em28xx/em28xx-cards.c b/linux/drivers/media/video/em28xx/em28xx-cards.c
index 6cab22d..d79c5d1 100644
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c
@@ -2033,6 +2033,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM28174_BOARD_PCTV_460E },
{ USB_DEVICE(0x2040, 0x1605),
.driver_info = EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C },
+ { USB_DEVICE(0x1b80, 0xe309), /* Sveon STV40 */
+ .driver_info = EM2860_BOARD_EASYCAP },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
--
1.7.7.5
Re: em28xx: no sound on board 1b80:e309 (sveon stv40)
On 06-01-2012 17:16, Mario Ceresa wrote: Hello Devin, you're right: here it goes! Hi Mario, Plese send it with your Signed-off-by: It is a requirement for merging the patches upstream. Best, Mario On 6 January 2012 19:33, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa mrcer...@gmail.com wrote: Ok boys: just to let you know that everything works now. thinking that the problem was with the audio input, I noticed that card=64 had an amux while card=19 no. .amux = EM28XX_AMUX_LINE_IN, So I tried this card and modified the mplayer options accordingly: mplayer -tv device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2 tv:// notice the forceaudio parameter that reads the audio even if no source is reported from v4l (The same approach with card=19 does not work) The output was a bit slugglish so I switched off pulse audio control of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and now everything is ok! I hope this will help some lonenly googlers in the future :) Regards, Mario Hi Mario, Since you've spent the time to figure out the details of your particular hardware, you should really consider submitting a patch to the em28xx driver which adds your device's USB ID. That would allow others who have that hardware to have it work out of the box with no need for figuring out the correct cardid value through experimentation as you had to. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: no sound on board 1b80:e309 (sveon stv40)
Hi Mauro,
Here it is. Does the Signed-off-by: go in the changelog, right?
Many thanks to all the developers for the hard work: it is a joy to
see the card working :)
Best,
Mario
On 6 January 2012 20:21, Mauro Carvalho Chehab mche...@redhat.com wrote:
On 06-01-2012 17:16, Mario Ceresa wrote:
Hello Devin, you're right: here it goes!
Hi Mario,
Plese send it with your Signed-off-by:
It is a requirement for merging the patches upstream.
Best,
Mario
On 6 January 2012 19:33, Devin Heitmueller dheitmuel...@kernellabs.com
wrote:
On Fri, Jan 6, 2012 at 1:29 PM, Mario Ceresa mrcer...@gmail.com wrote:
Ok boys: just to let you know that everything works now.
thinking that the problem was with the audio input, I noticed that
card=64 had an amux while card=19 no.
.amux = EM28XX_AMUX_LINE_IN,
So I tried this card and modified the mplayer options accordingly:
mplayer -tv
device=/dev/video0:input=0:norm=PAL:forceaudio:alsa:immediatemode=0:audiorate=48000:amode=1:adevice=hw.2
tv://
notice the forceaudio parameter that reads the audio even if no source
is reported from v4l (The same approach with card=19 does not work)
The output was a bit slugglish so I switched off pulse audio control
of the board (https://bbs.archlinux.org/viewtopic.php?id=114228) and
now everything is ok!
I hope this will help some lonenly googlers in the future :)
Regards,
Mario
Hi Mario,
Since you've spent the time to figure out the details of your
particular hardware, you should really consider submitting a patch to
the em28xx driver which adds your device's USB ID. That would allow
others who have that hardware to have it work out of the box with no
need for figuring out the correct cardid value through
experimentation as you had to.
Cheers,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
From 4599c56dedc80ec345ed87bbbae36eaa02184235 Mon Sep 17 00:00:00 2001
From: Mario Ceresa mrcer...@gmail.com
Date: Fri, 6 Jan 2012 20:00:12 +0100
Subject: [PATCH] Added model Sveon STV40
Signed-off-by: Mario Ceresa mrcer...@gmail.com
---
linux/drivers/media/video/em28xx/em28xx-cards.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/linux/drivers/media/video/em28xx/em28xx-cards.c b/linux/drivers/media/video/em28xx/em28xx-cards.c
index 6cab22d..d79c5d1 100644
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c
@@ -2033,6 +2033,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM28174_BOARD_PCTV_460E },
{ USB_DEVICE(0x2040, 0x1605),
.driver_info = EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C },
+ { USB_DEVICE(0x1b80, 0xe309), /* Sveon STV40 */
+ .driver_info = EM2860_BOARD_EASYCAP },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
--
1.7.7.5
Re: [PATCH] rc-videomate-m1f.c Rename to match remote controler name
On Fri, 06 Jan 2012 17:32:06 +0100, Samuel Rakitničan
samuel.rakitni...@gmail.com wrote:
This remote was added with support for card Compro VideoMate M1F.
This remote is shipped with various Compro cards, not this one only.
Furthermore this remote can be bought separately under name Compro
VideoMate K100.
http://compro.com.tw/en/product/k100/k100.html
So give it a proper name.
Signed-off-by: Samuel Rakitničan samuel.rakitni...@gmail.com
Resending a mail version for patchwork..diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index 36e4d5e..82d898a 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -85,7 +85,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-trekstor.o \
rc-tt-1500.o \
rc-twinhan1027.o \
- rc-videomate-m1f.o \
+ rc-videomate-k100.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
rc-winfast.o \
diff --git a/drivers/media/rc/keymaps/rc-videomate-k100.c
b/drivers/media/rc/keymaps/rc-videomate-k100.c
index 3bd1de1..23ee05e 100644
--- a/drivers/media/rc/keymaps/rc-videomate-k100.c
+++ b/drivers/media/rc/keymaps/rc-videomate-k100.c
@@ -1,4 +1,4 @@
-/* videomate-m1f.h - Keytable for videomate_m1f Remote Controller
+/* videomate-k100.h - Keytable for videomate_k100 Remote Controller
*
* keymap imported from ir-keymaps.c
*
@@ -13,7 +13,7 @@
#include media/rc-map.h
#include linux/module.h
-static struct rc_map_table videomate_m1f[] = {
+static struct rc_map_table videomate_k100[] = {
{ 0x01, KEY_POWER },
{ 0x31, KEY_TUNER },
{ 0x33, KEY_VIDEO },
@@ -67,27 +67,27 @@ static struct rc_map_table videomate_m1f[] = {
{ 0x18, KEY_TEXT },
};
-static struct rc_map_list videomate_m1f_map = {
+static struct rc_map_list videomate_k100_map = {
.map = {
- .scan= videomate_m1f,
- .size= ARRAY_SIZE(videomate_m1f),
+ .scan= videomate_k100,
+ .size= ARRAY_SIZE(videomate_k100),
.rc_type = RC_TYPE_UNKNOWN, /* Legacy IR type */
- .name= RC_MAP_VIDEOMATE_M1F,
+ .name= RC_MAP_VIDEOMATE_K100,
}
};
-static int __init init_rc_map_videomate_m1f(void)
+static int __init init_rc_map_videomate_k100(void)
{
- return rc_map_register(videomate_m1f_map);
+ return rc_map_register(videomate_k100_map);
}
-static void __exit exit_rc_map_videomate_m1f(void)
+static void __exit exit_rc_map_videomate_k100(void)
{
- rc_map_unregister(videomate_m1f_map);
+ rc_map_unregister(videomate_k100_map);
}
-module_init(init_rc_map_videomate_m1f)
-module_exit(exit_rc_map_videomate_m1f)
+module_init(init_rc_map_videomate_k100)
+module_exit(exit_rc_map_videomate_k100)
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Pavel Osnova pvosn...@gmail.com);
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index 1b15b0d..22ecd72 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -755,7 +755,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
polling = 50; /* ms */
break;
case SAA7134_BOARD_VIDEOMATE_M1F:
- ir_codes = RC_MAP_VIDEOMATE_M1F;
+ ir_codes = RC_MAP_VIDEOMATE_K100;
mask_keycode = 0x0ff00;
mask_keyup = 0x04;
break;
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 183d701..f688bde 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -147,7 +147,7 @@ void rc_map_init(void);
#define RC_MAP_TREKSTOR rc-trekstor
#define RC_MAP_TT_1500 rc-tt-1500
#define RC_MAP_TWINHAN_VP1027_DVBS rc-twinhan1027
-#define RC_MAP_VIDEOMATE_M1F rc-videomate-m1f
+#define RC_MAP_VIDEOMATE_K100rc-videomate-k100
#define RC_MAP_VIDEOMATE_S350rc-videomate-s350
#define RC_MAP_VIDEOMATE_TV_PVR rc-videomate-tv-pvr
#define RC_MAP_WINFAST rc-winfast
cx231xx: possible circular locking dependency detected on 3.2
Hello,
I'm running the Hauppauge USB-Live 2 device on an ARM OMAP3 platform.
After loading the cx231xx driver and launching v4l2grab, I immediately
get:
[ 407.087158] cx231xx #0: setPowerMode::mode = 48, No Change req.
[ 407.145477]
[ 407.147064] ==
[ 407.153533] [ INFO: possible circular locking dependency detected ]
[ 407.160095] 3.2.0-7-gb928298 #18
[ 407.163848] ---
[ 407.170410] v4l2grab/680 is trying to acquire lock:
[ 407.175537] (mm-mmap_sem){++}, at: [bf03e10c]
videobuf_qbuf+0x298/0x48c [videobuf_core]
[ 407.184783]
[ 407.184783] but task is already holding lock:
[ 407.190887] (dev-lock#2){+.+.+.}, at: [bf00e47c] v4l2_ioctl+0xec/0x150
[videodev]
[ 407.199249]
[ 407.199249] which lock already depends on the new lock.
[ 407.199249]
[ 407.207824]
[ 407.207824] the existing dependency chain (in reverse order) is:
[ 407.215667]
[ 407.215667] - #1 (dev-lock#2){+.+.+.}:
[ 407.221435][c008bac8] lock_acquire+0x98/0x100
[ 407.226928][c0471594] mutex_lock_interruptible_nested+0x4c/0x37c
[ 407.234161][bf00e378] v4l2_mmap+0x94/0xac [videodev]
[ 407.240295][c00eee5c] mmap_region+0x2d4/0x468
[ 407.245788][c00ef3a0] sys_mmap_pgoff+0x78/0xc0
[ 407.251342][c0013b00] ret_fast_syscall+0x0/0x3c
[ 407.257019]
[ 407.257019] - #0 (mm-mmap_sem){++}:
[ 407.262878][c008b3f0] __lock_acquire+0x1d04/0x1d94
[ 407.268829][c008bac8] lock_acquire+0x98/0x100
[ 407.274291][c04726cc] down_read+0x2c/0x3c
[ 407.279418][bf03e10c] videobuf_qbuf+0x298/0x48c [videobuf_core]
[ 407.286529][bf00fbf4] __video_do_ioctl+0x500/0x55a8 [videodev]
[ 407.293579][bf00f2d0] video_usercopy+0x128/0x4d8 [videodev]
[ 407.300354][bf00e418] v4l2_ioctl+0x88/0x150 [videodev]
[ 407.306671][c0112cd4] do_vfs_ioctl+0x7c/0x584
[ 407.312164][c0113250] sys_ioctl+0x74/0x7c
[ 407.317260][c0013b00] ret_fast_syscall+0x0/0x3c
[ 407.322937]
[ 407.322937] other info that might help us debug this:
[ 407.322937]
[ 407.331329] Possible unsafe locking scenario:
[ 407.331329]
[ 407.337524]CPU0CPU1
[ 407.342285]
[ 407.347015] lock(dev-lock);
[ 407.350311]lock(mm-mmap_sem);
[ 407.356536]lock(dev-lock);
[ 407.362457] lock(mm-mmap_sem);
[ 407.366027]
[ 407.366027] *** DEADLOCK ***
[ 407.366027]
[ 407.372253] 1 lock held by v4l2grab/680:
[ 407.376342] #0: (dev-lock#2){+.+.+.}, at: [bf00e47c]
v4l2_ioctl+0xec/0x150 [videodev]
[ 407.385162]
[ 407.385162] stack backtrace:
[ 407.389739] [c001b3b0] (unwind_backtrace+0x0/0xf0) from [c0087c04]
(print_circular_bug+0x1d4/0x2f0)
[ 407.399597] [c0087c04] (print_circular_bug+0x1d4/0x2f0) from [c008b3f0]
(__lock_acquire+0x1d04/0x1d94)
[ 407.409729] [c008b3f0] (__lock_acquire+0x1d04/0x1d94) from [c008bac8]
(lock_acquire+0x98/0x100)
[ 407.419219] [c008bac8] (lock_acquire+0x98/0x100) from [c04726cc]
(down_read+0x2c/0x3c)
[ 407.427886] [c04726cc] (down_read+0x2c/0x3c) from [bf03e10c]
(videobuf_qbuf+0x298/0x48c [videobuf_core])
[ 407.438201] [bf03e10c] (videobuf_qbuf+0x298/0x48c [videobuf_core]) from
[bf00fbf4] (__video_do_ioctl+0x500/0x55a8 [videodev])
[ 407.450469] [bf00fbf4] (__video_do_ioctl+0x500/0x55a8 [videodev]) from
[bf00f2d0] (video_usercopy+0x128/0x4d8 [videodev])
[ 407.462341] [bf00f2d0] (video_usercopy+0x128/0x4d8 [videodev]) from
[bf00e418] (v4l2_ioctl+0x88/0x150 [videodev])
[ 407.473480] [bf00e418] (v4l2_ioctl+0x88/0x150 [videodev]) from
[c0112cd4] (do_vfs_ioctl+0x7c/0x584)
[ 407.483337] [c0112cd4] (do_vfs_ioctl+0x7c/0x584) from [c0113250]
(sys_ioctl+0x74/0x7c)
[ 407.492004] [c0113250] (sys_ioctl+0x74/0x7c) from [c0013b00]
(ret_fast_syscall+0x0/0x3c)
[ 407.500915] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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: [git:v4l-dvb/for_v3.3] [media] dvb_frontend: Don't use ops-info.type anymore
On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
drivers/media/dvb/dvb-core/dvb_frontend.c | 541
++---
1 files changed, 266 insertions(+), 275 deletions(-)
...
-static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *parms)
+static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
{
...
- /* check for supported modulation */
- if (fe-ops.info.type == FE_QAM
- (parms-u.qam.modulation QAM_AUTO ||
- !((1 (parms-u.qam.modulation + 10)) fe-ops.info.caps))) {
- printk(KERN_WARNING DVB: adapter %i frontend %i modulation %u
not supported\n,
-fe-dvb-num, fe-id, parms-u.qam.modulation);
+ /*
+ * check for supported modulation
+ *
+ * This is currently hacky. Also, it only works for DVB-S friends,
+ * and not all modulations has FE_CAN flags
+ */
+ switch (c-delivery_system) {
+ case SYS_DVBS:
+ case SYS_DVBS2:
+ case SYS_TURBO:
+ if ((c-modulation QAM_AUTO ||
+ !((1 (c-modulation + 10)) fe-ops.info.caps))) {
^^
+ printk(KERN_WARNING
+DVB: adapter %i frontend %i modulation %u not
supported\n,
+fe-dvb-num, fe-id, c-modulation);
return -EINVAL;
+ }
+ break;
...
This code is completely bogus: I get tons of warnings, if vdr tries to
tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.
PSK_8 == 9 is QAM_AUTO, and the shift operation does not make much
sense, except for modulation == 0 == QPSK.
The original version makes more sense for me.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
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] drxk: Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor'
On Friday 06 January 2012 20:11:56 Mauro Carvalho Chehab wrote: On 04-01-2012 16:45, Oliver Endriss wrote: Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor' As a result of this commit, DVB-T tuning did not work anymore. Signed-off-by: Oliver Endriss o.endr...@gmx.de diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c index 36e1c82..13f22a1 100644 --- a/drivers/media/dvb/frontends/drxk_hard.c +++ b/drivers/media/dvb/frontends/drxk_hard.c @@ -6235,6 +6235,8 @@ static int drxk_set_parameters(struct dvb_frontend *fe) case SYS_DVBC_ANNEX_C: state-m_itut_annex_c = true; break; + case SYS_DVBT: + break; default: return -EINVAL; } Hi Oliver, Thanks for the patch! It become obsoleted by the patch that converted the driver to create just one frontend: http://git.linuxtv.org/media_tree.git/commitdiff/fa4b2a171d42ffc512b3a86922ad68e1355eb17a Agreed. While I don't have DVB-T signal here, the logs were showing that the driver is switching properly between DVB-T and DVB-C. Yet, I'd appreciate if you could test it with a real signal, for us to be 100% sure that everything is working as expected. A quick test showed that switching to DVB-T works. Sorry, I do not have a DVB-C signal here. Btw, there are two lines, which are not harmful, but should be removed (bad formatting/dead code). --- drxk_hard.c.old 2012-01-07 01:40:00.0 +0100 +++ drxk_hard.c 2012-01-07 01:40:30.0 +0100 @@ -6236,8 +6236,6 @@ static int drxk_set_parameters(struct dv SetOperationMode(state, OM_QAM_ITU_C); else SetOperationMode(state, OM_QAM_ITU_A); - break; - state-m_itut_annex_c = true; break; case SYS_DVBT: if (!state-m_hasDVBT) CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: Pause/Resume and flush for V4L2 codec drivers.
Thanks Hans. Yes it does solve a part of my problem - Pause/Resume. But I dont see any command defined for Flush yet. Do you think we should add one more command to Flush. Also, I see two more commands #define V4L2_DEC_CMD_START (0) #define V4L2_DEC_CMD_STOP(1) How should I use the above two commands for an encoding/decoding session? I was calling start/stop to hardware in streamon/streamoff earlier. Thanks Vinay On Friday, January 06, 2012 03:31:37 vka...@codeaurora.org wrote: Hi I am trying to implement v4l2 driver for video decoders. The problem I am facing is how to send pause/resume and flush commands from user-space to v4l2 driver. I am thinking of using controls for this. Has anyone done this before or if anyone has any ideas please let me know. Appreciate your help. See this patch series: http://www.mail-archive.com/linux-media@vger.kernel.org/msg40516.html Does this give you what you need? Regards, Hans Thanks Vinay -- 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 -- 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:v4l-dvb/for_v3.3] [media] dvb_frontend: Don't use ops-info.type anymore
On 06-01-2012 22:36, Oliver Endriss wrote:
On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
drivers/media/dvb/dvb-core/dvb_frontend.c | 541
++---
1 files changed, 266 insertions(+), 275 deletions(-)
...
-static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
-struct dvb_frontend_parameters *parms)
+static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
{
...
-/* check for supported modulation */
-if (fe-ops.info.type == FE_QAM
-(parms-u.qam.modulation QAM_AUTO ||
- !((1 (parms-u.qam.modulation + 10)) fe-ops.info.caps))) {
-printk(KERN_WARNING DVB: adapter %i frontend %i modulation %u
not supported\n,
- fe-dvb-num, fe-id, parms-u.qam.modulation);
+/*
+ * check for supported modulation
+ *
+ * This is currently hacky. Also, it only works for DVB-S friends,
+ * and not all modulations has FE_CAN flags
+ */
+switch (c-delivery_system) {
+case SYS_DVBS:
+case SYS_DVBS2:
+case SYS_TURBO:
+if ((c-modulation QAM_AUTO ||
+!((1 (c-modulation + 10)) fe-ops.info.caps))) {
^^
+printk(KERN_WARNING
+ DVB: adapter %i frontend %i modulation %u not
supported\n,
+ fe-dvb-num, fe-id, c-modulation);
return -EINVAL;
+}
+break;
...
This code is completely bogus: I get tons of warnings, if vdr tries to
tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.
PSK_8 == 9 is QAM_AUTO, and the shift operation does not make much
sense, except for modulation == 0 == QPSK.
The original version makes more sense for me.
Oliver,
At least for DVBv3 calls, the old code will also generate bogus
warnings if you try to use a DVBv3 call to set PSK_8.
I almost removed this validation code during the conversion for several
reasons:
1) it does some magic by assuming that all QAM modulations are below
QAM_AUTO;
2) it checks modulation parameters only for DVB-S. IMO, or the core should
invalid parameters for all delivery systems, or should let the frontend
drivers do it;
3) frontend drivers should already be checking for invalid parameters
(most of them do it, anyway);
4) not all modulations are mapped at fe-ops.info.caps, so it is not
even possible to check for the valid modulations inside the core for
some delivery systems;
5) Why the core checks just the modulation, and doesn't check for other
types of invalid parameters, like FEC and bandwidth?
At the end, I decided to keep it, but added that note, as I really didn't
like that part of the code.
I can see two fixes for this:
a) just remove the validation, and let the frontend check what's
supported;
b) rewrite the code with a per-standard table of valid values.
I vote for removing the validation logic there.
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)
On 05-01-2012 17:09, Mauro Carvalho Chehab wrote: On 05-01-2012 15:47, Linus Torvalds wrote: Can you test the patch with some media capture apps (preferably with the obvious fix for the problem that Paulo already pointed out - although that won't actually matter until some block driver starts using ENOIOCTLCMD there, so even the unfixed patch should mostly work for testing)? Sure. I'm currently traveling, so I have just my first aids kit of devices but they should be enough for testing it. I'll return you as soon as I finish compiling the kernel on this slow 4 years-old notebook and run some tests with the usual applications. I did a quick test today: didn't notice any regressions with the usual applications. 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: [git:v4l-dvb/for_v3.3] [media] dvb_frontend: Don't use ops-info.type anymore
On Saturday 07 January 2012 03:05:40 Mauro Carvalho Chehab wrote:
On 06-01-2012 22:36, Oliver Endriss wrote:
On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
drivers/media/dvb/dvb-core/dvb_frontend.c | 541
++---
1 files changed, 266 insertions(+), 275 deletions(-)
...
-static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *parms)
+static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
{
...
- /* check for supported modulation */
- if (fe-ops.info.type == FE_QAM
- (parms-u.qam.modulation QAM_AUTO ||
- !((1 (parms-u.qam.modulation + 10)) fe-ops.info.caps))) {
- printk(KERN_WARNING DVB: adapter %i frontend %i modulation %u
not supported\n,
- fe-dvb-num, fe-id, parms-u.qam.modulation);
+ /*
+ * check for supported modulation
+ *
+ * This is currently hacky. Also, it only works for DVB-S friends,
+ * and not all modulations has FE_CAN flags
+ */
+ switch (c-delivery_system) {
+ case SYS_DVBS:
+ case SYS_DVBS2:
+ case SYS_TURBO:
+ if ((c-modulation QAM_AUTO ||
+ !((1 (c-modulation + 10)) fe-ops.info.caps))) {
^^
+ printk(KERN_WARNING
+ DVB: adapter %i frontend %i modulation %u not
supported\n,
+ fe-dvb-num, fe-id, c-modulation);
return -EINVAL;
+ }
+ break;
...
This code is completely bogus: I get tons of warnings, if vdr tries to
tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.
PSK_8 == 9 is QAM_AUTO, and the shift operation does not make much
sense, except for modulation == 0 == QPSK.
The original version makes more sense for me.
Oliver,
At least for DVBv3 calls, the old code will also generate bogus
warnings if you try to use a DVBv3 call to set PSK_8.
No, since the checks were only performed for type==QAM, i.e. DVB-C.
So DVB-S2 was not affected before.
I almost removed this validation code during the conversion for several
reasons:
1) it does some magic by assuming that all QAM modulations are below
QAM_AUTO;
2) it checks modulation parameters only for DVB-S. IMO, or the core should
invalid parameters for all delivery systems, or should let the frontend
drivers do it;
3) frontend drivers should already be checking for invalid parameters
(most of them do it, anyway);
4) not all modulations are mapped at fe-ops.info.caps, so it is not
even possible to check for the valid modulations inside the core for
some delivery systems;
5) Why the core checks just the modulation, and doesn't check for other
types of invalid parameters, like FEC and bandwidth?
At the end, I decided to keep it, but added that note, as I really didn't
like that part of the code.
I can see two fixes for this:
a) just remove the validation, and let the frontend check what's
supported;
b) rewrite the code with a per-standard table of valid values.
I vote for removing the validation logic there.
Ack.
Atm the core could only do proper checks for frontends, which support a
single delivery system. For multi-delsys frontends some values of the
info struct might not apply to the currently selected delivery system.
To fix this, you need precise information, what is supported for a given
delivery system. In this case we need 'per delivery system' information.
Maybe it would make sense to add a callback, and let the driver do the
checks?
Furthermore, old API-5 applications do not set the delivery system!
For example: VDR checked the FE_CAN_2G_MODULATION flag and eventually
issues a tune call, no matter whether the current delsys is DVB-S or
DVB-S2. So it is difficult to do check parameters in a precise way,
while keeping backward compatibility.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
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:v4l-dvb/for_v3.3] [media] dvb_frontend: Don't use ops-info.type anymore
On 07-01-2012 03:18, Oliver Endriss wrote:
On Saturday 07 January 2012 03:05:40 Mauro Carvalho Chehab wrote:
On 06-01-2012 22:36, Oliver Endriss wrote:
On Wednesday 04 January 2012 20:29:36 Mauro Carvalho Chehab wrote:
drivers/media/dvb/dvb-core/dvb_frontend.c | 541
++---
1 files changed, 266 insertions(+), 275 deletions(-)
...
-static int dvb_frontend_check_parameters(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *parms)
+static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
{
...
- /* check for supported modulation */
- if (fe-ops.info.type == FE_QAM
- (parms-u.qam.modulation QAM_AUTO ||
- !((1 (parms-u.qam.modulation + 10)) fe-ops.info.caps))) {
- printk(KERN_WARNING DVB: adapter %i frontend %i modulation %u
not supported\n,
- fe-dvb-num, fe-id, parms-u.qam.modulation);
+ /*
+ * check for supported modulation
+ *
+ * This is currently hacky. Also, it only works for DVB-S friends,
+ * and not all modulations has FE_CAN flags
+ */
+ switch (c-delivery_system) {
+ case SYS_DVBS:
+ case SYS_DVBS2:
+ case SYS_TURBO:
+ if ((c-modulation QAM_AUTO ||
+ !((1 (c-modulation + 10)) fe-ops.info.caps))) {
^^
+ printk(KERN_WARNING
+ DVB: adapter %i frontend %i modulation %u not
supported\n,
+ fe-dvb-num, fe-id, c-modulation);
return -EINVAL;
+ }
+ break;
...
This code is completely bogus: I get tons of warnings, if vdr tries to
tune to DVB-S2 (modulation == 9 == PSK_8) on my stv090x.
PSK_8 == 9 is QAM_AUTO, and the shift operation does not make much
sense, except for modulation == 0 == QPSK.
The original version makes more sense for me.
Oliver,
At least for DVBv3 calls, the old code will also generate bogus
warnings if you try to use a DVBv3 call to set PSK_8.
No, since the checks were only performed for type==QAM, i.e. DVB-C.
So DVB-S2 was not affected before.
Sorry, I coded it wrong.
Anyway, when DVB-C2 will be added, the code will likely break again.
I almost removed this validation code during the conversion for several
reasons:
1) it does some magic by assuming that all QAM modulations are below
QAM_AUTO;
2) it checks modulation parameters only for DVB-S. IMO, or the core should
invalid parameters for all delivery systems, or should let the frontend
drivers do it;
3) frontend drivers should already be checking for invalid parameters
(most of them do it, anyway);
4) not all modulations are mapped at fe-ops.info.caps, so it is not
even possible to check for the valid modulations inside the core for
some delivery systems;
5) Why the core checks just the modulation, and doesn't check for other
types of invalid parameters, like FEC and bandwidth?
At the end, I decided to keep it, but added that note, as I really didn't
like that part of the code.
I can see two fixes for this:
a) just remove the validation, and let the frontend check what's
supported;
b) rewrite the code with a per-standard table of valid values.
I vote for removing the validation logic there.
Ack.
Atm the core could only do proper checks for frontends, which support a
single delivery system. For multi-delsys frontends some values of the
info struct might not apply to the currently selected delivery system.
To fix this, you need precise information, what is supported for a given
delivery system. In this case we need 'per delivery system' information.
Maybe it would make sense to add a callback, and let the driver do the
checks?
With the changes I made, all frontends are now filling ops.delsys with
the supported delivery system. The DVB core picks ops.delsys[0] during
register and on cache clear. So, no callback is needed, and the core can
quickly check the supported delivery systems.
Furthermore, old API-5 applications do not set the delivery system!
In this case, it will use ops.delsys[0]. On all frondends with 2G support,
the first delivery system is the 1 gen.
For example: VDR checked the FE_CAN_2G_MODULATION flag and eventually
issues a tune call, no matter whether the current delsys is DVB-S or
DVB-S2. So it is difficult to do check parameters in a precise way,
while keeping backward compatibility.
Yes. Still, the frontend may not do the right thing, as it may use different
checks for SYS_DVBS/SYS_DVBS2 internally.
I did not touch (at least not intentionally) on any of such checks, but a
quick grep for SYS_DVBS2 shows that setting the wrong delivery system will
cause troubles.
For example, on frontends/ds3000.c, ds3000_read_status() uses a different
register for DVB_S2 lock. So, an application that doesn't set the delivery
system to SYS_DVBS2 will (likely) not lock into DVB-S2 channels.
The
[PATCH RFC] [media] dvb: remove bogus modulation check
This code is wrong as I should have coded it as SYS_DVBC, instead of
SYS_DVBS friends. Anyway, this check has other problems
1) it does some magic by assuming that all QAM modulations are below
QAM_AUTO;
2) it checks modulation parameters only for one delivery system.
Or the core should check invalid parameters for all delivery
systems, or it should let the frontend drivers do it;
3) frontend drivers should already be checking for invalid parameters
(most of them do it, anyway);
4) not all modulations are mapped at fe-ops.info.caps, so it is not
even possible to check for the valid modulations inside the core
for some delivery systems;
5) The core check is incomplete anyway: it only checks for a few
parameters. If moved into the core other parameters like bandwidth
and fec should also be checked;
6) 2nd gen DVB-C uses OFDM. So, that test would fail for it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 23 ---
1 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 0e079a1..a904793 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -897,29 +897,6 @@ static int dvb_frontend_check_parameters(struct
dvb_frontend *fe)
break;
}
- /*
-* check for supported modulation
-*
-* This is currently hacky. Also, it only works for DVB-S friends,
-* and not all modulations has FE_CAN flags
-*/
- switch (c-delivery_system) {
- case SYS_DVBS:
- case SYS_DVBS2:
- case SYS_TURBO:
- if ((c-modulation QAM_AUTO ||
- !((1 (c-modulation + 10)) fe-ops.info.caps))) {
- printk(KERN_WARNING
- DVB: adapter %i frontend %i modulation %u not
supported\n,
- fe-dvb-num, fe-id, c-modulation);
- return -EINVAL;
- }
- break;
- default:
- /* FIXME: it makes sense to validate othere delsys here */
- break;
- }
-
return 0;
}
--
1.7.7.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
