[PATCH 10/24] au8522: fix regression in logging introduced by separation of modules

[Devin Heitmueller]

The au8522 driver was broken into three modules (dig, decoder, common), and
as a result the debug modprobe option doesn't work for any of the common
functions.

Copy the module macros over to the common module so that the debug option
works again.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb/frontends/au8522_common.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/frontends/au8522_common.c 
b/drivers/media/dvb/frontends/au8522_common.c
index 5cfe151..8b4da40 100644
--- a/drivers/media/dvb/frontends/au8522_common.c
+++ b/drivers/media/dvb/frontends/au8522_common.c
@@ -26,8 +26,6 @@
 #include "dvb_frontend.h"
 #include "au8522_priv.h"
 
-MODULE_LICENSE("GPL");
-
 static int debug;
 
 #define dprintk(arg...)\
@@ -257,3 +255,10 @@ int au8522_sleep(struct dvb_frontend *fe)
return 0;
 }
 EXPORT_SYMBOL(au8522_sleep);
+
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Enable verbose debug messages");
+
+MODULE_DESCRIPTION("Auvitek AU8522 QAM-B/ATSC Demodulator driver");
+MODULE_AUTHOR("Steven Toth");
+MODULE_LICENSE("GPL");
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/24] au0828: fix race condition that causes xc5000 to not bind for digital

[Devin Heitmueller]

In some cases users would see the xc5000_attach() call failing for the
digital side of the tuner on initialization.  This is because of udev
running v4l-id while the digital side of the board is still coming up.

This is the exact same race condition which was present in em28xx (not
surprising since I copied all the locking logic from that driver when I
added analog support).  Reproduce Mauro's fix from the em28xx driver in
au0828.

Reported-by: Rick Harding 
Signed-off-by: Devin Heitmueller 
---
 drivers/media/video/au0828/au0828-core.c  |5 +
 drivers/media/video/au0828/au0828-video.c |   21 -
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/media/video/au0828/au0828-core.c 
b/drivers/media/video/au0828/au0828-core.c
index 1e4ce50..b2c4254 100644
--- a/drivers/media/video/au0828/au0828-core.c
+++ b/drivers/media/video/au0828/au0828-core.c
@@ -205,6 +205,8 @@ static int au0828_usb_probe(struct usb_interface *interface,
return -ENOMEM;
}
 
+   mutex_init(&dev->lock);
+   mutex_lock(&dev->lock);
mutex_init(&dev->mutex);
mutex_init(&dev->dvb.lock);
dev->usbdev = usbdev;
@@ -215,6 +217,7 @@ static int au0828_usb_probe(struct usb_interface *interface,
if (retval) {
printk(KERN_ERR "%s() v4l2_device_register failed\n",
   __func__);
+   mutex_unlock(&dev->lock);
kfree(dev);
return -EIO;
}
@@ -245,6 +248,8 @@ static int au0828_usb_probe(struct usb_interface *interface,
printk(KERN_INFO "Registered device AU0828 [%s]\n",
dev->board.name == NULL ? "Unset" : dev->board.name);
 
+   mutex_unlock(&dev->lock);
+
return 0;
 }
 
diff --git a/drivers/media/video/au0828/au0828-video.c 
b/drivers/media/video/au0828/au0828-video.c
index 6e30c09..b1f8d18 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -864,17 +864,15 @@ static int res_get(struct au0828_fh *fh, unsigned int bit)
return 1;
 
/* is it free? */
-   mutex_lock(&dev->lock);
if (dev->resources & bit) {
/* no, someone else uses it */
-   mutex_unlock(&dev->lock);
return 0;
}
/* it's free, grab it */
fh->resources  |= bit;
dev->resources |= bit;
dprintk(1, "res: get %d\n", bit);
-   mutex_unlock(&dev->lock);
+
return 1;
 }
 
@@ -894,11 +892,9 @@ static void res_free(struct au0828_fh *fh, unsigned int 
bits)
 
BUG_ON((fh->resources & bits) != bits);
 
-   mutex_lock(&dev->lock);
fh->resources  &= ~bits;
dev->resources &= ~bits;
dprintk(1, "res: put %d\n", bits);
-   mutex_unlock(&dev->lock);
 }
 
 static int get_ressource(struct au0828_fh *fh)
@@ -1023,7 +1019,8 @@ static int au0828_v4l2_open(struct file *filp)
NULL, &dev->slock,
V4L2_BUF_TYPE_VIDEO_CAPTURE,
V4L2_FIELD_INTERLACED,
-   sizeof(struct au0828_buffer), fh, NULL);
+   sizeof(struct au0828_buffer), fh,
+   &dev->lock);
 
/* VBI Setup */
dev->vbi_width = 720;
@@ -1032,8 +1029,8 @@ static int au0828_v4l2_open(struct file *filp)
NULL, &dev->slock,
V4L2_BUF_TYPE_VBI_CAPTURE,
V4L2_FIELD_SEQ_TB,
-   sizeof(struct au0828_buffer), fh, NULL);
-
+   sizeof(struct au0828_buffer), fh,
+   &dev->lock);
return ret;
 }
 
@@ -1312,8 +1309,6 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
if (rc < 0)
return rc;
 
-   mutex_lock(&dev->lock);
-
if (videobuf_queue_is_busy(&fh->vb_vidq)) {
printk(KERN_INFO "%s queue busy\n", __func__);
rc = -EBUSY;
@@ -1322,7 +1317,6 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
 
rc = au0828_set_format(dev, VIDIOC_S_FMT, f);
 out:
-   mutex_unlock(&dev->lock);
return rc;
 }
 
@@ -1832,7 +1826,7 @@ static struct v4l2_file_operations au0828_v4l_fops = {
.read   = au0828_v4l2_read,
.poll   = au0828_v4l2_poll,
.mmap   = au0828_v4l2_mmap,
-   .ioctl  = video_ioctl2,
+   .unlocked_ioctl = video_ioctl2,
 };
 
 static const struct v4l2_ioctl_ops video_ioctl_ops = {
@@ -1922,7 +1916,6 @@ int au0828

[PATCH 07/24] xc5000: properly report i2c write failures

[Devin Heitmueller]

The logic as written would *never* actually return an error condition, since
the loop would run until the counter hit zero but the check was for a value
less than zero.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/common/tuners/xc5000.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/common/tuners/xc5000.c 
b/drivers/media/common/tuners/xc5000.c
index f660e33..a7fa17e 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -341,7 +341,7 @@ static int xc_write_reg(struct xc5000_priv *priv, u16 
regAddr, u16 i2cData)
}
}
}
-   if (WatchDogTimer < 0)
+   if (WatchDogTimer <= 0)
result = XC_RESULT_I2C_WRITE_FAILURE;
 
return result;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/24] xc5000: properly show quality register values

[Devin Heitmueller]

The quality register only has relevant data in bits 2-0, so discard the
other bits (which results in a value being printed that is consistent with
the expected 0-7 range).

Signed-off-by: Devin Heitmueller 
---
 drivers/media/common/tuners/xc5000.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/common/tuners/xc5000.c 
b/drivers/media/common/tuners/xc5000.c
index dcca42c..c41f2b9 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -684,7 +684,7 @@ static void xc_debug_dump(struct xc5000_priv *priv)
dprintk(1, "*** Frame lines = %d\n", frame_lines);
 
xc_get_quality(priv,  &quality);
-   dprintk(1, "*** Quality (0:<8dB, 7:>56dB) = %d\n", quality);
+   dprintk(1, "*** Quality (0:<8dB, 7:>56dB) = %d\n", quality & 0x07);
 }
 
 static int xc5000_set_params(struct dvb_frontend *fe)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/24] au0828: Make the s_reg and g_reg advanced debug calls work against the bridge

[Devin Heitmueller]

The g_reg and s_reg calls worked properly if acting on subdev registers (such
as the au8522), but didn't work against the au0828 itself.  Copy the logic
over from em28xx.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/video/au0828/au0828-video.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/au0828/au0828-video.c 
b/drivers/media/video/au0828/au0828-video.c
index ac3dd73..6e30c09 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -1717,8 +1717,12 @@ static int vidioc_g_register(struct file *file, void 
*priv,
v4l2_device_call_all(&dev->v4l2_dev, 0, core, g_register, reg);
return 0;
default:
-   return -EINVAL;
+   if (!v4l2_chip_match_host(®->match))
+   return -EINVAL;
}
+
+   reg->val = au0828_read(dev, reg->reg);
+   return 0;
 }
 
 static int vidioc_s_register(struct file *file, void *priv,
@@ -1732,9 +1736,10 @@ static int vidioc_s_register(struct file *file, void 
*priv,
v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_register, reg);
return 0;
default:
-   return -EINVAL;
+   if (!v4l2_chip_match_host(®->match))
+   return -EINVAL;
}
-   return 0;
+   return au0828_writereg(dev, reg->reg, reg->val);
 }
 #endif
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/24] au8522: Fix off-by-one in SNR table for QAM256

[Devin Heitmueller]

The table of valid SNR values for QAM 256 is off by one, and as a result if
the SNR is oscillating between 40.0 and 39.9 dB, tools like azap show it
going back and forth between 40.0 and 0 (misleading some people, including
myself, to think signal lock is being lost or there is a problem with register
reads).

Fix the table so that 40.0 dB is properly represented.

Cc: Steven Toth 
Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb/frontends/au8522_dig.c |   96 +++---
 1 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/drivers/media/dvb/frontends/au8522_dig.c 
b/drivers/media/dvb/frontends/au8522_dig.c
index 5fc70d6..ee8cf81 100644
--- a/drivers/media/dvb/frontends/au8522_dig.c
+++ b/drivers/media/dvb/frontends/au8522_dig.c
@@ -157,54 +157,54 @@ static struct mse2snr_tab qam64_mse2snr_tab[] = {
 
 /* QAM256 SNR lookup table */
 static struct mse2snr_tab qam256_mse2snr_tab[] = {
-   {  16,   0 },
-   {  17, 400 },
-   {  18, 398 },
-   {  19, 396 },
-   {  20, 394 },
-   {  21, 392 },
-   {  22, 390 },
-   {  23, 388 },
-   {  24, 386 },
-   {  25, 384 },
-   {  26, 382 },
-   {  27, 380 },
-   {  28, 379 },
-   {  29, 378 },
-   {  30, 377 },
-   {  31, 376 },
-   {  32, 375 },
-   {  33, 374 },
-   {  34, 373 },
-   {  35, 372 },
-   {  36, 371 },
-   {  37, 370 },
-   {  38, 362 },
-   {  39, 354 },
-   {  40, 346 },
-   {  41, 338 },
-   {  42, 330 },
-   {  43, 328 },
-   {  44, 326 },
-   {  45, 324 },
-   {  46, 322 },
-   {  47, 320 },
-   {  48, 319 },
-   {  49, 318 },
-   {  50, 317 },
-   {  51, 316 },
-   {  52, 315 },
-   {  53, 314 },
-   {  54, 313 },
-   {  55, 312 },
-   {  56, 311 },
-   {  57, 310 },
-   {  58, 308 },
-   {  59, 306 },
-   {  60, 304 },
-   {  61, 302 },
-   {  62, 300 },
-   {  63, 298 },
+   {  15,   0 },
+   {  16, 400 },
+   {  17, 398 },
+   {  18, 396 },
+   {  19, 394 },
+   {  20, 392 },
+   {  21, 390 },
+   {  22, 388 },
+   {  23, 386 },
+   {  24, 384 },
+   {  25, 382 },
+   {  26, 380 },
+   {  27, 379 },
+   {  28, 378 },
+   {  29, 377 },
+   {  30, 376 },
+   {  31, 375 },
+   {  32, 374 },
+   {  33, 373 },
+   {  34, 372 },
+   {  35, 371 },
+   {  36, 370 },
+   {  37, 362 },
+   {  38, 354 },
+   {  39, 346 },
+   {  40, 338 },
+   {  41, 330 },
+   {  42, 328 },
+   {  43, 326 },
+   {  44, 324 },
+   {  45, 322 },
+   {  46, 320 },
+   {  47, 319 },
+   {  48, 318 },
+   {  49, 317 },
+   {  50, 316 },
+   {  51, 315 },
+   {  52, 314 },
+   {  53, 313 },
+   {  54, 312 },
+   {  55, 311 },
+   {  56, 310 },
+   {  57, 308 },
+   {  58, 306 },
+   {  59, 304 },
+   {  60, 302 },
+   {  61, 300 },
+   {  62, 298 },
{  65, 295 },
{  68, 294 },
{  70, 293 },
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/24] au8522: fix intermittent lockup of analog video decoder

[Devin Heitmueller]

It turns up the autodetection for the video standard in the au8522 is prone
to hanging the chip until a reset is performed.  This condition is trivial
to reproduce simply by tuning to a station and then rapidly unplugging/
replugging the coax feed.

Because we've never claimed to support anything other than NTSC-M, just
disable the video-standard autodetection logic and force it to always be
NTSC-M.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb/frontends/au8522_decoder.c |6 +++-
 drivers/media/dvb/frontends/au8522_priv.h|   28 +++--
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb/frontends/au8522_decoder.c 
b/drivers/media/dvb/frontends/au8522_decoder.c
index 55b6390..f2e786b 100644
--- a/drivers/media/dvb/frontends/au8522_decoder.c
+++ b/drivers/media/dvb/frontends/au8522_decoder.c
@@ -257,9 +257,11 @@ static void setup_decoder_defaults(struct au8522_state 
*state, u8 input_mode)
au8522_writereg(state, AU8522_TVDED_DBG_MODE_REG060H,
AU8522_TVDED_DBG_MODE_REG060H_CVBS);
au8522_writereg(state, AU8522_TVDEC_FORMAT_CTRL1_REG061H,
-   AU8522_TVDEC_FORMAT_CTRL1_REG061H_CVBS13);
+   AU8522_TVDEC_FORMAT_CTRL1_REG061H_FIELD_LEN_525 |
+   AU8522_TVDEC_FORMAT_CTRL1_REG061H_LINE_LEN_63_492 |
+   AU8522_TVDEC_FORMAT_CTRL1_REG061H_SUBCARRIER_NTSC_MN);
au8522_writereg(state, AU8522_TVDEC_FORMAT_CTRL2_REG062H,
-   AU8522_TVDEC_FORMAT_CTRL2_REG062H_CVBS13);
+   AU8522_TVDEC_FORMAT_CTRL2_REG062H_STD_NTSC);
au8522_writereg(state, AU8522_TVDEC_VCR_DET_LLIM_REG063H,
AU8522_TVDEC_VCR_DET_LLIM_REG063H_CVBS);
au8522_writereg(state, AU8522_TVDEC_VCR_DET_HLIM_REG064H,
diff --git a/drivers/media/dvb/frontends/au8522_priv.h 
b/drivers/media/dvb/frontends/au8522_priv.h
index 6e4a438..9f44a7b 100644
--- a/drivers/media/dvb/frontends/au8522_priv.h
+++ b/drivers/media/dvb/frontends/au8522_priv.h
@@ -325,6 +325,31 @@ int au8522_led_ctrl(struct au8522_state *state, int led);
 
 /**/
 
+/* Format control 1 */
+
+/* VCR Mode 7-6 */
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_VCR_MODE_YES 0x80
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_VCR_MODE_NO  0x40
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_VCR_MODE_AUTO0x00
+/* Field len 5-4 */
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_FIELD_LEN_6250x20
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_FIELD_LEN_5250x10
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_FIELD_LEN_AUTO   0x00
+/* Line len (us) 3-2 */
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_LINE_LEN_64_000  0x0b
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_LINE_LEN_63_492  0x08
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_LINE_LEN_63_556  0x04
+/* Subcarrier freq 1-0 */
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_SUBCARRIER_NTSC_AUTO 0x03
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_SUBCARRIER_NTSC_443  0x02
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_SUBCARRIER_NTSC_MN   0x01
+#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_SUBCARRIER_NTSC_50   0x00
+
+/* Format control 2 */
+#define AU8522_TVDEC_FORMAT_CTRL2_REG062H_STD_AUTODETECT   0x00
+#define AU8522_TVDEC_FORMAT_CTRL2_REG062H_STD_NTSC 0x01
+
+
 #define AU8522_INPUT_CONTROL_REG081H_ATSC  0xC4
 #define AU8522_INPUT_CONTROL_REG081H_ATVRF 0xC4
 #define AU8522_INPUT_CONTROL_REG081H_ATVRF13   0xC4
@@ -385,9 +410,6 @@ int au8522_led_ctrl(struct au8522_state *state, int led);
 #define AU8522_TVDEC_COMB_MODE_REG015H_CVBS0x00
 #define AU8522_REG016H_CVBS0x00
 #define AU8522_TVDED_DBG_MODE_REG060H_CVBS 0x00
-#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_CVBS 0x0B
-#define AU8522_TVDEC_FORMAT_CTRL1_REG061H_CVBS13   0x03
-#define AU8522_TVDEC_FORMAT_CTRL2_REG062H_CVBS13   0x00
 #define AU8522_TVDEC_VCR_DET_LLIM_REG063H_CVBS 0x19
 #define AU8522_REG0F9H_AUDIO   0x20
 #define AU8522_TVDEC_VCR_DET_HLIM_REG064H_CVBS 0xA7
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/24] Various HVR-950q and xc5000 fixes

[Devin Heitmueller]

This patch series contains fixes for a variety of problems found in the
HVR-950q as well as the xc5000 driver.

Details can be found in the individual patches, but it is worth mentioning
specifically that this addresses the MythTV problem causing BUG() to occur,
firmware loading is now significantly improved, and we now have a
redistributable version for the xc5000c firmware.

Devin Heitmueller (24):
  au8522: fix intermittent lockup of analog video decoder
  au8522: Fix off-by-one in SNR table for QAM256
  au8522: properly recover from the au8522 delivering misaligned TS
streams
  au0828: Make the s_reg and g_reg advanced debug calls work against
the bridge
  xc5000: properly show quality register values
  xc5000: add support for showing the SNR and gain in the debug output
  xc5000: properly report i2c write failures
  au0828: fix race condition that causes xc5000 to not bind for digital
  au0828: make sure video standard is setup in tuner-core
  au8522: fix regression in logging introduced by separation of modules
  xc5000: don't invoke auto calibration unless we really did reset
tuner
  au0828: prevent i2c gate from being kept open while in analog mode
  au0828: fix case where STREAMOFF being called on stopped stream
causes BUG()
  au0828: speed up i2c clock when doing xc5000 firmware load
  au0828: remove control buffer from send_control_msg
  au0828: tune retry interval for i2c interaction
  au0828: fix possible race condition in usage of dev->ctrlmsg
  xc5000: reset device if encountering PLL lock failure
  xc5000: add support for firmware load check and init status
  au0828: tweak workaround for i2c clock stretching bug
  xc5000: show debug version fields in decimal instead of hex
  au0828: fix a couple of missed edge cases for i2c gate with analog
  au0828: make xc5000 firmware speedup apply to the xc5000c as well
  xc5000: change filename to production/redistributable xc5000c
firmware

 drivers/media/common/tuners/xc5000.c |  161 +-
 drivers/media/dvb/frontends/au8522_common.c  |   22 +++-
 drivers/media/dvb/frontends/au8522_decoder.c |   11 +-
 drivers/media/dvb/frontends/au8522_dig.c |   98 
 drivers/media/dvb/frontends/au8522_priv.h|   29 -
 drivers/media/video/au0828/au0828-cards.c|4 +-
 drivers/media/video/au0828/au0828-core.c |   59 --
 drivers/media/video/au0828/au0828-dvb.c  |   54 -
 drivers/media/video/au0828/au0828-i2c.c  |   21 +++-
 drivers/media/video/au0828/au0828-reg.h  |1 +
 drivers/media/video/au0828/au0828-video.c|   76 +---
 drivers/media/video/au0828/au0828.h  |2 +
 12 files changed, 379 insertions(+), 159 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tda18271 driver power consumption

[Devin Heitmueller]

On Mon, Aug 6, 2012 at 2:19 PM, Antti Palosaari  wrote:
> You should understand from DVB driver model:
> * attach() called only once when driver is loaded
> * init() called to wake-up device
> * sleep() called to sleep device
>
> What I would like to say is that there is very big risk to shoot own leg
> when doing some initialization on attach(). For example resuming from the
> suspend could cause device reset and if you rely some settings that are done
> during attach() you will likely fail as Kernel / USB-host controller has
> reset your device.
>
> See reset_resume from Kernel documentation:
> Documentation/usb/power-management.txt

Be forewarned:  there is a very high likelihood that this patch will
cause regressions on hybrid devices due to known race conditions
related to dvb_frontend sleeping the tuner asynchronously on close.
This is a hybrid tuner, and unless code is specifically added to the
bridge or tuner driver, going from digital to analog mode too quickly
will cause the tuner to be shutdown while it's actively in analog
mode.

(I discovered this the hard way when working on problems MythTV users
reported against the HVR-950q).

Description of race:

1.  User opens DVB frontend tunes
2.  User closes DVB frontend
3.  User *immediately* opens V4L device using same tuner
4.  User performs tuning request for analog
5.  DVB frontend issues sleep() call to tuner, causing analog tuning to fail.

This class of problem isn't seen on DVB only devices or those that
have dedicated digital tuners not shared for analog usage.  And in
some cases it isn't noticed because a delay between closing the DVB
device and opening the analog devices causes the sleep() call to
happen before the analog tune (in which case you don't hit the race).

I'm certainly not against improved power management, but it will
require the race conditions to be fixed first in order to avoid
regressions.

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: [PATCH 0/2] get rid of fe_ioctl_override()

[Devin Heitmueller]

On Sun, Aug 5, 2012 at 5:31 PM, Mauro Carvalho Chehab
 wrote:
> This is not how it works. Patches are posted at the ML and developers can
> review and comment about them. Does those patches break something? If not,
> please stop flaming.

I'm confused why you think this email was a flame.  It's asked three
very straight-forward questions that could have easily have been asked
of any submitter who failed to cc: the maintainer for a particular
driver in the patch submission.

> With regards to Cc the driver maintainer (mkrufky), the patch also got
> forwarded to him, in priv (it were supposed to be sent via git send-email,
> but, as it wasn't, the patch was manually forwarded for him to review,
> just after the patchbomb).

Stating that a clerical error had been made during the git send-email
and thus you forwarded it to him in private would have been a
perfectly reasonable answer to my question.

No need to create drama where there isn't any.

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: [PATCH 0/2] get rid of fe_ioctl_override()

[Devin Heitmueller]

On Sun, Aug 5, 2012 at 2:16 PM, Mauro Carvalho Chehab
 wrote:
> There's just one driver using fe_ioctl_override(), and it can be
> replaced at tuner_attach call. This callback is evil, as only DVBv3
> calls are handled.
>
> Removing it is also a nice cleanup, as about 90 lines of code are
> removed.
>
> Get rid of it!

Did you consult with anyone about this?  Did you talk to the
maintainer for the driver that uses this functionality (he's not on
the CC: for this patch series).  Did you actually do any testing to
validate that it didn't break anything?

This might indeed be a piece of functionality that can possibly be
removed, assuming you can answer yes to all three of the questions
above.

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: [PATCH] em28xx: Fix height setting on non-progressive captures

[Devin Heitmueller]

On Fri, Aug 3, 2012 at 2:42 PM, Ezequiel Garcia  wrote:
> Wait a minute, unless I completely misunderstood the bug (which is possible),
> I think this patch is straightforward.
>
> By the look of this hunk on commit c2a6b54a:
>
> -8<--
> diff --git a/drivers/media/video/em28xx/em28xx-core.c
> b/drivers/media/video/em28xx/em28xx-core.c
> index 5b78e19..339fffd 100644
> --- a/drivers/media/video/em28xx/em28xx-core.c
> +++ b/drivers/media/video/em28xx/em28xx-core.c
> @@ -720,7 +720,10 @@ int em28xx_resolution_set(struct em28xx *dev)
>  {
> int width, height;
> width = norm_maxw(dev);
> -   height = norm_maxh(dev) >> 1;
> +   height = norm_maxh(dev);
> +
> +   if (!dev->progressive)
> +   height >>= norm_maxh(dev);
>
> ->8--
>
> It seems to me that for non-progressive the height should just be
>
>   height = height / 2 (or height = height >> 1)
>
> as was before, and as my patch is doing. It seems to driver will
> "merge" the interlaced
> frames and so the "expected" height is half the real height.
> I hope I got it right.
>
> That said and no matter how straightforward may be, which I'm not sure,
> I also want the patch to get tested before being accepted.

So my concern here is that I don't actually know what that code does
on x86 (what does height end up being equal to?).  On ARM it results
in height being zero, but on x86 I don't know what it will do (and the
fact that it works on x86 despite the change makes me worry about a
regression being introduced).

In other words, it might be working just out of dumb luck and making
the code behave like it does on ARM may cause problems for devices
other than the one I tested with.

I guess I'm worried that the broken code might be a no-op on x86 and
the height ends up still being 480 (or 576 for PAL), in which case
cutting the size of the accumulator window in half may introduce
problems not being seen before.

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: [PATCH] em28xx: Fix height setting on non-progressive captures

[Devin Heitmueller]

On Fri, Aug 3, 2012 at 2:11 PM, Ezequiel Garcia  wrote:
> On Fri, Aug 3, 2012 at 2:52 PM, Ezequiel Garcia  wrote:
>> This was introduced on commit c2a6b54a9:
>> "em28xx: fix: don't do image interlacing on webcams"
>> It is a known bug that has already been reported several times
>> and confirmed by Mauro.
>> Tested by compilation only.
>>
>
> I wonder if it's possible to get an Ack or a Tested-By from any of the
> em28xx owners?

This shouldn't be accepted upstream without testing at least on x86.
I did make such a change to make it work in my ARM tree, but I don't
fully understand the nature of the change and I'm not completely
confident it's correct for x86 (based on my reading of the datasheet
and how the accumulator field is structured in the em28xx chip).
Also, I actually don't have any progressive devices (I've got probably
a dozen em28xx devices, but they are all interlaced capture), which
made me particularly hesitant to submit this patch.

> Also, Devin: you mentioned in an old mail [1] you had some patches for em28xx,
> but you had no time to put them into shape for submission.
>
> If you want to, send then to me (or the full em28xx tree) and I can
> try to submit
> the patches.

Yeah, probably not a bad idea.  I've been sitting on the tree because
they haven't been tested on any other platforms and some of them are
not necessarily generally suitable for the mainline kernel.  And of
course the tree needs to be parsed out into an actual patch series,
and each patch has to be individually validated across multiple
devices to ensure they don't cause breakage (they were tested on an
em2863, but I have no idea if they cause problems on other chips such
as the em2820 or em2880).

All that said, I'm not really sure what the benefit would be in
sending you the tree if you don't actually have any hardware to test
with.  The last thing we need is more crap being sent upstream that is
"compile tested only" since that's where many of the regressions come
from (well meaning people sending completely untested 'cleanup
patches' can cause more harm than good).

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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250

[Devin Heitmueller]

On Thu, Aug 2, 2012 at 3:41 PM,   wrote:
>
>> Heck, even for the 1250 there are eight or ten different versions, so
>> most users wouldn't even know the right one to choose.
>
> Do you mean boards that use different chips?
> I hate it when manufacturers do that (ie. with routers).

In some cases it's different chips (changing the design to use a
better/cheaper bridge, demodulator or tuner).  In some cases it's
because they have different inputs (there are several variants that
have different configurations of composite, s-video, audio connector,
IR support, etc).

As far as the manufacturer is concerned, if there is no end-user
visible feature difference, it's reasonable to not change the model
number and cause the confusion.  That said though, it's a real PITA
for Linux users who think they're something that the web says works
but in fact they are getting something else.

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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250

[Devin Heitmueller]

On Thu, Aug 2, 2012 at 12:34 PM,   wrote:
> It should have been easier, select the card and it builds all the drivers
> it needs. :-)
> Is there a script somewhere that lets me select a card and automatically
> modifies the kernel config?

Yeah, that isn't really practical.  There are *hundreds* of boards,
and having one config option isn't practical given the number of
different bridge/demod/tuner combinations there are.

Heck, even for the 1250 there are eight or ten different versions, so
most users wouldn't even know the right one to choose.

The reality is that the kernel config isn't optimized for this use
case, and given the overhead in administration combined with the
*EXTREME* unlikelihood that any real users would use it, it just isn't
worth the effort.

If you're hacking the kernel config to include support for a single
board as opposed to the whole media subsystem, you're 0.001% of the
user base, and your use case isn't worth the developer effort that
would be required.

In short, we barely have the manpower to make this stuff work at all.
Wasted effort to optimize for really obscure use cases is better spent
on expanding the set of supported products.

>> Also, the 1250 is broken for analog until very recently (patches went
>> upstream for 3.5/3.6 a few days ago).
>
> North American OTA is all digital so I have no way to test it.

That's fine.  I was just trying to make clear that if you wanted
analog functionality then you need the latest code.

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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250

[Devin Heitmueller]

On Thu, Aug 2, 2012 at 5:53 AM, Andy Walls  wrote:
> You can 'grep MODULE_ drivers/media/video/cx23885/* 
> drivers/media/video/cx25840/* ' and other relevant directories under 
> drivers/media/{dvb, common} to find all the parameter options for all the 
> drivers involved in making a HVR_1250 work.

Or just build with everything enabled until you know it is working,
and then optimize the list of modules later.

Also, the 1250 is broken for analog until very recently (patches went
upstream for 3.5/3.6 a few days ago).

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: support for Elgato eyetv one

[Devin Heitmueller]

On Thu, Aug 2, 2012 at 3:33 AM, Dutchdude  wrote:
> I just subcribed to maillinglist to comment that there is probably some
> misunderstanding about the Elgato EyeTV One: It is not a Mac-only product, it 
> is
> also on the market for Windows. In the Netherlands, Elgato EyeTV One is the 
> only
> product available for receiving TV Channels that are not free to air.
>
> In the Netherlands, only the national public television channels Nederland 1,
> Nederland 2, Nederland 3 and a regional public television channels are made
> available free-to-air. DVB-T transmissions in the Netherlands are provided
> commercially by KPN daughter company Digitenne. They offer 25 TV channels and 
> 16
> radio channels (which is growing).
>
> In order to receive the TV channels that are not free to air, a smartcard is
> needed. IMHO, Elgato EyeTV One is the only product on the Dutch market that is
> compatible with this smartcard.

Bear in mind that this may not actually be the same product.  Many of
these vendors release multiple products with the same name.  Hence the
"EyeTV One" sold in the Netherlands may be different than the one that
started this thread.  This is especially likely since your product has
a smartcard reader (and I don't think Tim's product does).

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

Reporting signal overload condition for tuners?

[Devin Heitmueller]

Hi there,

Quick question:  we don't currently have any way to report to userland
that a tuning is failing due to signal overload, right?

There are some tuner chips out there which can detect this condition,
and being able to report it back to userland would make it much easier
to inform the user that he/she needs to stick an attenuator inline.

Has anybody given any thought to this before?  Perhaps use up the last
available bit in fe_status for DVB?

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: cx231xx interlace-like artifacts

[Devin Heitmueller]

On Wed, Jul 25, 2012 at 8:51 PM, Yan Seiner  wrote:
> Yan Seiner wrote:
>>
>> I just recently changed my vidcap to a Hauppage .  Now I get these
>> interlace-like artifacts:
>>
>>
>> http://seiner.com/cz/rtpictures/2012_07_25T14h20m46sZ_0.451651_44.090619_-123.126059.jpg
>>
>> http://seiner.com/cz/rtpictures/2012_07_25T14h22m48sZ_0.224624_44.089669_-123.139100.jpg

The video you are capturing is inherently interlaced.  The Hauppauge
device does raw capture of interlaced video, and takes no
responsibility for deinterlacing.  You need your application to do
such deinterlacing (all the major applications support such:  mplayer,
vlc, tvtime, etc).

>> cxx231x.h has the following line:
>>
>> #define CX231XX_INTERLACED_DEFAULT  1
>>
>> Is there some way to turn off interlacing with a parameter?

This parameter doesn't do what you think.  It's used for cases where
progressive video is being delivered by the camera (or progressive
scan DVD player).  It doesn't cause the device to perform
deinterlacing.

In short, everything you are seeing is expected behavior.  If you want
to deinterlace the video, you need to do this in the application.

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: [PATCH] xc5000: Add MODULE_FIRMWARE statements

[Devin Heitmueller]

On Wed, Jul 25, 2012 at 9:43 AM, Tim Gardner  wrote:
> Devin - Please have a closer look. XC5000A_FIRMWARE and XC5000C_FIRMWARE
> are defined in the patch.

Yup, my bad.  I looked at the patch twice but for some reason didn't
see the #define.

I'm not really taking a position on whether this approach is good or not.

Mauro, let me know if this should be accepted and if so I will stick
it onto the end of my tree before sending it upstream this weekend.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements

[Devin Heitmueller]

On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner  wrote:
> This will make modinfo more useful with regard
> to discovering necessary firmware files.
>
> Cc: Mauro Carvalho Chehab 
> Cc: Michael Krufky 
> Cc: Eddi De Pieri 
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Tim Gardner 
> ---
>  drivers/media/common/tuners/xc5000.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/common/tuners/xc5000.c 
> b/drivers/media/common/tuners/xc5000.c
> index dcca42c..4d33f86 100644
> --- a/drivers/media/common/tuners/xc5000.c
> +++ b/drivers/media/common/tuners/xc5000.c
> @@ -210,13 +210,15 @@ struct xc5000_fw_cfg {
> u16 size;
>  };
>
> +#define XC5000A_FIRMWARE "dvb-fe-xc5000-1.6.114.fw"
>  static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
> -   .name = "dvb-fe-xc5000-1.6.114.fw",
> +   .name = XC5000A_FIRMWARE,
> .size = 12401,
>  };
>
> +#define XC5000C_FIRMWARE "dvb-fe-xc5000c-41.024.5.fw"
>  static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
> -   .name = "dvb-fe-xc5000c-41.024.5.fw",
> +   .name = XC5000C_FIRMWARE,
> .size = 16497,
>  };
>
> @@ -1253,3 +1255,5 @@ EXPORT_SYMBOL(xc5000_attach);
>  MODULE_AUTHOR("Steven Toth");
>  MODULE_DESCRIPTION("Xceive xc5000 silicon tuner driver");
>  MODULE_LICENSE("GPL");
> +MODULE_FIRMWARE(XC5000A_FIRMWARE);
> +MODULE_FIRMWARE(XC5000C_FIRMWARE);
> --

Hi Tim,

I'm just eyeballing the patch and I'm not familiar with this new
functionality, but where are the new macros you're specifying actually
defined?  You're swapping out the filename for XC5000A_FIRMWARE, but
where is the actual reference to "dvb-fe-xc5000-1.6.114.fw"?

Also, Mauro, can I merge this into my tree first rather than you
pulling it direct?  I've got a whole patch series for xc5000 that I'm
slated to issue a PULL for this weekend, and I *really* don't want to
rebase the series for a four line change (which will definitely cause
a conflict).

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: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit

[Devin Heitmueller]

On Tue, Jul 24, 2012 at 5:50 PM, Antti Palosaari  wrote:
> I wonder if it is wise to merge both DVB and V4L2 APIs, add needed DVB stuff
> to V4L2 API and finally remove whole DVB API. V4L2 API seems to be much more
> feature rich, developed more actively and maybe has less problems than
> current DVB API.

This may just be a case of "the grass is always greener on the other
side of the fence".  The V4L2 subsystem has more than it's share of
problems - you just don't see them since you don't work with that code
on a regular basis.

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: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit

[Devin Heitmueller]

On Tue, Jul 24, 2012 at 4:05 PM, Rémi Denis-Courmont  wrote:
> If it's of interest to anyone, I could probably present a bunch of issues with
> V4L2 and DVB from userspace perspective.

Remi,

I would strongly be in favor of this.  One thing that we get far to
little of is feedback from actual userland developers making use of
the V4L and DVB interfaces (aside from the SoC vendors, which is a
completely different target audience than the traditional V4L and DVB
consumers)

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: CX25821 driver in kernel 3.4.4 problem

[Devin Heitmueller]

On Mon, Jul 23, 2012 at 3:40 AM, Radek Mašín  wrote:
> Hello,
> may be one more problem. I use Zoneminder software for capturing pictures 
> from card and occasionally
> I get corrupted picture. Please take a look for attached files.

Looks like the IRQ handler wasn't servicing fast enough, causing parts
of a frame to get dropped.  Does this only happen when you have a
bunch of streams running in parallel?

This sort of performance issue would be very difficult to debug
without one of the developers having a board.  From what I understand
the code provided by Conexant was merged essentially as-is (with some
codingstyle cleanups and zero testing), with no upstream developers
actually having the hardware.

You're probably out of luck unless you're willing to pay somebody to
get a board and debug the problem.

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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit

[Devin Heitmueller]

On Wed, Jul 18, 2012 at 10:00 AM, Laurent Pinchart
 wrote:
> Another ambiguity for your list: what should a driver return in TRY_FMT/S_FMT
> if the requested format is not supported (possible behaviours include
> returning the currently selected format or a default format).

Whatever gets decided in terms of eliminating the ambiguity, we should
definitely do a v4l2-compliance test for this.  I've seen drivers in
the past that return -EINVAL if the requested format is not supported
(which resulted in various userland apps inventing their own
workarounds over the years).

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: V4L doesn't work on Wii

[Devin Heitmueller]

On Mon, Jul 16, 2012 at 9:17 AM, Darwin O'Connor  wrote:
> I have been trying to use my Wii to record video. I'm using MIKE p5
> kernel based on 2.6
>  with the wiitoo
> Gentoo distribution.
>
> When I try and capture video with ffmpeg it fails because it can't
> allocate enough memory. I added some debugging code to ffmpeg and I
> found that the VIDIOC_QUERYBUF ioctl command is returning a size of
> 16777216 and a location of -1412567296 for the first video buffer. It
> doesn't appear any errors are generated by V4L.
>
> I also tried to capture with transcode, but it generated a similar memory 
> error.
>
> This happens for both the em28xx USB video capture device I have and
> the V4L Virtual Video device.
>
> Does anyone have any suggestions on what the cause could be. Perhaps
> some kernel component is missing.

There are known issues with em28xx on non-Intel CPUs.  That's not a
good driver to use for such testing.

No easy answers here.  I suspect nobody has ever tried it, so if you
want it to work you would need to be prepared to roll up your sleeves
and debug the driver code (assuming you have kernel development
experience).  Otherwise your only option is to wait for some developer
who cares enough to figure out why such an obscure setup doesn't work.

We barely have enough resources to keep this stuff working correctly
under x86 - developers are too overloaded to worry about platforms
with zero userbase.

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: pctv452e

[Devin Heitmueller]

On Tue, Jul 10, 2012 at 11:51 AM, poma  wrote:
>> Is this pctv452e device known to have poor reception?

Traditionally speaking, these problems are usually not the hardware
itself - it tends to be crappy Linux drivers.  Somebody gets support
working for a chip on some product, and then somebody else does a
cut/paste of the code to make some other product work.  They see it
getting signal lock under optimal tuning conditions and declare
success.

Making any given device work *well* tends to be much harder than
making it work at all.

Want to rule out bad hardware design?  Drop it into a Windows machine
and see how it performs.  If it works fine under Windows but poorly
under Linux, then you definitely have a Linux driver problem.

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: Any program that creates captions from pixel data?

[Devin Heitmueller]

On Mon, Jul 9, 2012 at 11:19 PM, Tim Stowell  wrote:
> Hello,
>
> I'm trying to create a bitmap image such that when output via a
> composite port it will translate into captions, very similar to this:
> http://al.robotfuzz.com/generating-teletext-in-software/ except NTSC.
> I have some ideas but wanted to check if anyone had tried something
> similar as Google didn't turn up much, thanks!

I don't know if this is related to your previous thread about VBI
capture on em28xx, but if so I can tell you that you can probably
pretty easily "pass through" the VBI data as a graphical waveform if
that is your goal.  The only difference between the data provided via
raw VBI capture and the standard image data is that the chroma is
stripped out (every other byte in a YUYV sequence).

If your goal is to generate the waveform from scratch, I haven't seen
any software to do that but it would be pretty trivial to write
(probably a couple hundred lines of code).  You just need to read the
EIA-608 spec and understand how the byte pairs are represented in the
waveform.  You should also look more closely at the zvbi source code -
it has the ability to create a "dummy source" which if I recall
actually can work with osc (meaning it can generate the waveform
internally).  You would have to hack up the code to connect the parts
and extract the actual image data.

It's probably also worth mentioning that much of this is dependent on
the output device you are using.   Many devices don't actually let you
put data into the VBI area just by including it in the image data.
You typically have to use special APIs that are specific to the
platform.

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: Linux equivalent of Windows VBIScope?

[Devin Heitmueller]

On Mon, Jul 9, 2012 at 5:32 PM, Andy Walls  wrote:
> Tim Stowell  wrote:
>
>>Hi all,
>>
>>I am using the em28xx driver and have been able to extract captions
>>using zvbi. I would like to visualize the waveform like the DirectShow
>>VBIScope filter on windows (unfortunately the Windows driver doesn't
>>expose any VBI pins). Does anyone know of anythings similar on Linux?
>>Thanks
>>--
>>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
>
> 'osc' is a test utility that is part of the zvbi source distribution.  It 
> probably does what you need.
>
> Regards,
> Andy

I'll second Andy's endorsement of osc.  It's a very handy little tool.

Also, if you run into any VBI issues with em28xx, please let me know
(I did the original driver support for it).

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: [PATCH 1/1] Add support for newer PCTV 800i cards with s5h1411 demodulators

[Devin Heitmueller]

On Fri, Jul 6, 2012 at 3:39 PM, Mauro Carvalho Chehab
 wrote:
> Em 29-06-2012 01:38, Mack Stanley escreveu:
>> I'm sorry to have missed the word-wrap.  Here's a new copy. ---Mack
>>
>> Testing needed on older (Pinnacle) PCTV 800i cards with S5H1409 demodulators
>> to check that current support for them isn't broken by this patch.
>>
>> Signed-off-by: Mack Stanley 
>> ---
>>   drivers/media/video/cx88/cx88-dvb.c |   40
>> --
>
>
> It is still completely mangled. It is impossible to apply it this way.
>
> Regards,
> Mauro

Mack,

Assuming this is a git tree, just use "git format-patch" followed by
"git send-email".

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: [PATCH 2/3] [media] tuner-xc2028: Fix signal strength report

[Devin Heitmueller]

On Thu, Jul 5, 2012 at 10:25 AM, Devin Heitmueller
 wrote:
> On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab
>> -   /* Use both frq_lock and signal to generate the result */
>> -   signal = signal || ((signal & 0x07) << 12);
>> +   /* Signal level is 3 bits only */
>> +
>> +   signal = ((1 << 12) - 1) | ((signal & 0x07) << 12);
>
> Are you sure this is correct?   It's entirely possible the original
> code used a logical or because the signal level isn't valid unless
> there is a lock.  The author may have been intending to say:
>
> if (signal != 0) /* There is a lock, so set the signal level */
>   signal = (signal & 0x07) << 12;
> else
>   signal = 0 /* Leave signal level at zero since there is no lock */
>
> I agree that the way the original code was written is confusing, but
> it may actually be correct.

On second reading, it would have needed to be a logical AND, not an OR
in order for my suggestion to have been correct.

That said, empirical results are definitely a stronger argument in
this case.  You did test this change in cases with no signal, signal
lock with weak signal, and signal lock with strong signal, right?

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: [PATCH 2/3] [media] tuner-xc2028: Fix signal strength report

[Devin Heitmueller]

On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab
> -   /* Use both frq_lock and signal to generate the result */
> -   signal = signal || ((signal & 0x07) << 12);
> +   /* Signal level is 3 bits only */
> +
> +   signal = ((1 << 12) - 1) | ((signal & 0x07) << 12);

Are you sure this is correct?   It's entirely possible the original
code used a logical or because the signal level isn't valid unless
there is a lock.  The author may have been intending to say:

if (signal != 0) /* There is a lock, so set the signal level */
  signal = (signal & 0x07) << 12;
else
  signal = 0 /* Leave signal level at zero since there is no lock */

I agree that the way the original code was written is confusing, but
it may actually be correct.

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: ATI theatre 750 HD tuner USB stick

[Devin Heitmueller]

On Wed, Jul 4, 2012 at 9:27 AM, Fisher Grubb  wrote:
> I was in contact with AMD today regarding this tuner haveing no
> support on Linux and I was given a link for a feedback form and told
> to get specific needs from www.linuxtv.org to help the cause and if
> there were enough people, then the AMD developers may help.

I'm not sure why they would direct you to linuxtv.org.  *They* are the
ones with all the information that the linuxtv community would need.

> Of course I wouldn't be surprised if people will have to reverse
> engineer it from the windows drivers but I thought I would mention it.
>  I could not find any info on this 750 HD on www.linuxtv.org regarding
> where it stands.  What help is needed for it?

1.  Datasheets for the 750 (under NDA is fine), but they need to agree
to allow them to be used to author a GPL driver.
2.  Reference driver sources which can be legally incorporated into a
GPL driver.
3.  Firmware with a license that permits free redistribution.

I attempted to work with them back in 2009 on the T316 chip (an
ATSC/ClearQAM demodulator), and they couldn't provide all of the
above.  Perhaps things have changed since then but I doubt it (in
particular, the sale of their TV chip unit to Broadcom left all sorts
of unknowns regarding who owns the relevant intellectual property).

Finally, even if you get the above, there still needs to be some
developer who has the time/interest to do the work.  While three years
ago the big challenge was getting access to the datasheets, nowadays a
much bigger problem is there are no developers who are both qualified
and not already too busy with other work.  Bootstrapping a new chip
like that is probably a 50-100 hour investment for somebody who is
experienced in this area, which is a fairly big chunk of time if the
developer doesn't have any vested interest.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] cx23885: add support for HVR-1255 analog (cx23888 variant)

[Devin Heitmueller]

Get the HVR-1255 analog support working for all supported inputs.  This
includes introduction of a new board profile for an OEM variant which doesn't
have all the same inputs as the retail version of the board.

Validated with the following boards:

HVR-1255 (0070:2259)

Thanks to Steven Toth and Hauppauge for loaning me various boards to
regression test with.

Thanks-to: Steven Toth 
Signed-off-by: Devin Heitmueler 
---
 drivers/media/video/cx23885/cx23885-cards.c |   56 ++-
 drivers/media/video/cx23885/cx23885-dvb.c   |6 +++
 drivers/media/video/cx23885/cx23885-video.c |8 +++-
 drivers/media/video/cx23885/cx23885.h   |1 +
 4 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/cx23885/cx23885-cards.c 
b/drivers/media/video/cx23885/cx23885-cards.c
index 1af9108..5103735 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -282,7 +282,55 @@ struct cx23885_board cx23885_boards[] = {
},
[CX23885_BOARD_HAUPPAUGE_HVR1255] = {
.name   = "Hauppauge WinTV-HVR1255",
+   .porta  = CX23885_ANALOG_VIDEO,
.portc  = CX23885_MPEG_DVB,
+   .tuner_type = TUNER_ABSENT,
+   .tuner_addr = 0x42, /* 0x84 >> 1 */
+   .force_bff  = 1,
+   .input  = {{
+   .type   = CX23885_VMUX_TELEVISION,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN5_CH2 |
+   CX25840_VIN2_CH1 |
+   CX25840_DIF_ON,
+   .amux   = CX25840_AUDIO8,
+   }, {
+   .type   = CX23885_VMUX_COMPOSITE1,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN4_CH2 |
+   CX25840_VIN6_CH1,
+   .amux   = CX25840_AUDIO7,
+   }, {
+   .type   = CX23885_VMUX_SVIDEO,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN4_CH2 |
+   CX25840_VIN8_CH1 |
+   CX25840_SVIDEO_ON,
+   .amux   = CX25840_AUDIO7,
+   } },
+   },
+   [CX23885_BOARD_HAUPPAUGE_HVR1255_22111] = {
+   .name   = "Hauppauge WinTV-HVR1255",
+   .porta  = CX23885_ANALOG_VIDEO,
+   .portc  = CX23885_MPEG_DVB,
+   .tuner_type = TUNER_ABSENT,
+   .tuner_addr = 0x42, /* 0x84 >> 1 */
+   .force_bff  = 1,
+   .input  = {{
+   .type   = CX23885_VMUX_TELEVISION,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN5_CH2 |
+   CX25840_VIN2_CH1 |
+   CX25840_DIF_ON,
+   .amux   = CX25840_AUDIO8,
+   }, {
+   .type   = CX23885_VMUX_SVIDEO,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN4_CH2 |
+   CX25840_VIN8_CH1 |
+   CX25840_SVIDEO_ON,
+   .amux   = CX25840_AUDIO7,
+   } },
},
[CX23885_BOARD_HAUPPAUGE_HVR1210] = {
.name   = "Hauppauge WinTV-HVR1210",
@@ -635,7 +683,7 @@ struct cx23885_subid cx23885_subids[] = {
}, {
.subvendor = 0x0070,
.subdevice = 0x2259,
-   .card  = CX23885_BOARD_HAUPPAUGE_HVR1255,
+   .card  = CX23885_BOARD_HAUPPAUGE_HVR1255_22111,
}, {
.subvendor = 0x0070,
.subdevice = 0x2291,
@@ -1137,6 +1185,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1270:
case CX23885_BOARD_HAUPPAUGE_HVR1275:
case CX23885_BOARD_HAUPPAUGE_HVR1255:
+   case CX23885_BOARD_HAUPPAUGE_HVR1255_22111:
case CX23885_BOARD_HAUPPAUGE_HVR1210:
/* GPIO-5 RF Control: 0 = RF1 Terrestrial, 1 = RF2 Cable */
/* GPIO-6 I2C Gate which can isolate the demod from the bus */
@@ -1274,6 +1323,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1400:
case CX23885_BOARD_HAUPPAUGE_HVR1275:
case CX23885_BOARD_HAUPPAUGE_HVR1255:
+   case CX23885_BOARD_HAUPPAUGE_HVR1255_22111:
case CX23885_BOARD_HAUPPAUGE_HVR1210:
/* FIXME: Implement me */
break;
@@ -1431,6 +1481,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BO

[PATCH 5/6] cx23885: make analog support work for HVR_1250 (cx23885 variant)

[Devin Heitmueller]

The analog support in the cx23885 driver was completely broken for the
HVR-1250.  Add the necessary code.

Note that this only implements analog for the composite and s-video inputs.
The tuner input continues to be non-functional due to a lack of analog support
in the mt2131 driver.

Validated with the following boards:

HVR-1250 (0070:7911)

Thanks to Steven Toth and Hauppauge for loaning me various boards to
regression test with.

Thanks-to: Steven Toth 
Signed-off-by: Devin Heitmueler 
---
 drivers/media/video/cx23885/cx23885-cards.c |   31 ---
 drivers/media/video/cx23885/cx23885-video.c |1 +
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/media/video/cx23885/cx23885-cards.c 
b/drivers/media/video/cx23885/cx23885-cards.c
index 19b5499..1af9108 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -127,22 +127,37 @@ struct cx23885_board cx23885_boards[] = {
},
[CX23885_BOARD_HAUPPAUGE_HVR1250] = {
.name   = "Hauppauge WinTV-HVR1250",
+   .porta  = CX23885_ANALOG_VIDEO,
.portc  = CX23885_MPEG_DVB,
+#ifdef MT2131_NO_ANALOG_SUPPORT_YET
+   .tuner_type = TUNER_PHILIPS_TDA8290,
+   .tuner_addr = 0x42, /* 0x84 >> 1 */
+   .tuner_bus  = 1,
+#endif
+   .force_bff  = 1,
.input  = {{
+#ifdef MT2131_NO_ANALOG_SUPPORT_YET
.type   = CX23885_VMUX_TELEVISION,
-   .vmux   = 0,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN5_CH2 |
+   CX25840_VIN2_CH1,
+   .amux   = CX25840_AUDIO8,
.gpio0  = 0xff00,
}, {
-   .type   = CX23885_VMUX_DEBUG,
-   .vmux   = 0,
-   .gpio0  = 0xff01,
-   }, {
+#endif
.type   = CX23885_VMUX_COMPOSITE1,
-   .vmux   = 1,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN4_CH2 |
+   CX25840_VIN6_CH1,
+   .amux   = CX25840_AUDIO7,
.gpio0  = 0xff02,
}, {
.type   = CX23885_VMUX_SVIDEO,
-   .vmux   = 2,
+   .vmux   =   CX25840_VIN7_CH3 |
+   CX25840_VIN4_CH2 |
+   CX25840_VIN8_CH1 |
+   CX25840_SVIDEO_ON,
+   .amux   = CX25840_AUDIO7,
.gpio0  = 0xff02,
} },
},
@@ -1517,10 +1532,10 @@ void cx23885_card_setup(struct cx23885_dev *dev)
 */
switch (dev->board) {
case CX23885_BOARD_TEVII_S470:
-   case CX23885_BOARD_HAUPPAUGE_HVR1250:
/* Currently only enabled for the integrated IR controller */
if (!enable_885_ir)
break;
+   case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1800:
case CX23885_BOARD_HAUPPAUGE_HVR1800lp:
case CX23885_BOARD_HAUPPAUGE_HVR1700:
diff --git a/drivers/media/video/cx23885/cx23885-video.c 
b/drivers/media/video/cx23885/cx23885-video.c
index c654bdc..4d05689 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -505,6 +505,7 @@ static int cx23885_video_mux(struct cx23885_dev *dev, 
unsigned int input)
 
if ((dev->board == CX23885_BOARD_HAUPPAUGE_HVR1800) ||
(dev->board == CX23885_BOARD_MPX885) ||
+   (dev->board == CX23885_BOARD_HAUPPAUGE_HVR1250) ||
(dev->board == CX23885_BOARD_HAUPPAUGE_HVR1850)) {
/* Configure audio routing */
v4l2_subdev_call(dev->sd_cx25840, audio, s_routing,
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/6] cx25840: fix vsrc/hsrc usage on cx23888 designs

[Devin Heitmueller]

The location of the vsrc/hsrc registers moved in the cx23888, causing the
s_mbus call to fail prematurely indicating that "720x480 is not a valid size".
The function bailed out before many pertinent registers were set related to
the scaler (causing unexpected results in video rendering when doing raw
video capture).

Use the correct registers for the cx23888.

Validated with the following boards:

HVR-1800 retail (0070:7801)
HVR-1800 OEM (0070:7809)
HVR-1850 retail (0070:8541)

Thanks to Steven Toth and Hauppauge for loaning me various boards to
regression test with.

Reported-by: Jonathan 
Thanks-to: Steven Toth 
Signed-off-by: Devin Heitmueler 
---
 drivers/media/video/cx25840/cx25840-core.c |   18 ++
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/cx25840/cx25840-core.c 
b/drivers/media/video/cx25840/cx25840-core.c
index 7dc7bb1..d8eac3e 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1380,11 +1380,21 @@ static int cx25840_s_mbus_fmt(struct v4l2_subdev *sd, 
struct v4l2_mbus_framefmt
fmt->field = V4L2_FIELD_INTERLACED;
fmt->colorspace = V4L2_COLORSPACE_SMPTE170M;
 
-   Vsrc = (cx25840_read(client, 0x476) & 0x3f) << 4;
-   Vsrc |= (cx25840_read(client, 0x475) & 0xf0) >> 4;
+   if (is_cx23888(state)) {
+   Vsrc = (cx25840_read(client, 0x42a) & 0x3f) << 4;
+   Vsrc |= (cx25840_read(client, 0x429) & 0xf0) >> 4;
+   } else {
+   Vsrc = (cx25840_read(client, 0x476) & 0x3f) << 4;
+   Vsrc |= (cx25840_read(client, 0x475) & 0xf0) >> 4;
+   }
 
-   Hsrc = (cx25840_read(client, 0x472) & 0x3f) << 4;
-   Hsrc |= (cx25840_read(client, 0x471) & 0xf0) >> 4;
+   if (is_cx23888(state)) {
+   Hsrc = (cx25840_read(client, 0x426) & 0x3f) << 4;
+   Hsrc |= (cx25840_read(client, 0x425) & 0xf0) >> 4;
+   } else {
+   Hsrc = (cx25840_read(client, 0x472) & 0x3f) << 4;
+   Hsrc |= (cx25840_read(client, 0x471) & 0xf0) >> 4;
+   }
 
Vlines = fmt->height + (is_50Hz ? 4 : 7);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] cx25840: fix regression in HVR-1800 analog audio

[Devin Heitmueller]

The refactoring of the cx25840 driver to support the cx23888 caused breakage
with the existing support for cx23885/cx23887 analog audio support.  Tweak
the code so that it only uses the code if it really is a cx23888 instead of
applying it to all cx2388x based devices.

Validated with the following boards:

HVR-1800 retail (0070:7801)
HVR-1800 OEM (0070:7809)
HVR_1850 retail (0070:8541)

Thanks to Steven Toth and Hauppauge for loaning me various boards to
regression test with.

Reported-by: Jonathan 
Thanks-to: Steven Toth 
Signed-off-by: Devin Heitmueler 
---
 drivers/media/video/cx25840/cx25840-core.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/cx25840/cx25840-core.c 
b/drivers/media/video/cx25840/cx25840-core.c
index e12b3b0..7dc7bb1 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1250,7 +1250,7 @@ static int set_input(struct i2c_client *client, enum 
cx25840_video_input vid_inp
cx25840_write4(client, 0x8d0, 0x1f063870);
}
 
-   if (is_cx2388x(state)) {
+   if (is_cx23888(state)) {
/* HVR1850 */
/* AUD_IO_CTRL - I2S Input, Parallel1*/
/*  - Channel 1 src - Parallel1 (Merlin out) */
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/6] cx25840: fix regression in HVR-1800 analog support hue/saturation controls

[Devin Heitmueller]

The changes made for the cx23888 caused regressions in the analog support
for cx23885/cx23887 based boards (partly due to changes in the locations of
the hue/saturation controls).  As a result the wrong registers were being
overwritten.

Add code to use the correct registers if it's a cx23888

Validated with the following boards:

HVR-1800 retail (0070:7801)
HVR-1800 OEM (0070:7809)
HVR-1850 retail (0070:8541)

Thanks to Steven Toth and Hauppauge for loaning me various boards to
regression test  with.

Reported-by: Jonathan 
Thanks-to: Steven Toth 
Signed-off-by: Devin Heitmueler 
---
 drivers/media/video/cx25840/cx25840-core.c |   33 +++
 1 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/cx25840/cx25840-core.c 
b/drivers/media/video/cx25840/cx25840-core.c
index a82b704..e12b3b0 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1106,9 +1106,23 @@ static int set_input(struct i2c_client *client, enum 
cx25840_video_input vid_inp
 
cx25840_write4(client, 0x410, 0x0dbf);
cx25840_write4(client, 0x414, 0x00137d03);
-   cx25840_write4(client, 0x418, 0x01008080);
+
+   /* on the 887, 0x418 is HSCALE_CTRL, on the 888 it is 
+  CHROMA_CTRL */
+   if (is_cx23888(state))
+   cx25840_write4(client, 0x418, 0x01008080);
+   else
+   cx25840_write4(client, 0x418, 0x0100);
+
cx25840_write4(client, 0x41c, 0x);
-   cx25840_write4(client, 0x420, 0x001c3e0f);
+
+   /* on the 887, 0x420 is CHROMA_CTRL, on the 888 it is 
+  CRUSH_CTRL */
+   if (is_cx23888(state))
+   cx25840_write4(client, 0x420, 0x001c3e0f);
+   else
+   cx25840_write4(client, 0x420, 0x001c8282);
+
cx25840_write4(client, 0x42c, 0x4260);
cx25840_write4(client, 0x430, 0x039b);
cx25840_write4(client, 0x438, 0x);
@@ -1315,6 +1329,7 @@ static int set_v4lstd(struct i2c_client *client)
 static int cx25840_s_ctrl(struct v4l2_ctrl *ctrl)
 {
struct v4l2_subdev *sd = to_sd(ctrl);
+   struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
 
switch (ctrl->id) {
@@ -1327,12 +1342,20 @@ static int cx25840_s_ctrl(struct v4l2_ctrl *ctrl)
break;
 
case V4L2_CID_SATURATION:
-   cx25840_write(client, 0x420, ctrl->val << 1);
-   cx25840_write(client, 0x421, ctrl->val << 1);
+   if (is_cx23888(state)) {
+   cx25840_write(client, 0x418, ctrl->val << 1);
+   cx25840_write(client, 0x419, ctrl->val << 1);
+   } else {
+   cx25840_write(client, 0x420, ctrl->val << 1);
+   cx25840_write(client, 0x421, ctrl->val << 1);
+   }
break;
 
case V4L2_CID_HUE:
-   cx25840_write(client, 0x422, ctrl->val);
+   if (is_cx23888(state))
+   cx25840_write(client, 0x41a, ctrl->val);
+   else
+   cx25840_write(client, 0x422, ctrl->val);
break;
 
default:
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] cx25840: fix regression in HVR-1800 analog support

[Devin Heitmueller]

The refactoring of the cx25840 driver to support the cx23888 caused breakage
with the existing support for cx23885/cx23887 analog support.  Rework the
routines such that the new code is only used for the 888.

Validated with the following boards:

HVR-1800 retail (0070:7801)
HVR-1800 OEM (0070:7809)
HVR_1850 retail (0070:8541)

Thanks to Steven Toth and Hauppauge for loaning me various boards to
regression test with.

Reported-by: Jonathan 
Thanks-to: Steven Toth 
Signed-off-by: Devin Heitmueler 
---
 drivers/media/video/cx25840/cx25840-core.c |   23 +--
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/media/video/cx25840/cx25840-core.c 
b/drivers/media/video/cx25840/cx25840-core.c
index fc1ff69..a82b704 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -84,7 +84,7 @@ MODULE_PARM_DESC(debug, "Debugging messages [0=Off (default) 
1=On]");
 
 
 /* --- */
-static void cx23885_std_setup(struct i2c_client *client);
+static void cx23888_std_setup(struct i2c_client *client);
 
 int cx25840_write(struct i2c_client *client, u16 addr, u8 value)
 {
@@ -638,10 +638,13 @@ static void cx23885_initialize(struct i2c_client *client)
finish_wait(&state->fw_wait, &wait);
destroy_workqueue(q);
 
-   /* Call the cx23885 specific std setup func, we no longer rely on
+   /* Call the cx23888 specific std setup func, we no longer rely on
 * the generic cx24840 func.
 */
-   cx23885_std_setup(client);
+   if (is_cx23888(state))
+   cx23888_std_setup(client);
+   else
+   cx25840_std_setup(client);
 
/* (re)set input */
set_input(client, state->vid_input, state->aud_input);
@@ -1298,8 +1301,8 @@ static int set_v4lstd(struct i2c_client *client)
}
cx25840_and_or(client, 0x400, ~0xf, fmt);
cx25840_and_or(client, 0x403, ~0x3, pal_m);
-   if (is_cx2388x(state))
-   cx23885_std_setup(client);
+   if (is_cx23888(state))
+   cx23888_std_setup(client);
else
cx25840_std_setup(client);
if (!is_cx2583x(state))
@@ -1782,8 +1785,8 @@ static int cx25840_s_video_routing(struct v4l2_subdev *sd,
struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
 
-   if (is_cx2388x(state))
-   cx23885_std_setup(client);
+   if (is_cx23888(state))
+   cx23888_std_setup(client);
 
return set_input(client, input, state->aud_input);
 }
@@ -1794,8 +1797,8 @@ static int cx25840_s_audio_routing(struct v4l2_subdev *sd,
struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
 
-   if (is_cx2388x(state))
-   cx23885_std_setup(client);
+   if (is_cx23888(state))
+   cx23888_std_setup(client);
return set_input(client, state->vid_input, input);
 }
 
@@ -4939,7 +4942,7 @@ void cx23885_dif_setup(struct i2c_client *client, u32 
ifHz)
}
 }
 
-static void cx23885_std_setup(struct i2c_client *client)
+static void cx23888_std_setup(struct i2c_client *client)
 {
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
v4l2_std_id std = state->std;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/6] Various cx23885 analog fixes

[Devin Heitmueller]

This patch series contains fixes for various cx23885 boards, as well as
introducing support for analog for the HVR-1250 and 1255.

Devin Heitmueller (6):
  cx25840: fix regression in HVR-1800 analog support
  cx25840: fix regression in HVR-1800 analog support hue/saturation
controls
  cx25840: fix regression in HVR-1800 analog audio
  cx25840: fix vsrc/hsrc usage on cx23888 designs
  cx23885: make analog support work for HVR_1250 (cx23885 variant)
  cx23885: add support for HVR-1255 analog (cx23888 variant)

 drivers/media/video/cx23885/cx23885-cards.c |   87 ---
 drivers/media/video/cx23885/cx23885-dvb.c   |6 ++
 drivers/media/video/cx23885/cx23885-video.c |9 +++-
 drivers/media/video/cx23885/cx23885.h   |1 +
 drivers/media/video/cx25840/cx25840-core.c  |   76 +--
 5 files changed, 149 insertions(+), 30 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AverTVHD Volar Max (h286DU)

[Devin Heitmueller]

On Fri, Jun 29, 2012 at 3:10 PM,   wrote:
> Great info. I'm less familiar with the way that Cable is
> transmitted, but I do understand that ATSC carries multiple
> channels per frequency. Are you suggesting that I could
> capture a single stream from a single tuner which would
> contain several channels, and pull the CC data for all of
> those channels from a single stream? Would QAM work similarly?
> ( Assuming the feed is unencrypted )

Yes, QAM is very similar.  On many cable systems, while there may be
fifteen or twenty unencrypted channels, they are spread across only
three our four actual frequencies (meaning 3-4 tuners could grab
effectively all the unencrypted channels at the same time).

> I've found that most, if not all, cable boxes do not pass
> through CC data, because they are meant to interpret it and
> pass it on with customized formatting and whatnot, so another
> scaling challenge will be finding a feed that I can use
> without a cable box. OTA broadcasts have been my testing
> ground because they are so readily available.

Yeah, the fact that many cable boxes don't provide a way to expose CC
data other than their inserting the decoded text into the video is
pretty frustrating.  Bear in mind though that since you don't care
about the video then as long as the cable box has standard definition
outputs then it may very well include the CC data (HD component and
HDMI don't have a way to send CC data, but the older standard def
outputs still do).

You should definitely look at the Cablecard based devices such as the
HD HomeRun Prime, Ceton InfiniTV, or Hauppauge DCR-2650.  These
devices will allow you to get to the unencrypted streams including CC
data (assuming that the channel is marked "copy freely").

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: AverTVHD Volar Max (h286DU)

[Devin Heitmueller]

On Fri, Jun 29, 2012 at 1:57 PM,   wrote:
> I don't need to save the video, except that I'm using CC
> extractor, which expects an Mpeg-2 file. I'd like to capture as
> many streams from one tuner as possible (one reason for working
> in the Linux environment), the vendor-provided applications do
> not allow me to run parallel instances. I'm hoping I can get
> around that - does that seem naive?
>
> I do need ATSC/Clear QAM support. Analog is not necessary. USB
> is preferable because I'm testing with a laptop.

If you don't need analog then that makes things considerably simpler.
The tuner will already deliver MPEG-2 (since that's what the
broadcaster is sending), and tuners can be configured to deliver a
full stream for cases where there are multiple channels on the same
frequency.  That said though, you are limited by the number of
physical tuners in that a single tuner can only be on one frequency at
a time.

What you need to understand is that different products have different
numbers of tuners.  For example, the Hauppauge HVR-950q has a single
tuner which can be shared for analog and digital while the HVR-2250
has two tuners (each of which can tune to a single analog or digital
channel).

There is no inherent limitation under Linux which prevents you from
having multiple tuners in use in parallel.  In fact it's actually
quite common (many MythTV users for example record several programs at
the same time since they have multiple tuners installed).

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: AverTVHD Volar Max (h286DU)

[Devin Heitmueller]

On Fri, Jun 29, 2012 at 1:19 PM,   wrote:
> Hi Devin
>
> I agree. What device would you suggest? Is there one which seems
> to be most popular / robust?

That depends largely on your use case.  Do you need to actually save
the video, or just extract the captions (if you want to save the
video, getting a board with an onboard MPEG encoder would be useful).
Do you need to support digital ATSC/ClearQAM streams as well as
analog?  How many streams do you need to capture in a single PC?  Any
restrictions on bus type (USB/PCI/PCIe)?

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: AverTVHD Volar Max (h286DU)

[Devin Heitmueller]

On Fri, Jun 29, 2012 at 12:49 PM,   wrote:
> Hello all,
>
> I'm currently working on an automated process to increase the
> number of online Closed Captions for the hearing-impaired
> community on a popular video-streaming service. I've had a
> successful proof-of-concept on mac and PC platforms, but to
> take this process to scale, I'd like to design a linux
> solution.
>
> The device I'm currently using is the AverTVHD Volar Max
> (h286DU). I've attempted to use the Aver-supplied drivers in
> Ubuntu 10.4 and 9.10 to no avail. Any help in developing a
> working driver / installation method for my device would be
> greatly appreciated by me, and, potentially, a very large and
> very under-represented audience of hard-of-hearing.
>
> Thanks for any support in this matter, and for all the
> development done up to this point.

Given you're looking to do this on a large scale, you might be better
suited to choose a device that is actively maintained by the LinuxTV
community rather than a device that the vendor shipped a driver for
years ago, is not in the mainline kernel, and as far as I know doesn't
work with current kernels.

Just a suggestion though.

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: [PATCH 1/1] Add support for newer PCTV 800i cards with s5h1411 demodulators

[Devin Heitmueller]

On Thu, Jun 28, 2012 at 5:29 PM, Mack Stanley  wrote:
> Testing is needed on older (aka Pinnacle) PCTV 800i cards with S5H1409
> demodulators
> to check that current support for them isn't broken by this patch.
>
> Signed-off-by: Mack Stanley 
> ---
>  drivers/media/video/cx88/cx88-dvb.c |   40
> --
>  1 files changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/video/cx88/cx88-dvb.c
> b/drivers/media/video/cx88/cx88-dvb.c
> index 003937c..6d49672 100644
> --- a/drivers/media/video/cx88/cx88-dvb.c
> +++ b/drivers/media/video/cx88/cx88-dvb.c
> @@ -501,7 +501,7 @@ static const struct cx24123_config
> kworld_dvbs_100_config = {
>        .lnb_polarity  = 1,
>  };
>
> -static const struct s5h1409_config pinnacle_pctv_hd_800i_config = {
> +static const struct s5h1409_config pinnacle_pctv_hd_800i_s5h1409_config = {
>        .demod_address = 0x32 >> 1,
>        .output_mode   = S5H1409_PARALLEL_OUTPUT,
>        .gpio          = S5H1409_GPIO_ON,
> @@ -509,7 +509,7 @@ static const struct s5h1409_config
> pinnacle_pctv_hd_800i_config = {
>        .inversion     = S5H1409_INVERSION_OFF,
>        .status_mode   = S5H1409_DEMODLOCKING,
>        .mpeg_timing   = S5H1409_MPEGTIMING_NONCONTINOUS_NONINVERTING_CLOCK,
> -};
> +};
>
>  static const struct s5h1409_config dvico_hdtv5_pci_nano_config = {
>        .demod_address = 0x32 >> 1,
> @@ -556,6 +556,16 @@ static const struct s5h1411_config
> dvico_fusionhdtv7_config = {
>        .status_mode   = S5H1411_DEMODLOCKING
>  };
>
> +static const struct s5h1411_config pinnacle_pctv_hd_800i_s5h1411_config = {
> +       .output_mode   = S5H1411_PARALLEL_OUTPUT,
> +       .gpio          = S5H1411_GPIO_ON,
> +       .mpeg_timing   = S5H1411_MPEGTIMING_NONCONTINOUS_NONINVERTING_CLOCK,
> +       .qam_if        = S5H1411_IF_44000,
> +       .vsb_if        = S5H1411_IF_44000,
> +       .inversion     = S5H1411_INVERSION_OFF,
> +       .status_mode   = S5H1411_DEMODLOCKING
> +};
> +
>  static const struct xc5000_config dvico_fusionhdtv7_tuner_config = {
>        .i2c_address    = 0xc2 >> 1,
>        .if_khz         = 5380,
> @@ -1297,16 +1307,22 @@ static int dvb_register(struct cx8802_dev *dev)
>                }
>                break;
>        case CX88_BOARD_PINNACLE_PCTV_HD_800i:
> -               fe0->dvb.frontend = dvb_attach(s5h1409_attach,
> -
> &pinnacle_pctv_hd_800i_config,
> -                                              &core->i2c_adap);
> -               if (fe0->dvb.frontend != NULL) {
> -                       if (!dvb_attach(xc5000_attach, fe0->dvb.frontend,
> -                                       &core->i2c_adap,
> -
> &pinnacle_pctv_hd_800i_tuner_config))
> -                               goto frontend_detach;
> -               }
> -               break;
> +               /* Try s5h1409 chip first */
> +               fe0->dvb.frontend = dvb_attach(s5h1409_attach,
> +
> &pinnacle_pctv_hd_800i_s5h1409_config,
> +                                       &core->i2c_adap);
> +               /* Otherwise, try s5h1411 */
> +               if (fe0->dvb.frontend == NULL)
> +                       fe0->dvb.frontend = dvb_attach(s5h1411_attach,
> +
> &pinnacle_pctv_hd_800i_s5h1411_config,
> +                                       &core->i2c_adap);
> +               if (fe0->dvb.frontend != NULL) {
> +                       if (!dvb_attach(xc5000_attach, fe0->dvb.frontend,
> +                                       &core->i2c_adap,
> +
> &pinnacle_pctv_hd_800i_tuner_config))
> +                               goto frontend_detach;
> +               }
> +               break;
>        case CX88_BOARD_DVICO_FUSIONHDTV_5_PCI_NANO:
>                fe0->dvb.frontend = dvb_attach(s5h1409_attach,
>
> &dvico_hdtv5_pci_nano_config,
> --
> 1.7.7.6
>
>

Looks good.  Thanks for taking the time to put this together.

Reviewed-by: Devin Heitmueller 

-- 
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: dheitmueller/cx23885_fixes.git and mygica x8507

[Devin Heitmueller]

On Tue, Jun 26, 2012 at 11:40 PM, Alfredo Jesús Delaiti
 wrote:
> The problem was that tvtime was set to 768, by passing a resolution to 720
> was solved. Sorry for not having tried before.
> With a resolution of 720 pixels the image looks good.
> My sincere apologies and thanks.

I'll have to check if that's a driver bug or not.  The way the logic
is supposed to work is the application is supposed to propose a size,
and if the driver concludes the size is unacceptable it should return
the size that it intends to actually operate at.  The application is
expected to read the resulting size from the driver and adjust
accordingly.

Hence, either:

1.  the driver is saying "ok" to 768 and then tvtime receives green
video from the driver.
2.  the driver properly returns 720 when asked for 768, but tvtime
doesn't check for the adjusted size.

Scenario #1 is a driver bug, and scenario #2 is a tvtime bug.

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: dheitmueller/cx23885_fixes.git and mygica x8507

[Devin Heitmueller]

On Tue, Jun 26, 2012 at 2:07 PM, Alfredo Jesús Delaiti
 wrote:
> Hi all
>
> I tried the patches made by Devin Heitmueller, and returned soundto the
> plate mygica X8507.
> Has not corrected the green band that appears on the left side and shrinks
> the image by changing a little the aspect ratio, compresses a bit
> horizontally. With kernel versions 3.0, 3.1 and 3.2 that did not happen.

Hello Alfredo,

Thanks for testing.  Glad to hear you're having some success with
those patches.  A few questions about your specific board (since I
don't have the actual hardware):

1.  Which cx2388x based chip does it have?  cx23885?  cx23887?  cx23888?
2.  Specifically which video standard are you using?  NTSC?  PAL-BG?  PAL-DK?
3.  What input are you capturing on?  Tuner?  Composite?  S-video?
4.  Can you provide a screenshot showing the problem?
5.  Are you capturing raw video, or using MPEG encoder (assuming your
board has a cx23417)?

My guess is this is some sort of problem with the video standard
selection.  All of my testing thus far has been with NTSC-M, so I
would guess there is probably some general regression in PAL or SECAM
support (which should be pretty easy to fix once I have the answers to
the above questions).

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: stk1160 linux driver

[Devin Heitmueller]

On Mon, Jun 25, 2012 at 10:36 AM, Ezequiel Garcia  wrote:
> I've added Devin in Cc:
> Devin: You said you ran into some issues on em28xx on ARM, what kind
> of issues?

There are a handful of issues, but the big one which everybody runs
into is a typo in a left shift operation that causes capture to be
completely broken on ARM.  I just never got around to sending a patch
upstream for it.

I don't know if this is the original report, but the issue is
summarized well here:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28407.html

Others issue related to memory allocation on platforms like ARM with
limited coherent memory (if the device is unplugged/replugged often,
the device won't be able to allocate the URB buffers), as well as
performance problems related to the type of memory used (dependent on
which ARM chip is used).

Most of this stuff is relatively straightforward to fix but I've just
been too busy with other projects.

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: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Fri, Jun 22, 2012 at 11:55 AM, Mack Stanley  wrote:
> So, keeping all of the configuration settings exactly the same and
> simply using s5h1411_attach instead of s5h1409_attach works perfectly.
> Maybe the easiest path is just to have the driver try one, if it fails,
> try the other.

I actually don't have a sample of the new board, so if you wanted to
submit a patch upstream which does the following, that would be great:

1.  in cx88-dvb.c, do the dvb_attach() call against the s5h1409 just
as it was before
2.  If the dvb_attach() call returns NULL for the 1409, make the
attach call against the s5h1411.

Submit it to the linux-media mailing list to to solicit people willing
to test.  This is mostly to make sure that it doesn't break the 1409
based boards.  By doing the 1409 attach first, there is a high
likelihood that it won't cause a regression (if you did the 1411
attach first, there is greater risk that you will cause breakage for
the 1409 boards).

Be sure to include the "Signed-Off-By" line which is a requirement for
it to be accepted upstream.  I'll eyeball the patch and put a
"Reviewed-by" line on it.

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: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Fri, Jun 22, 2012 at 11:55 AM, Mack Stanley  wrote:
> Your absolutely right about the tuning problem.  The VID's and AID's
> were all wrong.  The card seems to have been choosing more at less at
> random among the channels on the same frequency.  I copied the correct
> VID's and AID's out of the DTA by hand and now everything is A-OK.

That's not the card.  It's the scanning app that is screwed up.  The
card knows absolutely nothing about parsing PAT/PMT info and figuring
out which PIDs are tied to which streams.  If you've got another
capture card, you should see the exact same behavior.

> So, keeping all of the configuration settings exactly the same and
> simply using s5h1411_attach instead of s5h1409_attach works perfectly.
> Maybe the easiest path is just to have the driver try one, if it fails,
> try the other.

After discussion with my PCTV contact, I think that's probably the
correct approach (assuming the I2C addresses are different for the
1409 vs. the 1411).  Just do an attach against one, and if it fails
(returns NULL) then attempt to attach to the other.

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: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Thu, Jun 21, 2012 at 6:43 PM, Mack Stanley  wrote:
> mplayer [various options] dvb://6
>
> tunes to different channels different times, sometimes to video from one
> channel and sound from another, sometimes to video but no sound.

I would try tuning to the same channel multiple times and see if it
behaves *consistently*.  In other words, does it always tune to the
same "wrong" channel or consistently show the same wrong audio/video
stream.  My guess is this has nothing to do with the card but rather
is a problem with the scanner putting the right values into the
channels.conf (wrong video/audio PIDs in the file).

> I'll be interested in what your contacts at pctv suggest.

I'm going back and forth with my PCTV contact.  He says the chip was
swapped out and there weren't any other changes to the PCB.  However
as you discovered, driver changes are required.  Should be pretty easy
to get working.

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: [PATCH] [media] drxk: change it to use request_firmware_nowait()

[Devin Heitmueller]

On Thu, Jun 21, 2012 at 9:36 AM, Mauro Carvalho Chehab
 wrote:
> The firmware blob may not be available when the driver probes.
>
> Instead of blocking the whole kernel use request_firmware_nowait() and
> continue without firmware.
>
> This shouldn't be that bad on drx-k devices, as they all seem to have an
> internal firmware. So, only the firmware update will take a little longer
> to happen.

The patch itself looks fine, however the comment at the end probably
isn't valid. Many of the drx-k devices don't have onboard flash, and
even for the ones that do have flash, uploading the firmware doesn't
actually rewrite the flash.  It patches the in-RAM copy (or replaces
the *running* image).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx : can work on ARM beagleboard ?

[Devin Heitmueller]

On Wed, Jun 20, 2012 at 10:12 PM, Julia  wrote:
> hi Devin,
> i don't understand what you mean when you say "analog support for the em28xx 
> is
> known to be broken on ARM right now'', I hope you can give me some advice.
>
> I use Pinnacle DVC100 capture card on cm-t3530 card to capture analog images.
> cm-t3530 uses linux 2.6.32 kernel. at first the card can be correctly detected
> and by the cm-t3530 and generated as the device file /dev/video1.
>
>
> but when I use some application to capture the images by use of v4l2,there is
> something wrong and the strace of the application shows the error message is
> "ioctl(3, VIDIOC_DQBUF, 0xbeeb4a00)      = ? ERESTARTSYS (To be restarted)". 
> The
> same application can correctly capture my usb-camera images.
>  does the problem can be solved?  I am yearning for  your advice.

Hello Julia,

Yeah, the driver is broken with analog on ARM.  I did some work for a
commercial customer (in fact, also on a Compulab board), but haven't
had a chance to clean up any of the patches and get them upstream.

It's likely the problem you are hitting can be fixed by the patch
described here:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg28194.html

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: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Wed, Jun 20, 2012 at 5:31 PM, Mack Stanley  wrote:
> Dear Mr. Pascoe,
>
> I'm writing to you as the maintainer of the cx88-dvb kernel module.
>
> I recently bought a pci tv card that the kernel identifies as supported:
>
> 05:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
> CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
> Subsystem: Pinnacle Systems Inc. Device [11bd:0051]
>
> My card appears to be the same card as this Pinnacle card
> (http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_%28800i%29)
> except that it has a Samsung S5H1411 chip in place of the S5H1409 on the
> original Pinnacle card identified by the kernel.
>
> My card is branded "PCTV HD PCI Card 800i"
> (http://www.pctvsystems.com/Products/ProductsNorthAmerica/HybridproductsUSA/PCTVHDCard/tabid/171/language/en-US/Default.aspx),
> though I bought it as a Hauppauge card
> (http://www.newegg.com/Product/Product.aspx?Item=15-116-043&SortField=0&SummaryType=0&Pagesize=10&PurchaseMark=&SelectedRating=-1&VideoOnlyMark=False&VendorMark=&IsFeedbackTab=true&Keywords=linux&Page=1#scrollFullInfo).
>
> Because of the changed chip, "dvb_attach" returns NULL, so the cx88-dvb
> module fails to insert, and no /dev/dvb nodes are created.
>
> I was able to get around this by copying s5h1411_config
> dvico_fusionhdtv7_config to a new
> "s5h1411_config pinnacle_pctv_hd_800i_config", then replacing
> s5h1409_attach with s5h1411_attach in
> case CX88_BOARD_PINNACLE_PCTV_HD_800i in the definition of dvb_register.
>
> I built against headers for Fedora 16 kernel 3.3.8-1.fc16.x86_64.  The
> result loads normally and creates /dev/dvb/adaper0 containing demux0,
> dvr0,  frontend0,  and net0.
>
> "w_scan -fa -A2 -c US -x " produces a long list of frequencies, all but
> two of which are in us-Cable-IRC-center-frequencies-QAM256. However,
> w_scan finds no "services" and I haven't been able to coax either
> scandvb or scte65scan into finding any channels. I don't know whether
> this is because my shot-in-the-dark modification to cx88-dvb doesn't
> work, or because Comcast has some screwy way of sending signals to its
> DTA's.
>
> I'm of course more than happy to help in any way.
>
> Thanks for your time,
> Mack

Hmmm, ok.  Let me talk to my contacts at PCTV and see what the deal is
there.  My guess is the 1409 reached end of life, so they had to
switch to the 1411.

I'm pretty surprised that they didn't bump the PCI ID though.  I'll
find out if they're relying on the eeprom to know which demod is
present.

The scan is probably failing due to something like a mismatched IF
output frequency.

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] [media] cx231xx: restore tuner settings on first open

[Devin Heitmueller]

Hi David,
> It sounds like we want a solution that
>      * lives in core code
>      * doesn't require tuner drivers to save state
>      * manages hybrid tuners appropriately
>      * allows for gradual API change-over (no flag day for tuners or
>        for capture devices)
>      * has a reasonable grace period before putting tuner to standby

These seem like pretty reasonable working requirements to start with.

> Aside from the entering standby issue, fixing the loss of mode/frequency
> looks like it may be fixable by just having the capture cards explicitly
> request the tuner become active -- the tuner core will already restore
> those for us. It's just that few cards do that today.

The challenge is *when* do those cards request the tuner become
active?  In response to what ioctl() calls?

> Is it safe to say that the tuner core will know about all hybrid tuners,
> even if it doesn't know if the digital side is still in use?

The tuner-core is used for pretty much every hybrid tuner I know of
except for saa7164, which from what I understand controls the tuners
directly.

> Can a single tuner be used for both digital and analog tuning at the
> same time?

No.  However one mode is often used *immediately* after the other.
I've seen quite a few race conditions over the years that had to do
with closing the v4l2 device and then immediately opening the DVB
device (or vice versa).

> I'm wondering if just having a simple counter would work, with the
> digital side calling for power just as the capture side should already
> be doing. If the count is non-zero on a standby call, don't do anything.
> If it goes to zero, then schedule the HW standby. The challenge would
> seem to be getting the DVB system to call into the tuner-core (or other
> proper place).

There is a ts_ctrl() callback in the dvb frontend which could be used
by the digital side to "claim" that it's using the tuner.

You may also wish to consider this in the context of allowing either
side to "lock" the tuner to prevent callers from attempting to use it
in both analog and digital mode simultaneously.  This is a huge
outstanding problem for hybrid tuners, where applications like MythTV
will attempt to use the device in both modes at the same time
(thinking they are separate tuners), and the failure to return
something like EBUSY to the second caller results in all sorts of
undefined behavior.

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] [media] cx231xx: restore tuner settings on first open

[Devin Heitmueller]

On Mon, Jun 18, 2012 at 10:32 AM, David Dillow  wrote:
> Hmm, it sounds like perhaps changing the standby call in the tuner core
> to asynchronously power down the tuner may be the way to go -- ie, when
> we tell it to standby, it will do a schedule_work for some 10 seconds
> later to really pull it down. If we get a resume call prior to then,
> we'll just cancel the work, otherwise we wait for the work to finish and
> then issue the resume.
>
> Does that sound reasonable?

At face value it sounds reasonable, except the approach breaks down as
soon as you have hybrid tuners which support both analog and digital.
Because the digital side of the tuner isn't tied into tuner-core,
you'll break in the following situation:

Start using analog
Stop using analog [schedule_work() call]
Start using digital
Timer pops and powers down the tuner even though it's in use for ATSC
or ClearQAM

Again, I'm not proposing a solution, but just poking a fatal hole in
your proposal (believe me, I had considered the same approach when
first looking at the problem).

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] [media] cx231xx: restore tuner settings on first open

[Devin Heitmueller]

On Mon, Jun 18, 2012 at 10:15 AM, David Dillow  wrote:
>> Tuner standards and frequencies must be persistent. So cx231xx is wrong.
>> Actually, all V4L2 settings must in general be persistent (there are
>> some per-filehandle settings when dealing with low-level subdev setups or
>> mem2mem devices).
>
> Is there a document somewhere I can reference; I need to go through the
> cx231xx driver and make sure it is doing the right things and it would
> be handy to have a checklist.

This isn't just the cx231xx driver.  Almost all USB devices that have
tuners which support power management have this problem
(em28xx/au0828/cx231xx with Xceive or tda18271 tuners).  Really the
tuner_core should be resending the set_params call to the tuner after
waking it up (it shouldn't be the tuner's responsibility to remember
its settings).

The other thing to watch out for is that the API is pretty brittle in
terms of cases where initializing the tuner takes a long time.  In the
case of the Xceive tuners it can take upwards of ten seconds on
devices with slow i2c busses (au0828 in particular due to a hardware
bug in clock stretching), and the 18271 initialization has a
"calibration loop" which can take 5-10 seconds.  Hence you would have
to be very careful in terms of figuring out where to put the call to
reset the tuner, since you don't want every call to v4l2-ctl taking
ten seconds.

And of course you don't want to leave the tuner running if it's no
longer in use (since it will run down the battery on laptops),
although figuring out when that is can be nearly impossible if the
sequence of events is a series of calls to the v4l2-ctl command line
tool followed by reading from the device node.

I'm certainly in favor of this long-standing problem being fixed, but
it will take considerable investigation to figure out the right place
to make the change.

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: hdpvr lockup with audio dropouts

[Devin Heitmueller]

On Thu, Jun 7, 2012 at 7:53 PM,   wrote:
> Apparently there is a known issue where the HD-PVR cannot handle the loss of 
> audio signal over SPDIF while recording.  If this happens, the unit locks up 
> requiring it to be power cycled before it can be used again. This behavior 
> can easily be reproduced by pulling the SPDIF cable during recording.  My 
> question is this:  are there any changes that could be made to the hdpvr 
> driver that would make it more tolerant of brief audio dropouts?

Does it do this under Windows?  If it does, then call Hauppauge and
get them to fix it (and if that results in a firmware fix, then it
will help Linux too).  If it works under Windows, then we know it's
some sort of driver issue which would be needed.

It's always good when it's readily reproducible.  :-)

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: Fwd: [Bug 827538] DVB USB device firmware requested in module_init()

[Devin Heitmueller]

On Mon, Jun 4, 2012 at 9:32 AM, Brian J. Murrell  wrote:
> On 12-06-03 05:01 PM, Antti Palosaari wrote:
>>
>> That firmware downloading patch is done top of my new dvb-usb
>> development tree. I have converted very limited set of drivers for that
>> tree, af9015, au6610, ec168 and anysee (and those are only on my local
>> hard disk). I tried to backport patch for the current dvb-usb but I ran
>> many problems and gave up. Looks like it is almost impossible to convert
>> old dvb-usb without big changes...
>>
>> So what driver you are using?
>
> I'm using the hvr-950q per
> https://bugzilla.kernel.org/show_bug.cgi?id=43145 and
> https://bugzilla.kernel.org/show_bug.cgi?id=43146.
>
>> It is possible I can convert your driver
>> too and then it is possible to test.
>
> Great.  Ideally it would be great to get this backported and applied to
> the linux 3.2.0 release stream.

The 950q doesn't use the dvb-usb framework (nor does it load the
firmware at init).  Whatever is going on there is completely unrelated
to what Antti is debugging.

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: HVR1600 and Centos 6.2 x86_64 -- Strange Behavior

[Devin Heitmueller]

On Tue, May 22, 2012 at 4:34 PM, Bob Lightfoot  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear LinuxTv and AtRpms Communities:
>     In the most recent three kernels {2.6.32-220.7.1 ;
> 2.6.32-220.13.1 ; 2.6.32-220.17.1} released for CentOS 6.2 I have
> experienced what can only be described as a strange behavior of the
> V4L kernel modules with the Hauppage HVR 1600 Card.  If I reboot the
> PC in question {HP Pavillion Elite M9040n} I will lose sound on the
> Analog TV Tuner.  If I Power off the PC, leave it off for 30-60
> seconds and start it back up then I have sound with the Analog TV
> Tuner every time.  Not sure what is causing this, but thought the
> condition was worth sharing.

Could you please clarify which HVR-1600 board you have (e.g. the PCI
ID)?  I suspect we're probably not resetting the audio processor
properly, but I would need to know exactly which board you have in
order to check that.

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: [RFCv1] DVB-USB improvements [alternative 2]

[Devin Heitmueller]

On Sun, May 20, 2012 at 6:30 PM, VDR User  wrote:
> On Sun, May 20, 2012 at 1:55 PM, Antti Palosaari  wrote:
>> I did some more planning and made alternative RFC.
>> As the earlier alternative was more like changing old functionality that new
>> one goes much more deeper.
>
>> Functionality enhancement mentioned earlier RFC are valid too:
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg46352.html
>
> One thing I didn't see mentioned in your post or the one your linked
> is the rc dependency for _all_ usb devices, whether they even have rc
> capability or not. It makes sense that is dvb usb is going to get
> overhauled, that rc functionality be at the very least optional rather
> than forced it on all usb devices.

If you think this is important, then you should feel free to submit
patches to Antti's tree.  Otherwise, this is the sort of optimization
that brings so little value as to not really be worth the engineering
effort.  The time is better spent working on problems that *actually*
have a visible effect to users (and a few extra modules being loaded
does not fall into this category).

I think you'll find after spending a few hours trying to abstract out
the logic and the ugly solution that results that it *really* isn't
worth it.

Regards,

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: How I must report that a driver has been broken?

[Devin Heitmueller]

On Fri, May 18, 2012 at 10:15 AM, Alfredo Jesús Delaiti
 wrote:
> Hi
>
> Thank you all for your responses.
>
> Devin, I appreciate the time and labor you do to revise the code.
>
> My previous letters maybe I can help you see where the problem and the date
> you began.
> I thought of a patch of this type:
>
> if (card != mycard) {
>
> "bad code for my card"}
>
> but unfortunately not so easy for me.

Some initial analysis of the driver code I did last night suggests
it's much more complicated than that (in addition to the HVR-1850
support there was a bunch of refactoring done to the both the cx23885
and cx25840 drivers).

You can keep an eye on http://www.kernellabs.com/blog for updates.

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: How I must report that a driver has been broken?

[Devin Heitmueller]

On Sun, May 13, 2012 at 1:50 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 05/12/2012 09:26 PM, Alfredo Jesús Delaiti wrote:
>>
>> Hi
>>
>> Thanks for your response Hans and Patrick
>>
>> Maybe I doing wrong this, because it reports twice:
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg45199.html
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg44846.html
>
>
> In your last message you indicate that you've found the patch causing it,
> and that you were looking into figuring which bit of the patch actually
> breaks things, so I guess people reading the thread were / are
> waiting for you to follow up on it with the results of your attempts
> to further isolate the cause.
>
> What I were do if I were you is send a mail directly to the author
> of the patch causing the problems, with what you've discovered
> about the problem sofar in there, and put the list in the CC.
>
> Regards,
>
> Hans

Steven loaned me his HVR-1850 board last week, and I'm hoping to debug
the regression this week (I have an HVR-1800 that is also effected).
I suspect the problem is related to a codepath for the cx23888's
onboard DIF being executed for 885 based boards.  Steven did a whole
series of patches to make the cx23888 work properly and I think a
regression snuck in there.  Simply backing out the change isn't the
correct fix.

I've got all the boards and the datasheets - I just need to find a bit
of time to get the current tree installed onto a machine and plug in
the various boards...

In short, it's in my queue so please be patient.

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: [PATCH 2/2] au0828: Move under dvb

[Devin Heitmueller]

On Fri, May 11, 2012 at 11:08 PM, Ismael Luceno  wrote:
> On Fri, 11 May 2012 08:04:59 -0400
> Devin Heitmueller  wrote:
> ...
>> What is the motivation for moving these files?
>
> Well, the device was on the wrong Kconfig section, and while thinking
> about changing that, I just thought to move it under DVB.
>
>> The au0828 is a hybrid bridge, and every other hybrid bridge is
>> under video?
>
> Sorry, the devices I got don't support analog, so I didn't thought
> about it that much...
>
> I guess it's arbitrary... isn't it? wouldn't it be better to have an
> hybrid section? (just thinking out loud)

Yeah, in this case it's largely historical (a product from before the
V4L and DVB subsystems were merged).  At this point I don't see any
real advantage to arbitrarily moving the stuff around.  And in fact in
some areas it's even more ambiguous because some drivers are hybrid
drivers but support both hybrid chips as well as analog-only (the
em28xx driver is one such example).

Anyway, Mauro is welcome to offer his opinion if it differs, but as
far as I'm concerned this patch shouldn't get applied.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] au0828: Move under dvb

[Devin Heitmueller]

On Fri, May 11, 2012 at 2:14 AM, Ismael Luceno  wrote:
> Signed-off-by: Ismael Luceno 
> ---
>  drivers/media/dvb/Kconfig                          |    1 +
>  drivers/media/dvb/Makefile                         |    1 +
>  drivers/media/{video => dvb}/au0828/Kconfig        |    0
>  drivers/media/{video => dvb}/au0828/Makefile       |    0
>  drivers/media/{video => dvb}/au0828/au0828-cards.c |    0
>  drivers/media/{video => dvb}/au0828/au0828-cards.h |    0
>  drivers/media/{video => dvb}/au0828/au0828-core.c  |    0
>  drivers/media/{video => dvb}/au0828/au0828-dvb.c   |    0
>  drivers/media/{video => dvb}/au0828/au0828-i2c.c   |    0
>  drivers/media/{video => dvb}/au0828/au0828-reg.h   |    0
>  drivers/media/{video => dvb}/au0828/au0828-vbi.c   |    0
>  drivers/media/{video => dvb}/au0828/au0828-video.c |    0
>  drivers/media/{video => dvb}/au0828/au0828.h       |    0
>  drivers/media/video/Kconfig                        |    2 --
>  drivers/media/video/Makefile                       |    2 --
>  15 files changed, 2 insertions(+), 4 deletions(-)
>  rename drivers/media/{video => dvb}/au0828/Kconfig (100%)
>  rename drivers/media/{video => dvb}/au0828/Makefile (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-cards.c (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-cards.h (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-core.c (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-dvb.c (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-i2c.c (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-reg.h (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-vbi.c (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828-video.c (100%)
>  rename drivers/media/{video => dvb}/au0828/au0828.h (100%)

What is the motivation for moving these files?  The au0828 is a hybrid
bridge, and every other hybrid bridge is under video?

NACK unless somebody can provide a good reason for doing this.

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: [RFCv1] DVB-USB improvements

[Devin Heitmueller]

On Thu, May 10, 2012 at 10:14 AM, Mauro Carvalho Chehab
 wrote:
> In order to add analog support, it is likely simpler to take em28xx (mainly 
> em28xx-video) as an
> example on how things are implemented on analog side. The gspca 
> implementation may also help a
> lot, but it doesn't contain the tuner bits.

Antti,

If you do decide to take on analog in dvb-usb and use em28xx as a
model, bear in mind that the locking between analog and digital is
*totally* broken.  You can open both the analog and digital devices
simultaneously, causing completely unpredictable behavior.  I'm just
mentioning this because this is something you should *not* model after
em28xx, and because it's a huge headache for real users (lack of
locking causes all sorts of end-user problems in MythTV and other
applications that support both analog and digital).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx : can work on ARM beagleboard ?

[Devin Heitmueller]

On Tue, May 8, 2012 at 2:24 PM, Antti Palosaari  wrote:
> It should work as I know one person ran PCTV NanoStick T2 290e using
> Pandaboard which is rather similar ARM hw.
> http://www.youtube.com/watch?v=Wuwyuw0y1Fo

I ran into a couple of issues related to em28xx analog on ARM.
Haven't had a chance to submit patches yet.  To answer the question
though:  yes, analog support for the em28xx is known to be broken on
ARM right now.

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: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

On Thu, May 3, 2012 at 12:06 PM, Brian J. Murrell  wrote:
> But as I mentioned before, it's now completely non-functional due to the
> coax connector on the card having become loose enough to turn (with some
> effort, so screwing an female F-connector on/off was still quite
> doable).  Perhaps it was marginal before due to that same problem.  I
> guess I will never know... unless I try cracking this thing open and
> reconnecting whatever has gotten disconnected -- if Hauppage won't RMA
> it for me.  They seem to be pretty silent about that now though after an
> initial e-mail exchange.

If the F-connector is loose, that can *definitely* explain the
problem.  Let me know if you have problems getting an RMA.

> If not, I've got my eye on a KWorld UB435-Q if I can determine that it's
> a hardware rev. 1 unit somehow since the store doesn't want to take it
> out of the box to check for me.  It's less than half the price of an
> HVR-950Q at $40, as much as I would love to stay loyal with Hauppage --
> this coax connector on my HVR-1600 coming loose, aside.

Even if they take it out of the box, you would be unlikely to be able
to determine the revision without plugging it in to something and
checking the USB ID.

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: common DVB USB issues we has currently

[Devin Heitmueller]

Hi Antti,

On Thu, May 3, 2012 at 10:18 AM, Antti Palosaari
> 1)
> Current static structure is too limited as devices are more dynamics
> nowadays. Driver should be able to probe/read from eeprom device
> configuration.
>
> Fixing all of those means rather much work - I think new version of DVB USB
> is needed.
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg44996.html

What does this link above have to do with problem #1?  Did you perhaps
cut/paste the wrong link?

> 2)
> Suspend/resume is not supported and crashes Kernel. I have no idea what is
> wrong here and what is needed. But as it has been long term known problem I
> suspect it is not trivial.
>
> http://www.spinics.net/lists/linux-media/msg10293.html

I doubt this is a dvb-usb problem, but rather something specific to
the realtek parts (suspend/resume does work with other devices that
rely on dvb-usb).

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

Resending with the ML back on the cc:.

On Wed, May 2, 2012 at 11:29 PM, Brian J. Murrell  wrote:
> On 12-04-29 08:09 PM, Devin Heitmueller wrote:
>>
>> I don't know why you're not seeing valid data on femon with the 950q.
>> It should be printing out fine, and it's on the same 0.1 dB scale.
>> Try running just azap and see if the SNR is reported there.
>
> $ azap -c ~/last-channel-scan.prev 100-3
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 65100 Hz
> video pid 0x, audio pid 0x07c1
> status 00 | signal  | snr  | ber  | unc  |
> status 1f | signal  | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr  | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr  | ber  | unc  | FE_HAS_LOCK
> status 1f | signal  | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal  | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal  | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr  | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr  | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber  | unc  | FE_HAS_LOCK
> status 1f | signal 0190 | snr  | ber  | unc  | FE_HAS_LOCK
> status 1f | signal  | snr 0190 | ber  | unc  | FE_HAS_LOCK
> ...
>
> Doesn't seem to be useful values.

That actually is useful data.  The SNR of 0x190 means 40.0 dB (which
is a max good signal).  The fact that it sometimes goes between 0x190
and 0x000 is actually a bug in the driver I discovered a couple of
months ago but haven't submitted a patch for.  In fact it's strong
enough that you might actually be over driving the tuner and may wish
to try an attenuator.

This suggests the signal is fine (although I would probably run it for
longer and make sure you don't see intermittent UNC conditions).  And
you're using the exact same cabling for the 1600 as you are for the
950q above?

Also, which version of the HVR-1600 is this?  The one with the
mxl5005s or the tda18271?  You can check the dmesg output to tell (and
if you cannot tell, please pastebin the dmesg output so I can look).

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: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

Oh, and as Andy suggested, please provide a sample of the azap or
femon output for the HVR-1600 where you don't grep out the lines, so
we can see what the SNR looks like before and after the point in time
when the uncorrectable errors occurred.

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: HVR-1800 Analog Driver: MPEG video broken

[Devin Heitmueller]

On Wed, May 2, 2012 at 3:23 PM,   wrote:
> I just tried again with a live CD running kernel 3.2 and got clean video with 
> cat /dev/video1 > /tmp/foo.mpg.  So there is a definitely a regression here.  
> Please let me know what I can do to help track it down.

I'm already about 95% certain this was something introduced in
Steven's last batch of cx23885 changes for the HVR-1850.  I just need
to do a register dump for both the working and failing case, see which
register got screwed up on the 1800, then look at the code figure out
how it got into that state.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HVR-1800 Analog Driver: MPEG video broken

[Devin Heitmueller]

On Wed, May 2, 2012 at 9:32 AM,   wrote:
> I have been testing the latest cx23885 driver built from 
> http://git.kernellabs.com/?p=stoth/cx23885-hvr1850-fixups.git;a=summary 
> running on kernel 3.3.4 with my HVR-1800 (model 78521).  I am able to watch 
> analog TV with tvtime using the raw device, /dev/video0.  But if I try to use 
> it with the MPEG device, /dev/video1, I briefly get a blue screen and then 
> tvtime segfaults.

Tvtime segfaulting if you try to use it on an MPEG device is a known
tvtime bug.  Tvtime lacks an MPEG decoder, and only works with devices
that support raw video.

cat /dev/video1 > /tmp/foo.mpg gives video with moving, distorted,
mostly black and white diagonal lines just like @Britney posted here:
http://www.kernellabs.com/blog/?p=1636.

Yup, I've been going back and forth with bfransen on this.  I received
a board last week, and am hoping to debug it this week.

Regards,

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: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

On Sun, Apr 29, 2012 at 4:27 PM, James Courtier-Dutton
 wrote:
> There are two measurements.
> 1) SNR.
> This is a measure of the quality of the signal. Bigger is better. 30dB is a
> good value. Spliters and amplifiers should only slightly reduce the SNR
> value.

30 dB for ClearQAM is actually a very marginal SNR.  It caps out at 40
dB, and as Andy pointed out, it's a logarithmic scale.  On a good
cable plant, you should expect an SNR between 35 and 40.  Anything
below 32 and you're very likely to have significant error rates.
Don't confuse it with Over-the-Air ATSC, which will typically cap out
at 30.0 dB.

I don't know why you're not seeing valid data on femon with the 950q.
It should be printing out fine, and it's on the same 0.1 dB scale.
Try running just azap and see if the SNR is reported there.

This indeed feels like a marginal signal condition problem, and Andy's
assertion is well founded that the mxl5005/s5h1409 isn't exactly the
best combo compared to more modern tuners and demodulators (Hauppauge
switched to the tda18271 and s5h1411 for the newer revision of the
HVR-1600).  The Linux driver support should be on-par with Windows
though in terms of performance as I did a bunch of work some time back
to analyze the differences which resulted in some fixes.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CX23885 MSI

[Devin Heitmueller]

On Fri, Apr 20, 2012 at 7:34 AM, James Courtier-Dutton
 wrote:
> Hi,
>
> I noticed that the CX23885 driver does not set it up to use MSI.
> I don't have the datasheets. Is there any know reason not to use MSI
> with this PCI Express card?
> I just want to know before I spend time enabling MSI for this device.
> It is my understanding that MSI is generally preferred over previous
> IRQ methods.

It was disabled intentionally by Andy due to a compatibility problem.
Search the ML archives for the following subject for more details:

"HVR-1250/CX23885 IR Rx"

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: Unknown eMPIA tuner

[Devin Heitmueller]

On Tue, Apr 10, 2012 at 11:24 AM, Stefan Monnier
 wrote:
>>> I just got a USB tuner ("HD TV ATSC USB stick") which lsusb describes as
>>> "ID eb1a: eMPIA Technology, Inc." and was wondering how to try to
>>> get it working.
>>> Would the em28xx driver be able to handle it?  If so, how should I modify
>>> it to try it out?
>> You would probably have to start by taking it apart and seeing which
>> demodulator and tuner chips it contained.
>
> Hmm... how would I go about taking it apart without destroying it?
> ...hhmmm... apparently, a bit of brute force did the trick (at least
> for the "taking it apart" bit, not sure about the "without destroying
> it" yet).
>
> On one side I see a small IC that says something like "Trident \n DRX
> 3933J B2".
>
> On the other side I see 2 ICs that say respectively "eMPIA \n ?M2874B"
> and "NXP \n TDA182?1HDC2 \n P3KNR" (the ? might be a slash or a 7) plus
> a third tiny "24C??? \n FTG..." but I don't think that one
> is significant.

Ok, so it's an em2874/drx-j/tda18271 design, which in terms of the
components is very similar to the PCTV 80e (which I believe Mauro got
into staging recently).  I would probably recommend looking at that
code as a starting point.  That said, you'll need to figure out the
correct IF frequency, the drx-j configuration block, the GPIO layout,
and the correct tuner config.  If those terms don't mean anything to
you, then you are best to wait until some developer stumbles across
the device and has the time to add the needed support.

In other words, all the core chips are supported, but you would have
to be able to figure out the correct glue that describes how the
components are actually wired up in this particular hardware design.

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: [PATCH] media: au0828: Convert BUG_ON to WARN_ONCE

[Devin Heitmueller]

On Sun, Apr 8, 2012 at 7:19 PM, Larry Finger  wrote:
> In the mail thread at 
> http://www.mythtv.org/pipermail/mythtv-users/2012-April/331164.html,
> a kernel crash is triggered when trying to run mythtv with a HVR950Q tuner.
> The crash condition is due to res_free() being called to free something that
> has is not reserved. The actual reason for this mismatch of reserve/free is
> not known; however, using a BUG_ON rather than a WARN_ON seems unfortunate.

This patch should be nack'd.  The real reason should be identified,
and a patch should be submitted for that (and from what I gather, it
seems like it is easily reproduced by the submitter).  Just add a few
"dump_stack()" calls in the res_get() and res_free() calls to identify
the failing call path.

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: Unknown eMPIA tuner

[Devin Heitmueller]

On Thu, Apr 5, 2012 at 3:30 PM, Stefan Monnier  wrote:
> I just got a USB tuner ("HD TV ATSC USB stick") which lsusb describes as
> "ID eb1a: eMPIA Technology, Inc." and was wondering how to try to
> get it working.
>
> Would the em28xx driver be able to handle it?  If so, how should I modify
> it to try it out?

You would probably have to start by taking it apart and seeing which
demodulator and tuner chips it contained.  Once those are known, we
can assess whether there are drivers for those components under Linux
today.

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: NTSC_443 problem in v4l and em28x

[Devin Heitmueller]

On Mon, Apr 2, 2012 at 5:02 PM, Colin Eby  wrote:
> There's clear evidence I can get some kind of tool chain to work in
> Windows. But I wondered if there wasn't some fine tuning to the driver
> that would get Linux rig to work.  And I wondered if there were known
> issues around the NTSC_443 norm. Forgive me if I've missed any, but I
> haven't found any so far.

It's probably also worth mentioning that if you want to try to debug
this yourself, the problem is probably in the saa711x driver (the
video decoder chip in the Dazzle), not the em28xx driver.

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: NTSC_443 problem in v4l and em28x

[Devin Heitmueller]

On Mon, Apr 2, 2012 at 5:02 PM, Colin Eby  wrote:
> There's clear evidence I can get some kind of tool chain to work in
> Windows. But I wondered if there wasn't some fine tuning to the driver
> that would get Linux rig to work.  And I wondered if there were known
> issues around the NTSC_443 norm. Forgive me if I've missed any, but I
> haven't found any so far.

I've done a bunch of work on that driver, and the answer is probably
really simple - 443 is so rare that none of the developers has the
playback hardware to test with.  I'm not even sure my analog signal
generator will output the format.

Unfortunately, until some developer needs it to work and has the time
to debug it, you're probably out of luck.

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 HVR 930C-HD - new USB ID 2040:b130 ?

[Devin Heitmueller]

On Mon, Mar 26, 2012 at 10:46 AM, Devin Heitmueller
 wrote:
> 2040:b130 isn't an em28xx based device.  It uses cx231xx.  That said,
> it's not supported under Linux not because of the cx231xx driver but
> because there is no driver for the demodulator (si2163).

Correction:  it's an si2165 (not 2163).

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 HVR 930C-HD - new USB ID 2040:b130 ?

[Devin Heitmueller]

On Sun, Mar 25, 2012 at 4:09 PM, Steffen Neumann  wrote:
> Hi,
>
> I am trying to get a Hauppauge WinTV HVR 930C-HD
> to work under Ubuntu 12.04 with the vanilla 3.3 kernel from [1].
> After (manually) loading the em28xx module,
> there are no additional messages in kern.log,
> only "registered new interface driver em28xx".
>
> What is odd is that lsusb shows for this card "ID 2040:b130 Hauppauge",
> while from [2] I think it should be [2040:1605],
> see below for the full lsusb -v output. The card
> was purchased this week.
>
> Do I have a new revision of the 930C ?
> I tried "modprobe em28xx card=81", but no change.
> Did I miss anything else ?

2040:b130 isn't an em28xx based device.  It uses cx231xx.  That said,
it's not supported under Linux not because of the cx231xx driver but
because there is no driver for the demodulator (si2163).

Nobody is working on such a driver, and there is no support planned
for this device at this time.

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: [Q] v4l buffer format inside isoc

[Devin Heitmueller]

2012/3/21 Ezequiel García :
> Ok. So, it's not saa7113 related, but rather stk1160 related?

Yes.

> When there is no video, isoc urbs are received with actual length=4.
> This is header right?

I'm not sure what you mean by "no video".  Do you have capture
disabled?  Are you saying that you didn't connect the video cable to
your input?  Most devices will continue to generate video frames over
isoc even if there is no actual video signal present.

But yeah, most of the solutions I have seen have every isoc packet
starting with a header that includes descriptors for things like start
of video frame, odd/even field, etc.

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: [Q] v4l buffer format inside isoc

[Devin Heitmueller]

2012/3/21 Ezequiel García :
> 2012/3/20 Andy Walls :
>
>>
>> Section 8.10 of the SAA7113 data sheet shows 16 "data formats".  The
>> interesting one for video is #15 Y:U:V 4:2:2.

Every USB bridge provides their raw video over isoc in a slightly
different format (not just in terms of the colorspace but also how to
read the isoc header to detect the start of video frame, which field
is being sent, etc).  Regarding the colorspace, in many cases it's
simply 16-bit YUYV, so I would probably start there.

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: [PATCH 1/2] [media] dib0700: Drop useless check when remote key is pressed

[Devin Heitmueller]

On Tue, Mar 13, 2012 at 1:50 PM, Jean Delvare  wrote:
> struct dvb_usb_device *d can never be NULL so don't waste time
> checking for this.
>
> Rationale: the urb's context is set when usb_fill_bulk_urb() is called
> in dib0700_rc_setup(), and never changes after that. d is dereferenced
> unconditionally in dib0700_rc_setup() so it can't be NULL or the
> driver would crash right away.
>
> Signed-off-by: Jean Delvare 
> Cc: Mauro Carvalho Chehab 
> Cc: Devin Heitmueller 
> ---
> Devin, am I missing something?

I think this was just a case of defensive coding where I didn't want
to dereference something without validating the pointer first (out of
fear that it got called through some other code path that I didn't
consider).

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: Mapping frontends to demuxes

[Devin Heitmueller]

2012/3/11 Rémi Denis-Courmont :
> By the way, the bt8xx driver exposes ATSC but not ITU J.83 annex B. This is
> contrary to all other ATSC frontends. Is this correct?

Many of the older cards didn't support J.83 annex B (i.e. ClearQAM).
Whether the device supports ClearQAM or not is actually controlled by
the demodulator driver, not the bridge driver.

If you provide specifically which product you are talking about (the
product name and PCI ID), it's easy enough to confirm by taking a
quick look at the source.

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: HVR-2250 remote

[Devin Heitmueller]

On Sat, Feb 18, 2012 at 12:04 PM, Joe Nahmias  wrote:
> Hello,
>
> I have a Hauppauge WinTV HVR 2250 card, which is working great for video
> using the saa7164 kernel driver.  I was wondering if the remote control
> that comes with it is supported under lirc.  I'm running Debian wheezy
> with kernel 3.2.0 and lirc 0.9.0-pre1.
>
> Thanks in advance for any help,
> --Joe

No, it is not supported.  Steven never got around to writing the
saa7164 driver support for IR.

Just spend $20 and buy yourself an MCEUSB kit.  It will probably work
better anyway (and is much easier to install than most of the IR
drivers that are for chipsets bundled with the tuners).

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: [PATCH] [media] hdpvr: update picture controls to support firmware versions > 0.15

[Devin Heitmueller]

On Tue, Feb 14, 2012 at 3:43 PM, Jarod Wilson  wrote:
> Looks sane to me, and really needs to get in ASAP. I'd even suggest we
> get it sent to stable, as these newer firmware HDPVR are pretty wonky
> with any current kernel.
>
> Acked-by: Jarod Wilson 
> Reviewed-by: Jarod Wilson 
> CC: sta...@vger.kernel.org

Where did the process break down here?  Taylor did this patch *months*
ago, and there has been absolutely no comment with why it wouldn't go
upstream.  If he hadn't been diligent in pinging the ML repeatedly, it
would have been lost.

Are there other patches that have hit the ML that aren't getting upstream?

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: PCTV 290e page allocation failure

[Devin Heitmueller]

On Tue, Feb 7, 2012 at 1:10 PM, Gianluca Gennari  wrote:
> Il 07/02/2012 15:57, Andy Furniss ha scritto:
>
>> It will still fail if it has already failed and not been replugged.
>>
>> It's not failing to allocate - it's just not trying to allocate AFAICT ,
>> which I guess counts as a bug?
>
> For what is worth, on the MIPS STB I can't even rmmod the em28xx module
> and reload it, as rmmod gets stuck.
> The only solution to get the PCTV working again is a reboot.

Which kernel are you running.  There were fixes for problems related
to rmmod em28xx not working, which were only fixed recently.  You
would have to check the linux-media ML archives for the actual details
in terms of what release the work was committed to.

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: PCTV 290e page allocation failure

[Devin Heitmueller]

On Tue, Feb 7, 2012 at 11:01 AM, Gianluca Gennari  wrote:
> Please note that the buffer size and the buffer allocation strategy (at
> runtime or at driver initialization) are two completely different
> topics. The first can cause regressions, the second should not produce
> any functional change (bugs excluded).

Agreed.  I would break this into two patches and submit the buffer
allocation strategy change first.  I think that should be able to go
upstream without too much debate/discussion.  From there we can
discuss the merits of the various approaches for the second patch
(relating to the buffer size).

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PCTV 290e page allocation failure

[Devin Heitmueller]

On Tue, Feb 7, 2012 at 5:44 AM, Gianluca Gennari  wrote:
> 1) dvb-usb drivers allocate the URBs when the device is connected, and
> they are never freed/reallocated until the device is disconnected; on
> the other hand, the em28xx driver allocates the URBs only when the data
> starts streaming and frees them when the stream stops, so the URBs are
> freed/reallocated every time the user zaps to a new channel;

Correct, the current strategy is to optimized to minimize memory use
when the device is not active, as opposed to tying up the memory when
it's not in use (obviously at the cost of the memory possibly not
being available on certain ARM/MIPS platforms).

> 2) dvb-usb drivers typically allocate 10 URBs each with a 4k buffer (but
> the exact size of the buffer is board dependent); instead, em28xx
> allocates 5 URBs with buffers of size 64xMaxPacketSize (which is 940
> byte for the PCTV 290e).
>
> This means a typical dvb-usb driver uses about 40k of coherent memory,
> while the PCTV 290e takes about 300k! And this 300k of coherent memory
> are freed/reallocated each time the user selects a new channel.
>
> I played a bit with the size of the buffers; I found out that both the
> PCTV 290e and the Terratec Hybrid XS work perfectly fine with 4k
> buffers, just like the usb-dvb drivers. So the PCTV 290e only needs 20k
> of coherent memory instead of the 300k currently allocated (this is
> equivalent to set EM28XX_DVB_MAX_PACKETS to just 4 instead of 64).

This one is a bit harder to speculate on.  Are you actually capturing
all the packets and ensuring there are no packets being dropped (e.g.
looking for discontinuities)?  Have you tried it with modulation types
that are high bandwidth?  Have you tried capturing an entire stream
with PID filtering disabled?  The change you described may "appear" to
be working when in fact it's only working for a subset of real-world
use cases.

Also, the buffer management may be appropriate for the em2874/em2884,
but be broken for other devices such as the em288[0123].  Testing
would be required to ensure it's not introducing regressions.  In
particular, the 2874/2884 had architecture changes which may result in
differences in behavior (the register map is significantly different,
for example).

> Also, I prepared a proof-of-concept patch to mimic the usb-dvb URB
> management; this means the URBs are allocated when the USB device is
> probed, and are freed when the device is disconnected (the patch code
> checks for changes in the requested buffer size, but this can never
> happen in digital mode).

I don't have any specific problem with such a change assuming it is
properly vetted against other devices.

> I've tested the patch (with 4k buffers) with both my em28xx sticks and
> both work perfectly fine on my PC as well as on my MIPS set-top-box.
> Analog mode is not tested.

Again, the big question here is surrounding your testing methodology.
If you could expand on how you're testing, that would be helpful in
assessing how well the patch will really work.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PCTV 290e page allocation failure

[Devin Heitmueller]

On Thu, Feb 2, 2012 at 6:06 PM, Gianluca Gennari  wrote:
> Il 02/02/2012 20:07, Devin Heitmueller ha scritto:
> Hi Devin,
> thanks for the explanation. The CPU is MIPS based (not ARM) but I guess
> there is not much of a difference from this point of view.
> As I mentioned in my first reply, I never had this kind of errors when I
> was using a dvb-usb USB stick. Now I'm trying to replicate the problem
> with a Terratec Hybrid XS (em28xx-dvb + zl10353 + xc2028), and so far
> I've stressed it for a few hours without problems. We will see in a day
> or two if I can make it fail in the same way.

I'm pretty sure this will happen under MIPS as well.  That said, you
will typically hit this condition if you stop streaming and then
restart it several hours into operation.  In other words, make sure
you're not just watching/streaming video for a few hours and thinking
you're stressing the particular use case.  You need to stop/start to
hit it.

I haven't looked that closely at dvb_usb's memory allocation strategy.
 Perhaps it allocates the memory up front, or perhaps it doesn't
demand coherent memory (something which will work on x86 and maybe
MIPS, but will cause an immediate panic on ARM).

I've run into this issue myself on an embedded target with em28xx and
ARM.  I plan on hacking a fix to statically allocate the buffers at
driver init, but I cannot imagine that being a change that would be
accepted into the upstream kernel.

It probably makes sense to figure out whether MIPS requires coherent
memory like ARM does.  If it doesn't then you can probably just hack
your copy of the em28xx driver to not ask for coherent memory.  If it
does require coherent memory, then you'll probably need to allocate
the memory up front.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PCTV 290e page allocation failure

[Devin Heitmueller]

On Thu, Feb 2, 2012 at 2:02 PM, Gianluca Gennari  wrote:
> I'm trying to reproduce the problem with another em28xx-dvb device to
> see if it is not restricted to the PCTV 290e. Before the PCTV 290e, I
> was using a different device with a driver based on the dvb-usb
> framework, and I never observed similar crashes.

On ARM based platforms it is very likely you will run into this issue
with most USB based tuners.  It's because over time there is memory
fragmentation that occurs which prevents being able to allocate large
enough chunks of coherent memory.

Making such a scenario work would require hacks to the driver code to
preallocate the memory in some form of static pool at system boot (or
perhaps at driver initialization), and then reuse that memory instead
of attempting to allocate it as needed.

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: removal of video/radio/vbi_nr module options?

[Devin Heitmueller]

On Fri, Jan 27, 2012 at 2:21 AM, Hans Verkuil  wrote:
> Hi all,
>
> I'm working on cleaning up some old radio drivers and while doing that I
> started wondering about the usefulness of the radio_nr module option (and
> the corresponding video_nr/vbi_nr module options for video devices).
>
> Is that really still needed? It originates from pre-udev times, but it seems
> fairly useless to me these days.

I can tell you from lurking in the mythtv-users IRC channel, that
there are still many, many users of video_nr.  Yes, they can in theory
accomplish the same thing through udev, but they aren't today, and if
you remove the functionality you'll have lots of users scambling to
figure out why stuff that previously worked is now broken.  This tends
to be more an issue with tuner cards than uvc devices, presumably
because MythTV starts up unattended and you're more likely to have
more than one capture device.

My hope is that once the media controller interface becomes more
mature (including adoption by userland applications such as Myth) that
it will eliminate the need for these sorts of hacks entirely.

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: 290e locking issue

[Devin Heitmueller]

On Thu, Jan 26, 2012 at 2:25 PM, Claus Olesen  wrote:
> I just came to think of my old 800e because also it is a em28xx device
> and for what it is worth I just tried it and it does not exhibit the
> issue. it's dmesg is

Wow, that's *really* surprising (I did both the original em2874 driver
support as well as the 800e driver, and as a result am intimately
familiar with the differences).  I'm not sure what is going on there.

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: 290e locking issue

[Devin Heitmueller]

On Thu, Jan 26, 2012 at 6:58 AM, Antti Palosaari  wrote:
> I think it is maybe some incapability of em28xx driver. Maybe it could be
> something to do with USB HCI too...

>From a USB standpoint there isn't a whole lot the em28xx driver could
do wrong.  It's an isoc device, and perhaps it's not clearing it's
bandwidth reservation after streaming is done, but even in that case
it shouldn't prevent a disk from working since those are typically
bulk devices.

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: HVR 4000 hybrid card still producing multiple frontends for single adapter

[Devin Heitmueller]

On Tue, Jan 24, 2012 at 9:58 AM, Antti Palosaari  wrote:
> So what was the actual benefit then just introduce one way more to implement
> same thing. As I sometime understood from Manu's talk there will not be
> difference if my device is based of DVB-T + DVB-C demod combination or just
> single chip that does same. Now there is devices that have same
> characteristics but different interface.

For one thing, you cannot use DVB-T and DVB-C at the same time if
they're on the same demod.  With many of the devices that have S/S2
and DVB-T, you can be using them both in parallel.  Having multiple
frontends actually makes sense since you don't want two applications
talking to the same frontend at the same time but operating on
different tuners/streams.

That said, there could be opportunities for consolidation if the
demods could not be used in parallel, but I believe that would require
a nontrivial restructuring of the core code and API.  In my opinion
the entry point for the kernel ABI should *never* have been the
demodulator but rather the bridge driver (where you can exercise
greater control over what can be used in parallel).

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: HVR 4000 hybrid card still producing multiple frontends for single adapter

[Devin Heitmueller]

On Tue, Jan 24, 2012 at 6:48 AM, Antti Palosaari  wrote:
> On 01/24/2012 06:41 AM, Hawes, Mark wrote:
>>
>> Hi,
>>
>> I have a HVR 4000 hybrid card  which provides both DVB-S2 and DVB-T
>> capabilities on the one adapter. Using the current media tree build updated
>> with the contents of the linux media drivers tarball dated 22/01/2012 the
>> drivers for this card are still generating two frontends on the adapter as
>> below:
>>
>>> Jan 23 12:16:44 Nutrigrain kernel: [    9.346240] DVB: registering
>>> adapter 1 frontend 0 (Conexant CX24116/CX24118)...
>>> Jan 23 12:16:44 Nutrigrain kernel: [    9.349110] DVB: registering
>>> adapter 1 frontend 1 (Conexant CX22702 DVB-T)...
>>
>>
>> I understand that this behaviour is now deprecated and that the correct
>> behaviour should be to generate one front end with multiple capabilities.
>> Can this please be corrected.
>
>
> Same applies for many other devices too. For example some older Anysee E7
> models have two chip and two frontends whilst new one have only one. Also
> TechnoTrend CT3650 and Hauppauge WinTV.
>
> Maybe it those are implemented later as one frontend, it not clear for me.

The merging of frontends is something that is only done if there are
multiple modulation types on the same demodulator chip.  As the
HVR-4000 has separate demods for DVB-T versus DVB-S2, they will always
be represented by two separate frontends (for the foreseeable future).

In other words, the recent work doesn't apply to this card (and others like it).

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: mygica hdcap

[Devin Heitmueller]

On Sat, Jan 21, 2012 at 11:07 AM, Nathan  wrote:
> Any progress made with this?  I have this same card and I can't find a
> datasheet for tm6200.

Nobody has written an open source driver for the tm6200 (and nobody is
in the process of doing such), and there are no publicly available
datasheets for the part.

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: Remote control driver issue

[Devin Heitmueller]

On Fri, Jan 20, 2012 at 11:14 AM, Tayeb Meftah  wrote:
> Hello folks,
> i am a linux-TV newby;
> dreaming to get my vdr up and runing for up to 4month
> i am a blind user and have a limited access to the linux machine due
> to my blindness, i access windows normaly, then ssh to linux (*SORY
> FOR THAT*)
> so,
> i set up my debian machine correctly, runing, dbvb card detected,
> scaned, working through multicast using mumuDVB
> thank a lot to the #linuxtv people on freenode
> they helped me a lot so i should return something:)
> i installed v4l into my debian machine
> if i do make load my remote control get detected
> but if i reboot;
> Couldn't find any node at /sys/class/rc/rc*.
> so please how to make it auto loadable?
> i should do that every time my pc reboot, make load
> thank you a lot
> BTW, can i help with mailing list moderation ?

What tuner are you using?  That is a very important piece of
information since it tells us what drivers are involved for the IR
support.

Regards,

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