[PATCH 2/5] soc-camera: tw9910: Add output signal control
tw9910 can control output signal.
This patch will stop all signal when video was stopped.
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 35 ---
1 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 5152d56..8bda689 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -152,7 +152,8 @@
/* 1 : non-auto */
#define VSCTL 0x08 /* 1 : Vertical out ctrl by DVALID */
/* 0 : Vertical out ctrl by HACTIVE and DVALID */
-#define OEN 0x04 /* Output Enable together with TRI_SEL. */
+#define OEN 0x00 /* Enable output */
+#define EN_TRI_SEL 0x04 /* TRI_SEL output */
/* OUTCTR1 */
#define VSP_LO 0x00 /* 0 : VS pin output polarity is active low */
@@ -236,7 +237,6 @@ struct tw9910_priv {
static const struct regval_list tw9910_default_regs[] =
{
- { OPFORM, 0x00 },
{ OUTCTR1, VSP_LO | VSSL_VVALID | HSP_HI | HSSL_HSYNC },
ENDMARKER,
};
@@ -513,19 +513,32 @@ static int tw9910_s_stream(struct v4l2_subdev *sd, int
enable)
{
struct i2c_client *client = sd-priv;
struct tw9910_priv *priv = to_tw9910(client);
+ u8 val;
- if (!enable)
+ if (!enable) {
+ switch (priv-rev) {
+ case 0:
+ val = EN_TRI_SEL | 0x2;
+ break;
+ case 1:
+ val = EN_TRI_SEL | 0x3;
+ break;
+ }
return 0;
+ } else {
- if (!priv-scale) {
- dev_err(client-dev, norm select error\n);
- return -EPERM;
+ if (!priv-scale) {
+ dev_err(client-dev, norm select error\n);
+ return -EPERM;
+ }
+
+ dev_dbg(client-dev, %s %dx%d\n,
+ priv-scale-name,
+ priv-scale-width,
+ priv-scale-height);
}
- dev_dbg(client-dev, %s %dx%d\n,
-priv-scale-name,
-priv-scale-width,
-priv-scale-height);
+ tw9910_mask_set(client, OPFORM, 0x7, val);
return 0;
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] soc-camera: tw9910: Add output pin control.
tw9910 can select output pin width and vs/hs pin feature.
This patch add new flags definition to control it.
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 72 --
include/media/tw9910.h | 21 +++-
2 files changed, 47 insertions(+), 46 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 8bda689..bdabc9a 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -201,12 +201,6 @@
/*
* structure
*/
-
-struct regval_list {
- unsigned char reg_num;
- unsigned char value;
-};
-
struct tw9910_scale_ctrl {
char *name;
unsigned short width;
@@ -229,18 +223,6 @@ struct tw9910_priv {
int rev;
};
-/*
- * register settings
- */
-
-#define ENDMARKER { 0xff, 0xff }
-
-static const struct regval_list tw9910_default_regs[] =
-{
- { OUTCTR1, VSP_LO | VSSL_VVALID | HSP_HI | HSSL_HSYNC },
- ENDMARKER,
-};
-
static const struct soc_camera_data_format tw9910_color_fmt[] = {
{
.name = VYUY,
@@ -442,20 +424,6 @@ static int tw9910_set_hsync(struct i2c_client *client,
return ret;
}
-static int tw9910_write_array(struct i2c_client *client,
- const struct regval_list *vals)
-{
- while (vals-reg_num != 0xff) {
- int ret = i2c_smbus_write_byte_data(client,
- vals-reg_num,
- vals-value);
- if (ret 0)
- return ret;
- vals++;
- }
- return 0;
-}
-
static int tw9910_mask_set(struct i2c_client *client, u8 command,
u8 mask, u8 set)
{
@@ -469,6 +437,24 @@ static int tw9910_mask_set(struct i2c_client *client, u8
command,
return i2c_smbus_write_byte_data(client, command, val);
}
+static int tw9910_set_outputcontrol(struct i2c_client *client)
+{
+ struct tw9910_priv *priv = to_tw9910(client);
+ u32 flags = priv-info-flags;
+ u8 val = 0;
+
+ if (flags TW9910_FLG_VS_ACTIVE_HIGH)
+ val |= (1 7);
+
+ if (flags TW9910_FLG_HS_ACTIVE_HIGH)
+ val |= (1 3);
+
+ val |= ((flags TW9910_FLG_VS_MASK) TW9910_FLG_VS_SHIFT) 4;
+ val |= ((flags TW9910_FLG_HS_MASK) TW9910_FLG_HS_SHIFT) 0;
+
+ return tw9910_mask_set(client, OUTCTR1, 0xff, val);
+}
+
static void tw9910_reset(struct i2c_client *client)
{
i2c_smbus_write_byte_data(client, ACNTL1, SRESET);
@@ -513,7 +499,7 @@ static int tw9910_s_stream(struct v4l2_subdev *sd, int
enable)
{
struct i2c_client *client = sd-priv;
struct tw9910_priv *priv = to_tw9910(client);
- u8 val;
+ u8 val = OEN;
if (!enable) {
switch (priv-rev) {
@@ -556,7 +542,12 @@ static unsigned long tw9910_query_bus_param(struct
soc_camera_device *icd)
struct soc_camera_link *icl = to_soc_camera_link(icd);
unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | priv-info-buswidth;
+ SOCAM_DATA_ACTIVE_HIGH;
+
+ if (TW9910_FLG_DATAWIDTH_16 priv-info-flags)
+ flags |= SOCAM_DATAWIDTH_16;
+ else
+ flags |= SOCAM_DATAWIDTH_8;
return soc_camera_apply_sensor_flags(icl, flags);
}
@@ -648,7 +639,7 @@ static int tw9910_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
* reset hardware
*/
tw9910_reset(client);
- ret = tw9910_write_array(client, tw9910_default_regs);
+ ret = tw9910_set_outputcontrol(client);
if (ret 0)
goto tw9910_set_fmt_error;
@@ -656,7 +647,7 @@ static int tw9910_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
* set bus width
*/
val = 0x00;
- if (SOCAM_DATAWIDTH_16 == priv-info-buswidth)
+ if (TW9910_FLG_DATAWIDTH_16 priv-info-flags)
val = LEN;
ret = tw9910_mask_set(client, OPFORM, LEN, val);
@@ -888,15 +879,6 @@ static int tw9910_video_probe(struct soc_camera_device
*icd,
to_soc_camera_host(icd-dev.parent)-nr != icd-iface)
return -ENODEV;
- /*
-* tw9910 only use 8 or 16 bit bus width
-*/
- if (SOCAM_DATAWIDTH_16 != priv-info-buswidth
- SOCAM_DATAWIDTH_8 != priv-info-buswidth) {
- dev_err(client-dev, bus width error\n);
- return -ENODEV;
- }
-
icd-formats = tw9910_color_fmt;
icd-num_formats = ARRAY_SIZE(tw9910_color_fmt);
diff --git a/include/media/tw9910.h b/include/media/tw9910.h
index 6ddb654..494ac53 100644
--- a/include/media/tw9910.h
+++ b/include/media/tw9910.h
@@ -18,6 +18,25 @@
#include
[PATCH 4/5] soc-camera: tw9910: Remove crop setting
Current driver had been set default value for copping,
but this value need not be changed at now.
In addition, default value is different by Revision 0 and 1.
So, this patch remove this settings
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 55 --
1 files changed, 0 insertions(+), 55 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index bdabc9a..59158bb 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -209,13 +209,6 @@ struct tw9910_scale_ctrl {
u16 vscale;
};
-struct tw9910_cropping_ctrl {
- u16 vdelay;
- u16 vactive;
- u16 hdelay;
- u16 hactive;
-};
-
struct tw9910_priv {
struct v4l2_subdevsubdev;
struct tw9910_video_info *info;
@@ -322,13 +315,6 @@ static const struct tw9910_scale_ctrl tw9910_pal_scales[]
= {
},
};
-static const struct tw9910_cropping_ctrl tw9910_cropping_ctrl = {
- .vdelay = 0x0012,
- .vactive = 0x00F0,
- .hdelay = 0x0010,
- .hactive = 0x02D0,
-};
-
/*
* general function
*/
@@ -360,40 +346,6 @@ static int tw9910_set_scale(struct i2c_client *client,
return ret;
}
-static int tw9910_set_cropping(struct i2c_client *client,
- const struct tw9910_cropping_ctrl *cropping)
-{
- int ret;
-
- ret = i2c_smbus_write_byte_data(client, CROP_HI,
- (cropping-vdelay 0x0300) 2 |
- (cropping-vactive 0x0300) 4 |
- (cropping-hdelay 0x0300) 6 |
- (cropping-hactive 0x0300) 8);
- if (ret 0)
- return ret;
-
- ret = i2c_smbus_write_byte_data(client, VDELAY_LO,
- cropping-vdelay 0x00FF);
- if (ret 0)
- return ret;
-
- ret = i2c_smbus_write_byte_data(client, VACTIVE_LO,
- cropping-vactive 0x00FF);
- if (ret 0)
- return ret;
-
- ret = i2c_smbus_write_byte_data(client, HDELAY_LO,
- cropping-hdelay 0x00FF);
- if (ret 0)
- return ret;
-
- ret = i2c_smbus_write_byte_data(client, HACTIVE_LO,
- cropping-hactive 0x00FF);
-
- return ret;
-}
-
static int tw9910_set_hsync(struct i2c_client *client,
const u16 start, const u16 end)
{
@@ -690,13 +642,6 @@ static int tw9910_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
goto tw9910_set_fmt_error;
/*
-* set cropping
-*/
- ret = tw9910_set_cropping(client, tw9910_cropping_ctrl);
- if (ret 0)
- goto tw9910_set_fmt_error;
-
- /*
* set hsync
*/
ret = tw9910_set_hsync(client,
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] soc-camera: tw9910: Add revision control on tw9910_set_hsync
10 - 3 bit hsync control are same as Rev0/Rev1.
But only rev1 can control more 3 bit for hsync.
This patch modify this problem
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 59158bb..a688c11 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -349,6 +349,7 @@ static int tw9910_set_scale(struct i2c_client *client,
static int tw9910_set_hsync(struct i2c_client *client,
const u16 start, const u16 end)
{
+ struct tw9910_priv *priv = to_tw9910(client);
int ret;
/* bit 10 - 3 */
@@ -363,15 +364,22 @@ static int tw9910_set_hsync(struct i2c_client *client,
if (ret 0)
return ret;
- /* bit 2 - 0 */
- ret = i2c_smbus_read_byte_data(client, HSLOWCTL);
- if (ret 0)
- return ret;
+ /* FIXME
+*
+* So far only revisions 0 and 1 have been seen
+*/
+ if (1 == priv-rev) {
- ret = i2c_smbus_write_byte_data(client, HSLOWCTL,
- (ret0x88)|
- (start 0x0007) 4 |
- (end0x0007));
+ /* bit 2 - 0 */
+ ret = i2c_smbus_read_byte_data(client, HSLOWCTL);
+ if (ret 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, HSLOWCTL,
+ (ret0x88)|
+ (start 0x0007) 4 |
+ (end0x0007));
+ }
return ret;
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] soc-camera: tw9910: Add revision control
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index df7934d..5152d56 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -225,6 +225,7 @@ struct tw9910_priv {
struct v4l2_subdevsubdev;
struct tw9910_video_info *info;
const struct tw9910_scale_ctrl *scale;
+ int rev;
};
/*
@@ -570,8 +571,11 @@ static int tw9910_enum_input(struct soc_camera_device *icd,
static int tw9910_g_chip_ident(struct v4l2_subdev *sd,
struct v4l2_dbg_chip_ident *id)
{
+ struct i2c_client *client = sd-priv;
+ struct tw9910_priv *priv = to_tw9910(client);
+
id-ident = V4L2_IDENT_TW9910;
- id-revision = 0;
+ id-revision = priv-rev;
return 0;
}
@@ -896,6 +900,8 @@ static int tw9910_video_probe(struct soc_camera_device *icd,
return -ENODEV;
}
+ priv-rev = GET_ReV(val);
+
dev_info(client-dev,
tw9910 Product ID %0x:%0x\n, GET_ID(val), GET_ReV(val));
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
16apsk for cx24116
Hi Does cx24116 support 16apsk for the modulation? BR/KH Ogden Nash - The trouble with a kitten is that when it grows up, it's always a cat. -- 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
uvcvideo causes ehci_hcd to halt
Hi, Some recent netbooks (Some MSI winds and LG X110's) equipped with an integrated webcam have non-working USB ports unless the uvcvideo module is blacklisted. I've found some bug reports in launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/435352 I have an LG X110 on which I can reproduce the problem with 2.6.30.8. Here's the interesting part in dmesg: Oct 13 08:46:32 x110 kernel: [ 261.048312] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203) Oct 13 08:46:32 x110 kernel: [ 261.053592] input: BisonCam, NB Pro as /devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10 Oct 13 08:46:32 x110 kernel: [ 261.053891] usbcore: registered new interface driver uvcvideo Oct 13 08:46:32 x110 kernel: [ 261.054755] USB Video Class driver (v0.1.0) Oct 13 08:46:32 x110 kernel: [ 261.091014] ehci_hcd :00:1d.7: force halt; handhake f807c024 4000 - -110 Oct 13 08:46:33 x110 kernel: [ 261.742335] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742360] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742381] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742400] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742419] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742433] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742454] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742478] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742496] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742514] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742532] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742550] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742564] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742582] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742597] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742609] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742622] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742634] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742647] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742657] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742670] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742684] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742697] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742709] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742722] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742734] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742744] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742758] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742771] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742839] hub 1-0:1.0: hub_port_status failed (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742902] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742923] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742943] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742963] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742983] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742997] hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.743018] hub 1-0:1.0: cannot disable port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743041] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743059] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743076] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743092] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743108] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743121] hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.743139] hub 1-0:1.0: cannot disable port 2 (err = -108) Oct 13
[PATCH 0/5] tw9910: Revision control patches
Dear Guennadi Kuninori Morimoto : soc-camera: tw9910: Add revision control soc-camera: tw9910: Add output signal control soc-camera: tw9910: Add output pin control. soc-camera: tw9910: Remove crop setting soc-camera: tw9910: Add revision control on tw9910_set_hsync I have tw9910 Rev0 and Rev1, and it have a little difference. These patches absorbs the difference of revision. And add new flags for platform. These patches are tested on EcoVec24 and MigoR board. These patches are depend on 30 Sep 2009[PATCH 0/4] tw9910: Add INTERLACE TB/BT support Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] soc-camera: tw9910: Add output signal control
On Tue, 13 Oct 2009, Kuninori Morimoto wrote:
tw9910 can control output signal.
This patch will stop all signal when video was stopped.
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 35 ---
1 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 5152d56..8bda689 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -152,7 +152,8 @@
/* 1 : non-auto */
#define VSCTL 0x08 /* 1 : Vertical out ctrl by DVALID */
/* 0 : Vertical out ctrl by HACTIVE and DVALID */
-#define OEN 0x04 /* Output Enable together with TRI_SEL. */
+#define OEN 0x00 /* Enable output */
+#define EN_TRI_SEL 0x04 /* TRI_SEL output */
Is this to tri-state the output? Ok, from the datasheet it tri-states all
outputs except clocks. My copy of the datasheet is funny at this point. It
first describes OEN = bit 2 of OPFORM, and then the TRI_SEL field, which
is said to occupy bits 1-0, but is documented together with bit 2 with
values 0-7... And you cannot really say that values 0-3 have a feature
distinguishing them from values 4-7. So, I wouldn't separate OEN and just
use the bits 2-0 as a single field. And call the required values like
#define OEN_TRI_SEL_ALL_ON 0
#define OEN_TRI_SEL_CLK_ON 4
/* OUTCTR1 */
#define VSP_LO 0x00 /* 0 : VS pin output polarity is active low */
@@ -236,7 +237,6 @@ struct tw9910_priv {
static const struct regval_list tw9910_default_regs[] =
{
- { OPFORM, 0x00 },
{ OUTCTR1, VSP_LO | VSSL_VVALID | HSP_HI | HSSL_HSYNC },
ENDMARKER,
};
@@ -513,19 +513,32 @@ static int tw9910_s_stream(struct v4l2_subdev *sd, int
enable)
{
struct i2c_client *client = sd-priv;
struct tw9910_priv *priv = to_tw9910(client);
+ u8 val;
- if (!enable)
+ if (!enable) {
+ switch (priv-rev) {
+ case 0:
+ val = EN_TRI_SEL | 0x2;
+ break;
+ case 1:
+ val = EN_TRI_SEL | 0x3;
+ break;
+ }
return 0;
+ } else {
Ok, it's 8:30 here, so, I might be still not quite awake... but I fail to
understand, why you bother calculating val above if you anyway just return
immediately without using it? And if that return is misplaced - what are
those 2 and 3 constants doing?
- if (!priv-scale) {
- dev_err(client-dev, norm select error\n);
- return -EPERM;
+ if (!priv-scale) {
+ dev_err(client-dev, norm select error\n);
+ return -EPERM;
+ }
+
+ dev_dbg(client-dev, %s %dx%d\n,
+ priv-scale-name,
+ priv-scale-width,
+ priv-scale-height);
}
- dev_dbg(client-dev, %s %dx%d\n,
- priv-scale-name,
- priv-scale-width,
- priv-scale-height);
+ tw9910_mask_set(client, OPFORM, 0x7, val);
...and you don't get an uninitialised variable warning here? I don't see
where val gets set in the enable case... Please, wake me up if I'm
dreaming. Oh, I see, you fix it in the next patch. Please, don't do that!
Don't introduce bugs to fix them in a later patch. Do it here.
return 0;
Yes, tri-stating outputs for switched off streaming is better than doing
nothing at all, but isn't there anything else that can be safely powered
down? What about CLK_PDN, Y_PDN and C_PDN in ACNTL? YSV, CSV and PLL_PDN
in Analog Control II? I would also expect, that we can at least tristate
all outputs without any problem, we shouldn't need pixel clock running
with disabled streaming.
}
--
1.6.0.4
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx mode switching
On Tue, Oct 13, 2009 at 1:04 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Oct 12, 2009 at 6:31 PM, Antti Palosaari cr...@iki.fi wrote: I ran this same trap few weeks ago when adding Reddo DVB-C USB Box support to em28xx :) Anyhow, since it is dvb only device I decided to switch from .dvb_gpio to .tuner_gpio to fix the problem. I haven't pull requested it yet. http://linuxtv.org/hg/~anttip/reddo-dvb-c/rev/38f946af568f Antti -- http://palosaari.fi/ You were able to get by with using tuner_gpio instead of dvb_gpio because the Reddo isn't a hybrid device. I'm going to propose removing the calls to em28xx_set_mode() in start_streaming() and stop_streaming(). Given the supported boards that are there, I can regression test: EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950 EM2880_BOARD_PINNACLE_PCTV_HD_PRO EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900 EM2880_BOARD_TERRATEC_HYBRID_XS and I cannot regression test: EM2880_BOARD_KWORLD_DVB_310U (I have a strong suspicion this board is currently broken anyway) EM2882_BOARD_TERRATEC_HYBRID_XS (I worked with the authors of this one and can probably get them to test) EM2882_BOARD_EVGA_INDTUBE (I worked with the authors of this one and can probably get them to test) EM2880_BOARD_EMPIRE_DUAL_TV (I worked with the authors of this one and can probably get them to test) EM2881_BOARD_PINNACLE_HYBRID_PRO (this is the board I noticed the problem under) I own a Dazzle Hybrid Stick (2881:eb1a IIRC) which I believe use the same hardware as the Pinnacle Hybrid Pro. I can test it with DVB-T, but only on the weekend (I have only access to DVB-C during the week). EM2883_BOARD_KWORLD_HYBRID_330U EM2870_BOARD_REDDO_DVB_C_USB_BOX Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- Alain Perrot -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] soc-camera: tw9910: Add output pin control.
On Tue, 13 Oct 2009, Kuninori Morimoto wrote:
tw9910 can select output pin width and vs/hs pin feature.
This patch add new flags definition to control it.
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 72
--
include/media/tw9910.h | 21 +++-
2 files changed, 47 insertions(+), 46 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 8bda689..bdabc9a 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -201,12 +201,6 @@
/*
* structure
*/
-
-struct regval_list {
- unsigned char reg_num;
- unsigned char value;
-};
-
struct tw9910_scale_ctrl {
char *name;
unsigned short width;
@@ -229,18 +223,6 @@ struct tw9910_priv {
int rev;
};
-/*
- * register settings
- */
-
-#define ENDMARKER { 0xff, 0xff }
-
-static const struct regval_list tw9910_default_regs[] =
-{
- { OUTCTR1, VSP_LO | VSSL_VVALID | HSP_HI | HSSL_HSYNC },
- ENDMARKER,
-};
-
static const struct soc_camera_data_format tw9910_color_fmt[] = {
{
.name = VYUY,
@@ -442,20 +424,6 @@ static int tw9910_set_hsync(struct i2c_client *client,
return ret;
}
-static int tw9910_write_array(struct i2c_client *client,
- const struct regval_list *vals)
-{
- while (vals-reg_num != 0xff) {
- int ret = i2c_smbus_write_byte_data(client,
- vals-reg_num,
- vals-value);
- if (ret 0)
- return ret;
- vals++;
- }
- return 0;
-}
-
static int tw9910_mask_set(struct i2c_client *client, u8 command,
u8 mask, u8 set)
{
@@ -469,6 +437,24 @@ static int tw9910_mask_set(struct i2c_client *client, u8
command,
return i2c_smbus_write_byte_data(client, command, val);
}
+static int tw9910_set_outputcontrol(struct i2c_client *client)
+{
+ struct tw9910_priv *priv = to_tw9910(client);
+ u32 flags = priv-info-flags;
+ u8 val = 0;
+
+ if (flags TW9910_FLG_VS_ACTIVE_HIGH)
+ val |= (1 7);
+
+ if (flags TW9910_FLG_HS_ACTIVE_HIGH)
+ val |= (1 3);
+
+ val |= ((flags TW9910_FLG_VS_MASK) TW9910_FLG_VS_SHIFT) 4;
+ val |= ((flags TW9910_FLG_HS_MASK) TW9910_FLG_HS_SHIFT) 0;
+
+ return tw9910_mask_set(client, OUTCTR1, 0xff, val);
+}
+
static void tw9910_reset(struct i2c_client *client)
{
i2c_smbus_write_byte_data(client, ACNTL1, SRESET);
@@ -513,7 +499,7 @@ static int tw9910_s_stream(struct v4l2_subdev *sd, int
enable)
{
struct i2c_client *client = sd-priv;
struct tw9910_priv *priv = to_tw9910(client);
- u8 val;
+ u8 val = OEN;
if (!enable) {
switch (priv-rev) {
@@ -556,7 +542,12 @@ static unsigned long tw9910_query_bus_param(struct
soc_camera_device *icd)
struct soc_camera_link *icl = to_soc_camera_link(icd);
unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | priv-info-buswidth;
+ SOCAM_DATA_ACTIVE_HIGH;
+
+ if (TW9910_FLG_DATAWIDTH_16 priv-info-flags)
+ flags |= SOCAM_DATAWIDTH_16;
+ else
+ flags |= SOCAM_DATAWIDTH_8;
return soc_camera_apply_sensor_flags(icl, flags);
}
@@ -648,7 +639,7 @@ static int tw9910_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
* reset hardware
*/
tw9910_reset(client);
- ret = tw9910_write_array(client, tw9910_default_regs);
+ ret = tw9910_set_outputcontrol(client);
if (ret 0)
goto tw9910_set_fmt_error;
@@ -656,7 +647,7 @@ static int tw9910_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
* set bus width
*/
val = 0x00;
- if (SOCAM_DATAWIDTH_16 == priv-info-buswidth)
+ if (TW9910_FLG_DATAWIDTH_16 priv-info-flags)
val = LEN;
ret = tw9910_mask_set(client, OPFORM, LEN, val);
@@ -888,15 +879,6 @@ static int tw9910_video_probe(struct soc_camera_device
*icd,
to_soc_camera_host(icd-dev.parent)-nr != icd-iface)
return -ENODEV;
- /*
- * tw9910 only use 8 or 16 bit bus width
- */
- if (SOCAM_DATAWIDTH_16 != priv-info-buswidth
- SOCAM_DATAWIDTH_8 != priv-info-buswidth) {
- dev_err(client-dev, bus width error\n);
- return -ENODEV;
- }
-
icd-formats = tw9910_color_fmt;
icd-num_formats = ARRAY_SIZE(tw9910_color_fmt);
diff --git a/include/media/tw9910.h b/include/media/tw9910.h
index 6ddb654..494ac53 100644
--- a/include/media/tw9910.h
+++
Re: DVB support for MSI DigiVox A/D II and KWorld 320U
Hello
Check the dvb_gpio setting in the board profile. On some of those
boards you need to take put one of the GPO pins high to take the demod
out of reset. The KWorld 315u and 330u are both like that.
Absolutely true. Using the same pin setting as KWorld 330U made the I2C
communication work correctly and the device is found.
Now the trouble is that scanning channels doesn't work, blue LED doesn't light
up and the device is not heated up.
I'm quite newbie in this field, is there a good way to know what registers to
set exactly?
I see that the working mcentral code had the following setting:
#define EETI_DEFAULT_GPIO { \
.ts1_on = _BIT_VAL(EM28XX_GPIO0, 0, 0),\
.a_on = _BIT_VAL(EM28XX_GPIO1, 0, 0),\
.xc3028_sec = _BIT_VAL(EM28XX_GPIO2, 1, 0),\
/* reserved */ \
.t1_reset = _BIT_VAL(EM28XX_GPIO4, 0, 1),\
/* reserved */ \
.t1_on = _BIT_VAL(EM28XX_GPIO6, 0, 0),\
.t2_on = _BIT_VAL(EM28XX_GPIO7, 1, 0),\
\
.l1_on = _BIT_VAL(EM28XX_GOP2, 1, 0),\
.d1_reset = _BIT_VAL(EM28XX_GOP3, 0, 1),\
}
But the v4l-dvb uses:
static struct em28xx_reg_seq kworld_330u_digital[] = {
{EM28XX_R08_GPIO, 0x6e, ~EM_GPIO_4, 10},
{EM2880_R04_GPO,0x08, 0xff, 10},
{ -1, -1, -1, -1},
};
Lauri
--
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 5/5] soc-camera: tw9910: Add revision control on tw9910_set_hsync
On Tue, 13 Oct 2009, Kuninori Morimoto wrote:
10 - 3 bit hsync control are same as Rev0/Rev1.
But only rev1 can control more 3 bit for hsync.
This patch modify this problem
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 59158bb..a688c11 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -349,6 +349,7 @@ static int tw9910_set_scale(struct i2c_client *client,
static int tw9910_set_hsync(struct i2c_client *client,
const u16 start, const u16 end)
{
+ struct tw9910_priv *priv = to_tw9910(client);
int ret;
/* bit 10 - 3 */
@@ -363,15 +364,22 @@ static int tw9910_set_hsync(struct i2c_client *client,
if (ret 0)
return ret;
- /* bit 2 - 0 */
- ret = i2c_smbus_read_byte_data(client, HSLOWCTL);
- if (ret 0)
- return ret;
+ /* FIXME
Why FIXME? If this is a real distinction between hardware revisions,
there's nothing to fix about that?
+ *
+ * So far only revisions 0 and 1 have been seen
+ */
+ if (1 == priv-rev) {
- ret = i2c_smbus_write_byte_data(client, HSLOWCTL,
- (ret0x88)|
- (start 0x0007) 4 |
- (end0x0007));
+ /* bit 2 - 0 */
+ ret = i2c_smbus_read_byte_data(client, HSLOWCTL);
+ if (ret 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, HSLOWCTL,
+ (ret0x88)|
+ (start 0x0007) 4 |
+ (end0x0007));
+ }
This looks like a perfect case for your mask_set():
ret = tw9910_mask_set(client, HSLOWCTL, 0x77,
(start 7) 4 | (end 7));
While at it, could you also fix that typo copied from the datasheet:
s/HSGEGIN/HSBEGIN/g?
return ret;
}
--
1.6.0.4
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Support on discontinuous planer buffer and stride
2009/10/10 Hans Verkuil hverk...@xs4all.nl:
On Saturday 10 October 2009 03:34:27 Jun Nie wrote:
2009/10/9 Hans Verkuil hverk...@xs4all.nl:
On Friday 09 October 2009 07:07:32 Jun Nie wrote:
2009/9/23 Jun Nie niej0...@gmail.com:
Hi,
I re-send this email for the last one is rejected by system. I am
sorry if you guys received both.
I am optimizing video playback with overlay with V4L2 driver. The
video content is a sub-region of codec output. Thus a memory copy is
necessary.
Is there plan to support for stride and discrete YUV planer in
kernel? Such as below changes can help much for my usage case.
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -529,7 +529,20 @@ struct v4l2_buffer {
__u32 offset;
unsigned long userptr;
} m;
+ /* UV/GB location is valid only in planer case */
+ union {
+ __u32 offset_ug;
+ unsigned long userptr_ug;
+ } m_ug;
+ union {
+ __u32 offset_vb;
+ unsigned long userptr_vb;
+ } m_vb;
__u32 length;
+ /* stride of YUV or RGB */
+ __u32 stride_yr;
+ __u32 stride_ug;
+ __u32 stride_vb;
__u32 input;
__u32 reserved;
};
If such change is acceptable for everyone, I may help on the
implementation.
Any comments are welcome.
Jun
Hi, Hans/Guennadi
What do you think of supporting this feature?
Jun
Well, it is definitely not possible to do it in this manner since changing
the size of struct v4l2_buffer will break the API. Furthermore, something
like
this will only work if the DMA engine can handle strides. Is that the case
for your hardware? I don't think you mentioned what the hardware is you
use.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Hi, Hans
Thanks for your comments. My hardware, PXA168/910 support Y/U/V,
three DMA addresses. Y and UV stride can be different with width, such
as Y_stride == 336, UV_stride == 168 while width == 320. LCD
controller will handle dropping 20 bytes for every line before new
line scanning.
Application should query driver for the sub-region capability
before use it. Driver that do not support this feature will return
false by default, application should copy the sub-region to v4l2
buffer in this case.
The v4l2_buffer size change does impact IOCTL entry index value,
application re-compilation is needed, but no code change needed. It is
a balance between exploration of hardware capability and existing
application binary compatibility. I am new to this community. Was
there similar problems in community?
It is not allowed to break application binary compatibility. That's just a
fact of life.
If you use the PXA hardware, does that mean that you use the pxa_camera
driver? (Just making sure we talk about the same thing :-) )
Anyway, what you are really trying to do is to crop before sending over the
picture.
The normal sequence for output devices is that with S_FMT you specify the
size of the input frame and with S_CROP you can specify the target 'window'
for that frame. Usually the target window is the same size as the input frame,
but it can be a different size as well and in that case the hardware will
have to scale the input frame to the size of the target window.
Note that for output windows the S_CROP command is sort of the inverse
operation of what S_CROP does for capturing. If we would redo the API I'm sure
we would implement this differently since it is pretty confusing. But so be
it.
What you want to do here is to crop the input frame. So we need either some
new S_PRECROP ioctl or perhaps some new v4l2_buf_type value and use that in
combination with S_CROP. It should definitely be the responsibility of the
driver to figure out the strides as that very much depends on the chosen pixel
format. It's bad API design to put such hardware assumptions in the API.
If we want to keep the symmetry between capture and output streams, then
S_POSTCROP might be the better name. I.e. for capture streams S_CROP
determines the source rectangle, S_FMT the output resolution of that rectangle
and S_POSTCROP the area within that output rectangle that we actually want to
use. All this reverses for an output stream, so S_POSTCROP would refer to the
part of the output frame that we want to use. Just brainstorming, mind you
:-).
BTW, I noticed you didn't reply to the linux-media list. I recommend that you
add that the next time you reply since this is of interest for everyone I
think.
Regards,
Hans
--
Hans Verkuil -
Re: [LTP] [PATCH] pac_common: redesign function for finding Start Of Frame
On Sun, 2009-10-04 at 22:56 +0200, Németh Márton wrote:
Hi,
I wrote a simple test for pac_find_sof(). I implemented a user-space test
which takes the implementation from the source file and calls it directly.
You can find the source code of the test attached.
Németh,
Can you please add this test to LTP then ?
Regards--
Subrata
The test results for the pac_find_sof() implementation in the Linux kernel
2.6.32-rc1 is the following:
Test case 1: exact match
PDEBUG: SOF found, bytes to analyze: 5. Frame starts at byte #5
PASSED
Test case 2: offset 1
PDEBUG: SOF found, bytes to analyze: 6. Frame starts at byte #6
PASSED
Test case 3: offset 1, first byte may be misleading
FAILED
Test case 4: offset 2, first two bytes may be misleading
PDEBUG: SOF found, bytes to analyze: 7. Frame starts at byte #7
PASSED
Test case 5: offset 3, first three bytes may be misleading
FAILED
Test case 6: offset 4, first four bytes may be misleading
FAILED
Test case 7: pattern starts at end of packet and continues in the next one
PDEBUG: SOF found, bytes to analyze: 1. Frame starts at byte #1
PASSED
Test case 8: splited pattern, with misleading first byte
FAILED
Test case 9: splited pattern, with misleading first three bytes
FAILED
Test case 10: no match, extra byte at offset 1
PASSED
Test case 11: no match, extra byte at offset 2
PASSED
Test case 12: no match, extra byte at offset 3
PASSED
Test case 13: no match, extra byte at offset 4
PASSED
I also executed the test with the patched pac_find_sof() implementation
and that one passes all these test cases.
Regards,
Márton Németh
Németh Márton wrote:
From: Márton Németh nm...@freemail.hu
The original implementation of pac_find_sof() does not always find
the Start Of Frame (SOF) marker. Replace it with a state machine
based design.
The change was tested with Labtec Webcam 2200.
Signed-off-by: Márton Németh nm...@freemail.hu
---
--- linux-2.6.32-rc1.orig/drivers/media/video/gspca/pac_common.h
2009-09-10 00:13:59.0 +0200
+++ linux-2.6.32-rc1/drivers/media/video/gspca/pac_common.h 2009-10-04
21:49:19.0 +0200
@@ -33,6 +33,45 @@
static const unsigned char pac_sof_marker[5] =
{ 0xff, 0xff, 0x00, 0xff, 0x96 };
+/*
+ The following state machine finds the SOF marker sequence
+ 0xff, 0xff, 0x00, 0xff, 0x96 in a byte stream.
+
+ +--+
+ | 0: START |---\
+ +--+-\ |
+| \---/otherwise|
+v 0xff|
+ +--+ otherwise |
+ | 1|---*
+ | |^
+ +--+|
+| |
+v 0xff|
+ +--+-\0xff |
+ /-| |--/ |
+ | | 2|---*
+ | | | otherwise ^
+ | +--+|
+ || |
+ |v 0x00|
+ | +--+|
+ | | 3||
+ | | |---*
+ | +--+ otherwise ^
+ || |
+ 0xff |v 0xff|
+ | +--+|
+ \--| 4||
+ | |/
+ +--+ otherwise
+|
+v 0x96
+ +--+
+ | FOUND |
+ +--+
+*/
+
static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
unsigned char *m, int len)
{
@@ -41,17 +80,54 @@ static unsigned char *pac_find_sof(struc
/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i len; i++) {
- if (m[i] == pac_sof_marker[sd-sof_read]) {
- sd-sof_read++;
- if (sd-sof_read == sizeof(pac_sof_marker)) {
+ switch (sd-sof_read) {
+ case 0:
+ if (m[i] == 0xff)
+ sd-sof_read = 1;
+ break;
+ case 1:
+ if (m[i] == 0xff)
+ sd-sof_read = 2;
+ else
+ sd-sof_read = 0;
+ break;
+ case 2:
+ switch (m[i]) {
+ case 0x00:
+ sd-sof_read = 3;
+ break;
+ case 0xff:
+ /* stay in this state */
+ break;
+ default:
+ sd-sof_read = 0;
+ }
+ break;
+ case 3:
+ if (m[i] == 0xff)
+
Re: Lifeview lv8h pci-e low profile
Hello: I'm using an Arch Linux, kernel 2.6.30-ARCH. I've a Lifeview LV8H pci-e dvb-t (low profile card) , that says: # lspci -vv 03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Subsystem: Conexant Systems, Inc. Device ec80 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at fe80 (64-bit, non-prefetchable) [size=2M] Capabilities: access denied Kernel driver in use: cx23885 Kernel modules: cx23885 cx23885 driver version 0.0.2 loaded The cx23885 module, is supported by the kernel but does not seem to work for this device. If i load the module without parameters, I get: # dmesg | grep cx23885 ACPI: PCI Interrupt Link [LNEA] enabled at IRQ 17 cx23885 :03:00.0: PCI INT A - Link[LNEA] - GSI 17 (level, low) - IRQ 17 cx23885[0]: Your board isn't known (yet) to the driver. cx23885[0]: Try to pick one of the existing card configs via cx23885[0]: card=n insmod option. Updating to the latest cx23885[0]: version might help as well. cx23885[0]: Here is a list of valid choices for the card=n insmod option: cx23885[0]: card=0 - UNKNOWN/GENERIC cx23885[0]: card=1 - Hauppauge WinTV-HVR1800lp cx23885[0]: card=2 - Hauppauge WinTV-HVR1800 cx23885[0]: card=3 - Hauppauge WinTV-HVR1250 cx23885[0]: card=4 - DViCO FusionHDTV5 Express cx23885[0]: card=5 - Hauppauge WinTV-HVR1500Q cx23885[0]: card=6 - Hauppauge WinTV-HVR1500 cx23885[0]: card=7 - Hauppauge WinTV-HVR1200 cx23885[0]: card=8 - Hauppauge WinTV-HVR1700 cx23885[0]: card=9 - Hauppauge WinTV-HVR1400 cx23885[0]: card=10 - DViCO FusionHDTV7 Dual Express cx23885[0]: card=11 - DViCO FusionHDTV DVB-T Dual Express cx23885[0]: card=12 - Leadtek Winfast PxDVR3200 H cx23885[0]: card=13 - Compro VideoMate E650F cx23885[0]: card=14 - TurboSight TBS 6920 cx23885[0]: card=15 - TeVii S470 cx23885[0]: card=16 - DVBWorld DVB-S2 2005 cx23885[0]: card=17 - NetUP Dual DVB-S2 CI CORE cx23885[0]: subsystem: 14f1:ec80, board: UNKNOWN/GENERIC [card=0,autodetected] cx23885_dev_checkrevision() Hardware revision = 0xb0 cx23885[0]/0: found at :03:00.0, rev: 2, irq: 17, latency: 0, mmio: 0xfe80 cx23885 :03:00.0: setting latency timer to 64 IRQ 17/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs Loading card=4, all the devices /dev/dvb/ are created (frontend,..). I get: # dmesg | grep cx23885 cx23885 driver version 0.0.2 loaded cx23885 :03:00.0: PCI INT A - Link[LNEA] - GSI 17 (level, low) - IRQ 17 CORE cx23885[0]: subsystem: 14f1:ec80, board: DViCO FusionHDTV5 Express [card=4,insmod option] cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card DVB: registering new adapter (cx23885[0]) cx23885_dev_checkrevision() Hardware revision = 0xb0 cx23885[0]/0: found at :03:00.0, rev: 2, irq: 17, latency: 0, mmio: 0xfe80 cx23885 :03:00.0: setting latency timer to 64 IRQ 17/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs Going to Kaffeine or making an scan from the console, it says that is in mode ATSC and that is not compatable. I'm living in Spain, and I have used this card as a PAL system. initial transponder 54600 0 3 9 1 0 0 0 initial transponder 57800 0 2 9 3 0 0 0 initial transponder 625833000 0 2 9 3 0 0 0 initial transponder 705833000 0 3 9 1 0 0 0 initial transponder 649833000 0 3 9 1 0 0 0 initial transponder 673833000 0 3 9 1 0 0 0 WARNING: frontend type (ATSC) is not compatible with requested tuning type (OFDM) WARNING: frontend type (ATSC) is not compatible with requested tuning type (OFDM) WARNING: frontend type (ATSC) is not compatible with requested tuning type (OFDM) WARNING: frontend type (ATSC) is not compatible with requested tuning type (OFDM) WARNING: frontend type (ATSC) is not compatible with requested tuning type (OFDM) WARNING: frontend type (ATSC) is not compatible with requested tuning type (OFDM) ERROR: initial tuning failed I've tried all options from the driver from the list. Only card=4, seems to be valid. Anyone can help me? Thanks and sorry for my english, Oinatz Aspiazu -- 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: uvcvideo causes ehci_hcd to halt
On Tue, 13 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote: Hi, Some recent netbooks (Some MSI winds and LG X110's) equipped with an integrated webcam have non-working USB ports unless the uvcvideo module is blacklisted. I've found some bug reports in launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/435352 I have an LG X110 on which I can reproduce the problem with 2.6.30.8. Here's the interesting part in dmesg: Oct 13 08:46:32 x110 kernel: [ 261.048312] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203) Oct 13 08:46:32 x110 kernel: [ 261.053592] input: BisonCam, NB Pro as /devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10 Oct 13 08:46:32 x110 kernel: [ 261.053891] usbcore: registered new interface driver uvcvideo Oct 13 08:46:32 x110 kernel: [ 261.054755] USB Video Class driver (v0.1.0) Oct 13 08:46:32 x110 kernel: [ 261.091014] ehci_hcd :00:1d.7: force halt; handhake f807c024 4000 - -110 Can you add a dump_stack() call just after the ehci_err() line in drivers/usb/host/ehci-hcd.c:handshake_on_error_set_halt()? It should provide some clues. At the same time (i.e., during the same test) you should collect a usbmon trace. Alan Stern -- 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/6] Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/davinci/vpfe_capture.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/davinci/vpfe_capture.c b/drivers/media/video/davinci/vpfe_capture.c index ff43446..dc32de0 100644 --- a/drivers/media/video/davinci/vpfe_capture.c +++ b/drivers/media/video/davinci/vpfe_capture.c @@ -1547,7 +1547,7 @@ static int vpfe_reqbufs(struct file *file, void *priv, vpfe_dev-memory = req_buf-memory; videobuf_queue_dma_contig_init(vpfe_dev-buffer_queue, vpfe_videobuf_qops, - NULL, + vpfe_dev-pdev, vpfe_dev-irqlock, req_buf-type, vpfe_dev-fmt.fmt.pix.field, -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] Davinci VPFE Capture: Take i2c adapter id through platform data
From: Vaibhav Hiremath hvaib...@ti.com
The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c |3 +--
include/media/davinci/vpfe_capture.h |2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index dc32de0..c3c37e7 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -2228,8 +2228,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, vpfe_dev);
/* set driver private data */
video_set_drvdata(vpfe_dev-video_dev, vpfe_dev);
- i2c_adap = i2c_get_adapter(1);
- vpfe_cfg = pdev-dev.platform_data;
+ i2c_adap = i2c_get_adapter(vpfe_cfg-i2c_adapter_id);
num_subdevs = vpfe_cfg-num_subdevs;
vpfe_dev-sd = kmalloc(sizeof(struct v4l2_subdev *) * num_subdevs,
GFP_KERNEL);
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index e8272d1..f610104 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -94,6 +94,8 @@ struct vpfe_subdev_info {
struct vpfe_config {
/* Number of sub devices connected to vpfe */
int num_subdevs;
+ /*I2c Bus adapter no*/
+ int i2c_adapter_id;
/* information about each subdev */
struct vpfe_subdev_info *sub_devs;
/* evm card info */
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] Davinci VPFE Capture: Take i2c adapter id through platform data
From: Vaibhav Hiremath hvaib...@ti.com
The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.
So modified respective davinci board files.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-davinci/board-dm355-evm.c |1 +
arch/arm/mach-davinci/board-dm644x-evm.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index f683559..4a9252a 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -372,6 +372,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM355 EVM,
.ccdc = DM355 CCDC,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index cfd9afa..fed64e2 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -257,6 +257,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev-ccdc_irq1
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/davinci/vpfe_capture.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/davinci/vpfe_capture.c b/drivers/media/video/davinci/vpfe_capture.c index c3c37e7..abe21e4 100644 --- a/drivers/media/video/davinci/vpfe_capture.c +++ b/drivers/media/video/davinci/vpfe_capture.c @@ -752,7 +752,7 @@ static void vpfe_detach_irq(struct vpfe_device *vpfe_dev) frame_format = ccdc_dev-hw_ops.get_frame_format(); if (frame_format == CCDC_FRMFMT_PROGRESSIVE) - free_irq(IRQ_VDINT1, vpfe_dev); + free_irq(vpfe_dev-ccdc_irq1, vpfe_dev); } static int vpfe_attach_irq(struct vpfe_device *vpfe_dev) -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] Davinci VPFE Capture: Add support for Control ioctls
From: Vaibhav Hiremath hvaib...@ti.com
Added support for Control IOCTL,
- s_ctrl
- g_ctrl
- queryctrl
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 43
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index abe21e4..f77d99b 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1368,6 +1368,46 @@ static int vpfe_g_std(struct file *file, void *priv,
v4l2_std_id *std_id)
return 0;
}
+static int vpfe_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+ int ret = 0;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ ret = v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-grp_id,
+core, queryctrl, qctrl);
+
+ if (ret)
+ qctrl-flags |= V4L2_CTRL_FLAG_DISABLED;
+
+ return 0;
+}
+
+static int vpfe_g_ctrl(struct file *file, void *priv, struct v4l2_control
*ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-grp_id,
+core, g_ctrl, ctrl);
+}
+
+static int vpfe_s_ctrl(struct file *file, void *priv, struct v4l2_control
*ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-grp_id,
+core, s_ctrl, ctrl);
+}
+
/*
* Videobuf operations
*/
@@ -1939,6 +1979,9 @@ static const struct v4l2_ioctl_ops vpfe_ioctl_ops = {
.vidioc_querystd = vpfe_querystd,
.vidioc_s_std= vpfe_s_std,
.vidioc_g_std= vpfe_g_std,
+ .vidioc_queryctrl= vpfe_queryctrl,
+ .vidioc_g_ctrl = vpfe_g_ctrl,
+ .vidioc_s_ctrl = vpfe_s_ctrl,
.vidioc_reqbufs = vpfe_reqbufs,
.vidioc_querybuf = vpfe_querybuf,
.vidioc_qbuf = vpfe_qbuf,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] TVP514x:Switch to automode for s_input/querystd
From: Vaibhav Hiremath hvaib...@ti.com Driver should switch to AutoSwitch mode on S_INPUT and QUERYSTD ioctls. It has been observed that, if user configure the standard explicitely then driver preserves the old settings. Reviewed by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Brijesh Jadav brijes...@ti.com --- drivers/media/video/tvp514x.c | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c index 2443726..0b0412d 100644 --- a/drivers/media/video/tvp514x.c +++ b/drivers/media/video/tvp514x.c @@ -523,10 +523,18 @@ static int tvp514x_querystd(struct v4l2_subdev *sd, v4l2_std_id *std_id) enum tvp514x_std current_std; enum tvp514x_input input_sel; u8 sync_lock_status, lock_mask; + int err; if (std_id == NULL) return -EINVAL; + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); + if (err 0) + return err; + + msleep(LOCK_RETRY_DELAY); + /* get the current standard */ current_std = tvp514x_get_current_std(sd); if (current_std == STD_INVALID) @@ -643,6 +651,15 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd, /* Index out of bound */ return -EINVAL; + /* Since this api is goint to detect the input, it is required + to set the standard in the auto switch mode */ + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); + if (err 0) + return err; + + msleep(LOCK_RETRY_DELAY); + input_sel = input; output_sel = output; -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] Davinci VPFE Capture: Take i2c adapter id through platform data
Hello.
hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
[...]
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index e8272d1..f610104 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -94,6 +94,8 @@ struct vpfe_subdev_info {
struct vpfe_config {
/* Number of sub devices connected to vpfe */
int num_subdevs;
+ /*I2c Bus adapter no*/
Put spaces after /* and before */, please. Also, it's I2C, not I2c...
WBR, Sergei
--
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 5/6] Davinci VPFE Capture: Add support for Control ioctls
-Original Message-
From: Hiremath, Vaibhav
Sent: Tuesday, October 13, 2009 8:40 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav
Subject: [PATCH 5/6] Davinci VPFE Capture: Add support for Control
ioctls
From: Vaibhav Hiremath hvaib...@ti.com
Added support for Control IOCTL,
- s_ctrl
- g_ctrl
- queryctrl
[Hiremath, Vaibhav] I am in the process of cleaning up of support for AM3517
Capture driver, which is almost same as DM6446 CCDC. Then I would want to
finish up with OMAP3 Display driver part before moving to Media Controller
support for MEM-to-MEM (like, Resizer).
Just FYI, I will be going for vacation for 1 1/2 week starting from coming
Friday. But I will make sure that I will submit patches for Display (OMAP3
AM3517) and AM3517 Capture driver before that.
Thanks,
Vaibhav
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 43
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index abe21e4..f77d99b 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1368,6 +1368,46 @@ static int vpfe_g_std(struct file *file, void
*priv, v4l2_std_id *std_id)
return 0;
}
+static int vpfe_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+ int ret = 0;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ ret = v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+ core, queryctrl, qctrl);
+
+ if (ret)
+ qctrl-flags |= V4L2_CTRL_FLAG_DISABLED;
+
+ return 0;
+}
+
+static int vpfe_g_ctrl(struct file *file, void *priv, struct
v4l2_control *ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+ core, g_ctrl, ctrl);
+}
+
+static int vpfe_s_ctrl(struct file *file, void *priv, struct
v4l2_control *ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-
grp_id,
+ core, s_ctrl, ctrl);
+}
+
/*
* Videobuf operations
*/
@@ -1939,6 +1979,9 @@ static const struct v4l2_ioctl_ops
vpfe_ioctl_ops = {
.vidioc_querystd = vpfe_querystd,
.vidioc_s_std= vpfe_s_std,
.vidioc_g_std= vpfe_g_std,
+ .vidioc_queryctrl= vpfe_queryctrl,
+ .vidioc_g_ctrl = vpfe_g_ctrl,
+ .vidioc_s_ctrl = vpfe_s_ctrl,
.vidioc_reqbufs = vpfe_reqbufs,
.vidioc_querybuf = vpfe_querybuf,
.vidioc_qbuf = vpfe_qbuf,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ALSA support in cx18
Hello Andy, Just a brief note to let you know that ALSA support in cx18 is near the top of my priorities now. I'm going to start with your work at http://linuxtv.org/hg/~awalls/mc-lab -- I'll send patches as and when I get things working, Simon Farnsworth -- 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: Bug in HVR1300. Found part of a patch, if reverted bug seems to be gone [spam-bayes][heur][spf]
On Mon, Oct 12, 2009 at 4:48 PM, Frank Sagurna fr...@sagurna.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, there seems to be a bug in cx88 (HVR1300) that is responsible for not switching channels, and not being able to scan. Complete description can be found on launchpad: https://bugs.launchpad.net/mythtv/+bug/439163 (starting from comment #16) Anyway, i digged it down to this patch: http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg02195.html When reverting the following part of the patch it starts working again: snip-- Thanks Frank. I'll pick up this patch and start the merge process. Regards, - Steve -- 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
More about Winfast TV USB Deluxe
Hi!
Thanks to Devin's moral support I now have sound in television. ;-)
Thanks!!
I pooked around some more managed to get radio to function with these settings:
[EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE] = {
.name = Leadtek Winfast USB II Deluxe,
.valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
.tda9887_conf = TDA9887_PRESENT |
TDA9887_PORT1_ACTIVE,
.decoder = EM28XX_SAA711X,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE4,
.amux = EM28XX_AMUX_AUX,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE5,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
} },
.radio= {
.type = EM28XX_RADIO,
.amux = EM28XX_AMUX_AUX,
}
},
I tested with different settings on tda9887 and modprobe tda9887
port1=1 seemed to work be best.
One odd thing when the modules is load is this:
[15680.459343] tuner 4-: chip found @ 0x0 (em28xx #0)
[15680.473017] tuner 4-0043: chip found @ 0x86 (em28xx #0)
[15680.473089] tda9887 4-0043: creating new instance
[15680.473091] tda9887 4-0043: tda988[5/6/7] found
[15680.485719] tuner 4-0061: chip found @ 0xc2 (em28xx #0)
[15680.486169] tuner-simple 4-: unable to probe Alps TSBE1,
proceeding anyway.-- What is that?
[15680.486171] tuner-simple 4-: creating new instance
--
[15680.486174] tuner-simple 4-: type set to 10 (Alps TSBE1)
--
[15680.496562] tuner-simple 4-0061: creating new instance
[15680.496566] tuner-simple 4-0061: type set to 38 (Philips PAL/SECAM
multi (FM1216ME MK3))
Another question, my box has a tda9874ah chip and if understand the
data sheet it gives support for stereo (even Nicam if that is still
used anymore.).
So I tried to configure my box the same way as
[EM2820_BOARD_COMPRO_VIDEOMATE_FORYOU] by adding these lines:
.tvaudio_addr = 0xb0, address of
tda9874 according to ic2-addr.h
.adecoder = EM28XX_TVAUDIO,
But it didnt work, got the following message when I plugged it in:
[15677.928972] em28xx #0: Please send a report of having this working
[15677.928974] em28xx #0: not to V4L mailing list (and/or to other addresses)
[15677.928975]
[15678.288360] saa7115 4-0021: saa7114 found (1f7114d0e00) @ 0x42
(em28xx #0)
[15680.457094] tvaudio: TV audio decoder + audio/video mux driver
[15680.457097] tvaudio: known chips: tda9840, tda9873h, tda9874h/a/ah,
tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425,
pic16c54 (PV951), ta8874z
[15680.457105] tvaudio 4-00b0: chip found @ 0x160
[15680.457107] tvaudio 4-00b0: no matching chip description found
[15680.457111] tvaudio: probe of 4-00b0 failed with error -5
[15680.459343] tuner 4-: chip found @ 0x0 (em28xx #0)
[15680.473017] tuner 4-0043: chip found @ 0x86 (em28xx #0)
[15680.473089] tda9887 4-0043: creating new instance
It might be so that my box is not wired to fully utilize the chip or I
did something wrong.
/Magnus
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/6] Davinci VPFE Capture: Take i2c adapter id through platform data
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
Sent: Tuesday, October 13, 2009 9:00 PM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com
Subject: Re: [PATCH 2/6] Davinci VPFE Capture: Take i2c adapter id
through platform data
Hello.
hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
The I2C adapter ID is actually depends on Board and may vary,
Davinci
uses id=1, but in case of AM3517 id=3.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
[...]
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index e8272d1..f610104 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -94,6 +94,8 @@ struct vpfe_subdev_info {
struct vpfe_config {
/* Number of sub devices connected to vpfe */
int num_subdevs;
+ /*I2c Bus adapter no*/
Put spaces after /* and before */, please. Also, it's I2C, not
I2c...
[Hiremath, Vaibhav] Thanks Sergei for catching this typo mistake.
I will update and post it again.
Thanks,
Vaibhav
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Oct 13 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13095:5578cc977a13 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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 mode switching
On Tue, Oct 13, 2009 at 2:27 PM, xwang1...@email.it wrote: Hi Devin, let me know if you need a tester for the EMPIRE_DUAL_TV. In case I will install the latest v4l driver on my old notebook which has a clean kubuntu 9.04 distro. On the newer notebook I'm using my new Dikom DK-300 device which does not work with the latest v4l drivers and which I can use using a patched version of the main v4l driver (thanks to Dainius Ridzevicius). If you have some spare time for this device too... Xwang Hi xwang, Well, I'm hoping to setup a tree sometime this week (and test it with my devices). Assuming it works, I will put out a call for testers such as yourself. Regarding your DK-300, if you send the diff between the main v4l driver and the patched version, we can take a look at what would be required to merge it upstream. 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 mode switching
Hi Devin, let me know if you need a tester for the EMPIRE_DUAL_TV. In case I will install the latest v4l driver on my old notebook which has a clean kubuntu 9.04 distro. On the newer notebook I'm using my new Dikom DK-300 device which does not work with the latest v4l drivers and which I can use using a patched version of the main v4l driver (thanks to Dainius Ridzevicius). If you have some spare time for this device too... Xwang Devin Heitmueller ha scritto: On Mon, Oct 12, 2009 at 6:31 PM, Antti Palosaari cr...@iki.fi wrote: I ran this same trap few weeks ago when adding Reddo DVB-C USB Box support to em28xx :) Anyhow, since it is dvb only device I decided to switch from .dvb_gpio to .tuner_gpio to fix the problem. I haven't pull requested it yet. http://linuxtv.org/hg/~anttip/reddo-dvb-c/rev/38f946af568f Antti -- http://palosaari.fi/ You were able to get by with using tuner_gpio instead of dvb_gpio because the Reddo isn't a hybrid device. I'm going to propose removing the calls to em28xx_set_mode() in start_streaming() and stop_streaming(). Given the supported boards that are there, I can regression test: EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950 EM2880_BOARD_PINNACLE_PCTV_HD_PRO EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900 EM2880_BOARD_TERRATEC_HYBRID_XS and I cannot regression test: EM2880_BOARD_KWORLD_DVB_310U (I have a strong suspicion this board is currently broken anyway) EM2882_BOARD_TERRATEC_HYBRID_XS (I worked with the authors of this one and can probably get them to test) EM2882_BOARD_EVGA_INDTUBE (I worked with the authors of this one and can probably get them to test) EM2880_BOARD_EMPIRE_DUAL_TV (I worked with the authors of this one and can probably get them to test) EM2881_BOARD_PINNACLE_HYBRID_PRO (this is the board I noticed the problem under) EM2883_BOARD_KWORLD_HYBRID_330U EM2870_BOARD_REDDO_DVB_C_USB_BOX Devin -- 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: Dazzle TV Hybrid USB and em28xx
On Mon, Oct 12, 2009 at 7:22 PM, Giuseppe Borzi gbo...@gmail.com
wrote:
Yeah, that happens with Ubuntu Karmic. The v4l-dvb firedtv driver
depends on headers that are private to ieee1394 and not in their
kernel headers package.
To workaround the issue, open v4l/.config and set the firedtv
driver from =m to =n
Devin
Thanks Devin,
following your instruction for firedtv I've compiled
v4l-dvb-5578cc977a13 but the results aren't so good. After doing an
make rminstall , compiling and make install I plugged the USB
stick, the various devices were created (including /dev/dvb) and
here is the dmesg output (now it's identified as card=1)
then I started checking if it works. The command vlc channels.conf
works, i.e. it plays the first channel in the list, but is unable to
switch channel. me-tv doesn't start, but I think this is related to
the recent gnome upgrade. w_scan doesn't find any channel.
Open v4l/em28xx-cards.c and comment out line 181 so it looks like:
//{EM2880_R04_GPO,0x04, 0xff, 100},/*
zl10353 reset */
This is an issue I have been actively debugging for two other users.
Analog TV only shows video, no audio. Tried this both with sox and
vlc. When you say that I have to choose the right TV standard (PAL
for my region) do you mean I have to select this in the TV app I'm
using (tvtime, vlc, xawtv) or as a module option? I've not seen any
em28xx option for TV standard, so I suppose it's in the app.
Correct - the em28xx module does not have module parameters for the
standard - you have to select it in the application.
Finally, I've noticed that the device is much less hot than it
happened with out of kernel modules and the card=11 workaround.
Is your latest post em28xx mode switching related to my device?
Yes, it is one device effected by that discussion.
Devin
Thanks Devin,
now DVB works as expected, i.e. I can change channel and w_scan
finds the channels available in my area. The stick is recognized as
card=1 instead of 53 as I expected, but still it works fine.
Still no sound for analog TV, but that's a minor problem.
Thanks again.
--
***
Giuseppe Borzi, Assistant Professor at the
University of Messina - Department of Civil Engineering
Address: Contrada di Dio, Messina, I-98166, Italy
Tel: +390903977323
Fax: +390903977480
email: gbo...@ieee.org
url: http://ww2.unime.it/dic/gborzi/index.php
***
signature.asc
Description: PGP signature
Re: Dazzle TV Hybrid USB and em28xx
On Tue, Oct 13, 2009 at 3:31 PM, Giuseppe Borzi gbo...@gmail.com wrote: Thanks Devin, now DVB works as expected, i.e. I can change channel and w_scan finds the channels available in my area. The stick is recognized as card=1 instead of 53 as I expected, but still it works fine. Still no sound for analog TV, but that's a minor problem. Thanks again. Can you please provide the output of dmesg after connecting the card? I am not sure why it would recognize as card=1. Do you have a modprobe option setup forcing it to card=1? 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
Andy Walls very busy for next few weeks; noted backlog
All, I'll be somewhat busy on non-linux things for the next 2-3 weeks as I support my wife in getting her corporation off the ground. (I'm already losing a quite a bit of sleep helping my wife with research and administrative help in the evenings.) I have the following linux v4l-dvb backlog noted for myself also listing the concerned or interested persons: cx23888-ir-part2: Fix whitespace problems: Mauro cx25840: 6.5 MHz sound carrieir detetction for DK systems: Aleksandr ivtv: AverTV MCE M116 remote, rework fixes: Aleksander and Jean ivtv: I2C clock frequency module option: Aleksandr cx25840: additional reset of the microcontroller for FM: Aleksandr ivtv: Add support for AverTV Ultra 116 (M103): Hiemanshu ivtv: Troubleshoot PVR-500 crash: Tony cx18: Assist as needed in development of cx18-alsa module/code: Simon Hopefully I haven't missed anything. I am especially grateful for the patches and comments. I will try to get them worked in, if I can, in the next few weeks. However, it may take until sometime in early November. One exception is that I plan on getting the cx23888-ir-part2 whitespace changes done this weekend. How hard could that be Regards, Andy -- 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: Hauppage WinTV-HVR-900H
Mauro Carvalho Chehab wrote: Em Sat, 10 Oct 2009 00:24:57 +0200 Markus Rechberger mrechber...@gmail.com escreveu: On Fri, Oct 9, 2009 at 11:58 PM, Simon Kenyon si...@koala.ie wrote: Markus Rechberger wrote: Available from 20th Oct on so in 11 days. There are not many competitive devices (none) available for linux which deliver such support. On the other side it's not kernel based either, it's entirely in userspace. It's also entirely supported by all participating companies. this is a mailing list for the open source dvb drivers you are talking about a closed source solution what does your solution have to do with linuxtv.org? I see linux-media, you can find the sources of a patched tvtime version on the website. It shows an alternative way how to integrate usb chipsolutions in linux. Aside of that the official DVB(3/5)/V4L(1/2) API has been reviewed through our work and bugreports have been submitted to various places (linux media, some linux distributions). It integrates flawlessly and helps to improve the overall media support with linux. The posting was pointing out to Ali's email that he was looking for a working analog TV solution for France. He has bought this Pinnacle device 3 years ago, the vendor does not care about support for it. We provide solutions which work within a few seconds, nevermind what distribution. Your business is so bad that you can't even pay to an adds on some magazine, for you to spam the open source mailing lists as a desperate trial to sell a single unit of your product? Please stop spamming. The answer was responsive to the question, a couple of links to software which might serve. I would think your going off about it was further off-topic, it certainly didn't help the O.P. any. When someone ends a question with please help I would assume that any answer would be better than we're working on it. Answering an on-topic question with a short list of links is hardly spamming or even advertising, it's called being polite and helpful. I would rather run commercial software on Linux that open source on Windows, thanks, if those are the choices. After several months of looking I have yet to find any video app that a typical office worker can use. Something no more complex than xawtv, which has been running fine on FC4 and FC6 for these folks. I would certainly consider a commercial solution rather than have them go back to the dark side of the force and Windows-7. -- Bill Davidsen david...@tmr.com Unintended results are the well-earned reward for incompetence. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] soc-camera: tw9910: Add output signal control
Dear Guennadi
Thank you for checking patch
Is this to tri-state the output? Ok, from the datasheet it tri-states all
outputs except clocks. My copy of the datasheet is funny at this point. It
(snip)
#define OEN_TRI_SEL_ALL_ON0
#define OEN_TRI_SEL_CLK_ON4
OK
Ok, it's 8:30 here, so, I might be still not quite awake... but I fail to
understand, why you bother calculating val above if you anyway just return
(snip)
dreaming. Oh, I see, you fix it in the next patch. Please, don't do that!
Don't introduce bugs to fix them in a later patch. Do it here.
oh my god.
It is very buggy patch.
It seems to had broken while patch clean up
While at it, could you also fix that typo copied from the datasheet:
s/HSGEGIN/HSBEGIN/g?
OK
struct tw9910_video_info {
-unsigned long buswidth;
+u32 flags;
enum tw9910_mpout_pin mpout;
struct soc_camera_link link;
u16 start_offset;
Hm, I am not convinced I liked all this. Do we understand what these
configuration options are doing? Datasheet is not very verbose on that
occasion. Is this configuration really platform-specific? What values have
you found meaningful in which cases?
I need research about this.
I might have made a big mistake.
I should re-check my patches and consider all of your comment.
Thank you
Best regards
--
Kuninori Morimoto
--
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] http://kernellabs.com/hg/~dheitmueller/950q-fixes
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/950q-fixes for the following au8522: add support for saturation and hue controls xc5000: return an error on tuning attempts if firmware not loaded Thanks, 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
em28xx DVB modeswitching change: call for testers
Hello all, I have setup a tree that removes the mode switching code when starting/stopping streaming. If you have one of the em28xx dvb devices mentioned in the previous thread and volunteered to test, please try out the following tree: http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch In particular, this should work for those of you who reported problems with zl10353 based devices like the Pinnacle 320e (or Dazzle) and were using that one line change I sent this week. It should also work with Antti's Reddo board without needing his patch to move the demod reset into the tuner_gpio. This also brings us one more step forward to setting up the locking properly so that applications cannot simultaneously open the analog and dvb side of the device. Thanks for your help, 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
Japan Linux Symposium
Next week, I'll be traveling to Japan to participate at the JLS and KS/2009. This, together with a very complicated merge window we had this time, a memory controller driver I'm finishing and a training course I've participated really consumed a lot of my time. This means that I'm also too busy and with a large backlog. I'll try to merge the pending patches and pull requests while there but please don't expect too much. It will be a long travel (about 60 hours in transit, going and going back to Japan). Anyway, I'm trying to setup an informal meeting with those of you that will be there. Please let me know in priv if some of you are interested on discussing relevant issues about the subsystem. In particular, it would be good to discuss about missing things to properly support Asian digital video standards. If there are enough audience, I'll probably be able to get a room there. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
