Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13
Hi Christopher,
On 10/26/2014 01:15 AM, Christopher Neufeld wrote:
> I've been using a PVR-500 to record shows in MythTV, and to capture the VBI
> part of the stream from the standard-definition output of my STB when it
> records high definition. This has worked for about 7 years now.
>
> I recently updated my LinHES MythTV distribution, and part of the update
> involved moving to a new kernel. The old kernel went by the code
> 3.6.7-1-ARCH, while the new one is 3.13.7-2-ARCH.
>
> With the updated kernel, my VBI captures no longer function.
> Standard-definition recordings made from MythTV using the PVR-500 before
> the update have caption data in the stream, those made after do not.
>
> The retrieval of caption data for high-definition shows involves some
> manual scripting to set the modes for the PVR-500, after which I run
> ccextractor on the V4L device node and just pull out the captions data (the
> audio and video being output separately on high-definition outputs of the
> STB, and captured by a HD-PVR).
>
> The script that I use to set up captions invokes this command:
> v4l2-ctl -d --set-fmt-sliced-vbi=cc --set-ctrl=stream_vbi_format=1
>
> This now errors out. Part of that is a parsing bug in v4l2-ctl, it wants
> to see more text after the 'cc'. I can change it to
> v4l2-ctl -d --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
This is a v4l2-ctl bug. I'll fix that asap. But using cc=1 is a valid
workaround.
>
> with this change, it no longer complains about the command line, but it
> errors out in the ioctls. This behaviour is seen with three versions of
> v4l2-ctl: the old one packaged with the old kernel, the new one packaged
> with the newer kernel, and the git-head, compiled against the headers of
> the new kernel.
Are you calling this when MythTV is already running? If nobody else is using
the PVR-500, does it work?
>
> I strace-d the v4l2-ctl command. The relevant output is:
> open("/dev/pvr_500_1", O_RDWR) = 3
> ioctl(3, VIDIOC_QUERYCAP or VT_OPENQRY, 0x7fff836aac10) = 0
> ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
> ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
> brk(0) = 0x12ca000
> brk(0x12eb000) = 0x12eb000
> ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
> <<>>
> ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
> ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = -1 EINVAL (Invalid argument)
> ioctl(3, VIDIOC_S_FMT or VT_RELDISP, 0x62eae0) = -1 EINVAL (Invalid argument)
> fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7fe8233bf000
> write(1, "VIDIOC_S_FMT: failed: Invalid ar"..., 39VIDIOC_S_FMT: failed:
> Invalid argument
> ) = 39
> close(3)= 0
> exit_group(-1) = ?
>
> I did once see VBI data arriving from one of the paired devices in the
> PVR-500, and not from the other. I would guess that to be because it
> started up in that state. When this happened, I ran v4l2-ctl --all on both
> devices, captured the output, and stored it to files. I did not see any
> relevent differences in these outputs, but I present the diff here:
>
> --- file1 2014-10-25 13:40:36.698703171 -0400
> +++ file2 2014-10-25 13:40:41.248614481 -0400
> @@ -1,15 +1,14 @@
> Driver Info (not using libv4l2):
> Driver name : ivtv
> - Card type : WinTV PVR 500 (unit #1)
> - Bus info : PCI::06:08.0
> + Card type : WinTV PVR 500 (unit #2)
> + Bus info : PCI::06:09.0
> Driver version: 3.13.7
> - Capabilities : 0x81070051
> + Capabilities : 0x81030051
> Video Capture
> VBI Capture
> Sliced VBI Capture
> Tuner
> Audio
> - Radio
> Read/Write
> Device Capabilities
> Device Caps : 0x01030001
> @@ -18,7 +17,7 @@
> Audio
> Read/Write
> Priority: 2
> -Frequency for tuner 0: 4148 (259.25 MHz)
> +Frequency for tuner 0: 884 (55.25 MHz)
> Tuner 0:
> Name : ivtv TV Tuner
> Capabilities : 62.5 kHz multi-standard stereo lang1 lang2
> freq-bands
>
>
> The fact that I once saw valid VBI data suggests that the driver is still
> capable of the feature, but something about the ioctl invocations in
> v4l2-ctl and in MythTV 0.27.4 is wrong for getting the driver reliably into
> the state where VBI data is present in the stream coming from the device.
I won't be able to test this myself until next weekend at the earliest.
Andy, are you able to look at this?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordom
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Oct 26 04:00:17 CET 2014 git branch: test git hash: 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-34-g71e642a host hardware: x86_64 host os:3.17-0.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-rc1-i686: ERRORS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-rc1-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
VBI on PVR-500 stopped working between kernels 3.6 and 3.13
I've been using a PVR-500 to record shows in MythTV, and to capture the VBI
part of the stream from the standard-definition output of my STB when it
records high definition. This has worked for about 7 years now.
I recently updated my LinHES MythTV distribution, and part of the update
involved moving to a new kernel. The old kernel went by the code
3.6.7-1-ARCH, while the new one is 3.13.7-2-ARCH.
With the updated kernel, my VBI captures no longer function.
Standard-definition recordings made from MythTV using the PVR-500 before
the update have caption data in the stream, those made after do not.
The retrieval of caption data for high-definition shows involves some
manual scripting to set the modes for the PVR-500, after which I run
ccextractor on the V4L device node and just pull out the captions data (the
audio and video being output separately on high-definition outputs of the
STB, and captured by a HD-PVR).
The script that I use to set up captions invokes this command:
v4l2-ctl -d --set-fmt-sliced-vbi=cc --set-ctrl=stream_vbi_format=1
This now errors out. Part of that is a parsing bug in v4l2-ctl, it wants
to see more text after the 'cc'. I can change it to
v4l2-ctl -d --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
with this change, it no longer complains about the command line, but it
errors out in the ioctls. This behaviour is seen with three versions of
v4l2-ctl: the old one packaged with the old kernel, the new one packaged
with the newer kernel, and the git-head, compiled against the headers of
the new kernel.
I strace-d the v4l2-ctl command. The relevant output is:
open("/dev/pvr_500_1", O_RDWR) = 3
ioctl(3, VIDIOC_QUERYCAP or VT_OPENQRY, 0x7fff836aac10) = 0
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
brk(0) = 0x12ca000
brk(0x12eb000) = 0x12eb000
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
<<>>
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = -1 EINVAL (Invalid argument)
ioctl(3, VIDIOC_S_FMT or VT_RELDISP, 0x62eae0) = -1 EINVAL (Invalid argument)
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fe8233bf000
write(1, "VIDIOC_S_FMT: failed: Invalid ar"..., 39VIDIOC_S_FMT: failed: Invalid
argument
) = 39
close(3)= 0
exit_group(-1) = ?
I did once see VBI data arriving from one of the paired devices in the
PVR-500, and not from the other. I would guess that to be because it
started up in that state. When this happened, I ran v4l2-ctl --all on both
devices, captured the output, and stored it to files. I did not see any
relevent differences in these outputs, but I present the diff here:
--- file1 2014-10-25 13:40:36.698703171 -0400
+++ file2 2014-10-25 13:40:41.248614481 -0400
@@ -1,15 +1,14 @@
Driver Info (not using libv4l2):
Driver name : ivtv
- Card type : WinTV PVR 500 (unit #1)
- Bus info : PCI::06:08.0
+ Card type : WinTV PVR 500 (unit #2)
+ Bus info : PCI::06:09.0
Driver version: 3.13.7
- Capabilities : 0x81070051
+ Capabilities : 0x81030051
Video Capture
VBI Capture
Sliced VBI Capture
Tuner
Audio
- Radio
Read/Write
Device Capabilities
Device Caps : 0x01030001
@@ -18,7 +17,7 @@
Audio
Read/Write
Priority: 2
-Frequency for tuner 0: 4148 (259.25 MHz)
+Frequency for tuner 0: 884 (55.25 MHz)
Tuner 0:
Name : ivtv TV Tuner
Capabilities : 62.5 kHz multi-standard stereo lang1 lang2
freq-bands
The fact that I once saw valid VBI data suggests that the driver is still
capable of the feature, but something about the ioctl invocations in
v4l2-ctl and in MythTV 0.27.4 is wrong for getting the driver reliably into
the state where VBI data is present in the stream coming from the device.
--
Christopher Neufeld
Home page: http://www.cneufeld.ca/neufeld
"Don't edit reality for the sake of simplicity"
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] xc5000: tuner firmware update
From: Richard Vollkommer
- Update the xc5000 tuner firmware to version 1.6.821
- Update the xc5000c tuner firmware to version 4.1.33
Firmware files can be downloaded from:
- http://hauppauge.lightpath.net/software/hvr950q/xc5000c-4.1.33.zip
- http://hauppauge.lightpath.net/software/hvr950q/xc5000-1.6.821.zip
Signed-off-by: Richard Vollkommer
Cc: Devin Heitmueller
Signed-off-by: Michael Ira Krufky
---
drivers/media/tuners/xc5000.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index e44c8ab..fafff4c 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -222,15 +222,15 @@ struct xc5000_fw_cfg {
u8 fw_checksum_supported;
};
-#define XC5000A_FIRMWARE "dvb-fe-xc5000-1.6.114.fw"
-static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
+#define XC5000A_FIRMWARE "dvb-fe-xc5000-1.6.821.fw"
+static const struct xc5000_fw_cfg xc5000a_fw_cfg = {
.name = XC5000A_FIRMWARE,
.size = 12401,
- .pll_reg = 0x806c,
+ .pll_reg = 0x8067,
};
-#define XC5000C_FIRMWARE "dvb-fe-xc5000c-4.1.30.7.fw"
-static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
+#define XC5000C_FIRMWARE "dvb-fe-xc5000c-4.1.33.fw"
+static const struct xc5000_fw_cfg xc5000c_fw_cfg = {
.name = XC5000C_FIRMWARE,
.size = 16497,
.pll_reg = 0x13,
@@ -243,9 +243,9 @@ static inline const struct xc5000_fw_cfg
*xc5000_assign_firmware(int chip_id)
switch (chip_id) {
default:
case XC5000A:
- return &xc5000a_1_6_114;
+ return &xc5000a_fw_cfg;
case XC5000C:
- return &xc5000c_41_024_5;
+ return &xc5000c_fw_cfg;
}
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] xc5000: add IF output level control
From: Richard Vollkommer
Adds control of the IF output level to the xc5000 tuner
configuration structure. Increases the IF level to the
demodulator to fix failure to lock and picture breakup
issues (with the au8522 demodulator, in the case of the
Hauppauge HVR950Q).
This patch works with all XC5000 firmware versions.
Signed-off-by: Richard Vollkommer
Cc: Devin Heitmueller
Signed-off-by: Michael Ira Krufky
---
drivers/media/tuners/xc5000.c | 14 +-
drivers/media/tuners/xc5000.h | 1 +
drivers/media/usb/au0828/au0828-dvb.c | 2 ++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index fafff4c..cd55110 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -62,6 +62,7 @@ struct xc5000_priv {
unsigned int mode;
u8 rf_mode;
u8 radio_input;
+ u16 output_amp;
int chip_id;
u16 pll_register_no;
@@ -744,7 +745,9 @@ static int xc5000_tune_digital(struct dvb_frontend *fe)
return -EIO;
}
- xc_write_reg(priv, XREG_OUTPUT_AMP, 0x8a);
+ dprintk(1, "%s() setting OUTPUT_AMP to 0x%x\n",
+ __func__, priv->output_amp);
+ xc_write_reg(priv, XREG_OUTPUT_AMP, priv->output_amp);
xc_tune_channel(priv, priv->freq_hz, XC_TUNE_DIGITAL);
@@ -1358,6 +1361,9 @@ static int xc5000_set_config(struct dvb_frontend *fe,
void *priv_cfg)
if (p->radio_input)
priv->radio_input = p->radio_input;
+ if (p->output_amp)
+ priv->output_amp = p->output_amp;
+
return 0;
}
@@ -1438,6 +1444,12 @@ struct dvb_frontend *xc5000_attach(struct dvb_frontend
*fe,
it can be overridden if this is a hybrid driver */
priv->chip_id = (cfg->chip_id) ? cfg->chip_id : 0;
+ /* don't override output_amp if it's already been set
+ unless explicitly specified */
+ if ((priv->output_amp == 0) || (cfg->output_amp))
+ /* use default output_amp value if none specified */
+ priv->output_amp = (cfg->output_amp) ? cfg->output_amp : 0x8a;
+
/* Check if firmware has been loaded. It is possible that another
instance of the driver has loaded the firmware.
*/
diff --git a/drivers/media/tuners/xc5000.h b/drivers/media/tuners/xc5000.h
index 7245cae..6aa534f 100644
--- a/drivers/media/tuners/xc5000.h
+++ b/drivers/media/tuners/xc5000.h
@@ -36,6 +36,7 @@ struct xc5000_config {
u32 if_khz;
u8 radio_input;
u16 xtal_khz;
+ u16 output_amp;
int chip_id;
};
diff --git a/drivers/media/usb/au0828/au0828-dvb.c
b/drivers/media/usb/au0828/au0828-dvb.c
index 00ab156..c267d76 100644
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -88,12 +88,14 @@ static struct xc5000_config hauppauge_xc5000a_config = {
.i2c_address = 0x61,
.if_khz = 6000,
.chip_id = XC5000A,
+ .output_amp = 0x8f,
};
static struct xc5000_config hauppauge_xc5000c_config = {
.i2c_address = 0x61,
.if_khz = 6000,
.chip_id = XC5000C,
+ .output_amp = 0x8f,
};
static struct mxl5007t_config mxl5007t_hvr950q_config = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] au8522: improve lock performance with ZeeVee modulators
From: Richard Vollkommer
Improves lock performance with signals from the ZeeVee family
of modulators.
Signed-off-by: Richard Vollkommer
Cc: Devin Heitmueller
Signed-off-by: Michael Ira Krufky
---
drivers/media/dvb-frontends/au8522_dig.c | 117 +--
1 file changed, 110 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/au8522_dig.c
b/drivers/media/dvb-frontends/au8522_dig.c
index a68974f..5d06c99 100644
--- a/drivers/media/dvb-frontends/au8522_dig.c
+++ b/drivers/media/dvb-frontends/au8522_dig.c
@@ -29,6 +29,7 @@
#include "au8522_priv.h"
static int debug;
+static int zv_mode = 1; /* default to on */
#define dprintk(arg...)\
do { if (debug)\
@@ -469,6 +470,87 @@ static struct {
{ 0x8526, 0x01 },
};
+static struct {
+ u16 reg;
+ u16 data;
+} QAM256_mod_tab_zv_mode[] = {
+ { 0x80a3, 0x09 },
+ { 0x80a4, 0x00 },
+ { 0x8081, 0xc4 },
+ { 0x80a5, 0x40 },
+ { 0x80b5, 0xfb },
+ { 0x80b6, 0x8e },
+ { 0x80b7, 0x39 },
+ { 0x80aa, 0x77 },
+ { 0x80ad, 0x77 },
+ { 0x80a6, 0x67 },
+ { 0x8262, 0x20 },
+ { 0x821c, 0x30 },
+ { 0x80b8, 0x3e },
+ { 0x80b9, 0xf0 },
+ { 0x80ba, 0x01 },
+ { 0x80bb, 0x18 },
+ { 0x80bc, 0x50 },
+ { 0x80bd, 0x00 },
+ { 0x80be, 0xea },
+ { 0x80bf, 0xef },
+ { 0x80c0, 0xfc },
+ { 0x80c1, 0xbd },
+ { 0x80c2, 0x1f },
+ { 0x80c3, 0xfc },
+ { 0x80c4, 0xdd },
+ { 0x80c5, 0xaf },
+ { 0x80c6, 0x00 },
+ { 0x80c7, 0x38 },
+ { 0x80c8, 0x30 },
+ { 0x80c9, 0x05 },
+ { 0x80ca, 0x4a },
+ { 0x80cb, 0xd0 },
+ { 0x80cc, 0x01 },
+ { 0x80cd, 0xd9 },
+ { 0x80ce, 0x6f },
+ { 0x80cf, 0xf9 },
+ { 0x80d0, 0x70 },
+ { 0x80d1, 0xdf },
+ { 0x80d2, 0xf7 },
+ { 0x80d3, 0xc2 },
+ { 0x80d4, 0xdf },
+ { 0x80d5, 0x02 },
+ { 0x80d6, 0x9a },
+ { 0x80d7, 0xd0 },
+ { 0x8250, 0x0d },
+ { 0x8251, 0xcd },
+ { 0x8252, 0xe0 },
+ { 0x8253, 0x05 },
+ { 0x8254, 0xa7 },
+ { 0x8255, 0xff },
+ { 0x8256, 0xed },
+ { 0x8257, 0x5b },
+ { 0x8258, 0xae },
+ { 0x8259, 0xe6 },
+ { 0x825a, 0x3d },
+ { 0x825b, 0x0f },
+ { 0x825c, 0x0d },
+ { 0x825d, 0xea },
+ { 0x825e, 0xf2 },
+ { 0x825f, 0x51 },
+ { 0x8260, 0xf5 },
+ { 0x8261, 0x06 },
+ { 0x821a, 0x01 },
+ { 0x8546, 0x40 },
+ { 0x8210, 0x26 },
+ { 0x8211, 0xf6 },
+ { 0x8212, 0x84 },
+ { 0x8213, 0x02 },
+ { 0x8502, 0x01 },
+ { 0x8121, 0x04 },
+ { 0x8122, 0x04 },
+ { 0x852e, 0x10 },
+ { 0x80a4, 0xca },
+ { 0x80a7, 0x40 },
+ { 0x8526, 0x01 },
+};
+
static int au8522_enable_modulation(struct dvb_frontend *fe,
fe_modulation_t m)
{
@@ -495,12 +577,23 @@ static int au8522_enable_modulation(struct dvb_frontend
*fe,
au8522_set_if(fe, state->config->qam_if);
break;
case QAM_256:
- dprintk("%s() QAM 256\n", __func__);
- for (i = 0; i < ARRAY_SIZE(QAM256_mod_tab); i++)
- au8522_writereg(state,
- QAM256_mod_tab[i].reg,
- QAM256_mod_tab[i].data);
- au8522_set_if(fe, state->config->qam_if);
+ if (zv_mode) {
+ dprintk("%s() QAM 256 (zv_mode)\n", __func__);
+ for (i = 0; i < ARRAY_SIZE(QAM256_mod_tab_zv_mode); i++)
+ au8522_writereg(state,
+ QAM256_mod_tab_zv_mode[i].reg,
+ QAM256_mod_tab_zv_mode[i].data);
+ au8522_set_if(fe, state->config->qam_if);
+ msleep(100);
+ au8522_writereg(state, 0x821a, 0x00);
+ } else {
+ dprintk("%s() QAM 256\n", __func__);
+ for (i = 0; i < ARRAY_SIZE(QAM256_mod_tab); i++)
+ au8522_writereg(state,
+ QAM256_mod_tab[i].reg,
+ QAM256_mod_tab[i].data);
+ au8522_set_if(fe, state->config->qam_if);
+ }
break;
default:
dprintk("%s() Invalid modulation\n", __func__);
@@ -537,7 +630,12 @@ static int au8522_set_frontend(struct dvb_frontend *fe)
return ret;
/* Allow the tuner to settle */
- msleep(100);
+ if (zv_mode) {
+ dprintk("%s() increase tuner settling time for zv_mode\n",
+ __func__);
+ msleep(250);
+ } else
+ msleep(100);
au8522_enable_modulation(fe, c->modulation);
@@ -823,6 +921,11 @@
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
Em Wed, 22 Oct 2014 14:26:41 -0500 Pierre-Louis Bossart escreveu: > On 10/21/14, 11:08 AM, Devin Heitmueller wrote: > >> Sorry, I'm not convinced by that. If the device has to be controlled > >> exclusively, the right position is the open/close. Otherwise, the > >> program cannot know when it becomes inaccessible out of sudden during > >> its operation. > > > > I can say that I've definitely seen cases where if you configure a > > device as the "default" capture device in PulseAudio, then pulse will > > continue to capture from it even if you're not actively capturing the > > audio from pulse. I only spotted this because I had a USB analyzer on > > the device and was dumbfounded when the ISOC packets kept arriving > > even after I had closed VLC. > > this seems like a feature, not a bug. PulseAudio starts streaming before > clients push any data and likewise keeps sources active even after for > some time after clients stop recording. Closing VLC in your example > doesn't immediately close the ALSA device. look for > module-suspend-on-idle in your default.pa config file. This could be a feature for an audio capture device that is standalone, but for sure it isn't a feature for an audio capture device where the audio is only available if video is also being streamed. A V4L device with ALSA capture is a different beast than a standalone capture port. In a simplified way, it will basically follow the following state machine: +---+ | start | +---+ | | v ++ | idle | <+ ++ | |^ || || || v| || +---+ | || | configuration | | || +---+ | || || || || || v| || +---+ | || +> | streaming | -+ || | +---+ || |||| |||| |vv| | +---+---++ | +- | 1 | suspended | 2 | -+ +---+---++ 1) start state This is when the V4L2 device gots probed. It checks if the hardware is present and initializes some vars/registers, turning off everything that can be powered down. The tuner on put in sleep mode, analog audio/video decoders and the dvb frontend and demux are also turned off. 2) idle state As the device is powered off, audio won't produce anything. Depending on the device, reading for audio may return a sequence of zeros, or may even fail, as the DMA engine is not ready yet for streaming. Also, the audio mixer is muted, but the audio input switch is on a random state. 2) configuration state When V4L2 node device is opened and configured, the audio mixer will be switched to input audio from the same source of the video stream. The corresponding audio input is also unmuted. Almost all devices have at least two audio/video inputs: TV TUNER and COMPOSITE. Other devices may also have S-VIDEO, COMPOSITE 2, RADIO TUNER, etc. If the device is set on TUNER mode, on modern devices, a tuner firmware will be loaded. That may require a long time. Typically, most devices take 1/2 seconds to load a firmware, but some devices may take up to 30 seconds. The firmware may depend on the TV standard that will be used, so this can't be loaded at driver warm up state. Also, the power consumption of the tuners is high (it can be ~100-200 mW or more when powered, and ~16mW when just I2C is powered). We don't want to keep it powered when the device is not used, as this spends battery. Also, the life of the device reduces a lot if we keep it always powered. During this stage, if an ALSA call is issued, it may interfere at the device settings and/or firmware load, with can cause the audio to fail. On such cases, applications might need to close the V4L2 node and re-open again. 3) streaming state The change to this staging requires a V4L2 ioctl. Please notice, however, that some apps will open the audio device before the V4L2 node, while others will open it after that. In any case, audio will only start to produce data after the V4L2 ioctl at V4L2 that starts the DMA engine there. After that ioctl: - Audio PCM capture will work; - The mixers will be in a good state: unmuted, and switched to the corresponding input as the video stream. If the user wants to do something unusual, like mixing the composite audio input with the tuner audio input, it can use the ALSA mixer for doing that. Otherwise, the only part of the ALSA device that will be used is the PCM engine. 4) streaming->stop trans
[GIT PULL] DVB: add support for LG Electronics LGDT3306A ATSC/QAM-B Demodulator
Mauro, We spoke briefly about the lgdt3306a driver. I've done a lot of cleanup on this driver, starting with checkpatch.pl complaining: total: 495 errors, 313 warnings, 2126 lines checked ... Now checkpatch.pl reports the following: total: 5 errors, 51 warnings, 2138 lines checked consisting of mostly "WARNING: line over 80 characters" This could use a *little* bit more cleanup, but I think it's clean enough to be merged now. The following changes since commit 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c: Merge tag 'v3.18-rc1' into patchwork (2014-10-21 08:32:51 -0200) are available in the git repository at: git://git.linuxtv.org/mkrufky/dvb lgdt3306a for you to fetch changes up to b5bf818584a22a9271c78fc18ca9cd44d36266ec: lgdt3306a: more small whitespace cleanups (2014-10-25 10:26:15 -0400) Fred Richter (1): DVB: add support for LG Electronics LGDT3306A ATSC/QAM-B Demodulator Michael Ira Krufky (9): lgdt3306a: clean up whitespace & unneeded brackets lgdt3306a: remove unnecessary 'else' lgdt3306a: fix WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable lgdt3306a: fix ERROR: do not use assignment in if condition lgdt3306a: do not add new typedefs lgdt3306a: fix ERROR: do not use C99 // comments lgdt3306a: fix WARNING: please, no spaces at the start of a line lgdt3306a: fix WARNING: 'supress' may be misspelled - perhaps 'suppress'? lgdt3306a: more small whitespace cleanups drivers/media/dvb-frontends/Kconfig |8 + drivers/media/dvb-frontends/Makefile|1 + drivers/media/dvb-frontends/lgdt3306a.c | 2035 ++ drivers/media/dvb-frontends/lgdt3306a.h | 82 ++ 4 files changed, 2126 insertions(+) create mode 100644 drivers/media/dvb-frontends/lgdt3306a.c create mode 100644 drivers/media/dvb-frontends/lgdt3306a.h 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
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
(re-sending from my other e-mail - somehow, the email I sent via m.che...@samsung.com doesn't seem to be delivered at vger.kernel.org) Em Wed, 22 Oct 2014 14:26:41 -0500 Pierre-Louis Bossart escreveu: > On 10/21/14, 11:08 AM, Devin Heitmueller wrote: > >> Sorry, I'm not convinced by that. If the device has to be controlled > >> exclusively, the right position is the open/close. Otherwise, the > >> program cannot know when it becomes inaccessible out of sudden during > >> its operation. > > > > I can say that I've definitely seen cases where if you configure a > > device as the "default" capture device in PulseAudio, then pulse will > > continue to capture from it even if you're not actively capturing the > > audio from pulse. I only spotted this because I had a USB analyzer on > > the device and was dumbfounded when the ISOC packets kept arriving > > even after I had closed VLC. > > this seems like a feature, not a bug. PulseAudio starts streaming before > clients push any data and likewise keeps sources active even after for > some time after clients stop recording. Closing VLC in your example > doesn't immediately close the ALSA device. look for > module-suspend-on-idle in your default.pa config file. This could be a feature for an audio capture device that is standalone, but for sure it isn't a feature for an audio capture device where the audio is only available if video is also being streamed. A V4L device with ALSA capture is a different beast than a standalone capture port. In a simplified way, it will basically follow the following state machine: +---+ | start | +---+ | | v ++ | idle | <+ ++ | |^ || || || v| || +---+ | || | configuration | | || +---+ | || || || || || v| || +---+ | || +> | streaming | -+ || | +---+ || |||| |||| |vv| | +---+---++ | +- | 1 | suspended | 2 | -+ +---+---++ 1) start state This is when the V4L2 device gots probed. It checks if the hardware is present and initializes some vars/registers, turning off everything that can be powered down. The tuner on put in sleep mode, analog audio/video decoders and the dvb frontend and demux are also turned off. 2) idle state As the device is powered off, audio won't produce anything. Depending on the device, reading for audio may return a sequence of zeros, or may even fail, as the DMA engine is not ready yet for streaming. Also, the audio mixer is muted, but the audio input switch is on a random state. 2) configuration state When V4L2 node device is opened and configured, the audio mixer will be switched to input audio from the same source of the video stream. The corresponding audio input is also unmuted. Almost all devices have at least two audio/video inputs: TV TUNER and COMPOSITE. Other devices may also have S-VIDEO, COMPOSITE 2, RADIO TUNER, etc. If the device is set on TUNER mode, on modern devices, a tuner firmware will be loaded. That may require a long time. Typically, most devices take 1/2 seconds to load a firmware, but some devices may take up to 30 seconds. The firmware may depend on the TV standard that will be used, so this can't be loaded at driver warm up state. Also, the power consumption of the tuners is high (it can be ~100-200 mW or more when powered, and ~16mW when just I2C is powered). We don't want to keep it powered when the device is not used, as this spends battery. Also, the life of the device reduces a lot if we keep it always powered. During this stage, if an ALSA call is issued, it may interfere at the device settings and/or firmware load, with can cause the audio to fail. On such cases, applications might need to close the V4L2 node and re-open again. 3) streaming state The change to this staging requires a V4L2 ioctl. Please notice, however, that some apps will open the audio device before the V4L2 node, while others will open it after that. In any case, audio will only start to produce data after the V4L2 ioctl at V4L2 that starts the DMA engine there. After that ioctl: - Audio PCM capture will work; - The mixers will be in a good state: unmuted, and switched to the corresponding input as the video stream. If the user wants to do something unusual, like mixing the composite audio input with the tuner audio input, it can use
Re: [PATCH v2 1/2] [media] rc-core: fix protocol_change regression in ir_raw_event_register
On Tue, Oct 21, 2014 at 09:30:17PM +0300, Tomas Melin wrote:
>IR reciever using nuvoton-cir and lirc required additional configuration
>steps after upgrade from kernel 3.16 to 3.17-rcX.
>Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b
>("[media] rc-core: simplify sysfs code").
>
>The regression comes from adding empty function change_protocol in
>ir-raw.c. It changes behaviour so that only the protocol enabled by driver's
>map_name will be active after registration. This breaks user space behaviour,
>lirc does not get key press signals anymore.
>
>Changed back to original behaviour by removing empty function
>change_protocol in ir-raw.c. Instead only calling change_protocol for
Wouldn't something like this be a simpler way of achieving the same
result? (untested):
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a7991c7..d521f20 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1421,6 +1421,9 @@ int rc_register_device(struct rc_dev *dev)
if (dev->change_protocol) {
u64 rc_type = (1 << rc_map->rc_type);
+ if (dev->driver_type == RC_DRIVER_IR_RAW)
+ rc_type |= RC_BIT_LIRC;
+
rc = dev->change_protocol(dev, &rc_type);
if (rc < 0)
goto out_raw;
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
(re-sending from my third e-mail - somehow, the two emails I have at Samsung didn't seem to be delivering to vger.kernel.org today) Em Wed, 22 Oct 2014 14:26:41 -0500 Pierre-Louis Bossart escreveu: > On 10/21/14, 11:08 AM, Devin Heitmueller wrote: > >> Sorry, I'm not convinced by that. If the device has to be controlled > >> exclusively, the right position is the open/close. Otherwise, the > >> program cannot know when it becomes inaccessible out of sudden during > >> its operation. > > > > I can say that I've definitely seen cases where if you configure a > > device as the "default" capture device in PulseAudio, then pulse will > > continue to capture from it even if you're not actively capturing the > > audio from pulse. I only spotted this because I had a USB analyzer on > > the device and was dumbfounded when the ISOC packets kept arriving > > even after I had closed VLC. > > this seems like a feature, not a bug. PulseAudio starts streaming before > clients push any data and likewise keeps sources active even after for > some time after clients stop recording. Closing VLC in your example > doesn't immediately close the ALSA device. look for > module-suspend-on-idle in your default.pa config file. This could be a feature for an audio capture device that is standalone, but for sure it isn't a feature for an audio capture device where the audio is only available if video is also being streamed. A V4L device with ALSA capture is a different beast than a standalone capture port. In a simplified way, it will basically follow the following state machine: +---+ | start | +---+ | | v ++ | idle | <+ ++ | |^ || || || v| || +---+ | || | configuration | | || +---+ | || || || || || v| || +---+ | || +> | streaming | -+ || | +---+ || |||| |||| |vv| | +---+---++ | +- | 1 | suspended | 2 | -+ +---+---++ 1) start state This is when the V4L2 device gots probed. It checks if the hardware is present and initializes some vars/registers, turning off everything that can be powered down. The tuner on put in sleep mode, analog audio/video decoders and the dvb frontend and demux are also turned off. 2) idle state As the device is powered off, audio won't produce anything. Depending on the device, reading for audio may return a sequence of zeros, or may even fail, as the DMA engine is not ready yet for streaming. Also, the audio mixer is muted, but the audio input switch is on a random state. 2) configuration state When V4L2 node device is opened and configured, the audio mixer will be switched to input audio from the same source of the video stream. The corresponding audio input is also unmuted. Almost all devices have at least two audio/video inputs: TV TUNER and COMPOSITE. Other devices may also have S-VIDEO, COMPOSITE 2, RADIO TUNER, etc. If the device is set on TUNER mode, on modern devices, a tuner firmware will be loaded. That may require a long time. Typically, most devices take 1/2 seconds to load a firmware, but some devices may take up to 30 seconds. The firmware may depend on the TV standard that will be used, so this can't be loaded at driver warm up state. Also, the power consumption of the tuners is high (it can be ~100-200 mW or more when powered, and ~16mW when just I2C is powered). We don't want to keep it powered when the device is not used, as this spends battery. Also, the life of the device reduces a lot if we keep it always powered. During this stage, if an ALSA call is issued, it may interfere at the device settings and/or firmware load, with can cause the audio to fail. On such cases, applications might need to close the V4L2 node and re-open again. 3) streaming state The change to this staging requires a V4L2 ioctl. Please notice, however, that some apps will open the audio device before the V4L2 node, while others will open it after that. In any case, audio will only start to produce data after the V4L2 ioctl at V4L2 that starts the DMA engine there. After that ioctl: - Audio PCM capture will work; - The mixers will be in a good state: unmuted, and switched to the corresponding input as the video stream. If the user wants to do something unusual, like mixing the composite audio input with the tuner audio input, it can use the
