RE: [PATCH v4] ARM: DaVinci: DM646x Video: Platform and board specific setup
Russell,
Requesting your ack on this patch.
Regards,
Chaithrika
On Wed, Aug 05, 2009 at 20:17:42, Chaithrika U S wrote:
> Platform specific display device setup for DM646x EVM
>
> Add platform device and resource structures. Also define a platform
specific
> clock setup function that can be accessed by the driver to configure the
clock
> and CPLD.
>
> Signed-off-by: Manjunath Hadli
> Signed-off-by: Brijesh Jadav
> Signed-off-by: Chaithrika U S
> Signed-off-by: Kevin Hilman
> ---
> Applies to Davinci GIT tree. Minor updates like change in structure name-
> subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
>
> arch/arm/mach-davinci/board-dm646x-evm.c| 125
+++
> arch/arm/mach-davinci/dm646x.c | 62 +
> arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
> 3 files changed, 211 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
> index b1bf18c..8c88fd0 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -63,6 +63,19 @@
> #define DM646X_EVM_PHY_MASK (0x2)
> #define DM646X_EVM_MDIO_FREQUENCY(220) /* PHY bus frequency */
>
> +#define VIDCLKCTL_OFFSET (0x38)
> +#define VSCLKDIS_OFFSET (0x6c)
> +
> +#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
> +#define VCH2CLK_SYSCLK8 (BIT(9))
> +#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
> +#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
> +#define VCH3CLK_SYSCLK8 (BIT(13))
> +#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
> +
> +#define VIDCH2CLK(BIT(10))
> +#define VIDCH3CLK(BIT(11))
> +
> static struct davinci_uart_config uart_config __initdata = {
> .enabled_uarts = (1 << 0),
> };
> @@ -288,6 +301,40 @@ static struct snd_platform_data dm646x_evm_snd_data[]
= {
> },
> };
>
> +static struct i2c_client *cpld_client;
> +
> +static int cpld_video_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + cpld_client = client;
> + return 0;
> +}
> +
> +static int __devexit cpld_video_remove(struct i2c_client *client)
> +{
> + cpld_client = NULL;
> + return 0;
> +}
> +
> +static const struct i2c_device_id cpld_video_id[] = {
> + { "cpld_video", 0 },
> + { }
> +};
> +
> +static struct i2c_driver cpld_video_driver = {
> + .driver = {
> + .name = "cpld_video",
> + },
> + .probe = cpld_video_probe,
> + .remove = cpld_video_remove,
> + .id_table = cpld_video_id,
> +};
> +
> +static void evm_init_cpld(void)
> +{
> + i2c_add_driver(&cpld_video_driver);
> +}
> +
> static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("24c256", 0x50),
> @@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] =
{
> {
> I2C_BOARD_INFO("cpld_reg0", 0x3a),
> },
> + {
> + I2C_BOARD_INFO("cpld_video", 0x3B),
> + },
> };
>
> static struct davinci_i2c_platform_data i2c_pdata = {
> @@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata =
{
> .bus_delay = 0 /* usec */,
> };
>
> +static int set_vpif_clock(int mux_mode, int hd)
> +{
> + int val = 0;
> + int err = 0;
> + unsigned int value;
> + void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
> +
> + if (!cpld_client)
> + return -ENXIO;
> +
> + /* disable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value |= (VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + val = i2c_smbus_read_byte(cpld_client);
> + if (val < 0)
> + return val;
> +
> + if (mux_mode == 1)
> + val &= ~0x40;
> + else
> + val |= 0x40;
> +
> + err = i2c_smbus_write_byte(cpld_client, val);
> + if (err)
> + return err;
> +
> + value = __raw_readl(base + VIDCLKCTL_OFFSET);
> + value &= ~(VCH2CLK_MASK);
> + value &= ~(VCH3CLK_MASK);
> +
> + if (hd >= 1)
> + value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
> + else
> + value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
> +
> + __raw_writel(value, base + VIDCLKCTL_OFFSET);
> +
> + /* enable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value &= ~(VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + return 0;
> +}
> +
> +static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
> + {
> + .addr = 0x2A,
> + .name = "adv7343",
> + },
> + {
> + .addr = 0x2C,
> + .name = "ths7303",
> + },
> +};
> +
> +static const char *output[] = {
> + "
[PATCH v4] ARM: DaVinci: DM646x Video: Platform and board specific setup
Platform specific display device setup for DM646x EVM
Add platform device and resource structures. Also define a platform specific
clock setup function that can be accessed by the driver to configure the clock
and CPLD.
Signed-off-by: Manjunath Hadli
Signed-off-by: Brijesh Jadav
Signed-off-by: Chaithrika U S
Signed-off-by: Kevin Hilman
---
Applies to Davinci GIT tree. Minor updates like change in structure name-
subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
arch/arm/mach-davinci/board-dm646x-evm.c| 125 +++
arch/arm/mach-davinci/dm646x.c | 62 +
arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
3 files changed, 211 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index b1bf18c..8c88fd0 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -63,6 +63,19 @@
#define DM646X_EVM_PHY_MASK(0x2)
#define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+#define VIDCLKCTL_OFFSET (0x38)
+#define VSCLKDIS_OFFSET(0x6c)
+
+#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
+#define VCH2CLK_SYSCLK8(BIT(9))
+#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
+#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
+#define VCH3CLK_SYSCLK8(BIT(13))
+#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
+
+#define VIDCH2CLK (BIT(10))
+#define VIDCH3CLK (BIT(11))
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
};
@@ -288,6 +301,40 @@ static struct snd_platform_data dm646x_evm_snd_data[] = {
},
};
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id cpld_video_id[] = {
+ { "cpld_video", 0 },
+ { }
+};
+
+static struct i2c_driver cpld_video_driver = {
+ .driver = {
+ .name = "cpld_video",
+ },
+ .probe = cpld_video_probe,
+ .remove = cpld_video_remove,
+ .id_table = cpld_video_id,
+};
+
+static void evm_init_cpld(void)
+{
+ i2c_add_driver(&cpld_video_driver);
+}
+
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
@@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("cpld_reg0", 0x3a),
},
+ {
+ I2C_BOARD_INFO("cpld_video", 0x3B),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
@@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ if (!cpld_client)
+ return -ENXIO;
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val < 0)
+ return val;
+
+ if (mux_mode == 1)
+ val &= ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+
+ value = __raw_readl(base + VIDCLKCTL_OFFSET);
+ value &= ~(VCH2CLK_MASK);
+ value &= ~(VCH3CLK_MASK);
+
+ if (hd >= 1)
+ value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
+ else
+ value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
+
+ __raw_writel(value, base + VIDCLKCTL_OFFSET);
+
+ /* enable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value &= ~(VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ return 0;
+}
+
+static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
+ {
+ .addr = 0x2A,
+ .name = "adv7343",
+ },
+ {
+ .addr = 0x2C,
+ .name = "ths7303",
+ },
+};
+
+static const char *output[] = {
+ "Composite",
+ "Component",
+ "S-Video",
+};
+
+static struct vpif_config dm646x_vpif_config = {
+ .set_clock = set_vpif_clock,
+ .subdevinfo = dm646x_vpif_subdev,
+ .subdev_count = ARRAY_SIZE(dm646x_vpif_subdev),
+ .output = output,
+
RE: [PATCH] Subject: [PATCH v4] ARM: DaVinci: DM646x Video: Platform and board specific setup
Please ignore this patch. The version numbering is wrong here.
On Wed, Aug 05, 2009 at 20:11:54, Chaithrika U S wrote:
> Platform specific display device setup for DM646x EVM
>
> Add platform device and resource structures. Also define a platform
specific
> clock setup function that can be accessed by the driver to configure the
clock
> and CPLD.
>
> Signed-off-by: Manjunath Hadli
> Signed-off-by: Brijesh Jadav
> Signed-off-by: Chaithrika U S
> Signed-off-by: Kevin Hilman
> ---
> Applies to Davinci GIT tree. Minor updates like change in structure name-
> subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
>
> Signed-off-by: Chaithrika U S
> ---
> arch/arm/mach-davinci/board-dm646x-evm.c| 125
+++
> arch/arm/mach-davinci/dm646x.c | 62 +
> arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
> 3 files changed, 211 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
> index b1bf18c..8c88fd0 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -63,6 +63,19 @@
> #define DM646X_EVM_PHY_MASK (0x2)
> #define DM646X_EVM_MDIO_FREQUENCY(220) /* PHY bus frequency */
>
> +#define VIDCLKCTL_OFFSET (0x38)
> +#define VSCLKDIS_OFFSET (0x6c)
> +
> +#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
> +#define VCH2CLK_SYSCLK8 (BIT(9))
> +#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
> +#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
> +#define VCH3CLK_SYSCLK8 (BIT(13))
> +#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
> +
> +#define VIDCH2CLK(BIT(10))
> +#define VIDCH3CLK(BIT(11))
> +
> static struct davinci_uart_config uart_config __initdata = {
> .enabled_uarts = (1 << 0),
> };
> @@ -288,6 +301,40 @@ static struct snd_platform_data dm646x_evm_snd_data[]
= {
> },
> };
>
> +static struct i2c_client *cpld_client;
> +
> +static int cpld_video_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + cpld_client = client;
> + return 0;
> +}
> +
> +static int __devexit cpld_video_remove(struct i2c_client *client)
> +{
> + cpld_client = NULL;
> + return 0;
> +}
> +
> +static const struct i2c_device_id cpld_video_id[] = {
> + { "cpld_video", 0 },
> + { }
> +};
> +
> +static struct i2c_driver cpld_video_driver = {
> + .driver = {
> + .name = "cpld_video",
> + },
> + .probe = cpld_video_probe,
> + .remove = cpld_video_remove,
> + .id_table = cpld_video_id,
> +};
> +
> +static void evm_init_cpld(void)
> +{
> + i2c_add_driver(&cpld_video_driver);
> +}
> +
> static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("24c256", 0x50),
> @@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] =
{
> {
> I2C_BOARD_INFO("cpld_reg0", 0x3a),
> },
> + {
> + I2C_BOARD_INFO("cpld_video", 0x3B),
> + },
> };
>
> static struct davinci_i2c_platform_data i2c_pdata = {
> @@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata =
{
> .bus_delay = 0 /* usec */,
> };
>
> +static int set_vpif_clock(int mux_mode, int hd)
> +{
> + int val = 0;
> + int err = 0;
> + unsigned int value;
> + void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
> +
> + if (!cpld_client)
> + return -ENXIO;
> +
> + /* disable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value |= (VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + val = i2c_smbus_read_byte(cpld_client);
> + if (val < 0)
> + return val;
> +
> + if (mux_mode == 1)
> + val &= ~0x40;
> + else
> + val |= 0x40;
> +
> + err = i2c_smbus_write_byte(cpld_client, val);
> + if (err)
> + return err;
> +
> + value = __raw_readl(base + VIDCLKCTL_OFFSET);
> + value &= ~(VCH2CLK_MASK);
> + value &= ~(VCH3CLK_MASK);
> +
> + if (hd >= 1)
> + value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
> + else
> + value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
> +
> + __raw_writel(value, base + VIDCLKCTL_OFFSET);
> +
> + /* enable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value &= ~(VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + return 0;
> +}
> +
> +static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
> + {
> + .addr = 0x2A,
> + .name = "adv7343",
> + },
> + {
> + .addr = 0x2C,
> + .name = "ths7303",
> + },
> +};
> +
> +stati
[PATCH] Subject: [PATCH v4] ARM: DaVinci: DM646x Video: Platform and board specific setup
Platform specific display device setup for DM646x EVM
Add platform device and resource structures. Also define a platform specific
clock setup function that can be accessed by the driver to configure the clock
and CPLD.
Signed-off-by: Manjunath Hadli
Signed-off-by: Brijesh Jadav
Signed-off-by: Chaithrika U S
Signed-off-by: Kevin Hilman
---
Applies to Davinci GIT tree. Minor updates like change in structure name-
subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
Signed-off-by: Chaithrika U S
---
arch/arm/mach-davinci/board-dm646x-evm.c| 125 +++
arch/arm/mach-davinci/dm646x.c | 62 +
arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
3 files changed, 211 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index b1bf18c..8c88fd0 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -63,6 +63,19 @@
#define DM646X_EVM_PHY_MASK(0x2)
#define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+#define VIDCLKCTL_OFFSET (0x38)
+#define VSCLKDIS_OFFSET(0x6c)
+
+#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
+#define VCH2CLK_SYSCLK8(BIT(9))
+#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
+#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
+#define VCH3CLK_SYSCLK8(BIT(13))
+#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
+
+#define VIDCH2CLK (BIT(10))
+#define VIDCH3CLK (BIT(11))
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
};
@@ -288,6 +301,40 @@ static struct snd_platform_data dm646x_evm_snd_data[] = {
},
};
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id cpld_video_id[] = {
+ { "cpld_video", 0 },
+ { }
+};
+
+static struct i2c_driver cpld_video_driver = {
+ .driver = {
+ .name = "cpld_video",
+ },
+ .probe = cpld_video_probe,
+ .remove = cpld_video_remove,
+ .id_table = cpld_video_id,
+};
+
+static void evm_init_cpld(void)
+{
+ i2c_add_driver(&cpld_video_driver);
+}
+
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
@@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("cpld_reg0", 0x3a),
},
+ {
+ I2C_BOARD_INFO("cpld_video", 0x3B),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
@@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ if (!cpld_client)
+ return -ENXIO;
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val < 0)
+ return val;
+
+ if (mux_mode == 1)
+ val &= ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+
+ value = __raw_readl(base + VIDCLKCTL_OFFSET);
+ value &= ~(VCH2CLK_MASK);
+ value &= ~(VCH3CLK_MASK);
+
+ if (hd >= 1)
+ value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
+ else
+ value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
+
+ __raw_writel(value, base + VIDCLKCTL_OFFSET);
+
+ /* enable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value &= ~(VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ return 0;
+}
+
+static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
+ {
+ .addr = 0x2A,
+ .name = "adv7343",
+ },
+ {
+ .addr = 0x2C,
+ .name = "ths7303",
+ },
+};
+
+static const char *output[] = {
+ "Composite",
+ "Component",
+ "S-Video",
+};
+
+static struct vpif_config dm646x_vpif_config = {
+ .set_clock = set_vpif_clock,
+ .subdevinfo = dm646x_vpif_subdev,
+ .subdev_count = ARRAY_SIZE(dm646x_vpif_subdev),
+
RE: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board specific setup
On Wed, Aug 05, 2009 at 02:45:36, Karicheri, Muralidharan wrote:
>
>
> >-Original Message-
> >From: davinci-linux-open-source-boun...@linux.davincidsp.com
> >[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
> >Of Subrahmanya, Chaithrika
> >Sent: Monday, July 20, 2009 4:01 AM
> >To: li...@arm.linux.org.uk
> >Cc: davinci-linux-open-sou...@linux.davincidsp.com;
mche...@infradead.org;
> >linux-media@vger.kernel.org
> >Subject: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board
specific
> >setup
> >
> >Platform specific display device setup for DM646x EVM
> >
> >Add platform device and resource structures. Also define a platform
> >specific
> >clock setup function that can be accessed by the driver to configure the
> >clock
> >and CPLD.
> >
> >Signed-off-by: Manjunath Hadli
> >Signed-off-by: Brijesh Jadav
> >Signed-off-by: Chaithrika U S
> >Signed-off-by: Kevin Hilman
> >---
> >Applies to Davinci GIT tree. Minor updates like change in structure name-
> >subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
> >
> > arch/arm/mach-davinci/board-dm646x-evm.c| 125
> >+++
> > arch/arm/mach-davinci/dm646x.c | 62 +
> > arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
> > 3 files changed, 211 insertions(+), 0 deletions(-)
> >
> >diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-
> >davinci/board-dm646x-evm.c
> >index b1bf18c..8c88fd0 100644
> >--- a/arch/arm/mach-davinci/board-dm646x-evm.c
> >+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> >@@ -63,6 +63,19 @@
> > #define DM646X_EVM_PHY_MASK (0x2)
> > #define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
> >
> >+#define VIDCLKCTL_OFFSET(0x38)
> >+#define VSCLKDIS_OFFSET (0x6c)
> >+
> >+#define VCH2CLK_MASK(BIT_MASK(10) | BIT_MASK(9) |
BIT_MASK(8))
> >+#define VCH2CLK_SYSCLK8 (BIT(9))
> >+#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
> >+#define VCH3CLK_MASK(BIT_MASK(14) | BIT_MASK(13) |
BIT_MASK(12))
> >+#define VCH3CLK_SYSCLK8 (BIT(13))
> >+#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
> >+
> >+#define VIDCH2CLK (BIT(10))
> >+#define VIDCH3CLK (BIT(11))
> >+
> > static struct davinci_uart_config uart_config __initdata = {
> > .enabled_uarts = (1 << 0),
> > };
> >@@ -288,6 +301,40 @@ static struct snd_platform_data
dm646x_evm_snd_data[]
> >= {
> > },
> > };
> >
> >+static struct i2c_client *cpld_client;
> >+
> >+static int cpld_video_probe(struct i2c_client *client,
> >+const struct i2c_device_id *id)
> >+{
> >+cpld_client = client;
> >+return 0;
> >+}
> >+
> >+static int __devexit cpld_video_remove(struct i2c_client *client)
> >+{
> >+cpld_client = NULL;
> >+return 0;
> >+}
> >+
> >+static const struct i2c_device_id cpld_video_id[] = {
> >+{ "cpld_video", 0 },
> >+{ }
> >+};
> >+
> >+static struct i2c_driver cpld_video_driver = {
> >+.driver = {
> >+.name = "cpld_video",
> >+},
> >+.probe = cpld_video_probe,
> >+.remove = cpld_video_remove,
> >+.id_table = cpld_video_id,
> >+};
> >+
> >+static void evm_init_cpld(void)
> >+{
> >+i2c_add_driver(&cpld_video_driver);
> >+}
> >+
> > static struct i2c_board_info __initdata i2c_info[] = {
> > {
> > I2C_BOARD_INFO("24c256", 0x50),
> >@@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] =
{
> > {
> > I2C_BOARD_INFO("cpld_reg0", 0x3a),
> > },
> >+{
> >+I2C_BOARD_INFO("cpld_video", 0x3B),
> >+},
> > };
> >
> > static struct davinci_i2c_platform_data i2c_pdata = {
> >@@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata =
{
> > .bus_delay = 0 /* usec */,
> > };
> >
> >+static int set_vpif_clock(int mux_mode, int hd)
> >+{
> >+int val = 0;
> >+int err = 0;
> >+unsigned int value;
> >+void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
> >+
> >+if (!cpld_client)
> >+return -ENXIO;
> >+
> >+/* disable the clock */
> >+value = __raw_readl(base + VSCLKDIS_OFFSET);
> >+value |= (VIDCH3CLK | VIDCH2CLK);
> >+__raw_writel(value, base + VSCLKDIS_OFFSET);
> >+
> >+val = i2c_smbus_read_byte(cpld_client);
> >+if (val < 0)
> >+return val;
> >+
> >+if (mux_mode == 1)
> >+val &= ~0x40;
> >+else
> >+val |= 0x40;
> >+
> >+err = i2c_smbus_write_byte(cpld_client, val);
> >+if (err)
> >+return err;
> >+
> >+value = __raw_readl(base + VIDCLKCTL_OFFSET);
> >+value &= ~(VCH2CLK_MASK);
> >+value &= ~(VCH3CLK_MASK);
> >+
> >+if (hd >= 1)
> >+value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
> >+else
> >+value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
> >+
> >+__raw_writel(value, base + VIDCLKCTL_OFFSE
Re: Linux Plumbers Conference 2009: V4L2 API discussions
On Wed, Aug 5, 2009 at 12:06 PM, Hiremath, Vaibhav wrote: >> -Original Message- >> From: Magnus Damm [mailto:magnus.d...@gmail.com] >> Sent: Wednesday, August 05, 2009 8:01 AM >> To: Karicheri, Muralidharan >> Cc: Hiremath, Vaibhav; Hans Verkuil; linux-media@vger.kernel.org; >> davinci-linux-open-sou...@linux.davincidsp.com; linux- >> o...@vger.kernel.org; eduardo.valen...@nokia.com; Dongsoo, Nathaniel >> Kim >> Subject: Re: Linux Plumbers Conference 2009: V4L2 API discussions >> >> On Wed, Aug 5, 2009 at 5:14 AM, Karicheri, >> Muralidharan wrote: >> > 2) Previewer & Resizer driver. I am working with Vaibhav who had >> worked on an RFC for this. The previewer and resizer devices are >> doing memory to memory operations. Also should be flexible to use >> these hardware with capture driver to do on the fly preview and >> resize. The TI hardware is parameter intensive. We believe these >> parameters are to be exported to user space through IOCTLs and would >> require addition of new IOCTLs and extension of control IDs. We will >> be working with you on this as well. >> >> FWIW, for our SuperH Mobile devices we make use of UIO and user >> space >> libraries to support for our on-chip multimedia blocks. These blocks >> do scaling, rotation, color space conversion and hardware >> encode/decode of various formats including h264 and mpeg4 in HD >> resolution. >> >> Apart from UIO we use V4L2 for the camera capture interface driver >> sh_mobile_ceu_camera.c. It has support for on the fly color space >> conversion and scaling/cropping. The CEU driver is making use of >> videobuf-dma-contig.c and the USERPTR changes included in 2.6.31-rc >> gives the driver zero copy frame capture support. >> >> All of this is of course available upstream. > [Hiremath, Vaibhav] Thanks Magnus, > > I will definitely take reference from this device and driver code. I think > now I have one more device which has similar capabilities. Can you please > share or point me to the spec/TRM for SuperH Mobile device for my reference? The multimedia software is used on a wide range of devices, so it's hard to come up with a specific device. Google may give you some examples. > Currently we are referring to Davinci, OMAP and Samsung S3C6400X devices, the > user configurable/exported parameters are very different. This is why we do the most of the multimedia pipe line in user space using UIO . High level frameworks like gstreamer and openmax are suitable for this kind of stuff IMO. Cheers, / 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: Linux Plumbers Conference 2009: V4L2 API discussions
> -Original Message- > From: Magnus Damm [mailto:magnus.d...@gmail.com] > Sent: Wednesday, August 05, 2009 8:01 AM > To: Karicheri, Muralidharan > Cc: Hiremath, Vaibhav; Hans Verkuil; linux-media@vger.kernel.org; > davinci-linux-open-sou...@linux.davincidsp.com; linux- > o...@vger.kernel.org; eduardo.valen...@nokia.com; Dongsoo, Nathaniel > Kim > Subject: Re: Linux Plumbers Conference 2009: V4L2 API discussions > > On Wed, Aug 5, 2009 at 5:14 AM, Karicheri, > Muralidharan wrote: > > 2) Previewer & Resizer driver. I am working with Vaibhav who had > worked on an RFC for this. The previewer and resizer devices are > doing memory to memory operations. Also should be flexible to use > these hardware with capture driver to do on the fly preview and > resize. The TI hardware is parameter intensive. We believe these > parameters are to be exported to user space through IOCTLs and would > require addition of new IOCTLs and extension of control IDs. We will > be working with you on this as well. > > FWIW, for our SuperH Mobile devices we make use of UIO and user > space > libraries to support for our on-chip multimedia blocks. These blocks > do scaling, rotation, color space conversion and hardware > encode/decode of various formats including h264 and mpeg4 in HD > resolution. > > Apart from UIO we use V4L2 for the camera capture interface driver > sh_mobile_ceu_camera.c. It has support for on the fly color space > conversion and scaling/cropping. The CEU driver is making use of > videobuf-dma-contig.c and the USERPTR changes included in 2.6.31-rc > gives the driver zero copy frame capture support. > > All of this is of course available upstream. [Hiremath, Vaibhav] Thanks Magnus, I will definitely take reference from this device and driver code. I think now I have one more device which has similar capabilities. Can you please share or point me to the spec/TRM for SuperH Mobile device for my reference? Currently we are referring to Davinci, OMAP and Samsung S3C6400X devices, the user configurable/exported parameters are very different. Thanks Vaibhav > > Cheers, > > / 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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
Am Dienstag, den 04.08.2009, 23:35 -0300 schrieb Mauro Carvalho Chehab: > Em Wed, 05 Aug 2009 03:07:29 +0200 > hermann pitton escreveu: > > > First of all, it is a pleasure to see Alex here again, he helped a lot > > in the past. > > Agreed. > > > > > Now going off topic. > > It would be better if you had changed the subject. > > > We have no rules about NDAs. > > No, we don't. It should be a personal decision of each developer if he will > sign a NDA or not. > > I personally think that the better is that, if someone decide to sign it, if > he > could do it via Linux Foundation, due to two reasons: > > 1) this way, other people with an NDA with LF can also use the same NDA to > improve the driver; > 2) there will be some Lawyers that will analyze the NDA and see if they'll > allow a later release of the source code under GPL. > > But this is just my 2 cents > Yeah. I give a simple example. The huge 5.5 MHz radio IF filter used with tda8290/saa7131e devices to indicate, that radio/FM support might be present on a board, is replaced by a bandpath filter, not easily visible any more on later devices. Those sitting on NDAs for the follow up devices, since years meanwhile, did not give the slightest tone, if you are going into deserts with users to verify radio. It is hard to believe, that this very minor hardware change, now public at NXP, was included within NDA restrictions. Some like to see you walking around in circles. Cheers, Hermann -- 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: adding ISDB-T/ISDB-Tsb to DVB-API 5
Hi Patrick, Thank you for your effort to add support for ISDB-T/S. I've skimmed through the ARIB standard before, but it is too complicated for me to understand well enough. So this is not a comment for the API extension itself, but for the document part. Some of the parameters are currently (and probably will stay) fixed or not used according to the "operational guidelines". For example, DQPSK is not used at all (if I read correctly). These guidelines are defined in ARIB TR-B14 for ISDB-T and in ARIB TR-B15 for ISDB-S respectively. So, including these two TRs (in additino to ARIB STD-B31) as a reference in the document may help readers. - Akihiro TSUKADA -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
Em Wed, 05 Aug 2009 03:07:29 +0200 hermann pitton escreveu: > First of all, it is a pleasure to see Alex here again, he helped a lot > in the past. Agreed. > > Now going off topic. It would be better if you had changed the subject. > We have no rules about NDAs. No, we don't. It should be a personal decision of each developer if he will sign a NDA or not. I personally think that the better is that, if someone decide to sign it, if he could do it via Linux Foundation, due to two reasons: 1) this way, other people with an NDA with LF can also use the same NDA to improve the driver; 2) there will be some Lawyers that will analyze the NDA and see if they'll allow a later release of the source code under GPL. But this is just my 2 cents Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Plumbers Conference 2009: V4L2 API discussions
On Wed, Aug 5, 2009 at 5:14 AM, Karicheri, Muralidharan wrote: > 2) Previewer & Resizer driver. I am working with Vaibhav who had worked on an > RFC for this. The previewer and resizer devices are doing memory to memory > operations. Also should be flexible to use these hardware with capture driver > to do on the fly preview and resize. The TI hardware is parameter intensive. > We believe these parameters are to be exported to user space through IOCTLs > and would require addition of new IOCTLs and extension of control IDs. We > will be working with you on this as well. FWIW, for our SuperH Mobile devices we make use of UIO and user space libraries to support for our on-chip multimedia blocks. These blocks do scaling, rotation, color space conversion and hardware encode/decode of various formats including h264 and mpeg4 in HD resolution. Apart from UIO we use V4L2 for the camera capture interface driver sh_mobile_ceu_camera.c. It has support for on the fly color space conversion and scaling/cropping. The CEU driver is making use of videobuf-dma-contig.c and the USERPTR changes included in 2.6.31-rc gives the driver zero copy frame capture support. All of this is of course available upstream. Cheers, / 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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
Am Dienstag, den 04.08.2009, 20:40 -0300 schrieb Mauro Carvalho Chehab: > Em Tue, 4 Aug 2009 16:19:46 -0400 > Michael Krufky escreveu: > > > On Tue, Aug 4, 2009 at 3:58 PM, Alex Deucher wrote: > > > On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky > > > wrote: > > >> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher > > >> wrote: > > >>> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky > > >>> wrote: > > Mauro, > > > > Please pull from: > > > > http://kernellabs.com/hg/~mkrufky/cx23885 > > > > for the following fixes: > > > > - cx23885: Enable mplayer pvr:// usage > > >>> > > >>> I'm not too familiar with mplayer's v4l support, but why not fix > > >>> mplayer rather than adding a fake audio interface to the driver. > > >>> Wouldn't that potentially confuse users or other apps? > > >> > > >> Thats a good question, Alex. > > >> > > >> The answer, for now, is conformity amongst the v4l2 drivers. > > >> > > >> Mplayer has been around for a good long time, and any v4l2 mpeg > > >> encoder that doesnt do this is broken in the vraious userspace > > >> applications. > > >> > > >> I agree that we should fix userspace also -- but fix the kernel first, > > >> so that older userspace works as-is. > > > > > > er... yeah, but you are re-enforcing broken behavior, rather than > > > "fixing" more drivers, why not submit a mplayer patch and tell users > > > they need a newer version of mplayer/etc. to work with their card? > > > Otherwise we'll end up with tons of drivers with fake audio interfaces > > > and mplayer will never get fixed and users will complain that the > > > audio interface doesn't work. > > > > You don't really have the full picture here, Alex. The applications > > expect to see an audio input, and rightfully so. > > > > This particular driver doesn't expose all of the functionality that is > > available from the raw video device onto the encoder device. > > > > Little by little, we are fixing up the cx23885-417 driver to fully > > expose all featuresets, but in the meanwhile, we do what is needed to > > make things work. > > > > The problem is not mplayer, the real problem is incomplete analog > > video (and analog audio) support in the cx23885 driver, itself. As > > THAT support improves, you will see small hacks like this disappear. > > There are some separate issues that came with this patch: > > 1) V4L2 API (chapter 1.5) states that: > > Drivers must implement all input ioctls when the device has one > or more inputs, all output ioctls when the device has one or more > outputs. > When the device has any audio inputs or outputs the driver must set the > V4L2_CAP_AUDIO flag in the struct v4l2_capability returned by the > VIDIOC_QUERYCAP ioctl. > > My understanding is that, except for webcams without any audio input, all > other > V4L2 devices should implement VIDIOC_G_AUDIO, VIDIOC_ENUMAUDIO and > VIDIOC_S_AUDIO. > > So, your patch should have implemented VIDIOC_S_AUDIO as well. > > 2) Based on the above understanding, your comments are wrong, since the device > has one audio input (otherwise, no audio would be streamed). > > So, it is not mplayer that requires those functions, but V4L2 API. So, please > remove the comments. The same fix applies to pvrusb2 comments. > > 3) On this piece of code: > > + strncpy(vin->name, "CX23885 Audio", 14); > + vin->capability = V4L2_AUDCAP_STEREO; > > the "magic" size above is very ugly. Please find another way for it, like: > > #define CX23885_INPUT_NAME "CX23885 Audio" > strncpy(vin->name, CX23885_INPUT_NAME, sizeof(CX23885_INPUT_NAME) + 1); > > 4) mplayer should be fixed to not require audio inputs for devices without > V4L2_CAP_AUDIO. > > I just tested it here with a webcam, where I have this parameter at > .mplayer/config: > > tv = > "driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast:alsa=1:adevice=hw.1:audiorate=32000:immediatemode=0:amode=1" > > With a device without audio cap: > > $ v4l2-ctl -D > Driver info: > Driver name : em28xx > Card type : Silvercrest Webcam 1.3mpix > Bus info : usb-:00:1d.7-7 > Driver version: 258 > Capabilities : 0x0541 > Video Capture > Sliced VBI Capture > Read/Write > Streaming > > it is still requesting for audio input, so mplayer has a small non-compliance > with V4L2 API. > > 5) There is one trouble with VIDIOC_G_AUDIO and VIDIOC_ENUMAUDIO: > > As stated at V4L2 API, at chapter 6.2.10, added on 2003-06-19: > > 3. The audio input and output interface was found to be incomplete. > > Previously the VIDIOC_G_AUDIO ioctl would enumerate the available audio > inputs. > An ioctl to determine the current audio input, if more than one > combines with > the current video input, did not exist. So VIDIOC_G_AUDIO was renamed to > VIDIOC_G_AUDIO_OLD, this ioc
Re: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
On Tue, 4 Aug 2009, Mauro Carvalho Chehab wrote:
> + strncpy(vin->name, "CX23885 Audio", 14);
> + vin->capability = V4L2_AUDCAP_STEREO;
>
> the "magic" size above is very ugly. Please find another way for it, like:
>
> #define CX23885_INPUT_NAME "CX23885 Audio"
> strncpy(vin->name, CX23885_INPUT_NAME, sizeof(CX23885_INPUT_NAME) + 1);
There is no need to add one here, as sizeof("foo") == 4, i.e. sizeof
includes the trailing \0 for a string literal.
But, there is no point to using strncpy() like this. How could the
behavior possibly be any different than just strcpy()? We know the string
literal must be NUL terminated.
The proper way to do this would be either:
strcpy(vin->name, "CX23885 Audio");
strncpy(vin->name, "CX23885 Audio", ARRAY_SIZE(vin->name));
The latter insures we don't overrun the end of vin->name, but IMHO it's
unnecessary since we know there is enough space. Using ARRAY_SIZE()
instead of sizeof() should give us a compile error if vin->name were a
pointer instead of an array, while sizeof() would happily compile to
completely wrong code.
--
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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
Em Tue, 4 Aug 2009 16:19:46 -0400 Michael Krufky escreveu: > On Tue, Aug 4, 2009 at 3:58 PM, Alex Deucher wrote: > > On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky > > wrote: > >> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote: > >>> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote: > Mauro, > > Please pull from: > > http://kernellabs.com/hg/~mkrufky/cx23885 > > for the following fixes: > > - cx23885: Enable mplayer pvr:// usage > >>> > >>> I'm not too familiar with mplayer's v4l support, but why not fix > >>> mplayer rather than adding a fake audio interface to the driver. > >>> Wouldn't that potentially confuse users or other apps? > >> > >> Thats a good question, Alex. > >> > >> The answer, for now, is conformity amongst the v4l2 drivers. > >> > >> Mplayer has been around for a good long time, and any v4l2 mpeg > >> encoder that doesnt do this is broken in the vraious userspace > >> applications. > >> > >> I agree that we should fix userspace also -- but fix the kernel first, > >> so that older userspace works as-is. > > > > er... yeah, but you are re-enforcing broken behavior, rather than > > "fixing" more drivers, why not submit a mplayer patch and tell users > > they need a newer version of mplayer/etc. to work with their card? > > Otherwise we'll end up with tons of drivers with fake audio interfaces > > and mplayer will never get fixed and users will complain that the > > audio interface doesn't work. > > You don't really have the full picture here, Alex. The applications > expect to see an audio input, and rightfully so. > > This particular driver doesn't expose all of the functionality that is > available from the raw video device onto the encoder device. > > Little by little, we are fixing up the cx23885-417 driver to fully > expose all featuresets, but in the meanwhile, we do what is needed to > make things work. > > The problem is not mplayer, the real problem is incomplete analog > video (and analog audio) support in the cx23885 driver, itself. As > THAT support improves, you will see small hacks like this disappear. There are some separate issues that came with this patch: 1) V4L2 API (chapter 1.5) states that: Drivers must implement all input ioctls when the device has one or more inputs, all output ioctls when the device has one or more outputs. When the device has any audio inputs or outputs the driver must set the V4L2_CAP_AUDIO flag in the struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. My understanding is that, except for webcams without any audio input, all other V4L2 devices should implement VIDIOC_G_AUDIO, VIDIOC_ENUMAUDIO and VIDIOC_S_AUDIO. So, your patch should have implemented VIDIOC_S_AUDIO as well. 2) Based on the above understanding, your comments are wrong, since the device has one audio input (otherwise, no audio would be streamed). So, it is not mplayer that requires those functions, but V4L2 API. So, please remove the comments. The same fix applies to pvrusb2 comments. 3) On this piece of code: + strncpy(vin->name, "CX23885 Audio", 14); + vin->capability = V4L2_AUDCAP_STEREO; the "magic" size above is very ugly. Please find another way for it, like: #define CX23885_INPUT_NAME "CX23885 Audio" strncpy(vin->name, CX23885_INPUT_NAME, sizeof(CX23885_INPUT_NAME) + 1); 4) mplayer should be fixed to not require audio inputs for devices without V4L2_CAP_AUDIO. I just tested it here with a webcam, where I have this parameter at .mplayer/config: tv = "driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast:alsa=1:adevice=hw.1:audiorate=32000:immediatemode=0:amode=1" With a device without audio cap: $ v4l2-ctl -D Driver info: Driver name : em28xx Card type : Silvercrest Webcam 1.3mpix Bus info : usb-:00:1d.7-7 Driver version: 258 Capabilities : 0x0541 Video Capture Sliced VBI Capture Read/Write Streaming it is still requesting for audio input, so mplayer has a small non-compliance with V4L2 API. 5) There is one trouble with VIDIOC_G_AUDIO and VIDIOC_ENUMAUDIO: As stated at V4L2 API, at chapter 6.2.10, added on 2003-06-19: 3. The audio input and output interface was found to be incomplete. Previously the VIDIOC_G_AUDIO ioctl would enumerate the available audio inputs. An ioctl to determine the current audio input, if more than one combines with the current video input, did not exist. So VIDIOC_G_AUDIO was renamed to VIDIOC_G_AUDIO_OLD, this ioctl will be removed in the future. The VIDIOC_ENUMAUDIO ioctl was added to enumerate audio inputs, while VIDIOC_G_AUDIO now reports the current audio input. There are very few drivers that are respecting this change. On almost all drivers, VIDIOC_G_AUDIO is still working like VIDIOC_G_AUDIO_OLD. For ex
best buy easy yv usb hybrod pro on ubuntu 9.04
Hi! Need help to make my DVB-T USB work on my AMD64 machine. Pretty new on Linux so I'm a little losr with the feedback of following msg. On Kaffeine no option for DVB TV appears. This is the dmesg reading after plugin. Thanks for the help [ 487.916033] usb 1-4: new high speed USB device using ehci_hcd and address 3 [ 488.073740] usb 1-4: configuration #1 chosen from 1 choice [ 488.073926] em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) [ 488.073935] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 488.074071] em28xx #0: chip ID is em2882/em2883 [ 488.157447] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 [ 488.157466] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [ 488.157480] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 01 00 b8 00 00 00 5b 1e 00 00 [ 488.157493] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 [ 488.157506] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157518] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157531] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [ 488.157543] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [ 488.157556] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [ 488.157569] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157581] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157594] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157606] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157619] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157631] em28xx #0: i2c eeprom e0: 5a 00 55 aa 23 21 5b 03 00 17 fc 01 00 00 00 00 [ 488.157644] em28xx #0: i2c eeprom f0: 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 [ 488.157659] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xa2d00320 [ 488.157663] em28xx #0: EEPROM info: [ 488.157666] em28xx #0: AC97 audio (5 sample rates) [ 488.157670] em28xx #0: USB Remote wakeup capable [ 488.157673] em28xx #0: 500mA max power [ 488.157677] em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x [ 488.205330] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 488.209950] em28xx #0: found i2c device @ 0xb8 [tvp5150a] [ 488.211820] em28xx #0: found i2c device @ 0xc2 [tuner (analog)] [ 488.222952] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 488.222960] em28xx #0: You may try to use card= insmod option to workaround that. [ 488.222964] em28xx #0: Please send an email with this log to: [ 488.222968] em28xx #0: V4L Mailing List [ 488.222972] em28xx #0: Board eeprom hash is 0xa2d00320 [ 488.222976] em28xx #0: Board i2c devicelist hash is 0x27e10080 [ 488.222980] em28xx #0: Here is a list of valid choices for the card= insmod option: [ 488.222985] em28xx #0: card=0 -> Unknown EM2800 video grabber [ 488.222989] em28xx #0: card=1 -> Unknown EM2750/28xx video grabber [ 488.222993] em28xx #0: card=2 -> Terratec Cinergy 250 USB [ 488.222997] em28xx #0: card=3 -> Pinnacle PCTV USB 2 [ 488.223001] em28xx #0: card=4 -> Hauppauge WinTV USB 2 [ 488.223004] em28xx #0: card=5 -> MSI VOX USB 2.0 [ 488.223008] em28xx #0: card=6 -> Terratec Cinergy 200 USB [ 488.223012] em28xx #0: card=7 -> Leadtek Winfast USB II [ 488.223016] em28xx #0: card=8 -> Kworld USB2800
Re: Linux Plumbers Conference 2009: V4L2 API discussions
On Wed, 5 Aug 2009 03:13:29 Hiremath, Vaibhav wrote: > > -Original Message- > > From: davinci-linux-open-source-boun...@linux.davincidsp.com > > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On > > Behalf Of Hans Verkuil > > Sent: Tuesday, August 04, 2009 12:42 PM > > To: linux-media@vger.kernel.org > > Cc: eduardo.valen...@nokia.com; davinci-linux-open- > > sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus > > Damm; Dongsoo, Nathaniel Kim > > Subject: Linux Plumbers Conference 2009: V4L2 API discussions > > > > Hi all, > > > > During this years Plumbers Conference I will be organizing a session > > (or > > possibly more than one) on what sort of new V4L2 APIs are needed to > > support the new SoC devices. These new APIs should also solve the > > problem > > of how to find all the related alsa/fb/ir/dvb devices that a typical > > video > > device might create. > > > > A proposal was made about a year ago (note that this is a bit > > outdated > > by now, but the basics are still valid): > > > > http://www.archivum.info/video4linux-list%40redhat.com/2008- > > 07/msg00371.html > > > > In the past year the v4l2 core has evolved enough so that we can > > finally > > start thinking about this for real. > > > > I would like to know who will be attending this conference. I also > > urge > > anyone who is working in this area and who wants to have a say in > > this to > > attend the conference. The goal is to prepare a new RFC with a > > detailed > > proposal on the new APIs that are needed to fully support all the > > new > > SoCs. So the more input we get, the better the end-result will be. > > [Hiremath, Vaibhav] Hi Hans, > > I will be attending the conference and along with above mentioned RFC I > would want to discuss some of the open issues, forthcoming TI devices, > their complexity and required software interfaces (media processor (as you > mentioned above)) and similar stuff. > > I will work with you offline before sharing the details here with the > community. > > Thanks, > Vaibhav Hiremath > > > Early-bird registration is still possible up to August 5th (that's > > tomorrow :-) ). > > > > Regards, > > > > Hans > > > > -- > > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > > > > ___ > > Davinci-linux-open-source mailing list > > davinci-linux-open-sou...@linux.davincidsp.com > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > > source > > -- > 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 does this mean that the definition of "howto" signal to noise and signal strength might get fixed up? Mike -- 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: Noisy video with Avermedia AVerTV Digi Volar X HD (AF9015) and mythbuntu 9.04
Antti, can this patch be integrated in the af015 module? Signed-off-by: Jose Alberto Reguero Jose Alberto El Martes, 4 de Agosto de 2009, Cyril Hansen escribió: > Thank you very much, your patch has fixed the issue i had using the > firmware provided by mythbuntu. > > Maybe we should add this info to the LinuxTV wiki. > > Regards, > > Cyril Hansen > > 2009/8/4 Jose Alberto Reguero : > > El Martes, 4 de Agosto de 2009, Cyril Hansen escribió: > >> Hi all, > >> > >> I am trying to solve a noisy video issue with my new avermedia stick > >> (AF9015). I am receiving french DVB signal, both SD and HD. Viewing SD > >> is annoying, with the occasional video and audio quirk, and HD is > >> almost unwatchable. > >> > >> The same usb stick with another computer and Vista gives a perfect > >> image with absolutely no error from the same antenna. > >> > >> Yesterday I tried to update the drivers from the mercurial tree with no > >> change. > >> > >> I noticed that the firmware available from the Net and Mythbuntu for > >> the chip is quite old (2007 ?), so maybe this is the source of my > >> problem. I am willing to try to use usbsnoop and the firmware cutter > >> from > >> > >> http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware > >>_fi les/ if nobody has done it with a recent windows driver. > >> > >> > >> I haven't found any parameter for the module dvb_usb_af9015 : Are they > >> any than can be worth to try to fix my issue ? > >> > >> > >> Thank you in advance, > >> > >> Cyril Hansen > >> -- > > > > I have problems with some hardware, and the buffersize when the > > buffersize is not multiple of TS_PACKET_SIZE. > > > > You can try the attached patch. > > > > Jose Alberto > > -- > 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: [patch] Added Support for STK7700D (DVB)
Hi Pete, On Tuesday 04 August 2009 21:38:11 Pete Hildebrandt wrote: > Hello, > > To this mail I attached two patch-files to add support for the STK7700D > USB-DVB-Device. > > lsusb identifies it as: > idVendor 0x1164 YUAN High-Tech Development Co., Ltd > idProduct 0x1efc > iProduct2 STK7700D > > My two patches mainly just add the new product-ID. > > I have tested the modification with the 2.6.28 and the 2.6.30 kernel. The > patches are for the 2.6.30 kernel. > > The device is build into my laptop (Samsung R55-T5500) and works great > after applying the patches. I will apply your patches tomorrow, but before I need your Signed-off-by-line. So something like that: Signed-off-by: Name thanks, -- Patrick Boettcher - 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: Noisy video with Avermedia AVerTV Digi Volar X HD (AF9015) and mythbuntu 9.04
Thank you very much, your patch has fixed the issue i had using the firmware provided by mythbuntu. Maybe we should add this info to the LinuxTV wiki. Regards, Cyril Hansen 2009/8/4 Jose Alberto Reguero : > El Martes, 4 de Agosto de 2009, Cyril Hansen escribió: >> Hi all, >> >> I am trying to solve a noisy video issue with my new avermedia stick >> (AF9015). I am receiving french DVB signal, both SD and HD. Viewing SD >> is annoying, with the occasional video and audio quirk, and HD is >> almost unwatchable. >> >> The same usb stick with another computer and Vista gives a perfect >> image with absolutely no error from the same antenna. >> >> Yesterday I tried to update the drivers from the mercurial tree with no >> change. >> >> I noticed that the firmware available from the Net and Mythbuntu for >> the chip is quite old (2007 ?), so maybe this is the source of my >> problem. I am willing to try to use usbsnoop and the firmware cutter >> from >> >> http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_fi >>les/ if nobody has done it with a recent windows driver. >> >> >> I haven't found any parameter for the module dvb_usb_af9015 : Are they >> any than can be worth to try to fix my issue ? >> >> >> Thank you in advance, >> >> Cyril Hansen >> -- > > I have problems with some hardware, and the buffersize when the buffersize is > not multiple of TS_PACKET_SIZE. > > You can try the attached patch. > > Jose Alberto > > -- 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: Issue with LifeView FlyDVB-T Duo CardBus.
Am Dienstag, den 04.08.2009, 09:02 +0200 schrieb Francesco Marangoni: > Hi Hermann, > > the card works fine on win2000 on another pc. Ah, fine. Some of them have been reported to become very hot and finally faulty. Maybe you could test it on this PC too with some LIVE linux media. > The pc with linux installed is a pentium 3 800 mhz with RAM 256 MB: I don't > think it's a resources problem because when I launch channels scan ram used > is always at 70 MB and CPU is at 25%. Should be enough. The NATOMA PCI to PCI quirk is enabled for some faulty motherboards. Usually works then, but you seem to have still parity errors. > The card becomes warm after the use, but not hot. The problem is, that at least the digital tuner is not detected. So it is not usable and also not fully powered. Look more carefully at dmesg, if the analog tuner is at least present. Your early version of the card should also have a fan, IIRC. > What dou You think about errors in compiling v4l-dvb? http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers You follow the instructions for Debian. As already printed, on Ubuntu are some back ported media modules in unusual places. You need to be root to get them removed or have to do it manually to avoid duplicate modules. There have also been problems with an incompatible alsa version there. > And from output of dmesg | grep saa do You think the card has benn well > detected or there is something wrong? At least the digital tuner is not found at 0x60 and the card can't work. Have you forced other cards previously, since it also should be auto detected? Wrong tuner initialization code can make i2c unreliable. You might try to unload the driver starting with saa7134-alsa and saa7134-dvb, eject the card then and wait at least 30 seconds before you give it another try. You could also try to enable i2c_debug=1 for saa7134. Maybe more errors become visible, dunno. Cheers, Hermann > Thanks a lot for any suggetsion. > > -- Initial Header --- > > >From : "hermann pitton" hermann-pit...@arcor.de > To : "Francesco Marangoni" fmarang...@libero.it > Cc : "linux-media" linux-media@vger.kernel.org > Date : Tue, 04 Aug 2009 02:21:38 +0200 > Subject : Re: Issue with LifeView FlyDVB-T Duo CardBus. > > > > > > > > > Hi Francesco, > > > > Am Montag, den 03.08.2009, 23:49 +0200 schrieb Francesco Marangoni: > > > Dear sirs, > > > > > > I'm not able to make my pcmcia LifeView DVB-T Duo Cardbus working on > > > Ununtu 8.04 LTS kernel 2.6.24.24. > > > > > > The card seems to be detected but the DVB channel detection fails (using > > > Kaffeine too). > > > > > > Here the output of some commands: Can Youhelp me? > > > > > > france...@ubuntu:~$ lspci > > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host > > > bridge (rev 03) > > > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP > > > bridge (rev 03) > > > 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) > > > 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) > > > 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) > > > 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > > > 00:0a.0 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus > > > Controller > > > 00:0a.1 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus > > > Controller > > > 00:0b.0 Ethernet controller: 3Com Corporation 3c556 Hurricane CardBus > > > [Cyclone] (rev 10) > > > 00:0b.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem > > > (rev 10) > > > 00:0d.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i > > > PCI Audio Accelerator > > > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M > > > AGP 2x (rev 64) > > > 02:00.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 > > > Video Broadcast Decoder (rev d0) > > > > > > france...@ubuntu:~$ dmesg | grep saa | more > > > [ 46.176353] saa7130/34: v4l2 driver version 0.2.14 loaded > > > [ 46.176618] saa7133[0]: quirk: PCIPCI_NATOMA > > > [ 46.176628] saa7133[0]: found at :02:00.0, rev: 208, irq: 10, > > > latency: 0, mmio: 0x2400 > > > [ 46.176653] saa7133[0]: subsystem: 5168:0502, board: > > > LifeView/Typhoon/Genius FlyDVB-T Duo Cardbus [card=60,insmod option] > > > [ 46.176681] saa7133[0]: board init: gpio is 821 > > > [ 46.280562] saa7133[0]: i2c eeprom 00: 68 51 02 05 54 20 1c 00 43 43 > > > a9 1c 55 d2 b2 92 > > > [ 46.280587] saa7133[0]: i2c eeprom 10: 00 ff 22 0f ff 20 ff ff ff ff > > > ff ff ff ff ff ff > > > [ 46.280607] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff > > > 01 aa ff ff ff ff > > > [ 46.280627] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff > > > ff ff ff ff ff ff > > > [ 46.280646] saa7133[0]: i2c eeprom 40: ff 25 00 c0 ff 10 07 01 c2 96 > > > 0
RE: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board specific setup
>-Original Message-
>From: davinci-linux-open-source-boun...@linux.davincidsp.com
>[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
>Of Subrahmanya, Chaithrika
>Sent: Monday, July 20, 2009 4:01 AM
>To: li...@arm.linux.org.uk
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; mche...@infradead.org;
>linux-media@vger.kernel.org
>Subject: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board specific
>setup
>
>Platform specific display device setup for DM646x EVM
>
>Add platform device and resource structures. Also define a platform
>specific
>clock setup function that can be accessed by the driver to configure the
>clock
>and CPLD.
>
>Signed-off-by: Manjunath Hadli
>Signed-off-by: Brijesh Jadav
>Signed-off-by: Chaithrika U S
>Signed-off-by: Kevin Hilman
>---
>Applies to Davinci GIT tree. Minor updates like change in structure name-
>subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
>
> arch/arm/mach-davinci/board-dm646x-evm.c| 125
>+++
> arch/arm/mach-davinci/dm646x.c | 62 +
> arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
> 3 files changed, 211 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-
>davinci/board-dm646x-evm.c
>index b1bf18c..8c88fd0 100644
>--- a/arch/arm/mach-davinci/board-dm646x-evm.c
>+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
>@@ -63,6 +63,19 @@
> #define DM646X_EVM_PHY_MASK (0x2)
> #define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
>
>+#define VIDCLKCTL_OFFSET (0x38)
>+#define VSCLKDIS_OFFSET (0x6c)
>+
>+#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
>+#define VCH2CLK_SYSCLK8 (BIT(9))
>+#define VCH2CLK_AUXCLK(BIT(9) | BIT(8))
>+#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
>+#define VCH3CLK_SYSCLK8 (BIT(13))
>+#define VCH3CLK_AUXCLK(BIT(14) | BIT(13))
>+
>+#define VIDCH2CLK (BIT(10))
>+#define VIDCH3CLK (BIT(11))
>+
> static struct davinci_uart_config uart_config __initdata = {
> .enabled_uarts = (1 << 0),
> };
>@@ -288,6 +301,40 @@ static struct snd_platform_data dm646x_evm_snd_data[]
>= {
> },
> };
>
>+static struct i2c_client *cpld_client;
>+
>+static int cpld_video_probe(struct i2c_client *client,
>+ const struct i2c_device_id *id)
>+{
>+ cpld_client = client;
>+ return 0;
>+}
>+
>+static int __devexit cpld_video_remove(struct i2c_client *client)
>+{
>+ cpld_client = NULL;
>+ return 0;
>+}
>+
>+static const struct i2c_device_id cpld_video_id[] = {
>+ { "cpld_video", 0 },
>+ { }
>+};
>+
>+static struct i2c_driver cpld_video_driver = {
>+ .driver = {
>+ .name = "cpld_video",
>+ },
>+ .probe = cpld_video_probe,
>+ .remove = cpld_video_remove,
>+ .id_table = cpld_video_id,
>+};
>+
>+static void evm_init_cpld(void)
>+{
>+ i2c_add_driver(&cpld_video_driver);
>+}
>+
> static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("24c256", 0x50),
>@@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("cpld_reg0", 0x3a),
> },
>+ {
>+ I2C_BOARD_INFO("cpld_video", 0x3B),
>+ },
> };
>
> static struct davinci_i2c_platform_data i2c_pdata = {
>@@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata = {
> .bus_delay = 0 /* usec */,
> };
>
>+static int set_vpif_clock(int mux_mode, int hd)
>+{
>+ int val = 0;
>+ int err = 0;
>+ unsigned int value;
>+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
>+
>+ if (!cpld_client)
>+ return -ENXIO;
>+
>+ /* disable the clock */
>+ value = __raw_readl(base + VSCLKDIS_OFFSET);
>+ value |= (VIDCH3CLK | VIDCH2CLK);
>+ __raw_writel(value, base + VSCLKDIS_OFFSET);
>+
>+ val = i2c_smbus_read_byte(cpld_client);
>+ if (val < 0)
>+ return val;
>+
>+ if (mux_mode == 1)
>+ val &= ~0x40;
>+ else
>+ val |= 0x40;
>+
>+ err = i2c_smbus_write_byte(cpld_client, val);
>+ if (err)
>+ return err;
>+
>+ value = __raw_readl(base + VIDCLKCTL_OFFSET);
>+ value &= ~(VCH2CLK_MASK);
>+ value &= ~(VCH3CLK_MASK);
>+
>+ if (hd >= 1)
>+ value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
>+ else
>+ value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
>+
>+ __raw_writel(value, base + VIDCLKCTL_OFFSET);
>+
>+ /* enable the clock */
>+ value = __raw_readl(base + VSCLKDIS_OFFSET);
>+ value &= ~(VIDCH3CLK | VIDCH2CLK);
>+ __raw_writel(value, base + VSCLKDIS_OFFSET);
>+
>+ return 0;
>+}
>+
>+static const struct vpif_subdev_info dm64
RE: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board specific setup
Chaithrika, Could you send the patches inline to Russell King r...@arm.linux.org.uk? This was what Mauro had suggested to me. We need to get a resolution on this quickly since I have some patches waiting to be submitted against display driver and would like to base it on your patches. Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com >-Original Message- >From: davinci-linux-open-source-boun...@linux.davincidsp.com >[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf >Of Subrahmanya, Chaithrika >Sent: Monday, August 03, 2009 5:27 AM >To: 'Mauro Carvalho Chehab' >Cc: davinci-linux-open-sou...@linux.davincidsp.com; li...@arm.linux.org.uk; >linux-media@vger.kernel.org >Subject: RE: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board >specific setup > >Mauro, > >OK. Thank you for taking care of this. > >On Mon, Aug 03, 2009 at 11:20:03, Mauro Carvalho Chehab wrote: >> Em Mon, 3 Aug 2009 09:17:06 +0530 >> "chaithrika" escreveu: >> >> > Mauro/Russell, >> > >> > The previous version (v2) of this patch is on the linux-next tree. >> > This patch has some updates done on top of that patch. Should I post >> > an incremental patch for those changes to the Linux-next tree? >> > Please suggest. >> > >> It is not needed. After having Russell ack, I'll just replace the old >patch by the new one. >> >> >> >> Cheers, >> Mauro >> > > >Regards, >Chaithrika > > >___ >Davinci-linux-open-source mailing list >davinci-linux-open-sou...@linux.davincidsp.com >http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
On Tue, Aug 4, 2009 at 4:19 PM, Michael Krufky wrote: > On Tue, Aug 4, 2009 at 3:58 PM, Alex Deucher wrote: >> On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky wrote: >>> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote: On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote: > Mauro, > > Please pull from: > > http://kernellabs.com/hg/~mkrufky/cx23885 > > for the following fixes: > > - cx23885: Enable mplayer pvr:// usage I'm not too familiar with mplayer's v4l support, but why not fix mplayer rather than adding a fake audio interface to the driver. Wouldn't that potentially confuse users or other apps? >>> >>> Thats a good question, Alex. >>> >>> The answer, for now, is conformity amongst the v4l2 drivers. >>> >>> Mplayer has been around for a good long time, and any v4l2 mpeg >>> encoder that doesnt do this is broken in the vraious userspace >>> applications. >>> >>> I agree that we should fix userspace also -- but fix the kernel first, >>> so that older userspace works as-is. >> >> er... yeah, but you are re-enforcing broken behavior, rather than >> "fixing" more drivers, why not submit a mplayer patch and tell users >> they need a newer version of mplayer/etc. to work with their card? >> Otherwise we'll end up with tons of drivers with fake audio interfaces >> and mplayer will never get fixed and users will complain that the >> audio interface doesn't work. > > You don't really have the full picture here, Alex. The applications > expect to see an audio input, and rightfully so. > > This particular driver doesn't expose all of the functionality that is > available from the raw video device onto the encoder device. > > Little by little, we are fixing up the cx23885-417 driver to fully > expose all featuresets, but in the meanwhile, we do what is needed to > make things work. > > The problem is not mplayer, the real problem is incomplete analog > video (and analog audio) support in the cx23885 driver, itself. As > THAT support improves, you will see small hacks like this disappear. Ah, got it. Thanks for the clarification. Alex -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
On Tue, Aug 4, 2009 at 3:58 PM, Alex Deucher wrote: > On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky wrote: >> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote: >>> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote: Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/cx23885 for the following fixes: - cx23885: Enable mplayer pvr:// usage >>> >>> I'm not too familiar with mplayer's v4l support, but why not fix >>> mplayer rather than adding a fake audio interface to the driver. >>> Wouldn't that potentially confuse users or other apps? >> >> Thats a good question, Alex. >> >> The answer, for now, is conformity amongst the v4l2 drivers. >> >> Mplayer has been around for a good long time, and any v4l2 mpeg >> encoder that doesnt do this is broken in the vraious userspace >> applications. >> >> I agree that we should fix userspace also -- but fix the kernel first, >> so that older userspace works as-is. > > er... yeah, but you are re-enforcing broken behavior, rather than > "fixing" more drivers, why not submit a mplayer patch and tell users > they need a newer version of mplayer/etc. to work with their card? > Otherwise we'll end up with tons of drivers with fake audio interfaces > and mplayer will never get fixed and users will complain that the > audio interface doesn't work. You don't really have the full picture here, Alex. The applications expect to see an audio input, and rightfully so. This particular driver doesn't expose all of the functionality that is available from the raw video device onto the encoder device. Little by little, we are fixing up the cx23885-417 driver to fully expose all featuresets, but in the meanwhile, we do what is needed to make things work. The problem is not mplayer, the real problem is incomplete analog video (and analog audio) support in the cx23885 driver, itself. As THAT support improves, you will see small hacks like this disappear. This should be merged. Thanks for the feedback. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linux Plumbers Conference 2009: V4L2 API discussions
Hans, I plan to register for this. Following are some of the issues that I face today while porting TI DaVinci video drivers to open source:- 1) VPBE display drivers (DM6446,DM355 & DM365): Current implementation of display drivers uses encoder manager (encoders registers with this framework) and display manager (allocating video and OSD layers, managing the OSD hardware etc.). Both FBDev and V4l2 bridge drivers interfaces with these for display timing information and resource allocation. The encoders are developed using a encoder interface that are protocol independent vs sub devices framework in open source that are v4l2 specific. The protocol independent interface was used to avoid building v4l2 sub system when using FBDev devices (That driver VPBE). Internal driver uses SysFs interface to change output and standard at the active encoder (Same functionality is removed from v4l2 display device). I plan to discuss this with you in detail so that we could start working on the porting. I will also go through your RFC to find out if any thing is applicable related to this work 2) Previewer & Resizer driver. I am working with Vaibhav who had worked on an RFC for this. The previewer and resizer devices are doing memory to memory operations. Also should be flexible to use these hardware with capture driver to do on the fly preview and resize. The TI hardware is parameter intensive. We believe these parameters are to be exported to user space through IOCTLs and would require addition of new IOCTLs and extension of control IDs. We will be working with you on this as well. 3) Setting up timing information in capture and display sub devices (example for HD resolution capture and display) . I think Your media processor RFC discuss this. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com >-Original Message- >From: davinci-linux-open-source-boun...@linux.davincidsp.com >[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf >Of Hiremath, Vaibhav >Sent: Tuesday, August 04, 2009 1:13 PM >To: Hans Verkuil; linux-media@vger.kernel.org >Cc: Magnus Damm; davinci-linux-open-sou...@linux.davincidsp.com; linux- >o...@vger.kernel.org; eduardo.valen...@nokia.com; Dongsoo, Nathaniel Kim >Subject: RE: Linux Plumbers Conference 2009: V4L2 API discussions > > > >> -Original Message- >> From: davinci-linux-open-source-boun...@linux.davincidsp.com >> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On >> Behalf Of Hans Verkuil >> Sent: Tuesday, August 04, 2009 12:42 PM >> To: linux-media@vger.kernel.org >> Cc: eduardo.valen...@nokia.com; davinci-linux-open- >> sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus >> Damm; Dongsoo, Nathaniel Kim >> Subject: Linux Plumbers Conference 2009: V4L2 API discussions >> >> Hi all, >> >> During this years Plumbers Conference I will be organizing a session >> (or >> possibly more than one) on what sort of new V4L2 APIs are needed to >> support the new SoC devices. These new APIs should also solve the >> problem >> of how to find all the related alsa/fb/ir/dvb devices that a typical >> video >> device might create. >> >> A proposal was made about a year ago (note that this is a bit >> outdated >> by now, but the basics are still valid): >> >> http://www.archivum.info/video4linux-list%40redhat.com/2008- >> 07/msg00371.html >> >> In the past year the v4l2 core has evolved enough so that we can >> finally >> start thinking about this for real. >> >> I would like to know who will be attending this conference. I also >> urge >> anyone who is working in this area and who wants to have a say in >> this to >> attend the conference. The goal is to prepare a new RFC with a >> detailed >> proposal on the new APIs that are needed to fully support all the >> new >> SoCs. So the more input we get, the better the end-result will be. >> >[Hiremath, Vaibhav] Hi Hans, > >I will be attending the conference and along with above mentioned RFC I >would want to discuss some of the open issues, forthcoming TI devices, >their complexity and required software interfaces (media processor (as you >mentioned above)) and similar stuff. > > >I will work with you offline before sharing the details here with the >community. > >Thanks, >Vaibhav Hiremath > >> Early-bird registration is still possible up to August 5th (that's >> tomorrow :-) ). >> >> Regards, >> >> Hans >> >> -- >> Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom >> >> ___ >> Davinci-linux-open-source mailing list >> davinci-linux-open-sou...@linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- >> source >___ >Davinci-linux-open-source mailing list >davinci-linux-open-sou...@linux.davincidsp.com >http://
Re: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky wrote: > On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote: >> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote: >>> Mauro, >>> >>> Please pull from: >>> >>> http://kernellabs.com/hg/~mkrufky/cx23885 >>> >>> for the following fixes: >>> >>> - cx23885: Enable mplayer pvr:// usage >> >> I'm not too familiar with mplayer's v4l support, but why not fix >> mplayer rather than adding a fake audio interface to the driver. >> Wouldn't that potentially confuse users or other apps? > > Thats a good question, Alex. > > The answer, for now, is conformity amongst the v4l2 drivers. > > Mplayer has been around for a good long time, and any v4l2 mpeg > encoder that doesnt do this is broken in the vraious userspace > applications. > > I agree that we should fix userspace also -- but fix the kernel first, > so that older userspace works as-is. er... yeah, but you are re-enforcing broken behavior, rather than "fixing" more drivers, why not submit a mplayer patch and tell users they need a newer version of mplayer/etc. to work with their card? Otherwise we'll end up with tons of drivers with fake audio interfaces and mplayer will never get fixed and users will complain that the audio interface doesn't work. Alex -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote: > On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote: >> Mauro, >> >> Please pull from: >> >> http://kernellabs.com/hg/~mkrufky/cx23885 >> >> for the following fixes: >> >> - cx23885: Enable mplayer pvr:// usage > > I'm not too familiar with mplayer's v4l support, but why not fix > mplayer rather than adding a fake audio interface to the driver. > Wouldn't that potentially confuse users or other apps? Thats a good question, Alex. The answer, for now, is conformity amongst the v4l2 drivers. Mplayer has been around for a good long time, and any v4l2 mpeg encoder that doesnt do this is broken in the vraious userspace applications. I agree that we should fix userspace also -- but fix the kernel first, so that older userspace works as-is. This is needed for more than just mplayer -- mplayer is just the biggest, loudest, most obvious one for mention. Regards, Mike -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885
On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote: > Mauro, > > Please pull from: > > http://kernellabs.com/hg/~mkrufky/cx23885 > > for the following fixes: > > - cx23885: Enable mplayer pvr:// usage I'm not too familiar with mplayer's v4l support, but why not fix mplayer rather than adding a fake audio interface to the driver. Wouldn't that potentially confuse users or other apps? Alex -- 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] Added Support for STK7700D (DVB)
Hello,
To this mail I attached two patch-files to add support for the STK7700D
USB-DVB-Device.
lsusb identifies it as:
idVendor 0x1164 YUAN High-Tech Development Co., Ltd
idProduct 0x1efc
iProduct2 STK7700D
My two patches mainly just add the new product-ID.
I have tested the modification with the 2.6.28 and the 2.6.30 kernel. The
patches are for the 2.6.30 kernel.
The device is build into my laptop (Samsung R55-T5500) and works great after
applying the patches.
Bye
Pete
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-05-25 21:50:09.0 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-06-11 18:08:04.0 +0200
@@ -1493,6 +1493,7 @@
{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_TIGER_ATSC_B210) },
{ USB_DEVICE(USB_VID_YUAN, USB_PID_YUAN_MC770) },
{ USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_DTT) },
+/* 50 */{ USB_DEVICE(USB_VID_YUAN, USB_PID_YUAN_STK7700D) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1812,7 +1813,7 @@
},
},
- .num_device_descs = 7,
+ .num_device_descs = 8,
.devices = {
{ "Terratec Cinergy HT USB XE",
{ &dib0700_usb_id_table[27], NULL },
@@ -1842,6 +1843,11 @@
{ &dib0700_usb_id_table[48], NULL },
{ NULL },
},
+ { "YUAN High-Tech STK7700D",
+{ &dib0700_usb_id_table[50], NULL },
+{ NULL },
+ },
+
},
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dib0700_rc_keys,
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-05-25 21:50:09.0 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-06-23 19:34:20.0 +0200
@@ -245,6 +245,7 @@
#define USB_PID_YUAN_STK7700PH0x1f08
#define USB_PID_YUAN_PD378S0x2edc
#define USB_PID_YUAN_MC7700x0871
+#define USB_PID_YUAN_STK7700D0x1efc
#define USB_PID_DW2102 0x2102
#define USB_PID_XTENSIONS_XD_380 0x0381
#define USB_PID_TELESTAR_STARSTICK_2 0x8000
[PULL] http://kernellabs.com/hg/~mkrufky/cx23885
Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/cx23885 for the following fixes: - cx23885: Enable mplayer pvr:// usage - cx23885-417: Support V4L2 controls as well as MPEG controls cx23885-417.c | 36 cx23885-video.c |2 +- cx23885.h |1 + 3 files changed, 38 insertions(+), 1 deletion(-) Cheers, Mike -- 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: WARNINGS, 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 Aug 4 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12375:b15490457d60 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-rc5-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc5-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc5-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: WARNINGS 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-rc5-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc5-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: WARNINGS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): 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: WARNINGS linux-2.6.21.7-i686: WARNINGS 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: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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 from this daily build 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: Linux Plumbers Conference 2009: V4L2 API discussions
On Tuesday 04 August 2009 09:12:24 Hans Verkuil wrote: > Hi all, > > During this years Plumbers Conference I will be organizing a session (or > possibly more than one) on what sort of new V4L2 APIs are needed to > support the new SoC devices. These new APIs should also solve the problem > of how to find all the related alsa/fb/ir/dvb devices that a typical video > device might create. > > A proposal was made about a year ago (note that this is a bit outdated > by now, but the basics are still valid): > > http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html > > In the past year the v4l2 core has evolved enough so that we can finally > start thinking about this for real. > > I would like to know who will be attending this conference. I also urge > anyone who is working in this area and who wants to have a say in this to > attend the conference. The goal is to prepare a new RFC with a detailed > proposal on the new APIs that are needed to fully support all the new > SoCs. So the more input we get, the better the end-result will be. > > Early-bird registration is still possible up to August 5th (that's > tomorrow :-) ). Just a quick follow-up: I am also attending the co-located LinuxCon (http://events.linuxfoundation.org/events/linuxcon), so I'm in Portland the whole week. If someone is there only for LinuxCon but still wants to discuss something with me, then let me know beforehand. Ditto if you prefer to have some preliminary discussions before the Plumbers Conference starts. I will also update the RFC referred to above and repost it early September. That way we have a proper starting point for our discussions. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
saa7134 module doesn't load under 64 bit slackware
Hello. I'm trying the saa7134 module to load on my laptop, but when I modprobe it, I get this message: $ modprobe saa7134 i2c_scan=1 Killed and dmesg gives Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.14 loaded ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 17 saa7134 :05:02.0: PCI INT A -> Link[LNKD] -> GSI 17 (level, low) -> IRQ 17 saa7133[0]: found at :05:02.0, rev: 209, irq: 17, latency: 64, mmio: 0xdfffd800 saa7133[0]: subsystem: 1461:a836, board: Avermedia M115 [card=138,autodetected] saa7133[0]: board init: gpio is a40 saa7133[0]: i2c eeprom 00: 61 14 36 a8 00 00 00 00 00 00 00 00 00 00 00 00 saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 03 08 ff 00 c0 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 65 00 ff c2 1e ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c scan: found device @ 0xa0 [eeprom] saa7133[0]: i2c scan: found device @ 0xc2 [???] tuner' 3-0061: chip found @ 0xc2 (saa7133[0]) xc2028 3-0061: creating new instance xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner BUG: unable to handle kernel NULL pointer dereference at IP: [<>] 0x0 PGD 7a329067 PUD 7786e067 PMD 0 Oops: 0010 [#1] PREEMPT SMP last sysfs file: /sys/devices/platform/it87.656/temp2_input CPU 0 Modules linked in: tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 saa7134(+) ir_common compat_ioctl32 videodev v4l1_compat v4l2_common videobuf_dma_sg videobuf_core tveeprom nvidia(P) vboxnetflt vboxdrv it87 hwmon_vid snd_usb_audio snd_usb_lib snd_rawmidi snd_seq_device snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd snd_page_alloc rfcomm l2cap bluetooth Pid: 3070, comm: modprobe Tainted: P 2.6.28.4 #6 RIP: 0010:[<>] [<>] 0x0 RSP: 0018:880077b33bd8 EFLAGS: 00010282 RAX: RBX: RCX: RDX: RSI: 0040 RDI: RBP: 880077b64000 R08: 880077b64170 R09: 806135e0 R10: R11: a0d10732 R12: a0ceeea0 R13: 88007f8ec800 R14: 880077b64170 R15: FS: 7fd1691fe6f0() GS:8067a040() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 778f2000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 3070, threadinfo 880077b32000, task 88007ec16750) Stack: 880077b64000 a0cd4288 880077b64170 80424fe2 0001007f 880077b33c2f 007f a0ccbb92 00010011fd7c 80239814 00ff88007ec16750 Call Trace: [] ? i2c_master_recv+0x3a/0x46 [] ? saa7134_i2c_register+0x171/0x1b3 [saa7134] [] ? process_timeout+0x0/0x5 [] ? saa7134_initdev+0x5e1/0x918 [saa7134] [] ? sysfs_do_create_link+0xd0/0x11b [] ? pci_device_probe+0x4c/0x73 [] ? driver_probe_device+0xb5/0x159 [] ? __driver_attach+0x59/0x80 [] ? __driver_attach+0x0/0x80 [] ? bus_for_each_dev+0x44/0x78 [] ? bus_add_driver+0xac/0x1f2 [] ? driver_register+0xa2/0x11f [] ? saa7134_init+0x0/0x4e [saa7134] [] ? __pci_register_driver+0x5d/0x8f [] ? saa7134_init+0x0/0x4e [saa7134] [] ? _stext+0x56/0x14f [] ? sys_init_module+0xa0/0x1a9 [] ? system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [<>] 0x0 RSP CR2: ---[ end trace 6572bfa70bfdf67a ]--- I'm using a self-compiled 2.6.28.4 kernel, on a 64-bit system: $ uname -a Linux swift 2.6.28.4 #6 SMP PREEMPT Wed Feb 18 11:25:30 CET 2009 x86_64 x86_64 x86_64 GNU/Linux Any hint on hwo to solve that? Thanks! -- Fabrice DELENTE -- 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 a
RE: Linux Plumbers Conference 2009: V4L2 API discussions
> -Original Message- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On > Behalf Of Hans Verkuil > Sent: Tuesday, August 04, 2009 12:42 PM > To: linux-media@vger.kernel.org > Cc: eduardo.valen...@nokia.com; davinci-linux-open- > sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus > Damm; Dongsoo, Nathaniel Kim > Subject: Linux Plumbers Conference 2009: V4L2 API discussions > > Hi all, > > During this years Plumbers Conference I will be organizing a session > (or > possibly more than one) on what sort of new V4L2 APIs are needed to > support the new SoC devices. These new APIs should also solve the > problem > of how to find all the related alsa/fb/ir/dvb devices that a typical > video > device might create. > > A proposal was made about a year ago (note that this is a bit > outdated > by now, but the basics are still valid): > > http://www.archivum.info/video4linux-list%40redhat.com/2008- > 07/msg00371.html > > In the past year the v4l2 core has evolved enough so that we can > finally > start thinking about this for real. > > I would like to know who will be attending this conference. I also > urge > anyone who is working in this area and who wants to have a say in > this to > attend the conference. The goal is to prepare a new RFC with a > detailed > proposal on the new APIs that are needed to fully support all the > new > SoCs. So the more input we get, the better the end-result will be. > [Hiremath, Vaibhav] Hi Hans, I will be attending the conference and along with above mentioned RFC I would want to discuss some of the open issues, forthcoming TI devices, their complexity and required software interfaces (media processor (as you mentioned above)) and similar stuff. I will work with you offline before sharing the details here with the community. Thanks, Vaibhav Hiremath > Early-bird registration is still possible up to August 5th (that's > tomorrow :-) ). > > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > > ___ > Davinci-linux-open-source mailing list > davinci-linux-open-sou...@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > source -- 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://www.kernellabs.com/hg/~dheitmueller/geniatech_x8000
Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/geniatech_x8000 for the following: cx88: Disable xc3028 power management for Geniatech x8000 cx88: fix regression in tuning for Geniatech X8000 MT This fixes two regressions - one introduced when the disable_i2c_gate feature was added to zl10353, and a second when the xc3028 power management was added. Both are required for the board to start working again. 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: Hauppauge WinTV usb 1 not working?
Ok, so it is indeed very similar to the USB-live, but with a coax input I guess. Well, what I said before still applies - the 640x480 support was never added to the Linux driver for the usbvision chipset, and it doesn't surprise me that the driver performs poorly for you as it did for me with the USB-live. The driver overall is a mess and I don't foresee anybody spending the cycles to clean it up. Unless you can find someone willing to do the work I would suggest just getting a newer product. Devin Sorry Devin I sent from the wrong account!! Anyhow, it is actually a TV Tuner but I guess the resolution restricts it. What would you suggest as a replacement product for it?? Basically what I need is for it to work globally in compatibility with all analog terrestrial streams and also digital and cable too. The reason for this is I do some traveling at the moment bouncing back and forth between UK and Turkey which I think Turkey is PAL BETA if I'm not mistaken and also since they don't have any digital broadcasting as of yet. They mainly use cable and satellite which they call digital for some strange reason?? Also since I'm done now with my studies and am looking for a job it could mean that it will take me round the world, at least if the offer of UNIX admin comes through for me I could find myself in very exotic places and would be good to have compatibility with that too I was thinking of going for something like the Hauppauge WinTV HVR 900 HD-ready Stick but not sure what the support is or if it is able to do what I need from it?? Also being HD ready does this mean it can handle HD digital broadcasts?? I have heard good things about the WinTV Nova card again from Hauppauge but I think that is only digital TV not analog and won't achieve the results I'm looking for --Kaya -- 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
[Fwd: Re: Hauppauge WinTV usb 1 not working?]
Again apologies for the inconvenience sent from wrong account! --- Begin Message --- It's the top picture/model from this link: http://www.hauppauge.com/site/support/support_main_usb.html --- End Message ---
Re: Hauppauge WinTV usb 1 not working?
It's the top picture/model from this link: http://www.hauppauge.com/site/support/support_main_usb.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
[Fwd: Re: Hauppauge WinTV usb 1 not working?]
Sorry I sent from wrong account please reply back here. --- Begin Message --- Hi Devin, sorry for the late reply had to go out to pick up some groceries! the link is here: http://www.hauppauge.com/site/support/support_usb.html It's the WinTV USB which has USB1.1 compliency and 640x480 res for tv watching although can do full screen on it. Pre WinTV USB2 model :-) -- Kaya --- End Message ---
Re: Hauppauge WinTV usb 1 not working?
Hi Devin, sorry for the late reply had to go out to pick up some groceries! the link is here: http://www.hauppauge.com/site/support/support_usb.html It's the WinTV USB which has USB1.1 compliency and 640x480 res for tv watching although can do full screen on it. Pre WinTV USB2 model :-) -- Kaya -- 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: Hauppauge WinTV usb 1 not working?
On Tue, Aug 4, 2009 at 10:27 AM, Kaya Saman wrote: > Hi Devin, > > sorry for the late reply had to go out to pick up some groceries! > > the link is here: http://www.hauppauge.com/site/support/support_usb.html > > It's the WinTV USB which has USB1.1 compliency and 640x480 res for tv > watching although can do full screen on it. > > Pre WinTV USB2 model :-) Ok, so it is indeed very similar to the USB-live, but with a coax input I guess. Well, what I said before still applies - the 640x480 support was never added to the Linux driver for the usbvision chipset, and it doesn't surprise me that the driver performs poorly for you as it did for me with the USB-live. The driver overall is a mess and I don't foresee anybody spending the cycles to clean it up. Unless you can find someone willing to do the work I would suggest just getting a newer product. 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: RFC: adding ISDB-T/ISDB-Tsb to DVB-API 5
Hi again, I updated some things in the document, please use the following for your comments: Version 1.2 - 2009-08-04 Changelog = v1.2 - 2009-08-04 - removed DTV_BANDWIDTH from being a necessary parameter - now optional v1.1 - 2009-08-04 - added DTV_FREQUENCY as a necessary parameter v1.0 - 2009-08-03 - initial draft Proposal This document describes shortly what are the possible parameters in the Linux DVB-API called "S2API" and now DVB API 5 in order to tune an ISDB-T/ISDB-Tsb demodulator: This ISDB-T/ISDB-Tsb API extension should reflect all information needed to tune any ISDB-T/ISDB-Tsb hardware. Of course it is possible that some very sophisticated devices won't need certain parameters to tune. The information given here should help application writers to know how to handle ISDB-T and ISDB-Tsb hardware using the Linux DVB-API. The details given here about ISDB-T and ISDB-Tsb are just enough to basically show the dependencies between the needed parameter values, but surely some information is left out. For more detailed information see the standard document: ARIB STD-B31 - "Transmission System for Digital Terrestrial Television Broadcasting". In order to read this document one has to know about the channel structure in ISDB-T and ISDB-Tsb. I.e. it has to be known to the reader that an ISDB-T channel consists of 13 segments, that it can have up to 3 layer sharing those segments, and so on. Parameters used by ISDB-T and ISDB-Tsb. Existing parameters === a) DTV_FREQUENCY Central frequency of the channel. For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of the channel which is 6MHz. As in ISDB-Tsb the channel consists of only one or three segments the frequency step is 429kHz, 3*429 respectively. As for ISDB-T the central frequency of the channel is expected. b) DTV_BANDWIDTH_HZ (optional) Possible values: For ISDB-T it should be always 600Hz (6MHz) For ISDB-Tsb it can vary depending on the number of connected segments Note: Hardware specific values might be given here, but standard applications should not bother to set a value to this field as standard demods are ignoring it anyway. Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from other parameters (DTV_ISDBT_SB_SEGMENT_IDX, DTV_ISDBT_SB_SEGMENT_COUNT). c) DTV_DELIVERY_SYSTEM Possible values: SYS_ISDBT d) DTV_TRANSMISSION_MODE ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called 'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K Possible values: TRANSMISSION_MODE_2K, TRANSMISSION_MODE_8K, TRANSMISSION_MODE_AUTO, TRANSMISSION_MODE_4K If DTV_TRANSMISSION_MODE is set the TRANSMISSION_MODE_AUTO the hardware will try to find the correct FFT-size (if capable) and will use TMCC to fill in the missing parameters. TRANSMISSION_MODE_4K is added at the same time as the other new parameters. e) DTV_GUARD_INTERVAL Possible values: GUARD_INTERVAL_1_32, GUARD_INTERVAL_1_16, GUARD_INTERVAL_1_8, GUARD_INTERVAL_1_4, GUARD_INTERVAL_AUTO If DTV_GUARD_INTERVAL is set the GUARD_INTERVAL_AUTO the hardware will try to find the correct guard interval (if capable) and will use TMCC to fill in the missing parameters. New parameters == 1. DTV_ISDBT_PARTIAL_RECEPTION (1b) If DTV_ISDBT_SOUND_BROADCASTING is '0' this bit-field represents whether the channel is in partial reception mode or not. If '1' DTV_ISDBT_LAYERA_* values are assigned to the center segment and DTV_ISDBT_LAYERA_SEGMENT_COUNT has to be '1'. If in addition DTV_ISDBT_SOUND_BROADCASTING is '1' DTV_ISDBT_PARTIAL_RECEPTION represents whether this ISDB-Tsb channel is consisting of one segment and layer or three segments and two layers. Possible values: 0, 1, -1 (AUTO) 2. DTV_ISDBT_SOUND_BROADCASTING (1b) This field represents whether the other DTV_ISDBT_*-parameters are referring to an ISDB-T and an ISDB-Tsb channel. (See also DTV_ISDBT_PARTIAL_RECEPTION). Possible values: 0, 1, -1 (AUTO) 3. DTV_ISDBT_SB_SUBCHANNEL_ID This field only applies if DTV_ISDBT_SOUND_BROADCASTING is '1'. (Note of the author: This might not be the correct description of the SUBCHANNEL-ID in all details, but it is my understanding of the technical background needed to program a device) An ISDB-Tsb channel (1 or 3 segments) can be broadcasted alone or in a set of connected ISDB-Tsb channels. In this set of channels every channel can be received independently. The number of connected ISDB-Tsb segment can vary, e.g. depending on the frequency spectrum bandwidth available. Example: Assume 8 ISDB-Tsb connected segments are broadcasted. The broadcaster has several possibilities to put those channels in the air: Assuming a normal 13-segment ISDB-T spectrum he can align the 8 segments from position 1-8 to 5-13 or anything in between. The underlying layer of segments
Re: [linux-dvb] Recieving DVB-C with DVB-T units
On Tue, 4 Aug 2009, Christian Wattengård wrote: But after doing some research on Wikipedia and such, I can't figure out why a DVB-T unit can't be easily modified to recieve DVB-C? They use the same frequencies, the DVB-T specs support QAM (atleast low QAM). My specific cable network uses 64QAM which the specs apparently supports... So where is the underlying problem? Could somebody be so nice as to explain to me? :) I would put money on it that most cable channels are encrypted. My WinTV-Nova T devices can't handle the encrypted channels on DVB-T so it probably can't handle DVB-C either. Tim W -- Tim Williams BSc MSc MBCS Euromotor Autotrain LLP 58 Jacoby Place Priory Road Edgbaston Birmingham B5 7UW United Kingdom Web : http://www.autotrain.org Tel : +44 (0)121 414 2214 EuroMotor-AutoTrain is a company registered in the UK, Registration number: OC317070.
Re: Hauppauge WinTV usb 1 not working?
On Tue, Aug 4, 2009 at 9:15 AM, Kaya Saman wrote: > When you say that the device doesn't have an onboard tuner you mean that the > machine that it's attached to does the tuning? My card has S-Video, RCA and > Co-Ax inputs > I thought you are talking about this product (which doesn't have a coax input): http://www.hauppauge.com/site/products/data_usblive.html > I think to be honest about the newer models that they are priced similarly?? > I just checked dabs.com since I am in UK and they are round £50-70 which is > what I paid for mine, although the £75 I did pay was only because I got it > at the very expensive shop on my university campus back then! Most of the newer products either are analog/digital hybrid and have support for DVB-T, or they have onboard MPEG encoders, which is why the price is the same or higher. Which product are you actually referring to? Can you send a link? 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: Hauppauge WinTV usb 1 not working?
I can indeed confirm what you are seeing. I tried out the device a few months ago and hit the same results. The maximum capture resolution is 320x200 so it won't work for tvtime, and I did hit intermittent segfaults with other apps. Note that zapping will not work since the device does not have an onboard tuner. It only has composite and s-video inputs. The chipset in question does have support for 640x480, but the driver never had the support added. The device is pretty ancient so I didn't have the time to invest in cleaning up all the bugs I found (and newer USB2 based devices are so cheap I didn't think it was worth the effort). Devin Hmm, ok that makes sense. When you say that the device doesn't have an onboard tuner you mean that the machine that it's attached to does the tuning? My card has S-Video, RCA and Co-Ax inputs I think to be honest about the newer models that they are priced similarly?? I just checked dabs.com since I am in UK and they are round £50-70 which is what I paid for mine, although the £75 I did pay was only because I got it at the very expensive shop on my university campus back then! Kaya -- 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: Hauppauge WinTV usb 1 not working?
On Tue, Aug 4, 2009 at 8:46 AM, Kaya Saman wrote: > Hi, > > I hope I'm in the right place!! > > I have a Hauppauge WinTV usb 1.1 tuner but I don't seem to be able to get it > working. > > I am running Kubuntu 9.04 64-bit edition. > > The tuner detects in the kernel as: > Bus 006 Device 002: ID 0573:4d22 Zoran Co. Personal Media Division > (Nogatech) Hauppauge WinTV-USB II (PAL) Model 566 > > Using the USBVision driver. > > In the kernel using dmesg the tuner is detected as a WinTV Pro?? > > I have tried various apps to watch tv including tvtime, xawtv, and Zapping. > > Running tvtime-scanner gives this output: > > Reading configuration from /etc/tvtime/tvtime.xml > Reading configuration from /home/kaya/.tvtime/tvtime.xml > Scanning using TV standard PAL. > /home/kaya/.tvtime/stationlist.xml: No existing PAL station list "Custom". > > Your capture card driver: USBVision [Hauppauge WinTV USB Pro (PAL > I)/6-2/2313] > does not support full size studio-quality images required by tvtime. > This is true for many low-quality webcams. Please select a > different video device for tvtime to use with the command line > option --device. > > And xawtv and zapping seg fault each time I run them?? > > I have an ancient Hauppauge WinTV/Radio PCI card which uses the bttv driver > and xawtv works fine on it so I'm not sure why this one isn't working. > > Can anyone help at all or suggest something?? > > Many thanks, > > Kaya I can indeed confirm what you are seeing. I tried out the device a few months ago and hit the same results. The maximum capture resolution is 320x200 so it won't work for tvtime, and I did hit intermittent segfaults with other apps. Note that zapping will not work since the device does not have an onboard tuner. It only has composite and s-video inputs. The chipset in question does have support for 640x480, but the driver never had the support added. The device is pretty ancient so I didn't have the time to invest in cleaning up all the bugs I found (and newer USB2 based devices are so cheap I didn't think it was worth the effort). 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: Noisy video with Avermedia AVerTV Digi Volar X HD (AF9015) and mythbuntu 9.04
El Martes, 4 de Agosto de 2009, Cyril Hansen escribió:
> Hi all,
>
> I am trying to solve a noisy video issue with my new avermedia stick
> (AF9015). I am receiving french DVB signal, both SD and HD. Viewing SD
> is annoying, with the occasional video and audio quirk, and HD is
> almost unwatchable.
>
> The same usb stick with another computer and Vista gives a perfect
> image with absolutely no error from the same antenna.
>
> Yesterday I tried to update the drivers from the mercurial tree with no
> change.
>
> I noticed that the firmware available from the Net and Mythbuntu for
> the chip is quite old (2007 ?), so maybe this is the source of my
> problem. I am willing to try to use usbsnoop and the firmware cutter
> from
>
> http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_fi
>les/ if nobody has done it with a recent windows driver.
>
>
> I haven't found any parameter for the module dvb_usb_af9015 : Are they
> any than can be worth to try to fix my issue ?
>
>
> Thank you in advance,
>
> Cyril Hansen
> --
I have problems with some hardware, and the buffersize when the buffersize is
not multiple of TS_PACKET_SIZE.
You can try the attached patch.
Jose Alberto
diff -r b15490457d60 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Sat Aug 01 01:38:01 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Tue Aug 04 13:02:37 2009 +0200
@@ -877,7 +877,7 @@
af9015_config.dual_mode = 0;
} else {
af9015_properties[i].adapter[0].stream.u.bulk.buffersize
-= TS_USB20_MAX_PACKET_SIZE;
+= TS_USB20_FRAME_SIZE;
}
}
@@ -1312,7 +1312,7 @@
.u = {
.bulk = {
.buffersize =
- TS_USB20_MAX_PACKET_SIZE,
+ TS_USB20_FRAME_SIZE,
}
}
},
@@ -1417,7 +1417,7 @@
.u = {
.bulk = {
.buffersize =
- TS_USB20_MAX_PACKET_SIZE,
+ TS_USB20_FRAME_SIZE,
}
}
},
@@ -1523,7 +1523,7 @@
.u = {
.bulk = {
.buffersize =
- TS_USB20_MAX_PACKET_SIZE,
+ TS_USB20_FRAME_SIZE,
}
}
},
[PATCH] Support for Kaiser Baas ExpressCard Dual HD Tuner
Second attempt to support recently purchased Kaiser Baas ExpressCard
Dual HD Tuner. The card is reported as YUAN High-Tech Development Co.,
Ltd STK7700D (lsusb -v attached).
Err, I don't (yet) have a Developer's Certificate of Origin. Would this
mean that someone will (eventually) commit the patch on my behalf?
Signed-off-by: James A Webb
diff -r b15490457d60 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sat Aug 01 01:38:01 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Mon Aug 03 12:11:49 2009 +1000
@@ -1501,6 +1501,7 @@
{ USB_DEVICE(USB_VID_LEADTEK, USB_PID_WINFAST_DTV_DONGLE_H) },
{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_T3) },
{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_T5) },
+ { USB_DEVICE(USB_VID_YUAN, USB_PID_DIBCOM_STK7700DY) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1628,7 +1629,7 @@
}
},
- .num_device_descs = 4,
+ .num_device_descs = 5,
.devices = {
{ "Pinnacle PCTV 2000e",
{ &dib0700_usb_id_table[11], NULL },
@@ -1646,6 +1647,10 @@
{ &dib0700_usb_id_table[14], NULL },
{ NULL },
},
+ { "YUAN High-Tech DiBcom STK7700D",
+{ &dib0700_usb_id_table[54], NULL },
+{ NULL },
+ },
},
diff -r b15490457d60 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Aug 01 01:38:01 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Mon Aug 03 12:11:49 2009 +1000
@@ -91,6 +91,7 @@
#define USB_PID_DIBCOM_STK7700P0x1e14
#define USB_PID_DIBCOM_STK7700P_PC 0x1e78
#define USB_PID_DIBCOM_STK7700D0x1ef0
+#define USB_PID_DIBCOM_STK7700DY 0x1e8c
#define USB_PID_DIBCOM_STK7700_U7000 0x7001
#define USB_PID_DIBCOM_STK7070P0x1ebc
#define USB_PID_DIBCOM_STK7070PD 0x1ebe
Bus 001 Device 004: ID 1164:1e8c YUAN High-Tech Development Co., Ltd
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x1164 YUAN High-Tech Development Co., Ltd
idProduct 0x1e8c
bcdDevice1.00
iManufacturer 1 YUANRD
iProduct2 STK7700D
iSerial 3 01
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x
(Bus Powered)
signature.asc
Description: This is a digitally signed mes
Re: [PATCH] soc-camera: fix recursive locking in .buf_queue()
On Tue, 4 Aug 2009, Antonio Ospite wrote: > On Tue, 4 Aug 2009 11:31:24 +0200 (CEST) > Guennadi Liakhovetski wrote: > > > On Tue, 4 Aug 2009, Antonio Ospite wrote: > > > > > The current patch applies with some fuzzes on vanilla kernels, and it > > > even FAILS to apply for drivers/media/video/sh_mobile_ceu_camera.c in > > > one hunk. > > > > Yes, I'll produce one against vanilla for submission. > > > > Just to make sure you notice: the now unused 'flags' variables can go > away as well. Sure, already gone in my local version:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc-camera: fix recursive locking in .buf_queue()
On Tue, 4 Aug 2009 11:31:24 +0200 (CEST) Guennadi Liakhovetski wrote: > On Tue, 4 Aug 2009, Antonio Ospite wrote: > > > The current patch applies with some fuzzes on vanilla kernels, and it > > even FAILS to apply for drivers/media/video/sh_mobile_ceu_camera.c in > > one hunk. > > Yes, I'll produce one against vanilla for submission. > Just to make sure you notice: the now unused 'flags' variables can go away as well. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpDMjrgGvhrI.pgp Description: PGP signature
Re: [PATCH] soc-camera: fix recursive locking in .buf_queue()
On Tue, 4 Aug 2009, Antonio Ospite wrote: > On Tue, 4 Aug 2009 10:30:47 +0200 (CEST) > Guennadi Liakhovetski wrote: > > > On Tue, 4 Aug 2009, Antonio Ospite wrote: > > > > > verified to be present in linux-2.6.31-rc5, here's some info dumped > > > from RAM, since the machine hangs, sorry if it is not complete but I > > > couldn't get anything better for now, nothing is printed on > > > the screen. > > > > You're right, thanks for the report. Does the patch below fix the problem? > > It only gets a bit tricky in mx3_camera.c, will have to test. > > > > Yes, the patch fixes the problem. Many thanks. > > The current patch applies with some fuzzes on vanilla kernels, and it > even FAILS to apply for drivers/media/video/sh_mobile_ceu_camera.c in > one hunk. Yes, I'll produce one against vanilla for submission. > I hope that this one and also http://patchwork.kernel.org/patch/33960/ > will hit mainline soon. Yes, I pushed that one already: http://linuxtv.org/hg/v4l-dvb/rev/ee62ab3076e1 Will push this one too. 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
Please add patch for support Logitech QuickCam messenger Plus
Hi Please add small patch for support this webcam It is old webcam with Pid/vid = 0x046d 0x08f6 It is supported by current quickcam driver with small patch. Novell ticket - https://bugzilla.novell.com/show_bug.cgi?id=441650 and patch - https://bugzillafiles.novell.org/attachment.cgi?id=297996 -- With MBR Max CCSA/CCSE -- 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] soc-camera: fix recursive locking in .buf_queue()
On Tue, 4 Aug 2009 10:30:47 +0200 (CEST) Guennadi Liakhovetski wrote: > On Tue, 4 Aug 2009, Antonio Ospite wrote: > > > verified to be present in linux-2.6.31-rc5, here's some info dumped > > from RAM, since the machine hangs, sorry if it is not complete but I > > couldn't get anything better for now, nothing is printed on > > the screen. > > You're right, thanks for the report. Does the patch below fix the problem? > It only gets a bit tricky in mx3_camera.c, will have to test. > Yes, the patch fixes the problem. Many thanks. The current patch applies with some fuzzes on vanilla kernels, and it even FAILS to apply for drivers/media/video/sh_mobile_ceu_camera.c in one hunk. I hope that this one and also http://patchwork.kernel.org/patch/33960/ will hit mainline soon. Ciao, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpKr9xknJ74D.pgp Description: PGP signature
[PATCH] soc-camera: fix recursive locking in .buf_queue()
The .buf_queue() V4L2 driver method is called under
spinlock_irqsave(q->irqlock,...), don't take the lock again inside the
function.
Reported-by: Antonio Ospite
Signed-off-by: Guennadi Liakhovetski
---
Subject: Re: [BUG] pxa_camera: possible recursive locking detected
On Tue, 4 Aug 2009, Antonio Ospite wrote:
> Hi,
>
> verified to be present in linux-2.6.31-rc5, here's some info dumped
> from RAM, since the machine hangs, sorry if it is not complete but I
> couldn't get anything better for now, nothing is printed on
> the screen.
You're right, thanks for the report. Does the patch below fix the problem?
It only gets a bit tricky in mx3_camera.c, will have to test.
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 9632cb1..3e95c6d 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -235,6 +235,7 @@ static int mx1_camera_setup_dma(struct mx1_camera_dev
*pcdev)
return ret;
}
+/* Called under spinlock_irqsave(&pcdev->lock, ...) */
static void mx1_videobuf_queue(struct videobuf_queue *vq,
struct videobuf_buffer *vb)
{
@@ -247,8 +248,6 @@ static void mx1_videobuf_queue(struct videobuf_queue *vq,
dev_dbg(icd->dev.parent, "%s (vb=0x%p) 0x%08lx %d\n", __func__,
vb, vb->baddr, vb->bsize);
- spin_lock_irqsave(&pcdev->lock, flags);
-
list_add_tail(&vb->queue, &pcdev->capture);
vb->state = VIDEOBUF_ACTIVE;
@@ -265,8 +264,6 @@ static void mx1_videobuf_queue(struct videobuf_queue *vq,
__raw_writel(temp, pcdev->base + CSICR1);
}
}
-
- spin_unlock_irqrestore(&pcdev->lock, flags);
}
static void mx1_videobuf_release(struct videobuf_queue *vq,
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 6572ce7..1c70165 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -332,7 +332,10 @@ static enum pixel_fmt fourcc_to_ipu_pix(__u32 fourcc)
}
}
-/* Called with .vb_lock held */
+/*
+ * Called with .vb_lock mutex held and
+ * under spinlock_irqsave(&mx3_cam->lock, ...)
+ */
static void mx3_videobuf_queue(struct videobuf_queue *vq,
struct videobuf_buffer *vb)
{
@@ -348,6 +351,8 @@ static void mx3_videobuf_queue(struct videobuf_queue *vq,
dma_cookie_t cookie;
unsigned long flags;
+ BUG_ON(!irqs_disabled());
+
/* This is the configuration of one sg-element */
video->out_pixel_fmt= fourcc_to_ipu_pix(data_fmt->fourcc);
video->out_width= icd->user_width;
@@ -359,8 +364,6 @@ static void mx3_videobuf_queue(struct videobuf_queue *vq,
memset((void *)vb->baddr, 0xaa, vb->bsize);
#endif
- spin_lock_irqsave(&mx3_cam->lock, flags);
-
list_add_tail(&vb->queue, &mx3_cam->capture);
if (!mx3_cam->active) {
@@ -370,7 +373,7 @@ static void mx3_videobuf_queue(struct videobuf_queue *vq,
vb->state = VIDEOBUF_QUEUED;
}
- spin_unlock_irqrestore(&mx3_cam->lock, flags);
+ spin_unlock_irq(&mx3_cam->lock);
cookie = txd->tx_submit(txd);
dev_dbg(icd->dev.parent, "Submitted cookie %d DMA 0x%08x\n",
@@ -381,14 +384,12 @@ static void mx3_videobuf_queue(struct videobuf_queue *vq,
/* Submit error */
vb->state = VIDEOBUF_PREPARED;
- spin_lock_irqsave(&mx3_cam->lock, flags);
+ spin_lock_irq(&mx3_cam->lock);
list_del_init(&vb->queue);
if (mx3_cam->active == buf)
mx3_cam->active = NULL;
-
- spin_unlock_irqrestore(&mx3_cam->lock, flags);
}
/* Called with .vb_lock held */
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 7c86ef9..77be871 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -617,6 +617,7 @@ static void pxa_camera_stop_capture(struct pxa_camera_dev
*pcdev)
dev_dbg(pcdev->soc_host.v4l2_dev.dev, "%s\n", __func__);
}
+/* Called under spinlock_irqsave(&pcdev->lock, ...) */
static void pxa_videobuf_queue(struct videobuf_queue *vq,
struct videobuf_buffer *vb)
{
@@ -629,8 +630,6 @@ static void pxa_videobuf_queue(struct videobuf_queue *vq,
dev_dbg(icd->dev.parent, "%s (vb=0x%p) 0x%08lx %d active=%p\n",
__func__, vb, vb->baddr, vb->bsize, pcdev->active);
- spin_lock_irqsave(&pcdev->lock, flags);
-
list_add_tail(&vb->queue, &pcdev->capture);
vb->state = VIDEOBUF_ACTIVE;
@@ -638,8 +637,6 @@ static void pxa_videobuf_queue(struct videobuf_queue *vq,
if (!pcdev->active)
pxa_camera_start_capture(pcdev);
-
- spin_unlock_irqrestore(&pcdev->lock, flags);
}
static void pxa_videobuf_release(struct videobuf_queue *vq,
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh
Prof Revolution 7301 S2 PCI
Hi I have just receieved a Prof Revolution 7301 S2 PCI dvb-s2 card and cannot get this working. I am using Ubuntu Jaunty. I am very new to Linux and was hoping to get mythtv working with this card. I can see drivers for the 7300 version of the card, but not the 7301. Any help appreciated. Spence -- 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
Noisy video with Avermedia AVerTV Digi Volar X HD (AF9015) and mythbuntu 9.04
Hi all, I am trying to solve a noisy video issue with my new avermedia stick (AF9015). I am receiving french DVB signal, both SD and HD. Viewing SD is annoying, with the occasional video and audio quirk, and HD is almost unwatchable. The same usb stick with another computer and Vista gives a perfect image with absolutely no error from the same antenna. Yesterday I tried to update the drivers from the mercurial tree with no change. I noticed that the firmware available from the Net and Mythbuntu for the chip is quite old (2007 ?), so maybe this is the source of my problem. I am willing to try to use usbsnoop and the firmware cutter from http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_files/ if nobody has done it with a recent windows driver. I haven't found any parameter for the module dvb_usb_af9015 : Are they any than can be worth to try to fix my issue ? Thank you in advance, Cyril Hansen -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux Plumbers Conference 2009: V4L2 API discussions
Hi all, During this years Plumbers Conference I will be organizing a session (or possibly more than one) on what sort of new V4L2 APIs are needed to support the new SoC devices. These new APIs should also solve the problem of how to find all the related alsa/fb/ir/dvb devices that a typical video device might create. A proposal was made about a year ago (note that this is a bit outdated by now, but the basics are still valid): http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html In the past year the v4l2 core has evolved enough so that we can finally start thinking about this for real. I would like to know who will be attending this conference. I also urge anyone who is working in this area and who wants to have a say in this to attend the conference. The goal is to prepare a new RFC with a detailed proposal on the new APIs that are needed to fully support all the new SoCs. So the more input we get, the better the end-result will be. Early-bird registration is still possible up to August 5th (that's tomorrow :-) ). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: Issue with LifeView FlyDVB-T Duo CardBus.
Hi Hermann, the card works fine on win2000 on another pc. The pc with linux installed is a pentium 3 800 mhz with RAM 256 MB: I don't think it's a resources problem because when I launch channels scan ram used is always at 70 MB and CPU is at 25%. The card becomes warm after the use, but not hot. What dou You think about errors in compiling v4l-dvb? And from output of dmesg | grep saa do You think the card has benn well detected or there is something wrong? Thanks a lot for any suggetsion. -- Initial Header --- >From : "hermann pitton" hermann-pit...@arcor.de To : "Francesco Marangoni" fmarang...@libero.it Cc : "linux-media" linux-media@vger.kernel.org Date : Tue, 04 Aug 2009 02:21:38 +0200 Subject : Re: Issue with LifeView FlyDVB-T Duo CardBus. > Hi Francesco, > > Am Montag, den 03.08.2009, 23:49 +0200 schrieb Francesco Marangoni: > > Dear sirs, > > > > I'm not able to make my pcmcia LifeView DVB-T Duo Cardbus working on Ununtu > > 8.04 LTS kernel 2.6.24.24. > > > > The card seems to be detected but the DVB channel detection fails (using > > Kaffeine too). > > > > Here the output of some commands: Can Youhelp me? > > > > france...@ubuntu:~$ lspci > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host > > bridge (rev 03) > > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP > > bridge (rev 03) > > 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) > > 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) > > 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) > > 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > > 00:0a.0 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller > > 00:0a.1 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller > > 00:0b.0 Ethernet controller: 3Com Corporation 3c556 Hurricane CardBus > > [Cyclone] (rev 10) > > 00:0b.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem > > (rev 10) > > 00:0d.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI > > Audio Accelerator > > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M > > AGP 2x (rev 64) > > 02:00.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video > > Broadcast Decoder (rev d0) > > > > france...@ubuntu:~$ dmesg | grep saa | more > > [ 46.176353] saa7130/34: v4l2 driver version 0.2.14 loaded > > [ 46.176618] saa7133[0]: quirk: PCIPCI_NATOMA > > [ 46.176628] saa7133[0]: found at :02:00.0, rev: 208, irq: 10, > > latency: 0, mmio: 0x2400 > > [ 46.176653] saa7133[0]: subsystem: 5168:0502, board: > > LifeView/Typhoon/Genius FlyDVB-T Duo Cardbus [card=60,insmod option] > > [ 46.176681] saa7133[0]: board init: gpio is 821 > > [ 46.280562] saa7133[0]: i2c eeprom 00: 68 51 02 05 54 20 1c 00 43 43 a9 > > 1c 55 d2 b2 92 > > [ 46.280587] saa7133[0]: i2c eeprom 10: 00 ff 22 0f ff 20 ff ff ff ff ff > > ff ff ff ff ff > > [ 46.280607] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 > > aa ff ff ff ff > > [ 46.280627] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff > > ff ff ff ff ff > > [ 46.280646] saa7133[0]: i2c eeprom 40: ff 25 00 c0 ff 10 07 01 c2 96 00 > > 16 22 15 ff ff > > [ 46.280665] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff > > ff ff ff ff ff > > [ 46.280685] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff > > ff ff ff ff ff > > [ 46.280704] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff > > ff ff ff ff ff > > [ 46.321890] saa7133[0]: registered device video0 [v4l2] > > [ 46.321945] saa7133[0]: registered device vbi0 > > [ 46.321996] saa7133[0]: registered device radio0 > > [ 46.609615] saa7133[0]/dvb: no tda827x tuner found at addr: 60 > > [ 46.609624] DVB: registering new adapter (saa7133[0]) > > [ 238.981774] saa7133[0]: dsp access error > > [ 238.981801] saa7133[0]: dsp access error > > [ 238.981820] saa7133[0]: dsp access error > > [ 238.981824] saa7133[0]: dsp access error > > [ 238.981837] saa7133[0]: dsp access error > > [ 238.981841] saa7133[0]: dsp access error > > [ 238.981854] saa7133[0]: dsp access error > > [ 238.981858] saa7133[0]: dsp access error > > [ 238.981871] saa7133[0]: dsp access error > > [ 238.981875] saa7133[0]: dsp access error > > [ 238.981887] saa7133[0]: dsp access error > > [ 238.981892] saa7133[0]: dsp access error > > [ 238.981904] saa7133[0]: dsp access error > > [ 238.981909] saa7133[0]: dsp access error > > [ 238.981921] saa7133[0]: dsp access error > > [ 238.981926] saa7133[0]: dsp access error > > [ 238.981938] saa7133[0]: dsp access error > > [ 238.981942] saa7133[0]: dsp access error > > [ 238.981955] saa7133[0]: dsp access error > > [ 238.981959] saa7133[0]: dsp access error > > [ 238.981972] saa7133[0]/irq[10,76507]: r=0x s=0x DONE_RA0 >
