Re: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Fri, Feb 1, 2013 at 4:03 PM, Chris Clayton wrote: > Yes, I noticed that but even with the tuning timeout set at medium or > longest, I doesn't find any channels. However, I've been following the debug > messages through the code and ended up at > drivers/media/pci/cx23885/cx23885-i2c.c. > > I've found that by amending I2C_WAIT_DELAY from 32 to 64, I get improved > results from scanning. With that delay doubled, scandvb now finds 49 > channels over 3 frequencies. That's with all debugging turned off, so no > extra delays provided by the production of debug messages. > > I'll play around more tomorrow and update then. It could be that the cx23885 driver doesn't properly implement I2C clock stretching, which is something you don't encounter on most tuners but is an issue when communicating with the Xceive parts. 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: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Fri, Feb 1, 2013 at 9:16 AM, Chris Clayton wrote: > I've got some more diagnostics. I tuned on the 12c debugging in the cx23885 > driver and ran the scan again. Surprisingly, the scan found 22 channels on a > single frequency (that carries the BBC channels). I've attached two files - > the output from dvbscan and the kernel log covering the loading of the > drivers and running the scan. > > I'm no kernel guru, but is it possible that the root cause of the scan > failures is a timing problem which is being partially offset by the time > taken to produce all the debug output? w_scan does have some arguments that let you increase the timeout for tuning. You may wish to see if that has any effect. Maybe the w_scan timeout is just too short for that device. 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: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Thu, Jan 31, 2013 at 11:21 AM, Chris Clayton wrote: > Hi. > > On linuxtv.org, the Hauppauge WinTV-HVR-1400 is listed as being supported. > I've bought one, but I find that when I run the scan for dvb-t channels, > none are found. I have tried kernels 2.6.11, 2.7.5 and 3.8.0-rc5+ (pulled > from Linus' tree today) > > I know the aerial and cable are OK because, using the same cable, scanning > with an internal PCI dvb-t card in a desktop computer finds 117 TV and radio > channels. I know the HVR-1400 expresscard is OK because, again using the > same cable, on Windows 7 the Hauppauge TV viewing application also finds all > those channels. Try the patch described in this email sent last week: http://www.mail-archive.com/linux-media@vger.kernel.org/msg57577.html There's a very good chance you have the same 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
[RFC PATCH] Add new value for V4L2_CID_MPEG_STREAM_VBI_FMT for userdata GOP
Add a new possible value to the V4L2 API for embedded VBI data,
which allows for embedding of CC and teletext data in the userdata
section of the GOP. This allows for compatibility with applications
such as VLC which already have code to read captions out of the
userdata area for ATSC A/53 compliant streams.
This will be used by the cx18 driver to embed closed captions for NTSC
streams.
---
Documentation/DocBook/media/v4l/controls.xml |4
Documentation/DocBook/media/v4l/dev-sliced-vbi.xml |9 +
include/uapi/linux/v4l2-controls.h |1 +
3 files changed, 14 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 9e8f854..4b41b32 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -862,6 +862,10 @@ are:
VBI in private packets, IVTV format (documented
in the kernel sources in the file
Documentation/video4linux/cx2341x/README.vbi)
+
+
V4L2_MPEG_STREAM_VBI_FMT_USERDATA_GOP
+ VBI in user_data section of GOP for MPEG2 streams
(to embed closed captions that comply with ATSC A/53)
+
diff --git a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml
b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml
index 548f8ea..d295252 100644
--- a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml
+++ b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml
@@ -696,4 +696,13 @@ Sliced VBI services for a description of the line
payload.
+
+
+MPEG Stream Embedded, Sliced VBI Data Format: USERDATA_GOP
+The
+V4L2_MPEG_STREAM_VBI_FMT_USERDATA_GOP embedded sliced VBI
+format injects EIA-608 closed captions or Teletext into the Userdata GOP area
of the MPEG2 stream. This format allows for caption embedding which complies
with the ATSC A/53 specification (the same format used for ATSC digital
television streams in the United States).
+This format is not as flexible as the IVTV format as it does not
allow for embedding of arbitrary sliced VBI data. However it does have the
advantage of being the same format used for ATSC digital television streams,
meaning any application which can render captions for digital streams should be
able to render captions for these streams as well with no additional code
changes.
+
+
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 4dc0822..ad4901e 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -166,6 +166,7 @@ enum v4l2_mpeg_stream_type {
enum v4l2_mpeg_stream_vbi_fmt {
V4L2_MPEG_STREAM_VBI_FMT_NONE = 0, /* No VBI in the MPEG stream */
V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1, /* VBI in private packets, IVTV
format */
+ V4L2_MPEG_STREAM_VBI_FMT_USERDATA_GOP = 2, /* Inject VBI into
user_data GOP */
};
/* MPEG audio controls specific to multiplexed streams */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 00/20] cx231xx: v4l2-compliance fixes
On Tue, Jan 29, 2013 at 11:32 AM, Hans Verkuil wrote: > I will take a closer look at the vbi support, though.. It would be nice to get > that working. FYI: I had the VBI support working when I submitted the driver upstream (at least for NTSC CC). If it doesn't work, then somebody broke 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: [RFC PATCH] em28xx: fix bytesperline calculation in TRY_FMT
On Tue, Jan 29, 2013 at 4:49 AM, Hans Verkuil wrote: > This was part of my original em28xx patch series. That particular patch > combined two things: this fix and the change where TRY_FMT would no > longer return -EINVAL for unsupported pixelformats. The latter change was > rejected (correctly), but we all forgot about the second part of the patch > which fixed a real bug. I'm reposting just that fix. > > Regards, > > Hans > > The bytesperline calculation was incorrect: it used the old width instead > of the provided width, and it miscalculated the bytesperline value for the > depth == 12 case. > > Signed-off-by: Hans Verkuil > --- > drivers/media/usb/em28xx/em28xx-video.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/usb/em28xx/em28xx-video.c > b/drivers/media/usb/em28xx/em28xx-video.c > index 2eabf2a..070506d 100644 > --- a/drivers/media/usb/em28xx/em28xx-video.c > +++ b/drivers/media/usb/em28xx/em28xx-video.c > @@ -906,7 +906,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void > *priv, > f->fmt.pix.width = width; > f->fmt.pix.height = height; > f->fmt.pix.pixelformat = fmt->fourcc; > - f->fmt.pix.bytesperline = (dev->width * fmt->depth + 7) >> 3; > + f->fmt.pix.bytesperline = width * ((fmt->depth + 7) >> 3); > f->fmt.pix.sizeimage = f->fmt.pix.bytesperline * height; > f->fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; > if (dev->progressive) 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: [cx231xx] Support for Arm / Omap working at all?
On Tue, Jan 22, 2013 at 4:38 AM, Jan Stumpf wrote: > Thanks! > > I will try it with your patches! > > Regards > Jan FYI: the cx231xx driver has worked in the past on ARM platforms, although I haven't tried the USBLive2 on OMAP specifically. In fact, I merged the original driver support upstream as part of a project I did while developing a product that has it running on ARM. You may wish to try whatever kernel you have on an x86 platform, as people have a history of introducing regressions for the USBLive 2 in the past (I've fixed it multiple times since I originally submitted the support upstream). It's possible that it's broken on x86 as well, and has nothing to do with your being on ARM at all. 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: [PATCH RFCv10 00/15] DVB QoS statistics API
On Tue, Jan 15, 2013 at 10:21 AM, Mauro Carvalho Chehab wrote: >> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to >> be returned, whilst rest are not possible? As I remember DVBv5 API is >> broken by design and cannot return error code per request. > > The one(s) not available will have "FE_SCALE_NOT_AVAILABLE" as scale, > and its value is undefined. We may wish to rethink this approach - it lacks the ability to specify why the data isn't available. It would probably be very useful for userland to know the difference between a statistic not being available because the hardware doesn't ever provide that data (in which case a GUI might do something like not show the option), versus it not being available temporarily due to a lack of signal lock (in which as a GUI might show the option but indicate that the data is not currently available). Likewise I would want to know that data isn't being shown due to some error condition versus it not being supported by the hardware or the data being temporarily unavailable due to a lack of signal lock. See, I've been thinking about it for two minutes, and already found three perfectly reasonable error conditions userland would probably want to differentiate between. Do we really think it's wise to make this field the equivalent of a bool? It might make sense to add something equivalent to errno for a per-stat 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: Problem between DMB-TH USB dongle drivers and Frontend broken (DVBv3 migrate to DVBv5)
On Mon, Jan 14, 2013 at 1:01 PM, nise.design wrote: > After google search I think the problem may be come from connection between > DMB-TH drivers and dvb_frontend.c broken. I wanted to know any example code > or instruction about DVBv3 driver connect to dvb_frontend.c. Thank you for > any advice. Before suggesting that this is the cause, you should do a kenrel bisect and identify whether it worked before the patch series in question, but fails after it is applied. That will tell you whether the patch[es] are really the problem, or whether you're just speculating. 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 RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth wrote: > The wireless folk use dBm (reference point 1 milliwatt), as that's the > reference point used in the 802.11 standard. > > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference > point (so suitable for carrier to noise etc, or for when the reference point > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is > 1mW, so that frontends report in dBm? > > Note that if the frontend internally uses a different reference point, the > conversion is always going to be adding or subtracting a constant. Hi Simon, Probably the biggest issue you're going to have is that very few of the consumer-grade demodulators actually report data in that format. And only a small subset of those actually provide the documentation in their datasheet. The goal behind the "strength" indicator is to provide a field even an idiot can understand. While I appreciate the desire to be able to access the data in it's an "advanced" format, in reality the number of demodulator drivers that would actually be able to report such is very small -- and the approach prevents a "lowest common denominator", which is what 99% of the users *actually* care about. For that matter, even the SNR field being reported in dB isn't going to allow you to reliably compare across different demodulator chips. If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't *really* mean demod Y performs better - just that it's reporting a better number. However it *does* allow you to compare the demod against itself either across multiple frequencies or under different signal conditions - which is what typical users really care about. And while I realize in your case, Simon, that your requirements may be different from typical consumer-grade applications, I worry that adding yet more complexity to the solution will just result in getting *NOTHING*, as we have for all these years every time the issue of signal statistics has been raised. 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 15/15] em28xx: convert to videobuf2
On Tue, Jan 8, 2013 at 1:40 PM, Frank Schäfer wrote: > Bad news. :( > The patch seems to break USB bulk transfer mode. The framerate is zero. > I've tested with the Silvercrest webcam and the Cinergy 200. Both > devices work fine when selecting isoc transfers. I'll take a look. I cannot actively debug it since I don't have any devices which do bulk, but I'll at least see if anything jumps out at me. If I had to guess, probably something related to the setting up of the USB alternate. 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, sound problems, STV40, linux 3.7.1
On Tue, Jan 8, 2013 at 12:54 PM, Frank Schäfer wrote: > Thank you for reporting this issue. > Is there any known kernel version where this has been working ? > > Regards, > Frank Frank, Just an FYI: I'm already actively looking into 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: [PATCH 00/15] em28xx VBI2 port and v4l2-compliance fixes
On Fri, Jan 4, 2013 at 3:59 PM, Devin Heitmueller wrote: > This patch series converts the em28xx driver to videobuf2 and fixes > a number of issues found with v4l2-compliance on em28xx. There was a typo on my part. It's VB2 (videobuf2), not VBI2. 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 09/15] em28xx: fill in readbuffers and fix incorrect return code.
g/s_parm should fill in readbuffers. For non-webcams s_parm should return -ENOTTY instead of -EINVAL. Signed-off-by: Hans Verkuil Signed-off-by: Devin Heitmueller --- drivers/media/usb/em28xx/em28xx-video.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index acdb434..a91a248 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -972,6 +972,7 @@ static int vidioc_g_parm(struct file *file, void *priv, if (p->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) return -EINVAL; + p->parm.capture.readbuffers = EM28XX_MIN_BUF; if (dev->board.is_webcam) rc = v4l2_device_call_until_err(&dev->v4l2_dev, 0, video, g_parm, p); @@ -989,11 +990,12 @@ static int vidioc_s_parm(struct file *file, void *priv, struct em28xx *dev = fh->dev; if (!dev->board.is_webcam) - return -EINVAL; + return -ENOTTY; if (p->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) return -EINVAL; + p->parm.capture.readbuffers = EM28XX_MIN_BUF; return v4l2_device_call_until_err(&dev->v4l2_dev, 0, video, s_parm, p); } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/15] em28xx: add support for control events.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c | 38 +--
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index c67ff8d..acdb434 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -40,6 +40,7 @@
#include "em28xx.h"
#include
#include
+#include
#include
#include
#include
@@ -1927,24 +1928,33 @@ em28xx_v4l2_read(struct file *filp, char __user *buf,
size_t count,
static unsigned int em28xx_poll(struct file *filp, poll_table *wait)
{
struct em28xx_fh *fh = filp->private_data;
+ unsigned long req_events = poll_requested_events(wait);
struct em28xx *dev = fh->dev;
+ unsigned int res = 0;
int rc;
rc = check_dev(dev);
if (rc < 0)
- return rc;
-
- if (fh->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (!res_get(fh, EM28XX_RESOURCE_VIDEO))
- return POLLERR;
- return videobuf_poll_stream(filp, &fh->vb_vidq, wait);
- } else if (fh->type == V4L2_BUF_TYPE_VBI_CAPTURE) {
- if (!res_get(fh, EM28XX_RESOURCE_VBI))
- return POLLERR;
- return videobuf_poll_stream(filp, &fh->vb_vbiq, wait);
- } else {
- return POLLERR;
+ return DEFAULT_POLLMASK;
+
+ if (v4l2_event_pending(&fh->fh))
+ res = POLLPRI;
+ else if (req_events & POLLPRI)
+ poll_wait(filp, &fh->fh.wait, wait);
+
+ if (req_events & (POLLIN | POLLRDNORM)) {
+ if (fh->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ if (!res_get(fh, EM28XX_RESOURCE_VIDEO))
+ return res | POLLERR;
+ return videobuf_poll_stream(filp, &fh->vb_vidq, wait);
+ }
+ if (fh->type == V4L2_BUF_TYPE_VBI_CAPTURE) {
+ if (!res_get(fh, EM28XX_RESOURCE_VBI))
+ return res | POLLERR;
+ return res | videobuf_poll_stream(filp, &fh->vb_vbiq,
wait);
+ }
}
+ return res;
}
static unsigned int em28xx_v4l2_poll(struct file *filp, poll_table *wait)
@@ -2032,6 +2042,8 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_s_tuner = vidioc_s_tuner,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
+ .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register = vidioc_g_register,
.vidioc_s_register = vidioc_s_register,
@@ -2061,6 +2073,8 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_s_tuner = radio_s_tuner,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
+ .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register= vidioc_g_register,
.vidioc_s_register= vidioc_s_register,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] v4l2-ctrls: add a notify callback.
Sometimes platform/bridge drivers need to be notified when a control from
a sub-device changes value. In order to support this a notify callback was
added.
djh - fix merge conflict in v4l2-ctrls.c
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
Documentation/video4linux/v4l2-controls.txt | 22 ++
drivers/media/v4l2-core/v4l2-ctrls.c| 18 ++
include/media/v4l2-ctrls.h | 25 +
3 files changed, 57 insertions(+), 8 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
index cfe52c7..676f873 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -715,14 +715,20 @@ a control of this type whenever the first control
belonging to a new control
class is added.
-Proposals for Extensions
-
+Adding Notify Callbacks
+===
+
+Sometimes the platform or bridge driver needs to be notified when a control
+from a sub-device driver changes. You can set a notify callback by calling
+this function:
-Some ideas for future extensions to the spec:
+void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl,
+ void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv);
-1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead of
-decimal. Useful for e.g. video_mute_yuv.
+Whenever the give control changes value the notify callback will be called
+with a pointer to the control and the priv pointer that was passed with
+v4l2_ctrl_notify. Note that the control's handler lock is held when the
+notify function is called.
-2) It is possible to mark in the controls array which controls have been
-successfully written and which failed by for example adding a bit to the
-control ID. Not sure if it is worth the effort, though.
+There can be only one notify function per control handler. Any attempt
+to set another notify function will cause a WARN_ON.
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index f6ee201..fa02363 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1204,6 +1204,8 @@ static void new_to_cur(struct v4l2_fh *fh, struct
v4l2_ctrl *ctrl,
send_event(fh, ctrl,
(changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) |
(update_inactive ? V4L2_EVENT_CTRL_CH_FLAGS : 0));
+ if (ctrl->call_notify && changed && ctrl->handler->notify)
+ ctrl->handler->notify(ctrl, ctrl->handler->notify_priv);
}
}
@@ -2725,6 +2727,22 @@ int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64
val)
}
EXPORT_SYMBOL(v4l2_ctrl_s_ctrl_int64);
+void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, v4l2_ctrl_notify_fnc notify,
void *priv)
+{
+ if (ctrl == NULL)
+ return;
+ if (notify == NULL) {
+ ctrl->call_notify = 0;
+ return;
+ }
+ if (WARN_ON(ctrl->handler->notify && ctrl->handler->notify != notify))
+ return;
+ ctrl->handler->notify = notify;
+ ctrl->handler->notify_priv = priv;
+ ctrl->call_notify = 1;
+}
+EXPORT_SYMBOL(v4l2_ctrl_notify);
+
static int v4l2_ctrl_add_event(struct v4l2_subscribed_event *sev, unsigned
elems)
{
struct v4l2_ctrl *ctrl = v4l2_ctrl_find(sev->fh->ctrl_handler, sev->id);
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 9650911..c4cc041 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -53,6 +53,8 @@ struct v4l2_ctrl_ops {
int (*s_ctrl)(struct v4l2_ctrl *ctrl);
};
+typedef void (*v4l2_ctrl_notify_fnc)(struct v4l2_ctrl *ctrl, void *priv);
+
/** struct v4l2_ctrl - The control structure.
* @node: The list node.
* @ev_subs: The list of control event subscriptions.
@@ -72,6 +74,8 @@ struct v4l2_ctrl_ops {
*set this flag directly.
* @has_volatiles: If set, then one or more members of the cluster are
volatile.
*Drivers should never touch this flag.
+ * @call_notify: If set, then call the handler's notify function whenever the
+ *control's value changes.
* @manual_mode_value: If the is_auto flag is set, then this is the value
*of the auto control that determines if that control is in
*manual mode. So if the value of the auto control equals this
@@ -119,6 +123,7 @@ struct v4l2_ctrl {
unsigned int is_private:1;
unsigned int is_auto:1;
unsigned int has_volatiles:1;
+ unsigned int call_notify:1;
unsigned int manual_mode_value:8;
const struct v4l2_ctrl_ops *ops;
@@ -177,6 +182,10 @@ struct v4l2_ctrl_ref {
*control is needed multiple times, so this is a sim
[PATCH 14/15] em28xx: zero vbi_format reserved array and add try_vbi_fmt.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 1514b27..3adaa7b 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1521,6 +1521,7 @@ static int vidioc_g_fmt_vbi_cap(struct file *file, void
*priv,
format->fmt.vbi.sampling_rate = 675 * 4 / 2;
format->fmt.vbi.count[0] = dev->vbi_height;
format->fmt.vbi.count[1] = dev->vbi_height;
+ memset(format->fmt.vbi.reserved, 0, sizeof(format->fmt.vbi.reserved));
/* Varies by video standard (NTSC, PAL, etc.) */
if (dev->norm & V4L2_STD_525_60) {
@@ -1549,6 +1550,7 @@ static int vidioc_s_fmt_vbi_cap(struct file *file, void
*priv,
format->fmt.vbi.sampling_rate = 675 * 4 / 2;
format->fmt.vbi.count[0] = dev->vbi_height;
format->fmt.vbi.count[1] = dev->vbi_height;
+ memset(format->fmt.vbi.reserved, 0, sizeof(format->fmt.vbi.reserved));
/* Varies by video standard (NTSC, PAL, etc.) */
if (dev->norm & V4L2_STD_525_60) {
@@ -1991,6 +1993,7 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_try_fmt_vid_cap = vidioc_try_fmt_vid_cap,
.vidioc_s_fmt_vid_cap = vidioc_s_fmt_vid_cap,
.vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
+ .vidioc_try_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
.vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
.vidioc_enum_framesizes = vidioc_enum_framesizes,
.vidioc_g_audio = vidioc_g_audio,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/15] em28xx: convert to videobuf2
This patch converts the em28xx driver over to videobuf2. It is
likely that em28xx_fh can go away entirely, but that will come in
a separate patch.
[mche...@redhat.com: fix a non-trivial merge conflict with some VBI
patches]
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/Kconfig|3 +-
drivers/media/usb/em28xx/em28xx-cards.c |7 +-
drivers/media/usb/em28xx/em28xx-dvb.c |4 +-
drivers/media/usb/em28xx/em28xx-vbi.c | 123 ++---
drivers/media/usb/em28xx/em28xx-video.c | 743 +++
drivers/media/usb/em28xx/em28xx.h | 30 +-
6 files changed, 327 insertions(+), 583 deletions(-)
diff --git a/drivers/media/usb/em28xx/Kconfig b/drivers/media/usb/em28xx/Kconfig
index 094c4ec..c754a80 100644
--- a/drivers/media/usb/em28xx/Kconfig
+++ b/drivers/media/usb/em28xx/Kconfig
@@ -3,7 +3,7 @@ config VIDEO_EM28XX
depends on VIDEO_DEV && I2C
select VIDEO_TUNER
select VIDEO_TVEEPROM
- select VIDEOBUF_VMALLOC
+ select VIDEOBUF2_VMALLOC
select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_TVP5150 if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_MSP3400 if MEDIA_SUBDRV_AUTOSELECT
@@ -48,7 +48,6 @@ config VIDEO_EM28XX_DVB
select DVB_S5H1409 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_TDA18271 if MEDIA_SUBDRV_AUTOSELECT
- select VIDEOBUF_DVB
---help---
This adds support for DVB cards based on the
Empiatech em28xx chips.
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 4117d38..0a4c868 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -57,7 +57,7 @@ module_param(disable_usb_speed_check, int, 0444);
MODULE_PARM_DESC(disable_usb_speed_check,
"override min bandwidth requirement of 480M bps");
-static unsigned int card[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = UNSET };
+static unsigned int card[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = -1U };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, "card type");
@@ -2965,6 +2965,8 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
const char *chip_name = default_chip_name;
dev->udev = udev;
+ mutex_init(&dev->vb_queue_lock);
+ mutex_init(&dev->vb_vbi_queue_lock);
mutex_init(&dev->ctrl_urb_lock);
spin_lock_init(&dev->slock);
@@ -3411,6 +3413,9 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
/* save our data pointer in this interface device */
usb_set_intfdata(interface, dev);
+ /* initialize videobuf2 stuff */
+ em28xx_vb2_setup(dev);
+
/* allocate device struct */
mutex_init(&dev->lock);
mutex_lock(&dev->lock);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a70b19e..01bb800 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -27,7 +27,9 @@
#include "em28xx.h"
#include
-#include
+#include
+#include
+#include
#include
#include "tuner-simple.h"
#include
diff --git a/drivers/media/usb/em28xx/em28xx-vbi.c
b/drivers/media/usb/em28xx/em28xx-vbi.c
index d74713b..9fcfc910 100644
--- a/drivers/media/usb/em28xx/em28xx-vbi.c
+++ b/drivers/media/usb/em28xx/em28xx-vbi.c
@@ -41,105 +41,72 @@ MODULE_PARM_DESC(vbi_debug, "enable debug messages [vbi]");
/* -- */
-static void
-free_buffer(struct videobuf_queue *vq, struct em28xx_buffer *buf)
+static int vbi_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
- struct em28xx_fh *fh = vq->priv_data;
- struct em28xx*dev = fh->dev;
- unsigned long flags = 0;
- if (in_interrupt())
- BUG();
-
- /* We used to wait for the buffer to finish here, but this didn't work
- because, as we were keeping the state as VIDEOBUF_QUEUED,
- videobuf_queue_cancel marked it as finished for us.
- (Also, it could wedge forever if the hardware was misconfigured.)
-
- This should be safe; by the time we get here, the buffer isn't
- queued anymore. If we ever start marking the buffers as
- VIDEOBUF_ACTIVE, it won't be, though.
- */
- spin_lock_irqsave(&dev->slock, flags);
- if (dev->usb_ctl.vbi_buf == buf)
- dev->usb_ctl.vbi_buf = NULL;
- spin_unlock_irqrestore(&dev->slock, flags);
+ struct em28xx *dev = vb2_get_drv_
[PATCH 13/15] em28xx: remove sliced VBI support.
The sliced VBI support in the tvp5150 is completely broken. And there is no
support for the saa7115 sliced VBI implementation in the em28xx driver. So
we remove the sliced VBI support completely.
It should be possible to get it to work with the tvp5150, but that will
require someone to really dig into that driver.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c | 49 ++-
1 file changed, 2 insertions(+), 47 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index ae713a0..1514b27 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1438,8 +1438,7 @@ static int vidioc_querycap(struct file *file, void *priv,
else if (vdev->vfl_type == VFL_TYPE_RADIO)
cap->device_caps = V4L2_CAP_RADIO;
else
- cap->device_caps = V4L2_CAP_READWRITE |
- V4L2_CAP_VBI_CAPTURE | V4L2_CAP_SLICED_VBI_CAPTURE;
+ cap->device_caps = V4L2_CAP_READWRITE | V4L2_CAP_VBI_CAPTURE;
if (dev->audio_mode.has_audio)
cap->device_caps |= V4L2_CAP_AUDIO;
@@ -1450,8 +1449,7 @@ static int vidioc_querycap(struct file *file, void *priv,
cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS |
V4L2_CAP_READWRITE | V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_STREAMING;
if (dev->vbi_dev)
- cap->capabilities |=
- V4L2_CAP_VBI_CAPTURE | V4L2_CAP_SLICED_VBI_CAPTURE;
+ cap->capabilities |= V4L2_CAP_VBI_CAPTURE;
if (dev->radio_dev)
cap->capabilities |= V4L2_CAP_RADIO;
return 0;
@@ -1508,46 +1506,6 @@ static int vidioc_enum_framesizes(struct file *file,
void *priv,
return 0;
}
-/* Sliced VBI ioctls */
-static int vidioc_g_fmt_sliced_vbi_cap(struct file *file, void *priv,
- struct v4l2_format *f)
-{
- struct em28xx_fh *fh = priv;
- struct em28xx *dev = fh->dev;
- int rc;
-
- rc = check_dev(dev);
- if (rc < 0)
- return rc;
-
- f->fmt.sliced.service_set = 0;
- v4l2_device_call_all(&dev->v4l2_dev, 0, vbi, g_sliced_fmt,
&f->fmt.sliced);
-
- if (f->fmt.sliced.service_set == 0)
- rc = -EINVAL;
-
- return rc;
-}
-
-static int vidioc_try_set_sliced_vbi_cap(struct file *file, void *priv,
- struct v4l2_format *f)
-{
- struct em28xx_fh *fh = priv;
- struct em28xx *dev = fh->dev;
- int rc;
-
- rc = check_dev(dev);
- if (rc < 0)
- return rc;
-
- v4l2_device_call_all(&dev->v4l2_dev, 0, vbi, g_sliced_fmt,
&f->fmt.sliced);
-
- if (f->fmt.sliced.service_set == 0)
- return -EINVAL;
-
- return 0;
-}
-
/* RAW VBI ioctls */
static int vidioc_g_fmt_vbi_cap(struct file *file, void *priv,
@@ -2038,9 +1996,6 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_g_audio = vidioc_g_audio,
.vidioc_s_audio = vidioc_s_audio,
.vidioc_cropcap = vidioc_cropcap,
- .vidioc_g_fmt_sliced_vbi_cap = vidioc_g_fmt_sliced_vbi_cap,
- .vidioc_try_fmt_sliced_vbi_cap = vidioc_try_set_sliced_vbi_cap,
- .vidioc_s_fmt_sliced_vbi_cap = vidioc_try_set_sliced_vbi_cap,
.vidioc_reqbufs = vidioc_reqbufs,
.vidioc_querybuf= vidioc_querybuf,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/15] tvp5150: remove compat control ops.
No longer needed now that em28xx has been converted to the control framework.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/i2c/tvp5150.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 31104a9..5967e1a0 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1096,13 +1096,6 @@ static const struct v4l2_ctrl_ops tvp5150_ctrl_ops = {
static const struct v4l2_subdev_core_ops tvp5150_core_ops = {
.log_status = tvp5150_log_status,
- .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
- .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
- .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
- .queryctrl = v4l2_subdev_queryctrl,
- .querymenu = v4l2_subdev_querymenu,
.s_std = tvp5150_s_std,
.reset = tvp5150_reset,
.g_chip_ident = tvp5150_g_chip_ident,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/15] em28xx: fix broken TRY_FMT.
TRY_FMT should not return an error if a pixelformat is unsupported. Instead just
pick a common pixelformat.
Also the bytesperline calculation was incorrect: it used the old width instead
of
the provided with, and it miscalculated the bytesperline value for the depth ==
12
case.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index a91a248..7c09b55 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -821,7 +821,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
if (!fmt) {
em28xx_videodbg("Fourcc format (%08x) invalid.\n",
f->fmt.pix.pixelformat);
- return -EINVAL;
+ fmt = format_by_fourcc(V4L2_PIX_FMT_YUYV);
}
if (dev->board.is_em2800) {
@@ -847,7 +847,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
f->fmt.pix.width = width;
f->fmt.pix.height = height;
f->fmt.pix.pixelformat = fmt->fourcc;
- f->fmt.pix.bytesperline = (dev->width * fmt->depth + 7) >> 3;
+ f->fmt.pix.bytesperline = width * ((fmt->depth + 7) >> 3);
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline * height;
f->fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M;
if (dev->progressive)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/15] em28xx: std fixes: don't implement in webcam mode, and fix std changes.
When in webcam mode the STD API shouldn't be implemented.
When changing the standard the resolution wasn't updated, and there was no
check against streaming-in-progress.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 7c09b55..ae713a0 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -909,6 +909,8 @@ static int vidioc_g_std(struct file *file, void *priv,
v4l2_std_id *norm)
struct em28xx *dev = fh->dev;
intrc;
+ if (dev->board.is_webcam)
+ return -ENOTTY;
rc = check_dev(dev);
if (rc < 0)
return rc;
@@ -924,6 +926,8 @@ static int vidioc_querystd(struct file *file, void *priv,
v4l2_std_id *norm)
struct em28xx *dev = fh->dev;
intrc;
+ if (dev->board.is_webcam)
+ return -ENOTTY;
rc = check_dev(dev);
if (rc < 0)
return rc;
@@ -940,15 +944,24 @@ static int vidioc_s_std(struct file *file, void *priv,
v4l2_std_id *norm)
struct v4l2_format f;
intrc;
+ if (dev->board.is_webcam)
+ return -ENOTTY;
+ if (*norm == dev->norm)
+ return 0;
rc = check_dev(dev);
if (rc < 0)
return rc;
+ if (videobuf_queue_is_busy(&fh->vb_vidq)) {
+ em28xx_errdev("%s queue busy\n", __func__);
+ return -EBUSY;
+ }
+
dev->norm = *norm;
/* Adjusts width/height, if needed */
- f.fmt.pix.width = dev->width;
- f.fmt.pix.height = dev->height;
+ f.fmt.pix.width = 720;
+ f.fmt.pix.height = (*norm & V4L2_STD_525_60) ? 480 : 576;
vidioc_try_fmt_vid_cap(file, priv, &f);
/* set new image size */
@@ -1034,6 +1047,9 @@ static int vidioc_enum_input(struct file *file, void
*priv,
i->type = V4L2_INPUT_TYPE_TUNER;
i->std = dev->vdev->tvnorms;
+ /* webcams do not have the STD API */
+ if (dev->board.is_webcam)
+ i->capabilities = 0;
return 0;
}
@@ -2059,7 +2075,6 @@ static const struct video_device em28xx_video_template = {
.ioctl_ops = &video_ioctl_ops,
.tvnorms= V4L2_STD_ALL,
- .current_norm = V4L2_STD_PAL,
};
static const struct v4l2_file_operations radio_fops = {
@@ -2109,6 +2124,8 @@ static struct video_device *em28xx_vdev_init(struct
em28xx *dev,
vfd->debug = video_debug;
vfd->lock = &dev->lock;
set_bit(V4L2_FL_USE_FH_PRIO, &vfd->flags);
+ if (dev->board.is_webcam)
+ vfd->tvnorms = 0;
snprintf(vfd->name, sizeof(vfd->name), "%s %s",
dev->name, type_name);
@@ -2127,7 +2144,7 @@ int em28xx_register_analog_devices(struct em28xx *dev)
dev->name, EM28XX_VERSION);
/* set default norm */
- dev->norm = em28xx_video_template.current_norm;
+ dev->norm = V4L2_STD_PAL;
v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_std, dev->norm);
dev->interlaced = EM28XX_INTERLACED_DEFAULT;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] em28xx: convert to the control framework.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-cards.c | 24 +++
drivers/media/usb/em28xx/em28xx-video.c | 248 +++
drivers/media/usb/em28xx/em28xx.h |6 +
3 files changed, 53 insertions(+), 225 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index f5cac47..4117d38 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2941,6 +2941,8 @@ void em28xx_release_resources(struct em28xx *dev)
em28xx_i2c_unregister(dev);
+ v4l2_ctrl_handler_free(&dev->ctrl_handler);
+
v4l2_device_unregister(&dev->v4l2_dev);
usb_put_dev(dev->udev);
@@ -2957,6 +2959,7 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
struct usb_interface *interface,
int minor)
{
+ struct v4l2_ctrl_handler *hdl = &dev->ctrl_handler;
int retval;
static const char *default_chip_name = "em28xx";
const char *chip_name = default_chip_name;
@@ -3084,6 +3087,9 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
return retval;
}
+ v4l2_ctrl_handler_init(hdl, 4);
+ dev->v4l2_dev.ctrl_handler = hdl;
+
/* register i2c bus */
retval = em28xx_i2c_register(dev);
if (retval < 0) {
@@ -3109,6 +3115,18 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
__func__, retval);
goto fail;
}
+ if (dev->audio_mode.ac97 != EM28XX_NO_AC97) {
+ v4l2_ctrl_new_std(hdl, &em28xx_ctrl_ops,
+ V4L2_CID_AUDIO_MUTE, 0, 1, 1, 1);
+ v4l2_ctrl_new_std(hdl, &em28xx_ctrl_ops,
+ V4L2_CID_AUDIO_VOLUME, 0, 0x1f, 1, 0x1f);
+ } else {
+ /* install the em28xx notify callback */
+ v4l2_ctrl_notify(v4l2_ctrl_find(hdl, V4L2_CID_AUDIO_MUTE),
+ em28xx_ctrl_notify, dev);
+ v4l2_ctrl_notify(v4l2_ctrl_find(hdl, V4L2_CID_AUDIO_VOLUME),
+ em28xx_ctrl_notify, dev);
+ }
/* wake i2c devices */
em28xx_wake_i2c(dev);
@@ -3138,6 +3156,11 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
msleep(3);
}
+ v4l2_ctrl_handler_setup(&dev->ctrl_handler);
+ retval = dev->ctrl_handler.error;
+ if (retval)
+ goto fail;
+
retval = em28xx_register_analog_devices(dev);
if (retval < 0) {
goto fail;
@@ -3150,6 +3173,7 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
fail:
em28xx_i2c_unregister(dev);
+ v4l2_ctrl_handler_free(&dev->ctrl_handler);
unregister_dev:
v4l2_device_unregister(&dev->v4l2_dev);
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 89cbfaf..ebbf775 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -125,30 +125,6 @@ static struct em28xx_fmt format[] = {
},
};
-/* supported controls */
-/* Common to all boards */
-static struct v4l2_queryctrl ac97_qctrl[] = {
- {
- .id = V4L2_CID_AUDIO_VOLUME,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = "Volume",
- .minimum = 0x0,
- .maximum = 0x1f,
- .step = 0x1,
- .default_value = 0x1f,
- .flags = V4L2_CTRL_FLAG_SLIDER,
- }, {
- .id = V4L2_CID_AUDIO_MUTE,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .name = "Mute",
- .minimum = 0,
- .maximum = 1,
- .step = 1,
- .default_value = 1,
- .flags = 0,
- }
-};
-
/* --
DMA and thread functions
--*/
@@ -718,76 +694,48 @@ static int get_ressource(struct em28xx_fh *fh)
}
}
-/*
- * ac97_queryctrl()
- * return the ac97 supported controls
- */
-static int ac97_queryctrl(struct v4l2_queryctrl *qc)
+void em28xx_ctrl_notify(struct v4l2_ctrl *ctrl, void *priv)
{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(ac97_qctrl); i++) {
- if (qc->id && qc->id == ac97_qctrl[i].id) {
- memcpy(qc, &(ac97_qctrl[i]), sizeof(*qc));
- return 0;
- }
- }
-
- /* Control is not ac97 related */
- return 1;
-}
+ struct em28xx *dev = priv;
-/*
- * ac97_get_ctrl()
- * return t
[PATCH 07/15] em28xx: convert to v4l2_fh, fix priority handling.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c |5 +
drivers/media/usb/em28xx/em28xx.h |2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index ebbf775..c67ff8d 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1735,6 +1735,7 @@ static int em28xx_v4l2_open(struct file *filp)
mutex_unlock(&dev->lock);
return -ENOMEM;
}
+ v4l2_fh_init(&fh->fh, vdev);
fh->dev = dev;
fh->radio = radio;
fh->type = fh_type;
@@ -1774,6 +1775,7 @@ static int em28xx_v4l2_open(struct file *filp)
V4L2_FIELD_SEQ_TB,
sizeof(struct em28xx_buffer), fh,
&dev->lock);
mutex_unlock(&dev->lock);
+ v4l2_fh_add(&fh->fh);
return errCode;
}
@@ -1867,6 +1869,8 @@ static int em28xx_v4l2_close(struct file *filp)
"0 (error=%i)\n", errCode);
}
}
+ v4l2_fh_del(&fh->fh);
+ v4l2_fh_exit(&fh->fh);
videobuf_mmap_free(&fh->vb_vidq);
videobuf_mmap_free(&fh->vb_vbiq);
@@ -2088,6 +2092,7 @@ static struct video_device *em28xx_vdev_init(struct
em28xx *dev,
vfd->release= video_device_release;
vfd->debug = video_debug;
vfd->lock = &dev->lock;
+ set_bit(V4L2_FL_USE_FH_PRIO, &vfd->flags);
snprintf(vfd->name, sizeof(vfd->name), "%s %s",
dev->name, type_name);
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 707319e..7432be4 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#if defined(CONFIG_VIDEO_EM28XX_DVB) || defined(CONFIG_VIDEO_EM28XX_DVB_MODULE)
@@ -477,6 +478,7 @@ struct em28xx_audio {
struct em28xx;
struct em28xx_fh {
+ struct v4l2_fh fh;
struct em28xx *dev;
int radio;
unsigned int resources;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] em28xx: fix VIDIOC_DBG_G_CHIP_IDENT compliance errors.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index f025440..b71df42 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1403,6 +1403,14 @@ static int vidioc_g_chip_ident(struct file *file, void
*priv,
chip->ident = V4L2_IDENT_NONE;
chip->revision = 0;
+ if (chip->match.type == V4L2_CHIP_MATCH_HOST) {
+ if (v4l2_chip_match_host(&chip->match))
+ chip->ident = V4L2_IDENT_NONE;
+ return 0;
+ }
+ if (chip->match.type != V4L2_CHIP_MATCH_I2C_DRIVER &&
+ chip->match.type != V4L2_CHIP_MATCH_I2C_ADDR)
+ return -EINVAL;
v4l2_device_call_all(&dev->v4l2_dev, 0, core, g_chip_ident, chip);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] em28xx: fix tuner/frequency handling
v4l2-compliance found problems with frequency clamping that wasn't reported correctly and missing tuner index checks. Also removed unnecessary tuner type checks (these are now done by the v4l2 core). Signed-off-by: Hans Verkuil Signed-off-by: Devin Heitmueller --- drivers/media/usb/em28xx/em28xx-video.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index b71df42..89cbfaf 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -1322,7 +1322,6 @@ static int vidioc_g_tuner(struct file *file, void *priv, return -EINVAL; strcpy(t->name, "Tuner"); - t->type = V4L2_TUNER_ANALOG_TV; v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner, t); return 0; @@ -1352,7 +1351,9 @@ static int vidioc_g_frequency(struct file *file, void *priv, struct em28xx_fh *fh = priv; struct em28xx *dev = fh->dev; - f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; + if (0 != f->tuner) + return -EINVAL; + f->frequency = dev->ctl_freq; return 0; } @@ -1371,13 +1372,9 @@ static int vidioc_s_frequency(struct file *file, void *priv, if (0 != f->tuner) return -EINVAL; - if (unlikely(0 == fh->radio && f->type != V4L2_TUNER_ANALOG_TV)) - return -EINVAL; - if (unlikely(1 == fh->radio && f->type != V4L2_TUNER_RADIO)) - return -EINVAL; - - dev->ctl_freq = f->frequency; v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_frequency, f); + v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_frequency, f); + dev->ctl_freq = f->frequency; return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] em28xx: fix querycap.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c | 42 ++-
1 file changed, 19 insertions(+), 23 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 4c1726d..fb9ee46 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1577,6 +1577,7 @@ static int vidioc_streamoff(struct file *file, void *priv,
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
+ struct video_device *vdev = video_devdata(file);
struct em28xx_fh *fh = priv;
struct em28xx *dev = fh->dev;
@@ -1584,20 +1585,28 @@ static int vidioc_querycap(struct file *file, void
*priv,
strlcpy(cap->card, em28xx_boards[dev->model].name, sizeof(cap->card));
usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info));
- cap->capabilities =
- V4L2_CAP_SLICED_VBI_CAPTURE |
- V4L2_CAP_VIDEO_CAPTURE |
- V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
-
- if (dev->vbi_dev)
- cap->capabilities |= V4L2_CAP_VBI_CAPTURE;
+ if (vdev->vfl_type == VFL_TYPE_GRABBER)
+ cap->device_caps = V4L2_CAP_READWRITE |
+ V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ else if (vdev->vfl_type == VFL_TYPE_RADIO)
+ cap->device_caps = V4L2_CAP_RADIO;
+ else
+ cap->device_caps = V4L2_CAP_READWRITE |
+ V4L2_CAP_VBI_CAPTURE | V4L2_CAP_SLICED_VBI_CAPTURE;
if (dev->audio_mode.has_audio)
- cap->capabilities |= V4L2_CAP_AUDIO;
+ cap->device_caps |= V4L2_CAP_AUDIO;
if (dev->tuner_type != TUNER_ABSENT)
- cap->capabilities |= V4L2_CAP_TUNER;
+ cap->device_caps |= V4L2_CAP_TUNER;
+ cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS |
+ V4L2_CAP_READWRITE | V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_STREAMING;
+ if (dev->vbi_dev)
+ cap->capabilities |=
+ V4L2_CAP_VBI_CAPTURE | V4L2_CAP_SLICED_VBI_CAPTURE;
+ if (dev->radio_dev)
+ cap->capabilities |= V4L2_CAP_RADIO;
return 0;
}
@@ -1831,19 +1840,6 @@ static int vidioc_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *b)
/* RADIO ESPECIFIC IOCTLS */
/* --- */
-static int radio_querycap(struct file *file, void *priv,
- struct v4l2_capability *cap)
-{
- struct em28xx *dev = ((struct em28xx_fh *)priv)->dev;
-
- strlcpy(cap->driver, "em28xx", sizeof(cap->driver));
- strlcpy(cap->card, em28xx_boards[dev->model].name, sizeof(cap->card));
- usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info));
-
- cap->capabilities = V4L2_CAP_TUNER;
- return 0;
-}
-
static int radio_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
{
@@ -2281,7 +2277,7 @@ static const struct v4l2_file_operations radio_fops = {
};
static const struct v4l2_ioctl_ops radio_ioctl_ops = {
- .vidioc_querycap = radio_querycap,
+ .vidioc_querycap = vidioc_querycap,
.vidioc_g_tuner = radio_g_tuner,
.vidioc_enum_input= radio_enum_input,
.vidioc_g_audio = radio_g_audio,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/15] em28xx: remove bogus input/audio ioctls for the radio device.
Radio devices should not implement those ioctls.
Signed-off-by: Hans Verkuil
Signed-off-by: Devin Heitmueller
---
drivers/media/usb/em28xx/em28xx-video.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index fb9ee46..f025440 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1856,26 +1856,6 @@ static int radio_g_tuner(struct file *file, void *priv,
return 0;
}
-static int radio_enum_input(struct file *file, void *priv,
- struct v4l2_input *i)
-{
- if (i->index != 0)
- return -EINVAL;
- strcpy(i->name, "Radio");
- i->type = V4L2_INPUT_TYPE_TUNER;
-
- return 0;
-}
-
-static int radio_g_audio(struct file *file, void *priv, struct v4l2_audio *a)
-{
- if (unlikely(a->index))
- return -EINVAL;
-
- strcpy(a->name, "Radio");
- return 0;
-}
-
static int radio_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
{
@@ -1889,17 +1869,6 @@ static int radio_s_tuner(struct file *file, void *priv,
return 0;
}
-static int radio_s_audio(struct file *file, void *fh,
-const struct v4l2_audio *a)
-{
- return 0;
-}
-
-static int radio_s_input(struct file *file, void *fh, unsigned int i)
-{
- return 0;
-}
-
static int radio_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *qc)
{
@@ -2279,11 +2248,7 @@ static const struct v4l2_file_operations radio_fops = {
static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_querycap = vidioc_querycap,
.vidioc_g_tuner = radio_g_tuner,
- .vidioc_enum_input= radio_enum_input,
- .vidioc_g_audio = radio_g_audio,
.vidioc_s_tuner = radio_s_tuner,
- .vidioc_s_audio = radio_s_audio,
- .vidioc_s_input = radio_s_input,
.vidioc_queryctrl = radio_queryctrl,
.vidioc_g_ctrl= vidioc_g_ctrl,
.vidioc_s_ctrl= vidioc_s_ctrl,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/15] em28xx VBI2 port and v4l2-compliance fixes
This patch series converts the em28xx driver to videobuf2 and fixes a number of issues found with v4l2-compliance on em28xx. Devin Heitmueller (1): em28xx: convert to videobuf2 Hans Verkuil (14): em28xx: fix querycap. em28xx: remove bogus input/audio ioctls for the radio device. em28xx: fix VIDIOC_DBG_G_CHIP_IDENT compliance errors. em28xx: fix tuner/frequency handling v4l2-ctrls: add a notify callback. em28xx: convert to the control framework. em28xx: convert to v4l2_fh, fix priority handling. em28xx: add support for control events. em28xx: fill in readbuffers and fix incorrect return code. em28xx: fix broken TRY_FMT. tvp5150: remove compat control ops. em28xx: std fixes: don't implement in webcam mode, and fix std changes. em28xx: remove sliced VBI support. em28xx: zero vbi_format reserved array and add try_vbi_fmt. Documentation/video4linux/v4l2-controls.txt | 22 +- drivers/media/i2c/tvp5150.c |7 - drivers/media/usb/em28xx/Kconfig|3 +- drivers/media/usb/em28xx/em28xx-cards.c | 31 +- drivers/media/usb/em28xx/em28xx-dvb.c |4 +- drivers/media/usb/em28xx/em28xx-vbi.c | 123 ++- drivers/media/usb/em28xx/em28xx-video.c | 1159 --- drivers/media/usb/em28xx/em28xx.h | 38 +- drivers/media/v4l2-core/v4l2-ctrls.c| 18 + include/media/v4l2-ctrls.h | 25 + 10 files changed, 504 insertions(+), 926 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.9] em28xx videobuf2 support and v4l2-compliance fixes
On Fri, Jan 4, 2013 at 2:59 PM, Ezequiel Garcia wrote: > Maybe I'm wrong, but weren't **all** changes supposed to be sent as a PATCH > to the mailing list for community review, before the PULL request was sent? No, you are correct. I did a PULL specifically because Mauro asked me to. I'll resend the individual patches now to the list. 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
[GIT PULL FOR 3.9] em28xx videobuf2 support and v4l2-compliance fixes
Hello Mauro, Please pull the following series for 3.9, which ports em28xx to VB2 as well as applying Hans Verkuil's v4l2-compliance fixes for em28xx. Thanks, Devin The following changes since commit 8cd7085ff460ead3aba6174052a408f4ad52ac36: [media] get_dvb_firmware: Fix the location of firmware for Terratec HTC (2013-01-01 11:18:26 -0200) are available in the git repository at: git://git.kernellabs.com/dheitmueller/linuxtv.git v39staging for you to fetch changes up to 381abfc158c2dad81a558a3d3ff924fc7f80d277: em28xx: convert to videobuf2 (2013-01-04 14:16:24 -0500) Devin Heitmueller (1): em28xx: convert to videobuf2 Hans Verkuil (14): em28xx: fix querycap. em28xx: remove bogus input/audio ioctls for the radio device. em28xx: fix VIDIOC_DBG_G_CHIP_IDENT compliance errors. em28xx: fix tuner/frequency handling v4l2-ctrls: add a notify callback. em28xx: convert to the control framework. em28xx: convert to v4l2_fh, fix priority handling. em28xx: add support for control events. em28xx: fill in readbuffers and fix incorrect return code. em28xx: fix broken TRY_FMT. tvp5150: remove compat control ops. em28xx: std fixes: don't implement in webcam mode, and fix std changes. em28xx: remove sliced VBI support. em28xx: zero vbi_format reserved array and add try_vbi_fmt. Documentation/video4linux/v4l2-controls.txt | 22 +- drivers/media/i2c/tvp5150.c |7 - drivers/media/usb/em28xx/Kconfig|3 +- drivers/media/usb/em28xx/em28xx-cards.c | 31 +- drivers/media/usb/em28xx/em28xx-dvb.c |4 +- drivers/media/usb/em28xx/em28xx-vbi.c | 123 ++- drivers/media/usb/em28xx/em28xx-video.c | 1159 --- drivers/media/usb/em28xx/em28xx.h | 38 +- drivers/media/v4l2-core/v4l2-ctrls.c| 18 + include/media/v4l2-ctrls.h | 25 + 10 files changed, 504 insertions(+), 926 deletions(-) -- 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: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
On Sat, Dec 29, 2012 at 9:23 AM, Mauro Carvalho Chehab wrote: > On a tvtime compiled without libv4l, the cx18 driver will fail with the > current logic, as it doesn't return an error when format doesn't > match. So, tvtime will fail anyway with 50% of the TV drivers that don't > support YUYV directly. It will also fail with most cameras, as they're > generally based on proprietary/bayer formats and/or may not have the > resolutions that tvtime requires. > > That's said, libv4l does format conversion. So, if the logic on libv4l > is working properly, and as tvtime does upport libv4l upstream, > no real bug should be seen with tvtime, even if the device doesn't > support neither UYVY or YUYV. Tvtime doesn't use libv4l (and never has), unless you added support very recently and it's not in the linuxtv.org tree. I started to look into making it use libv4l some months back, but libv4l only supports providing the video to the app in a few select formats (e.g. RGB formats and YUV 4:2:0). Tvtime specifically needs the video in YUYV or UYVY because it does all its overlays directly onto the video buffer, the deinterlacers expect YUYV, and the XVideo support in the app currently only does YUYV. Changing the app to work with 4:2:0 would mean cleaning up the rats nest that does all of the above functions - certainly not impossible, but not trivial either. In fact, it would probably be better to add the colorspace conversion code to libv4l to support providing YUYV to the app when it asks for it. > The above also applies to MythTV, except that I'm not sure if MythTV uses > libv4l. It does not. There's no doubt that both MythTV and Tvtime could use an overhaul of their V4L2 code (which became as nasty as it is primarily due to all the years of the kernel's lack of specified behavior and failure to enforce consistency across boards). That's not really relevant to the discussion at hand though, which is about breaking existing applications (and possibly all the apps other than the two or three common open source apps I raised as examples). I would love to take a half dozen tuner boards of various types and spend a week cleaning up Myth's code, but frankly I just don't have the time/energy to take on such a task. 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: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
On Sat, Dec 29, 2012 at 6:53 AM, Hans Verkuil wrote: > In my opinion these are application bugs, and not ABI breakages. I'm not sure if you saw the email, but Linus seems to disagree with your assertion quite strongly: https://lkml.org/lkml/2012/12/23/75 The change as proposed results in a situation where apps worked fine, user upgrades kernel, and now apps are broken. That sounds a lot like: "If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?" > As Mauro > mentioned, some drivers don't return an error and so would always have failed > with these apps (examples: cx18/ivtv, gspca). Yeah, except uncompressed support is quite new with cx18, ivtv doesn't support uncompressed at all, and gspca is for webcams, not TV. > Do these apps even handle the case where TRY isn't implemented at all by the > driver? (hdpvr) I haven't looked at compressed formats. Tvtime doesn't support them at all, and MythTV uses a completely different code path for compressed capture. MythTV even has special code for the HD-PVR, which presumably was to work around API inconsistencies. > There is nothing in the spec that says that you will get an error if the > pixelformat isn't supported by the driver, in fact it says the opposite: > > "Very simple, inflexible devices may even ignore all input and always return > the default parameters." > > We are not in the business to work around application bugs, IMHO. We can of > course delay making these changes until those applications are fixed. Except those two applications aren't the only two applications in existence which make use of the V4L2 API. Oh, and applications are supposed to continue working unmodified through kernel upgrades. > I suspect that the behavior of returning an error if a pixelformat is not > supported is a leftover from the V4L1 API (VIDIOCSPICT). When drivers were > converted to S/TRY_FMT this method of handling unsupported pixelformats was > probably never changed. And quite a few newer drivers copy-and-pasted that > method. Drivers like cx18/ivtv that didn't copy-and-paste code looked at the > API and followed what the API said. > > At the moment most TV drivers seem to return an error, whereas for webcams > it is hit and miss: uvc returned an error (until it was fixed recently), > gspca didn't. So webcam applications probably do the right thing given the > behavior of gspca. What if we returned an error but still changed the struct to specify the supported format? That's not what the spec says, but it seems like that's what is implemented in many drivers today and what many applications expect to happen. No doubt, this is a mess, and if we had tighter enforcement and better specs before this stuff went upstream years ago, we wouldn't be in this situation. But that's not the world we live in, and we have to deal with where we stand 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: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab wrote: > The DVBv3 quality parameters are limited on several ways: > - Doesn't provide any way to indicate the used measure; > - Userspace need to guess how to calculate the measure; > - Only a limited set of stats are supported; > - Doesn't provide QoS measure for the OFDM TPS/TMCC > carriers, used to detect the network parameters for > DVB-T/ISDB-T; > - Can't be called in a way to require them to be filled > all at once (atomic reads from the hardware), with may > cause troubles on interpreting them on userspace; > - On some OFDM delivery systems, the carriers can be > independently modulated, having different properties. > Currently, there's no way to report per-layer stats; > This RFC adds the header definitions meant to solve that issues. > After discussed, I'll write a patch for the DocBook and add support > for it on some demods. Support for dvbv5-zap and dvbv5-scan tools > will also have support for those features. Hi Mauro, As I've told you multiple times in the past, where this proposal falls apart is in its complete lack of specificity for real world scenarios. You have a units field which is "decibels", but in what unit? 1 dB / unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why the current snr field varies across even demods where we have the datasheets. Many demods reported in 0.1 dB increments, while others reported in 1/255 dB increments. What happens when you ask for the SNR field when there is so signal lock (on most demods the SNR registers return garbage in this case)? What is the return value to userland? What happens when the data is unavailable for some other reason? What happens when you have group of statistics being asked for in a single call and *one* of them cannot be provided for some reason (in which case you cannot rely on a simple errno value since it doesn't apply to the entire call)? You need to take a step back and think about this from an application implementors standpoint. Most app developers for the existing apps look to show two data points: a signal indicator (0-100%), and some form of SNR (usually in dB, plotted on a scale where something like 40 dB=100% [of course this max varies by modulation type]). What would I need to do with the data you've provided to show that info? Do I really need to be a background in signal theory and understand the difference between SNR and CNR in order to tell the user how good his signal is? Since as an app developer I typically only have one or two tuners, how the hell am I supposed to write a piece of code that shows those two pieces of information given the huge number of different combinations of data types that demods could return given the proposed API? We have similar issues for UNC/BER values. Is the value returned the number of errors since the last time the application asked? Is it the number of errors in the last two seconds? Is it the number of errors since I reached signal lock? Does asking for the value clear out the counter? How do we handle the case where I asked for the data for the first time ten minutes after I reached signal lock? Are drivers internally supposed to be polling the register and updating the counters even when the application doesn't ask for the data (to handle cases where the demod's registers only have an error count for the last second's worth of data)? And where the examples that show "typical values" for the different modulation types? For example, I'm no expert in DVB-C but I'm trying to write an app which can be used by those users. What range of values will the API typically return for that modulation type? What values are "good" values, which represent "excellent" signal conditions, and what values suggest that the signal will probably be failing? What happens when a driver doesn't support a particular statistic? Right now some drivers return -EINVAL, others just set the field to zero or 0x1fff (in which case the user is mislead to believe that there is no signal lock *all* the time). EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API behaves inconsistently today - somebody who did one of the early demods returned in 1/255 dB format, and then some other developer who didn't have the first piece of hardware wrote a driver and because he/she didn't *know* what the field was supposed to contain (and couldn't try it his/herself), that developer wrote a driver which returned in 0.1 dB format. This needs to be defined *in the spec*, or else we'll end up with developers (both app developers and kernel develoeprs implementing new demods) guessing how the API should behave based on whatever hardware they have, which is how we got in this mess in the first place. In short, you need to describe typical usage scenarios in terms of what values the API should be returning for diffe
ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
Hi there, So I noticed that one of the "V4L2 ambiguities" discussed at the Media Workshop relates to expected behavior with TRY_FMT/S_FMT. Specifically (from http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab): === 1.4. Unsupported formats in TRY_FMT/S_FMT What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviors include returning the currently selected format or a default format). The spec says this: "Drivers should not return an error code unless the input is ambiguous", but it does not explain what constitutes an ambiguous input. In my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Should we make a recommendation whether the currently selected format or a default format should be returned? One proposal is to just return a default format if the requested pixelformat is unsupported. Returning the currently selected format leads to inconsistent results. Results: TRY_FMT/S_FMT should never return an error when the requested format is not supported. Drivers should always return a valid format, preferably a format that is as widely supported by applications as possible. Both TRY_FMT and S_FMT should have the same behaviour. Drivers should not return different formats when getting the same input parameters. The format returned should be a driver default format if possible (stateless behaviour) but can be stateful if needed. The API spec should let clear that format retuns may be different when different video inputs (or outputs) are selected. === Note that this will cause ABI breakage with existing applications. If an application expects an error condition to become aware that the requested format was not supported, that application will silently think the requested format was valid but in fact the driver is returning data in some other format. Tvtime (one of the more popular apps for watching analog television) is one such application that will broken. http://git.linuxtv.org/tvtime.git/blob/HEAD:/src/videoinput.c#l452 If YUVY isn't supported but UYVY is (for example, with the Hauppauge HVR-950q), the application will think it's doing YUYV when in fact the driver is returning UYVY. MythTV is a little better (it does ultimately store the format returned by the driver), however even there it depends on an error being returned in order to know to do userland format conversion. https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/NuppelVideoRecorder.cpp#L1367 Now it would be quite simple to change tvtime to use the expected behavior, but if backward compatibility with the ABI is of paramount importance, then we cannot proceed with this change as proposed. Don't misunderstand me - if I were inventing the API today then the proposed approach is what I would recommend - but since these parts of the ABI are something like ten years old, we have to take into account legacy applications. Discussion is welcome. 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] ngene: fix dvb_pll_attach failure
On Fri, Dec 14, 2012 at 6:02 PM, Antti Palosaari wrote: > That one is better solution... > > but it is clearly DRXD driver bug - it should offer working I2C gate control > after attach() :-( I looked quickly DRXD driver and there is clearly some > other places to enhance too. But I suspect there is no maintainer, nor > interest from anyone to start fix things properly, so only reasonable way is > to add that hack to get it working... > > Honestly, I hate this kind of hacks :/ That makes our live hard on long run. > It goes slowly more and more hard to make any core changes as regressions > will happen due to this kind of hacks. > > So send new patch which put demod chip sleeping after tuner attach. Or even > better, find out what is minimal set of commands needed do execute during > attach in order to offer working I2C gate (I suspect firmware load is > needed). Opening the gate at the end of the attach callback should be a trivial exercise. Should just be a call to drxd_config_i2c(fe, enable) at the end of drxd_attach(). 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/9] em28xx: refactor the frame data processing code
>>> Yes, there will likely be heavy merge conflicts... >>> In which tree are the videobuf2 patches ? >> It's in a private tree right now, and it doesn't support VBI >> currently. Once I've setup a public tree with yours and Hans changes, >> I'll start merging in my changes. > > I suggest to do the conversion on top of my patches, as they should make > things much easier for you. > I unified the handling of the VBI and video buffers, leaving just a few > common functions dealing with the videobuf stuff. Yup, that's exactly what I had planned. > In any case, we should develop against a common tree with a minimum > number of pending patches. > And we should coordinate development. > I don't work on further changes of the frame processing stuff at the moment. > Some I2C fixes/changes will be next. After that, I will try to fix > support for remote controls with external IR IC (connected via i2c). > >> Obviously it would be great for you to test with your webcam and make >> sure I didn't break anything along the way. > > Sure, I will be glad to test your changes. > >> I've also got changes to support V4L2_FIELD_SEQ_TB, which is needed in >> order to take the output and feed to certain hardware deinterlacers. >> In reality this is pretty much just a matter of treating the video >> data as progressive but changing the field type indicator. > > Ok, so I assume most of the changes will happen in em28xx_copy_video(). The changes really are all over the tree because it's not just vb2 support but also support for v4l2_fh, which means every ioctl() has a change to its arguments, and there is no longer an open/close call implemented. Also significant impact on the locking model. > Maybe we can then use a common copy function for video and VBI. Placing > the field data sequentially in the videobuf is what we already do with > the VBI data in em28xx_copy_vbi() Let's get something that works, at which point we can tune/optimize 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: [PATCH 0/9] em28xx: refactor the frame data processing code
On Thu, Dec 13, 2012 at 12:56 PM, Frank Schäfer wrote: > Am 13.12.2012 18:36, schrieb Devin Heitmueller: >> On Sat, Dec 8, 2012 at 10:31 AM, Frank Schäfer >> wrote: >>> This patch series refactors the frame data processing code in >>> em28xx-video.c to >>> - reduce code duplication >>> - fix a bug in vbi data processing >>> - prepare for adding em25xx/em276x frame data processing support >>> - clean up the code and make it easier to understand >> Hi Frank, >> >> Do you have these patches in a git tree somewhere that I can do a git >> pull from? If not then that's fine - I'll just save off the patches >> and apply them by hand. > > No, I have no public git tree. > >> I've basically got your patches, fixes Hans did for v4l2 compliance, >> and I've got a tree that converts the driver to videobuf2 (which >> obviously heavily conflicts with the URB handler cleanup you did). >> Plan is to suck them all into a single tree, deal with the merge >> issues, then issue a pull request to Mauro. > > Ahhh, videobuf2 ! > Good to know, because I've put this on my TODO list... ;) It's harder than it looks. There are currently no other devices ported to vb2 which have VBI and/or radio devices. Hence I have to refactor the locking a bit (since the URB callback feeds two different VB2 queues). In other words, there's no other driver to look at as a model and copy the business logic from. > Yes, there will likely be heavy merge conflicts... > In which tree are the videobuf2 patches ? It's in a private tree right now, and it doesn't support VBI currently. Once I've setup a public tree with yours and Hans changes, I'll start merging in my changes. Obviously it would be great for you to test with your webcam and make sure I didn't break anything along the way. I've also got changes to support V4L2_FIELD_SEQ_TB, which is needed in order to take the output and feed to certain hardware deinterlacers. In reality this is pretty much just a matter of treating the video data as progressive but changing the field type indicator. I'm generally pretty easy to find in #linuxtv or #v4l if you want to discuss further. 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: EM2800 and audio via USB ?
On Mon, Dec 10, 2012 at 2:32 PM, Frank Schäfer wrote: > a Terratec Cinergy 200 USB Most of those really old devices don't actually make the PCM audio available over the USB. That's why they provide an "audio out" connector - you're supposed to connect it to the line-in on your sound card. 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: msi Digivox ATSC board id [0db0:8810]
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer > Adding a new property to the RC profile certainly seems to be the > cleanest solution. > Do all protocols have paritiy checking ? Otherwise we could add a new > type RC_TYPE_NEC_NO_PARITY. > OTOH, introducing a new bitfield in struct rc_map might be usefull for > other flags, too, in the future... It's probably also worth mentioning that in that mode the device reports four bytes, not two. I guess perhaps if parity is ignored it reports the data in some other format? You will probably have to do some experimentation 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer wrote: > Am 09.12.2012 18:53, schrieb Matthew Gyurgyik: >> On 12/09/2012 12:06 PM, Frank Schäfer wrote: >>> Forget this sh... (never do multiple things at the same time ;) ) >>> >>> Reg 0x50 is set to according to rc_type specified in the selected remote >>> control map. >>> So if the correct map is selected, everything should be fine (as long as >>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet). >>> >>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so >>> the stick seems to use no NEC protocol. >>> >>> Matthew, insert a line >>> >>> ir_config = 0x01; >>> >>> before >>> >>> 380em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1); >>> >>> in em28xx-input.c and see if something shows up in the dmesg output. >>> >>> Regards, >>> Frank >> >> That seems to be a bit more successful! >> >> Here is the dmesg output: >> >>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle >>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1, >>> key 0x61d6 >>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2, >>> key 0x61d6 >>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1, >>> key 0x61d6 >>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1, >>> key 0x61d6 >>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2, >>> key 0x61d6 >>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1, >>> key 0x61d6 >>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2, >>> key 0x61d6 >> >> I pressed all the buttons on the remote (40 buttons). > > Did you cut the dmesg output ? Or do you really get these messages for > key 0x61d6 only ? > > It seems like things are working different with reg 0x50 = 0x01. Taking > a look into the datasheet might help, but I don't have it. ;) Setting that bit turns off NEC parity checking. I don't think we've ever had a need for it before, which is why it isn't exposed as configurable functionality in the driver. No clear answer on how this should be fixed, if that's what is really required. I guess in theory we could introduce some new board config option, but that would likely interfere with the ability to reconfigure the RC protocol at runtime. An alternative would be a new property of the RC profile, but that would pollute the definition of the struct presumably to work around some bug in a crappy remote control. 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: msi Digivox ATSC board id [0db0:8810]
On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik wrote: > Just to make sure I'm not misunderstanding, the messages should get logged > to dmesg, correct? I wrote the original IR support for the em2874, but it seems to have changed a bit since I submitted it. One thing that jumps out at me is if you specify a remote control of the wrong *type* (e.g. the driver is configured for RC5 but the actual remote is configured for NEC), then you're likely to get no events from the device. You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and try a remote that is of the other protocol type (e.g. if RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC). Then see if you get events. If so, then you know you have the correct RC protocol and just need to adjust the RC profile specified. Also, it's possible the remote control is an RC6 remote, which I never got around to adding em2874 driver support for. Take a look at the windows trace and see what register R50 is being set to. In particular, bits [3-2] will tell you what RC protocol the Windows driver expects the remote to be. I'm pretty sure I put the definition for the relevant bits in em28xx-reg.h. 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: msi Digivox ATSC board id [0db0:8810]
On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik wrote: > I was able to do a bit of testing tonight and this is what I found. > > A channel scan was unsuccessful: > http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg) > > Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to > crash and this messages to be logged in dmesg > http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt This looks like a combination of a misconfiguration of GPIOs and mplayer not properly handling an exception condition. You should definitely bring this up with the mplayer developers since their app shouldn't crash under this circumstance. > Audio is out-of-sync in mplayer. Using cache helps, but over time the audio > still goes out of sync. > http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt This has nothing to do with the tuner. The tuner delivers the MPEG2 stream already compressed and synchronized. If you're playback is out-of-sync, it's probably your ALSA drivers, PulseAudio, or mplayer that is the culprit. > Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to > generate a test.mpg > > mplayer plays the file fine without audio-sync issues, but VLC and Xine > refuse to play it. (is this normal?) What errors are VLC or Xine showing? Unless the stream is really corrupt VLC and Xine should play it fine. And if the stream were corrupt it wouldn't play with mplayer either? This sounds like bugs in VLC and Xine. There's definitely something going on in the tuner which is causing the channel scan to fail (and probably the tuning failure in mplayer). But all the stuff with actual playback causing segfaults, A/V sync issues, and failures to play back in certain applications are all userland problems that you would need to raise with the developers for those respective projects. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer wrote: > That's possible, because Matthews log doesn't show any access to this > register. > If it is not used, the question is if writing 0x07 to this register can > cause any trouble... Historically speaking, on that family of devices registers that are no longer used get treated as scratch registers (meaning writing to them has no adverse effect). 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: msi Digivox ATSC board id [0db0:8810]
On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
wrote:
>
> Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
> > On 12/05/2012 07:55 PM, Antti Palosaari wrote:
> >>
> >> It was good snoop. I didn't saw nothing very interesting. But, I
> >> think I found the reason. Just add that one line writing 0x42 to
> >> register 0x0d. IIRC I saw earlier it caused that kind of bug...
> >>
> >> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
> >> +{EM2874_R80_GPIO, 0xff, 0xff, 50}, /* GPIO_0=1 */
> >> +{0x0d,0xff, 0xff, 0},
> >> +{EM2874_R80_GPIO, 0xfe, 0xff, 0}, /* GPIO_0=0 */
> >> {0x0d,0x42, 0xff, 0},
> >> +{EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
> >> +{EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
> >> +{EM2874_R80_GPIO, 0x7e, 0xff, 20}, /* GPIO_7=0 */
> >> +{ -1, -1, -1, -1},
> >> +};
> >>
> >> regards
> >> Antti
> >>
> >>
> > I added that line, recompiled, tried the new module. Unfortunately
> > there was no improvement. I didn't see any differences in any of the
> > output (dmesg, azap). Let me know if there is any info you want me to
> > get.
> >
> > Matthew
>
> Did you switch back to
>
> .mpeg_mode = LGDT3305_MPEG_SERIAL,
> .tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE,
>
> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
> testing this ?
>
> You could also play with the other gpio settings.
>
> And the last idea (at the moment):
>
> +/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
> + * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
> +[EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
> +.name = "MSI DIGIVOX ATSC",
> +.dvb_gpio = msi_digivox_atsc,
> +.has_dvb = 1,
> +.tuner_type = TUNER_ABSENT,
> +.ir_codes = RC_MAP_MSI_DIGIVOX_III,/* just a guess
> from looking at the picture */
> +.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,/* TODO */
> +.i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
> +EM28XX_I2C_CLK_WAIT_ENABLE |
> +EM28XX_I2C_FREQ_100_KHZ,
> +},
>
> => change .xclk to 0x0f.
> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
> means...
>
> Hope this helps,
> Frank
I'm pretty sure the XCLK register isn't used at all on the em2874
(it's probably being set in the Windows driver because of some shared
code with the older 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: [PATCH 1/2] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2
On Tue, Dec 4, 2012 at 11:25 AM, Michael Krufky wrote: > Do you have any issues with these two patches as-is? Any suggestions? > If not, is it OK with you if I request that Mauro merge this for v3.9 > ? I have no specific issues with the patch as-is. 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: [PATCH 1/2] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2
On Tue, Dec 4, 2012 at 11:07 AM, Michael Krufky wrote: > This patch removes the dependendency of VIDEO_AU0828 on VIDEO_V4L2 by > creating a new Kconfig option, VIDEO_AU0828_V4L2, which enables analog > video capture support and depends on VIDEO_V4L2 itself. > > With VIDEO_AU0828_V4L2 disabled, the driver will only support digital > television and will not depend on the v4l2-core. With VIDEO_AU0828_V4L2 > enabled, the driver will be built with the analog v4l2 support included. Hi Mike, This is generally good stuff. A couple of thoughts. It seems that this driver effectively takes the approach which is the exact reverse of all the other hybrid drivers - it mandates DVB with V4L as optional, whereas most of the other drivers mandate V4L with DVB is optional. Now I recognize that in this case it was done because of some specific business need -- however I have to wonder if the moving around of all the code to no longer be "video" vs. "dvb" specific could be leveraged to allow users to select either condition - to select DVB, V4L, or both. This seems like the direction things are going in -- we've restructured the tree based on bus interface type (pci/usb/etc) rather than v4l versus dvb. This might be an opportunity to define the model for how other hybrid devices could also be refactored to not have V4L or DVB if not 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik wrote: >> I would try running "lsusb -v" and send the output. Make sure that >> it's not expecting to use bulk mode for DVB (which would require >> driver changes to support). >> >> Devin >> > Here is the output of lsusb -v > http://pyther.net/a/digivox_atsc/patch2/lsusb.txt Hmmm, it's isoc, so that should be ok. Maybe the 3305 TS configuration is mismatched (serial vs. parallel). I don't recall off the top of my head, but I think em2875 is pretty much always in serial mode, so check the lgdt3305 config block passed in the dvb_attach() call and see if it's the same. 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: msi Digivox ATSC board id [0db0:8810]
On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik wrote: > Although, it looked like tuning was semi-successful, I tried the following > > * cat /dev/dvb/adapter0/dvr0 (no output) > * mplayer /dev/dvb/adapter0/dvr0 (no output) > * cat /dev/dvb/adapter0/dvr0 > test.mpg (test.mpg was 0 bytes) I would try running "lsusb -v" and send the output. Make sure that it's not expecting to use bulk mode for DVB (which would require driver changes to support). 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 to use multiple video devices simultaneously
On Mon, Dec 3, 2012 at 5:02 AM, Dmitriy Alekseev wrote: > Hello. > > I have a pair of capture dongles Avermedia DVD EZMaker 7 (C039) which have > cx231xx chip. > Now using vlc and gst-launch-0.10 I can watch/stream video only from one of > them simultaneously. > > For example videolan messages I got opening second device: > [0x7f055c001688] v4l2 demux error: > VIDIOC_QBUF failed libv4l2: error mmapping buffer 0: Device or resource busy > [0x7f055c001688] v4l2 demux error: > VIDIOC_QBUF failed libv4l2: warning v4l2 mmap buffers still mapped on close() > [0x7f055c002ec8] v4l2 access error: mmap failed (Device or resource busy) > [0x7f055c002ec8] v4l2 access error: mmap failed (Device or resource busy) > [0xb5c698] main input error: open of `v4l2:///dev/video0' failed: (null) > > I wonder, what the problem is? You're probably using too much USB bandwidth. A single USB host controller does not have enough bandwidth to support two full resolution video captures at the same time. The video is uncompressed, and each will try to use around 60% of the available USB bandwidth. For a scenario like this, you would need to have two separate USB host controllers, reduce the capture resolution significantly, or choose different boards (such as a PCI or PCIe product). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LGDT3305 configuration questions
Hi Frank, I might be able to help out here a bit. On Sun, Dec 2, 2012 at 6:53 AM, Frank Schäfer wrote: > 1) When should deny_i2c_rptr in struct lgdt3305_config be set ? > I can see what the code does, but I'm unsure which value to use. > What's the i2c repeater / i2c gate ctrl and how does it work ? Basically an i2c gate is a construct where i2c traffic from the bridge to the tuner goes *through* the demodulator, and the demodulator has the ability to open/close the gate to block traffic. This is very typical in tuners since in many cases servicing i2c traffic can reducing tuning quality (hence you want it to only receive traffic if it's actually intended for the tuner). It's sometimes referred to as an I2C repeater, but it's the same thing. I discuss some more of the details here: How Tuners Work http://www.kernellabs.com/blog/?p=1045 > 2) User defined IF frequencies (fields vsb_if_khz and qam_if_khz in > struct lgdt3305_config): > What happens if no user defined values are selected ? The corresponding > registers seem to be 0x in this case (for the LGDT3305). You won't get a signal lock. This value must be set, and it must match the value configured in the tuner. > Which IF is used in this case ? > The USB log of the stick shows that the registers are set to 4a 3d 70 a3 > (for QAM; don't have a log for VSB). > According to the code in lgdt3305_set_if() this corresponds to a value > of .qam_if_khz = 4000. > In the em28xx driver we have another device with the LGDT3304 which sets > this value to 4000, too. > OTOH, these fields claim to hold the value in kHz, so this would be 4MHz > only. But AFAIK intermediate frequencies are usually about 10 times > higher !? ATSC seems to use 44MHz. 4000 MHz is a very common intermediate frequency for Both QAM and ATSC. The value is user definable but in reality the value chosen will directly impact the quality of tuning reception (the manufacturer typically determines the ideal IF by putting a spectrum analyzer on the output and evaluating performance at different IF levels). Hence if you got 4000 from the em28xx trace, that is probably the correct value (make sure the same value is specified in both the demodulator and tuner configuration blocks - in this case the tda18271_cfg block passed at dvb_attach). It's also not impossible (although uncommon) to have different IF settings for ATSC versus ClearQAM, so you should indeed get a second trace to see if it's 4MHz in both cases. 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: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24
On Sat, Nov 24, 2012 at 11:08 PM, Bob Lightfoot wrote: > Hope you can shed an idea or three. > > My end goal it to again record analog video in MythTV. Two other questions: Have you tried dropping the card into a Windows box to make sure your hardware isn't just dead? I know you said you thought it worked 6-9 months ago, but it's possible that it is just dumb luck that part of the hardware died and it has nothing to do with the kernel revision. Also, what kernel did it work last on? If you could determine a specific revision, it would help narrow down where the problem was introduced (assuming it really is a regression in the kernel). 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: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24
On Sat, Nov 24, 2012 at 11:08 PM, Bob Lightfoot wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Devin :
> Let me see if I can answer some of your questions.
>
> 1. lspci -nn -vvv returns the following for the HVR-1600 Card
>
>> 01:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
>> CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog
>> Video/Broadcast Audio Decoder [14f1:5b7a] Subsystem: Hauppauge
>> computer works Inc. WinTV HVR-1600 [0070:7444] Control: I/O- Mem+
>> BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR-
>> FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
>> DEVSEL=medium >TAbort- SERR- > Latency: 64 (500ns min, 5ns max), Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 17 Region 0: Memory at f400
>> (32-bit, non-prefetchable) [size=64M] Capabilities: [44] Vital
>> Product Data Not readable Capabilities: [4c] Power Management
>> version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable-
>> DSel=0 DScale=0 PME- Kernel driver in use: cx18 Kernel modules:
>> cx18
>
>
> 2. Links on Google to files related to this issue :
> A. The Main Can on the Tuner Card -
>https://docs.google.com/open?id=0B95B_9punKEmeHBUNHprMnVNV00
> B. First of the Conextant Chips on Card -
>https://docs.google.com/open?id=0B95B_9punKEmT2wwbmltSzFWb2c
> C. Second of the Conextant Chips on Card -
>https://docs.google.com/open?id=0B95B_9punKEmNTdVMENHUFllNzA
> D. A Final ESMT Chip on Card -
>https://docs.google.com/open?id=0B95B_9punKEmYUd5eWNrWEhudWc
> E. The v4l2-ctl and cat /dev/video2 file made from Svideo1
>https://docs.google.com/open?id=0B95B_9punKEmUGdJNTI3ZnR2T1k
> F. The v4l2-ctl and cat /dev/video2 file made from Tuner1
>https://docs.google.com/open?id=0B95B_9punKEmOUhLWjNyRG02NDA
>
> 3. I tested with both the SVideo and Coax Inputs for Analog. As
> you'll see from the 10 second videos the SVideo works fine but the
> Coax Tuner is a problem.
>
> 4. I don't know if I am capturing raw for MPEG compressed for certain
> but I'll go over the test method used to make to two videos and that
> should also answer this question.
>
> 5. As far as test tools I have used v4l2-ctl, mplayer, vlc and cat
> commands for testing.
>
> 6. Commands issued in order were as follows for the SVideo Capture:
> A. v4l2-ctl --list-devices
> B. v4l2-ctl -d /dev/video2 --list-inputs
> C. v4l2-ctl -d /dev/video2 --set-input=1 {Note this is SVideo1}
> D. v4l2-ctl -d /dev/video2 --list-standards | less
> E. v4l2-ctl -d /dev/video2 --set-standard=1 {Note this is NTSC}
> F. mplayer /dev/video2 -cache 8192
> G. close mplayer after successfully watching video
> H. cat /dev/video2 > hvr1600-svideo1.mpg
>
> 7. Commands issued in order were as follows for the Tuner1 Capture:
> A. v4l2-ctl --list-devices
> B. v4l2-ctl -d /dev/video2 --list-inputs
> C. v4l2-ctl -d /dev/video2 --set-input=0 {Note this is Tuner1}
> D. v4l2-ctl -d /dev/video2 --list-standards | less
> E. v4l2-ctl -d /dev/video2 --set-standard=1 {Note this is NTSC}
> F. v4l2-ctl -d /dev/video2 -f 67.250 {Note this is us-bdcst chan 4}
> G. mplayer /dev/video2 -cache 8192
> H. close mplayer after successfully watching video
> I. cat /dev/video2 > hvr1600-Tuner1.mpg
>
> 8. It should be obvious by this point, but I am too much of a
> neophyte to be compiling kernels. I am running Centos 6 and yum for
> updates for anything I have applied has come through their packaging
> and distribution system.
>
> NOTES : This SVideo looks good but the Tuner1 is garbage. I also
> tested the coax input thru my HVR-1850 using xawtv and while it had no
> audio the video was good although slightly greenish. So I don't
> suspect the coax cable, especially since when connected to a standard
> TV it produces a good picture.
>
> Hope you can shed an idea or three.
>
> My end goal it to again record analog video in MythTV.
Ok, so this narrows it down quite a bit. The fact that the s-video is
working but the tuner isn't suggests either the tuner is off tune, or
the analog demod isn't setup properly. After running the "v4l2-ctl -s
1" command, do you see the standard set to NTSC-M if you then run
"v4l2-ctl --all" ? Also, do you hear audio properly despite the video
being corrupt?
My guess is that some recent subtle change to the subdev framework is
probably resulting in the commands not actually being delivered to the
demod. I ran into similar problems a few months ago when doing some
work on the cx18 driver for WSS configuration, although I didn't get a
chance to push any patches 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-in
Re: Poor HVR 1600 Video Quality
On Sat, Nov 24, 2012 at 12:31 PM, Bob Lightfoot wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear Linux Media Community:
> I am struggling with what has changed in recent {past 6-9 months} of
> kernel releases as related to the HVR-1600 Tuner Card and Analog Signal
> processing. I spent the bulk of today going through my video chain
> feeding into the HVR-1600 and tried multiple sources all of which
> provide good video and sound when fed into a Sanyo TV bought in the
> 1990s. They all produce recordings similar to the attached file.
> It almost looks like noise on the system and I am beginning to suspect
> my card may be hosed on the analog side. Just looking for any thing I
> may have missed while RTFM and Google. I'd share a 1 minute sample
> capture but 30.5 mb is too large to attach to a google email and I'm not
> sure where to drop a sample file for others to download and check out.
> It should be noted analog video was fine, but sound was intermittent
> with the kernels and drivers in use back in May. Now the sound it rock
> solid, but the video has gone noisy.
A few questions,
Which version of the HVR-1600 do you have? Could you provide the
exact PCI ID, vendor ID, and subsystem ID?
Can you post the 1-minute video to a website where it can be downloaded?
Are you using the coax input? Composite? S-video? If you're using
the coax input, it would be good just as a test for you to try the
s-video input, as that would help rule out various problems that could
be introduced by the tuner and demodulation phases.
Are you capturing MPEG compressed video or raw? The HVR-1600 supports both.
Are you familiar enough with compiling kernels that you could bisect
this down to a specific commit which introduces the problem?
What application(s) are you testing with?
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: The em28xx driver error
On Thu, Nov 15, 2012 at 11:31 AM, Frank Schäfer wrote: > Hmm... I've made some experiments to find out what gcc does on x86 and > it seems to ignore bit shifting > 32. > I also noticed that this line has been removed in 3.7-rc. > So we do NOT want to halve the height for interlaced devices here, right ? Even with the datasheets, it was never clear to me what role the accumulator size played. It appeared to work regardless of whether it was halved (although making it zero obviously caused problems). Hence, since we couldn't see any visible difference, Mauro just removed the code. My guess is that it effects the on-chip internal buffering hence it's possible that performance/reliability could be effected under extreme load or some edge case, but I don't have any data to back up that assertion 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: The em28xx driver error
On Wed, Nov 14, 2012 at 11:58 AM, Frank Schäfer wrote: > This looks indeed like a bug. > a >>= b means a = a >> b, which in this case means shifting height 480 > or 576 bits to the right... > height >> 1 means height /= 2 which seems to be sane for interlaced devices. > OTOH, I wonder why it seems to be working on other platforms !? > Unfortunately I don't have an interlaced device here for testing. :( It's definitely a bug. I think Mauro put a patch in for 3.7 or 3.8. The reason it works under x86 is because shifting an arbitrary number of bits > 32 causes indeterminate behavior, and out of dumb luck it has no effect on x86. But yeah, I changed the code to shift by one bit and it's been working fine on ARM for months in my environment (DM3730). 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: Color problem with MPX-885 card (cx23885)
On Tue, Nov 13, 2012 at 2:03 PM, Neuer User wrote: > Thanks, you probably hinted me into the right direction. I use mplayer > to play the video stream and mplayer does indeed recognize a 640x480 > video stream. > > I am not using any crop settings for these tests. But maybe it is > possible to tell mplayer that the stream is 720x576 instead of the > 640x480 it believes. That is, if the stream coming from the driver is > really not 640x480. Just to be clear, I wasn't intending to suggest that you were using any of the actual V4L2 cropping features. I'm just saying that if the video scaler were broken, it's possible that the frames are *effectively* being cropped at 640x480. But yeah, you should definitely try capturing at 720x576 in mplayer. You can specific command line arguments to mplayer to set the width and height. 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: Color problem with MPX-885 card (cx23885)
On Tue, Nov 13, 2012 at 1:02 PM, Neuer User wrote: > The HSYNC problem is bigger than I thought. I compared the captured > image with an image from another (USB) video digitizer and it is obvious > that the image has lost about 10-20% on the right side and on the bottom. > > Can probably be easily fixed. But it is no commercial project, so I need > to do it myself, I guess. I hope there are some settings in the driver. > Any idea where I need to look? (Is it the cx23885 driver at all or even > the cx25840?) Almost certainly just changes needed for the cx25840 driver. These are all basic issues with the video decoder core. Google around - the cx25840 datasheet is readily available. You have to watch out though because there are some subtle differences that you won't be able to detect if it's a cx23887 or cx23888 as opposed to the cx23885. Regarding the cropped image, what capture resolution are you using? Perhaps the scaler isn't working and you're setting the capture to something like "640x480" (which would effectively crop out lines 640-720 on the horizontal and lines 480-576 on the vertical). 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: Color problem with MPX-885 card (cx23885)
On Tue, Nov 13, 2012 at 11:39 AM, Neuer User wrote: > I had looked through the linux-media GIT tree for any commits that have > "cx23885" in the description. The last ones I found were from mid 2011. Yeah, the changes were actually made to the cx25840 driver, which is used/shared by the cx23885. > I can confirm that the biggest problem, the color problem, is fixed at > least with kernel 3.5.7 (maybe earlier). Ok, good. > The minor ones (card not autodetected, and black border on the left > side) can probably be dealt with, e.g. in postprocessing. Or is there a > chance to fix these in the driver? They can almost certainly be fixed in the driver (the black border is a result of incorrect HSYNC configuration for PAL standards). The bigger issue though is finding someone willing to do the work. If this is for a commercial application, you may wish to reach out to Steven Toth. He did the original MPX support as a consulting project. 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: Color problem with MPX-885 card (cx23885)
On Tue, Nov 13, 2012 at 9:10 AM, Neuer User wrote: > Hello > > First of all, I don't know, if this is the right mailing list. I haven't > found any other. The video4linux list seems to be abandoned. > > I am testing a Commell MPX-885 mini-pcie card, which is based on a > cx23885 chip. There is "initial" support in the linux kernel for this card: > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=2cb9ccd4612907c0a30de9be1c694672e0cd8933 > > My system is based on Ubuntu 12.04LTS amd64 with kernel 3.2.0.32. You should start by installing the current media_build tree. There were a bunch of cx23885 fixes done back in June, which won't be in 12.04. I believe this issue may already be fixed. 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 v2 21/21] em28xx: add module parameter for selection of the preferred USB transfer type
On Fri, Nov 9, 2012 at 11:00 AM, Frank Schäfer wrote: > Well, I deliberately called the module 'prefer_bulk' (and not > 'use_bulk', 'force_bulk' ...) which should imply that nothing is guaranteed. > And selecting bulk transfers for a device which actually doesn not > provide bulk support doesn't make sense and is clearly the users fault. > Anway, I'm fine with adding a warning message and maybe I could extend > the module parameter description, too. > > I'm going to wait for further feedback from Mauro before sending an > updated version of the patch (series). Yeah, none of this should hold up it being merged as-is. A patch adding the warning can be submitted after the fact. 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 v2 21/21] em28xx: add module parameter for selection of the preferred USB transfer type
On Thu, Nov 8, 2012 at 1:37 PM, Frank Schäfer wrote: > at least the "Silvercrest Webcam 1.3mpix" (board 71) exposes both > endpoint types (0x82=isoc and 0x84=bulk). Ah, interesting. It might be worthwhile to log a warning in dmesg if the user sets the modprobe option but the board doesn't actually expose any bulk endpoints. This might help avoid questions from users (we already got one such question by somebody who believed enabling this would put the device into bulk mode even though his hardware didn't support 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 v2 21/21] em28xx: add module parameter for selection of the preferred USB transfer type
On Thu, Nov 8, 2012 at 1:11 PM, Frank Schäfer wrote: > By default, isoc transfers are used if possible. > With the new module parameter, bulk can be selected as the > preferred USB transfer type. Hi Frank, Does your device actually expose both isoc and bulk endpoints? If I recall from the datasheet, whether isoc or bulk mode is provided is not actually configurable from the driver. The EEPROM dictates how the endpoint map gets defined, and hence it's either one or the other. If that is indeed the case, then we don't need a modprobe option at all (since would never actually be user configurable), and we should just add a field to the board definition to indicate that bulk should be used for that product. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] em28xx: add support fur USB bulk transfers
On Tue, Oct 30, 2012 at 12:06 AM, Mauro Carvalho Chehab wrote: > Did a git bisect. The last patch where the bug doesn't occur is this > changeset: > em28xx: add module parameter for selection of the preferred USB > transfer type > > That means that this changeset broke it: > > em28xx: use common urb data copying function for vbi and non-vbi > devices Oh good, when I saw the subject line for that patch, I got worried. Looking at the patch, it seems like he just calls the VBI version for both cases assuming the VBI version is a complete superset of the non-VBI version, which it is clearly not. That whole patch should just be reverted. If he's going to spend the time to refactor the code to allow the VBI version to be used for both then fine, but blindly calling the VBI version without making real code changes is *NOT* going to work. Frank, good job in naming your patch - it made me scream "WAIT!" when I saw it. Bad job for blindly submitting a code change without any idea whether it actually worked. ;-) I know developers have the tendency to look at code and say "oh, that's ugly, I should change that." However it's more important that it actually work than it be pretty. 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 00/23] em28xx: add support fur USB bulk transfers
Hi Frank, On Sun, Oct 21, 2012 at 12:52 PM, Frank Schäfer wrote: > This patch series adds support for USB bulk transfers to the em28xx driver. This is a welcome change that some users have been asking about for a while. > Patch 1 is a bugfix for the image data processing with non-interlaced devices > (webcams) > that should be considered for stable (see commit message). > > Patches 2-21 extend the driver to support USB bulk transfers. > USB endpoint mapping had to be extended and is a bit tricky. > It might still not be sufficient to handle ALL isoc/bulk endpoints of ALL > existing devices, > but it should work with the devices we have seen so far and (most important !) > preserves backwards compatibility to the current driver behavior. > Isoc endpoints/transfers are preffered by default, patch 21 adds a module > parameter to change this behavior. > > The last two patches are follow-up patches not really related to USB tranfers. > Patch 22 reduces the code size in em28xx-video by merging the two URB data > processing functions This is generally good stuff. When I originally added the VBI support, I kept the URB handlers separate initially to reduce the risk of breaking existing devices, and always assumed that at some point the two routines would be merged. You did regression test without VBI support enabled though, right? > and patch 23 enables VBI-support for em2840-devices. Patch 23 shouldn't be applied unless somebody has an em2840 device to test with first. Nobody has complained about this so far, and it's better to not support VBI than to possibly break existing support. > Please note that I could test the changes with an analog non-interlaced > non-VBI device only ! > So further tests with DVB/interlaced/VBI devices are strongly recommended ! So here's the problem: I don't have the cycles to test this, and all the refactoring presents a very real risk that breakage of existing support could occur. You've basically got three options if you want to see this merged upstream: 1. Wait for me to eventually do the testing. 2. Plead for users to do testing, in particular of the VBI support for interlaced devices (which is 99% of devices out there) 3. See if Mauro has time to do the testing. 4. Spend $30 and buy one of the dozens of em28xx based analog capture devices out there and do the validation yourself (a huge percentage of the "Video tape capture devices" are em28xx based. For example, when I did the original VBI work, I used the following: KWorld DVD Maker USB 2.0 VS- USB2800 USB 2.0 Interface http://www.newegg.com/Product/Product.aspx?Item=N82E16815100112 If you're in the United States, I can mail you a device for testing. But given how dirt-cheap they are, buying one yourself might be easier (and if the money is really the issue, send me your paypal details offline and I'll give you the $30.00). Thanks for you hard work on this, and it will be great to get this stuff into the mainline. 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 to add support for the em2765 webcam Speedlink VAD Laplace to the kernel ?
On Sat, Oct 6, 2012 at 7:56 AM, Mauro Carvalho Chehab wrote: > AFAIKT, newer em28xx chips are using this concept. The em28xx-i2c code require > changes to support two I2C buses, and to handle 16 bit eeproms. We never cared > of doing that because we never needed, so far, to read anything from those > devices' eeproms. I actually wrote the code to read the 16-bit eeprom from the em2874, but removed it before submitting it upstream because I was afraid well-intentioned em28xx users trying to add support for their boards would trash their eeprom. This is because performing a read against a 16-bit eeprom is equivalent to a write on an 8-bit eeprom. Hence if the user didn't know what he/she was doing, and used the 16-bit eeprom code against an older eeprom, the eeprom would get trashed (this actually happened to me once when I was doing the em2874 device support originally). If we really want that code back in the tree, I can dig it up -- but I won't be responsible for users killing their 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-1600 fails frequently on multiple recordings
On Thu, Oct 4, 2012 at 7:58 AM, Brian J. Murrell wrote: > I have a fairly new HVR-1600 which I have seen fail quite a number of > times now when it's asked to record more than one channel on a clearqam > multiplex. This time it was 3 recordings at once. > > There's nothing at all in the kernel ring buffer, just mythtv reports a > failed recording. Usually one of the files being recorded to will only > be 376 bytes long and the rest will be 0 bytes. > > I am running ubuntu's 3.2.0-27-generic kernel with what looks like a > 1.5.1 cx18 driver. The card is either a: > > 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with > Integrated Analog Video/Broadcast Audio Decoder > > or a: > > :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) > > Sorry. I don't recall which is which any more. > > But I really need to figure this out since failed recordings is causing > all kinds of disappointment around here. I'm really at the end of my > rope with it. > > Tomorrow morning I am going to demote this card to secondary duty and > promote my HVR-950Q to primary duty since I never had this kind of > grief with it. But even in secondary duty, it could very well be > called upon to record multiple clearqam channels simultaneously so I > would really like to get this figured out. > > Any ideas? I think the real question at this point is: what version of MythTV are you running? I've seen so many reports recently of breakage in the MythTV codebase related to recording, I am almost inclined to demand you reproduce it outside of MythTV before we even spend any time talking about it. Also, has anything changed in your environment? Was it working before, and then you upgraded the kernel or Myth, and now it's not working? Or has there been a consistent pattern of failure over some extended period of time? The cx18 driver has changed very little as of late - the MythTV codebase has changed heavily and people are all over the place complaining about breakage. I'm not trying to get into the finger-pointing game, but I just want to better understand the history/background before I can make any recommendations. 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 RFC] em28xx: PCTV 520e switch tda18271 to tda18271c2dd
On Mon, Oct 1, 2012 at 8:52 PM, Antti Palosaari wrote: > New drxk firmware download does not work with tda18271. Actual > reason is more drxk driver than tda18271. Anyhow, tda18271c2dd > will work as it does not do as much I/O during attach than tda18271. > > Root of cause is tuner I/O during drx-k asynchronous firmware > download. request_firmware_nowait()... :-/ This seems like it's just changing the timing of the initialization process, which isn't really any better than the "msleep(2000)". It's just dumb luck that it happens to work on the developer's system. Don't get me wrong, I agree with Michael that this whole situation is ridiculous, but I don't see why swapping out the entire driver is a reasonable fix. 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: DiBcom 7000PC: Not able to scan for services on Raspberry Pi
On Sat, Sep 29, 2012 at 3:34 PM, Ladislav Józsa wrote: > Running the same on my x86_64 machine works and tvheadend sees > multiplexes. What else information do you need from me in order to > track the problem? Recompile your kernel with debug info so we can see the symbols for the stack dump. Otherwise there is no way for anybody to know where the oops is occurring in the 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: [PATCH] Support for Asus MyCinema U3100Mini Plus
On Thu, Sep 20, 2012 at 2:54 PM, Oliver Schinagl wrote: > dvbscan and dvbv5-scan does constantly say 'tuning failed' but it does say > that on my terratec too. It does work fine however, so probably a bug in > driver/tool unrelated to this patch. Just to be clear, the message "tuning failed" is expected behavior (albeit very misleading). Basically it means that the tuning attempt was performed but it failed to get a frequency lock on that channel. This is very common in cases where you're scanning a range of frequencies where many of them will not actually achieve a signal lock. I would really like to change that message to something more clear, especially since you're certainly not the first one to think it indicated there was a problem. Suggestions/patches welcome. 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] Support for Asus MyCinema U3100Mini Plus
On Wed, Sep 19, 2012 at 2:44 PM, wrote: > From: Oliver Schinagl > > This is initial support for the Asus MyCinema U3100Mini Plus. The driver > in its current form gets detected and loads properly. > > Scanning using dvbscan works without problems, Locking onto a channel > using tzap also works fine. Only playback using tzap -r + mplayer was > tested and was fully functional. Hi Oliver, The previous thread suggested that this driver didn't work with dvbv5-scan and w_scan. Is that still the case? If so, do we really want a "half working" driver upstream? Seems like this is more likely to cause support headaches than the device not being supported at all (since users will "think" it's supported but it's actually broken in some pretty common use cases). Or perhaps I'm mistaken and the issues have been addressed and now it works with all the common applications. 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: Terratec Cinergy T PCIe Dual doesn;t work nder the Xen hypervisor
On Tue, Sep 18, 2012 at 2:34 PM, Javier Marcet wrote: > I can't say how happy I am that you were wrong in your guess. Quoting > Konrad Rzeszutek Wilk: Well, you haven't proven me wrong yet. :-) > """ > The issue as I understand is that the DVB drivers allocate their > buffers from 0->4GB most (all the time?) so they never have to do > bounce-buffering. > > While the pv-ops one ends up quite frequently doing the > bounce-buffering, which implies that the DVB drivers end up allocating > their buffers above the 4GB. > This means we end up spending some CPU time (in the guest) copying the > memory from >4GB to 0-4GB region (And vice-versa). > """ > > You can see the original thread where this was found, together with a > working patch, here: > > http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html As far as I can read, the patch has never been confirmed to work. The user mentioned upgrading to an updated kernel and seeing a slight decrease in load: http://lists.xen.org/archives/html/xen-devel/2012-01/msg02166.html Further, the reason many of the drivers in question require the memory to be in the 0-4GB memory region is due to some hardware not being able to DMA to memory > 4GB. Such a change would have to be tested with every board that does scatter/gather, and the framework would likely have to change to explicitly allow the board driver to specify whether it supports memory > 4GB. In short, this is a useful bit of information, but not clear whether it would actually solve the underlying problem. Again, I would be happy to be proven wrong, but there appears to still be quite a bit of work required for such. I would suggest trying the patch yourself to see if it has any visible effect on 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: Terratec Cinergy T PCIe Dual doesn;t work nder the Xen hypervisor
On Mon, Sep 17, 2012 at 8:05 PM, Javier Marcet wrote: > Initially I thought Xen would be the cause of the problem, but after > having written on > the Xen development mailing list and talked about it with a couple > developers, it isn't > very clear where the problem is. So far I haven't been able to get the > smallest warning > or error. This is a very common problem when attempting to use any PCI/PCIe tuner under a hypervisor. Essentially the issue is all of the virtualization solutions provide very poor interrupt latency, which results in the data being lost. Devices delivering a high bitrate stream of data in realtime are much more likely for this problem to be visible since such devices have very little buffering (it's not like a hard drive controller where it can just deliver the data slower). The problem is not specific to the cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards work this way, and they cannot really be blamed for expecting to run in an environment with really crappy interrupt latency. I won't go as far as to say, "abandon all hope", but you're not really likely to find any help in this forum. 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: hdpvr and HD PVR 2 Gaming Edition from Haoppauge
On Thu, Sep 13, 2012 at 2:28 PM, Thomas Seilund wrote: > Do you know if anybody plans to make a driver? I have not heard of any such plans. It's a brand new device though, so it's possible that somebody will step up to do such (especially if the original HD-PVR stops being sold). > I would love to contribute but my skills are not quite there! > > I have looked at the code for hdpvr kernel driver and I will try to pick up > more knowledge from the internet. > > Do you have any hints on where to look? The Linuxtv.org wiki has some docs on creating Linux USB drivers (techniques for reverse engineering Windows drivers, collecting USB bus traces, etc). Normally I might suggest that you try to find the datasheets for all the chips involved, but I can tell you that you won't find them publicly available. 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 and HD PVR 2 Gaming Edition from Haoppauge
On Wed, Sep 12, 2012 at 11:37 AM, Thomas Seilund wrote: > Hi All, > > I just bought the HD PVR 2 Gaming Edition from Hauppauge. > > It there any change this device will be supported by the hdpvr kernel > driver. (Or any other driver for that matter!) No. It is a totally different hardware design and will need an entirely new 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: [RFCv2 API PATCH 00/28] Full series of API fixes from the 2012 Media Workshop
On Fri, Sep 7, 2012 at 9:29 AM, Hans Verkuil wrote: > I have also tested this patch series (actually a slightly older version) > with em28xx. That driver needed a lot of changes to get it to pass the > v4l2-compliance tests. Those can be found here: > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/em28xx This is mostly informational, but problems found with the em28xx v4l driver will likely also be in the au0828 (since when doing the analog support for au0828 I derived large portions of the code from em28xx). 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: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
On Sat, Sep 1, 2012 at 12:13 PM, Antti Palosaari wrote: > Is there anyone caring to review that carefully? > > I am quite out with semaphores (up/down_interruptible) and also frontend is > so complex... I would rather design / write whole dvb-frontend from the > scratch :] (not doing that as no time). If you're not willing to take the time to understand why the existing dvb-frontend is so complex, how could you possibly suggest that you could do a better job rewriting it from scratch? :-) Like most things, the devil is in the details. The threading model is complicated not because it was done poorly, but because there are lots of complexity that is not obvious (combined with it having evolved over time to adapt to hardware bugs). It's only when you run it against a half dozen cards with different behavior that you begin to see why certain things were done the way they were. In this case, I think the race condition in question has become more obvious because of more aggressive use of power management for the tuner and demod. Because powering down the frontend now takes actual time (due to i2c), users are now starting to hit the race condition. 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] rc-core: move timeout and checks to lirc
On Mon, Aug 20, 2012 at 6:02 PM, Mauro Carvalho Chehab wrote: > So, IMO, it makes sense to have a "high end" API that accepts > writing keystrokes like above, working with both "raw drivers" > using some kernel IR protocol encoders, and with devices that can > accept "processed" keystrokes, like HDMI CEC. It might also make sense to have a third mode for devices that support high level protocols such as RC5/NEC but you want to leverage the very large existing LIRC database of remote controls. The device would advertise all the modes it supports (RC5/NEC/RC6/whatever), and from there it can accept the actual RC codes instead of a raw waveform. I recognize that this is case that falls in between the two models proposed, but there are devices that fall into this category. The alternative for those devices would be for LIRC to convert the RC5 code into a raw waveform, send the raw waveform to the kernel, and then the driver convert it back into a code, which would be quite messy since it would have to figure out what RC format it was originally in. It would be much better if LIRC could just send the RC5 code directly into the kernel. 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: V4L2 API ambiguities
On Mon, Aug 13, 2012 at 5:39 PM, Mauro Carvalho Chehab wrote: > No, it is not out of scope. The thing is that none of the developers > that are going to be there proposed a DVB-specific themes, unfortunately. > > Yet, there are two themes there that are not V4L only: the userspace > discussions and the SoC discussions. I expect that it will focus at > the media API's as a hole, and not just V4L API. I'm talking specifically about a discussion of "V4L2 API Ambiguities", which is the topic of this thread and the meeting in question. I realize other parts of the conference include DVB. If you want me to start piling onto this thread will all the problems/deficiencies related to our DVB API, we can certainly do that. However, none of the people on this thread will have any real insight into them given those individuals focus entirely on V4L2. 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: V4L2 API ambiguities
On Mon, Aug 13, 2012 at 4:27 PM, Walter Van Eetvelt wrote: > For me there is a an issue in the V4L specs for the support of DVB-S/C/T > devices where the CI device is decoupled from the Tuners. > At the moment there is no standard solution on which device drivers > implementers and Application programmers can fall back. DVB isn't part of the V4L spec. There are *tons* of problems with DVB, none of which are being discussed in this meeting (out of scope). 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, RFC] Fix DVB ioctls failing if frontend open/closed too fast
On Sat, Aug 11, 2012 at 10:15 PM, Mauro Carvalho Chehab wrote: > Devin/Antti, > > As Juergen mentioned your help on this patch, do you mind helping reviewing > and testing it? I guided Juergen through the creation of the patch via #linuxtv a couple of weeks ago. While I'm generally confident that it should work (and it does address his basic issue), I hadn't had the time to stare at the code long enough to see what other side effects it might produce. I'm tied up in other projects right now and am not confident I will have cycles to look at this closer. Antti, if you want to give it some cycles, this would be a good fix to get upstream (and you've already been looking at dvb_frontend.c for quite a while, so I believe you would be able to spot a problem if one exists). 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 17/24] au0828: fix possible race condition in usage of dev->ctrlmsg
On Thu, Aug 9, 2012 at 7:48 PM, Mauro Carvalho Chehab
wrote:
> Em 06-08-2012 23:47, Devin Heitmueller escreveu:
>> The register read function is referencing the dev->ctrlmsg structure outside
>> of the dev->mutex lock, which can cause corruption of the value if multiple
>> callers are invoking au0828_readreg() simultaneously.
>>
>> Use a stack variable to hold the result, and copy the buffer returned by
>> usb_control_msg() to that variable.
>
> It is NOT OK to use stack to send and/or receive control messages. The USB
> core
> uses DMA transfers for sending/receiving data via USB; the memory used by
> stack
> is not warranted to be at the DMA-able area. This problem is more frequent on
> ARM-based machines, but even on Intel, the urb_control_msg() may fail.
>
>>
>> In reality, the whole recv_control_msg() function can probably be collapsed
>> into au0288_readreg() since it is the only caller.
>>
>> Also get rid of cmd_msg_dump() since the only case in which the function is
>> ever called only is ever passed a single byte for the response (and it is
>> already logged).
>>
>> Signed-off-by: Devin Heitmueller
>> ---
>> drivers/media/video/au0828/au0828-core.c | 40
>> +-
>> 1 files changed, 12 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/media/video/au0828/au0828-core.c
>> b/drivers/media/video/au0828/au0828-core.c
>> index 65914bc..745a80a 100644
>> --- a/drivers/media/video/au0828/au0828-core.c
>> +++ b/drivers/media/video/au0828/au0828-core.c
>> @@ -56,9 +56,12 @@ static int recv_control_msg(struct au0828_dev *dev, u16
>> request, u32 value,
>>
>> u32 au0828_readreg(struct au0828_dev *dev, u16 reg)
>> {
>> - recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, dev->ctrlmsg, 1);
>> - dprintk(8, "%s(0x%04x) = 0x%02x\n", __func__, reg, dev->ctrlmsg[0]);
>> - return dev->ctrlmsg[0];
>> + u8 result = 0;
>> +
>> + recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, &result, 1);
>
> As explained above, this won't work, as result is at stack, not warranted to
> be at the
> DMA-able area. So, either you could lock this function, or you'll need to
> allocate
> it with kmalloc() and free it after using the data.
>
>> + dprintk(8, "%s(0x%04x) = 0x%02x\n", __func__, reg, result);
>> +
>> + return result;
>> }
>>
>> u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32 val)
>> @@ -67,24 +70,6 @@ u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32
>> val)
>> return send_control_msg(dev, CMD_REQUEST_OUT, val, reg);
>> }
>>
>> -static void cmd_msg_dump(struct au0828_dev *dev)
>> -{
>> - int i;
>> -
>> - for (i = 0; i < sizeof(dev->ctrlmsg); i += 16)
>> - dprintk(2, "%s() %02x %02x %02x %02x %02x %02x %02x %02x "
>> - "%02x %02x %02x %02x %02x %02x %02x %02x\n",
>> - __func__,
>> - dev->ctrlmsg[i+0], dev->ctrlmsg[i+1],
>> - dev->ctrlmsg[i+2], dev->ctrlmsg[i+3],
>> - dev->ctrlmsg[i+4], dev->ctrlmsg[i+5],
>> - dev->ctrlmsg[i+6], dev->ctrlmsg[i+7],
>> - dev->ctrlmsg[i+8], dev->ctrlmsg[i+9],
>> - dev->ctrlmsg[i+10], dev->ctrlmsg[i+11],
>> - dev->ctrlmsg[i+12], dev->ctrlmsg[i+13],
>> - dev->ctrlmsg[i+14], dev->ctrlmsg[i+15]);
>> -}
>> -
>> static int send_control_msg(struct au0828_dev *dev, u16 request, u32 value,
>> u16 index)
>> {
>> @@ -118,24 +103,23 @@ static int recv_control_msg(struct au0828_dev *dev,
>> u16 request, u32 value,
>> int status = -ENODEV;
>> mutex_lock(&dev->mutex);
>> if (dev->usbdev) {
>> -
>> - memset(dev->ctrlmsg, 0, sizeof(dev->ctrlmsg));
>> -
>> - /* cp must be memory that has been allocated by kmalloc */
>> status = usb_control_msg(dev->usbdev,
>> usb_rcvctrlpipe(dev->usbdev, 0),
>> request,
>> USB_DIR_IN | USB_TYPE_VENDOR |
>> USB_RECIP_DEVICE,
>> value, index,
>> - cp, size, 1000);
>> + dev->ctrlmsg, size, 1000);
>>
>> s
Re: [PATCH 00/24] Various HVR-950q and xc5000 fixes
On Tue, Aug 7, 2012 at 2:26 AM, Hans Verkuil wrote: > Since you're working on the au0828 would it perhaps be possible to have that > driver use unlocked_ioctl instead of ioctl? It would be really nice if we > can get rid of the ioctl v4l2_operation at some point in the future. Hi Hans, I'm pretty sure that actually got done implicitly by patch #8 as a result of a fix for a race condition at startup. Please take a look and let me know if I missed anything: [PATCH 08/24] au0828: fix race condition that causes xc5000 to not bind for digital 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
[PATCH 03/24] au8522: properly recover from the au8522 delivering misaligned TS streams
There is an apparent bug in the au8522 TS clocking which can result in it
delivering a TS payload to the au0828 that is shifted by some number of bits.
For example, the device will announce a packet containing "FA 38 FF F8" which
if you shift left one bit is "1F 47 1F FF F0..."
This presents itself as no TS stream being delivered from the kernel to
userland, since the kernel demux will drop every packet.
In the event that this condition occurs, restart the DVB stream.
Also, this patch includes a couple of lines of cleanup to not change the
FIFO configuration while the FIFO is running (which can screw up the state
machine), and dequeue the buffers before turning off the FIFO. This puts the
logic in sync with the Windows driver.
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-dvb.c | 54 +++---
drivers/media/video/au0828/au0828.h |1 +
2 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-dvb.c
b/drivers/media/video/au0828/au0828-dvb.c
index 39ece8e..b328f65 100644
--- a/drivers/media/video/au0828/au0828-dvb.c
+++ b/drivers/media/video/au0828/au0828-dvb.c
@@ -101,11 +101,14 @@ static struct tda18271_config
hauppauge_woodbury_tunerconfig = {
.gate= TDA18271_GATE_DIGITAL,
};
+static void au0828_restart_dvb_streaming(struct work_struct *work);
+
/*---*/
static void urb_completion(struct urb *purb)
{
struct au0828_dev *dev = purb->context;
int ptype = usb_pipetype(purb->pipe);
+ unsigned char *ptr;
dprintk(2, "%s()\n", __func__);
@@ -121,6 +124,16 @@ static void urb_completion(struct urb *purb)
return;
}
+ /* See if the stream is corrupted (to work around a hardware
+ bug where the stream gets misaligned */
+ ptr = purb->transfer_buffer;
+ if (purb->actual_length > 0 && ptr[0] != 0x47) {
+ dprintk(1, "Need to restart streaming %02x len=%d!\n",
+ ptr[0], purb->actual_length);
+ schedule_work(&dev->restart_streaming);
+ return;
+ }
+
/* Feed the transport payload into the kernel demux */
dvb_dmx_swfilter_packets(&dev->dvb.demux,
purb->transfer_buffer, purb->actual_length / 188);
@@ -138,14 +151,13 @@ static int stop_urb_transfer(struct au0828_dev *dev)
dprintk(2, "%s()\n", __func__);
+ dev->urb_streaming = 0;
for (i = 0; i < URB_COUNT; i++) {
usb_kill_urb(dev->urbs[i]);
kfree(dev->urbs[i]->transfer_buffer);
usb_free_urb(dev->urbs[i]);
}
- dev->urb_streaming = 0;
-
return 0;
}
@@ -246,11 +258,8 @@ static int au0828_dvb_stop_feed(struct dvb_demux_feed
*feed)
mutex_lock(&dvb->lock);
if (--dvb->feeding == 0) {
/* Stop transport */
- au0828_write(dev, 0x608, 0x00);
- au0828_write(dev, 0x609, 0x00);
- au0828_write(dev, 0x60a, 0x00);
- au0828_write(dev, 0x60b, 0x00);
ret = stop_urb_transfer(dev);
+ au0828_write(dev, 0x60b, 0x00);
}
mutex_unlock(&dvb->lock);
}
@@ -258,6 +267,37 @@ static int au0828_dvb_stop_feed(struct dvb_demux_feed
*feed)
return ret;
}
+static void au0828_restart_dvb_streaming(struct work_struct *work)
+{
+ struct au0828_dev *dev = container_of(work, struct au0828_dev,
+ restart_streaming);
+ struct au0828_dvb *dvb = &dev->dvb;
+ int ret;
+
+ if (dev->urb_streaming == 0)
+ return;
+
+ dprintk(1, "Restarting streaming...!\n");
+
+ mutex_lock(&dvb->lock);
+
+ /* Stop transport */
+ ret = stop_urb_transfer(dev);
+ au0828_write(dev, 0x608, 0x00);
+ au0828_write(dev, 0x609, 0x00);
+ au0828_write(dev, 0x60a, 0x00);
+ au0828_write(dev, 0x60b, 0x00);
+
+ /* Start transport */
+ au0828_write(dev, 0x608, 0x90);
+ au0828_write(dev, 0x609, 0x72);
+ au0828_write(dev, 0x60a, 0x71);
+ au0828_write(dev, 0x60b, 0x01);
+ ret = start_urb_transfer(dev);
+
+ mutex_unlock(&dvb->lock);
+}
+
static int dvb_register(struct au0828_dev *dev)
{
struct au0828_dvb *dvb = &dev->dvb;
@@ -265,6 +305,8 @@ static int dvb_register(struct au0828_dev *dev)
dprintk(1, "%s()\n", __func__);
+ INIT_WORK(&dev->restart_streaming, au0828_restart_dvb_streaming);
+
/* register adapter */
result = dvb_register_adapter(&dvb->adapter
[PATCH 06/24] xc5000: add support for showing the SNR and gain in the debug output
When debugging is enabled, also show the analog SNR and the total gain
status values.
Signed-off-by: Devin Heitmueller
---
drivers/media/common/tuners/xc5000.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index c41f2b9..f660e33 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -111,6 +111,7 @@ struct xc5000_priv {
#define XREG_PRODUCT_ID 0x08
#define XREG_BUSY 0x09
#define XREG_BUILD0x0D
+#define XREG_TOTALGAIN0x0F
/*
Basic firmware description. This will remain with
@@ -539,6 +540,16 @@ static int xc_get_quality(struct xc5000_priv *priv, u16
*quality)
return xc5000_readreg(priv, XREG_QUALITY, quality);
}
+static int xc_get_analogsnr(struct xc5000_priv *priv, u16 *snr)
+{
+ return xc5000_readreg(priv, XREG_SNR, snr);
+}
+
+static int xc_get_totalgain(struct xc5000_priv *priv, u16 *totalgain)
+{
+ return xc5000_readreg(priv, XREG_TOTALGAIN, totalgain);
+}
+
static u16 WaitForLock(struct xc5000_priv *priv)
{
u16 lockState = 0;
@@ -650,6 +661,8 @@ static void xc_debug_dump(struct xc5000_priv *priv)
u32 hsync_freq_hz = 0;
u16 frame_lines;
u16 quality;
+ u16 snr;
+ u16 totalgain;
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
u16 fw_buildversion = 0;
@@ -685,6 +698,13 @@ static void xc_debug_dump(struct xc5000_priv *priv)
xc_get_quality(priv, &quality);
dprintk(1, "*** Quality (0:<8dB, 7:>56dB) = %d\n", quality & 0x07);
+
+ xc_get_analogsnr(priv, &snr);
+ dprintk(1, "*** Unweighted analog SNR = %d dB\n", snr & 0x3f);
+
+ xc_get_totalgain(priv, &totalgain);
+ dprintk(1, "*** Total gain = %d.%d dB\n", totalgain / 256,
+ (totalgain % 256) * 100 / 256);
}
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 09/24] au0828: make sure video standard is setup in tuner-core
If the user performs a tuning attempt without explicitly calling the s_std
ioctl(), a value of zero is sent from tuner-core to xc5000. This causes
the xc5000 driver to leave the standard unchanged. The problem was masked
by the fact that the xc5000 driver defaulted to NTSC, but if you happened to
perform an ATSC/ClearQAM tuning attempt and then do an analog tune, the net
effect is an analog tune with the standard still set to DTV6.
Keep track of whether the standard has ever been sent to tuner-core. We
don't make an s_std subdev call explicitly during probe because that will
cause a firmware load (which is very time consuming on the 950q). With the
logic in this patch, the s_std call will occur automatically on the s_freq
call if it hasn't already been set.
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-video.c | 10 ++
drivers/media/video/au0828/au0828.h |1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index b1f8d18..f3e6e3f 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -1330,6 +1330,7 @@ static int vidioc_s_std(struct file *file, void *priv,
v4l2_std_id * norm)
buffer, which is currently hardcoded at 720x480 */
v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_std, *norm);
+ dev->std_set_in_tuner_core = 1;
return 0;
}
@@ -1540,6 +1541,15 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
dev->ctrl_freq = freq->frequency;
+ if (dev->std_set_in_tuner_core == 0) {
+ /* If we've never sent the standard in tuner core, do so now. We
+don't do this at device probe because we don't want to incur
+the cost of a firmware load */
+ v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_std,
+ dev->vdev->tvnorms);
+ dev->std_set_in_tuner_core = 1;
+ }
+
v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_frequency, freq);
au0828_analog_stream_reset(dev);
diff --git a/drivers/media/video/au0828/au0828.h
b/drivers/media/video/au0828/au0828.h
index 61cd63e..66a56ef 100644
--- a/drivers/media/video/au0828/au0828.h
+++ b/drivers/media/video/au0828/au0828.h
@@ -225,6 +225,7 @@ struct au0828_dev {
unsigned int frame_count;
int ctrl_freq;
int input_type;
+ int std_set_in_tuner_core;
unsigned int ctrl_input;
enum au0828_dev_state dev_state;
enum au0828_stream_state stream_state;
--
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 14/24] au0828: speed up i2c clock when doing xc5000 firmware load
Put a hack in place to speed up the firmware load in the case that the
xc5000 has just been reset. The chip can safely do 400 KHz in this mode,
while in normal operation it can only do 100 KHz.
This reduces the firmware load time from 6.9 seconds to 4.2.
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-i2c.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-i2c.c
b/drivers/media/video/au0828/au0828-i2c.c
index 05c299f..d454555 100644
--- a/drivers/media/video/au0828/au0828-i2c.c
+++ b/drivers/media/video/au0828/au0828-i2c.c
@@ -26,7 +26,7 @@
#include
#include "au0828.h"
-
+#include "media/tuner.h"
#include
static int i2c_scan;
@@ -147,8 +147,18 @@ static int i2c_sendbytes(struct i2c_adapter *i2c_adap,
au0828_write(dev, AU0828_I2C_MULTIBYTE_MODE_2FF, 0x01);
/* Set the I2C clock */
- au0828_write(dev, AU0828_I2C_CLK_DIVIDER_202,
-dev->board.i2c_clk_divider);
+ if ((dev->board.tuner_type == TUNER_XC5000) &&
+ (dev->board.tuner_addr == msg->addr) &&
+ (msg->len == 64)) {
+ /* Hack to speed up firmware load. The xc5000 lets us do up
+ to 400 KHz when in firmware download mode */
+ au0828_write(dev, AU0828_I2C_CLK_DIVIDER_202,
+AU0828_I2C_CLK_250KHZ);
+ } else {
+ /* Use the i2c clock speed in the board configuration */
+ au0828_write(dev, AU0828_I2C_CLK_DIVIDER_202,
+dev->board.i2c_clk_divider);
+ }
/* Hardware needs 8 bit addresses */
au0828_write(dev, AU0828_I2C_DEST_ADDR_203, msg->addr << 1);
--
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 17/24] au0828: fix possible race condition in usage of dev->ctrlmsg
The register read function is referencing the dev->ctrlmsg structure outside
of the dev->mutex lock, which can cause corruption of the value if multiple
callers are invoking au0828_readreg() simultaneously.
Use a stack variable to hold the result, and copy the buffer returned by
usb_control_msg() to that variable.
In reality, the whole recv_control_msg() function can probably be collapsed
into au0288_readreg() since it is the only caller.
Also get rid of cmd_msg_dump() since the only case in which the function is
ever called only is ever passed a single byte for the response (and it is
already logged).
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-core.c | 40 +-
1 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-core.c
b/drivers/media/video/au0828/au0828-core.c
index 65914bc..745a80a 100644
--- a/drivers/media/video/au0828/au0828-core.c
+++ b/drivers/media/video/au0828/au0828-core.c
@@ -56,9 +56,12 @@ static int recv_control_msg(struct au0828_dev *dev, u16
request, u32 value,
u32 au0828_readreg(struct au0828_dev *dev, u16 reg)
{
- recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, dev->ctrlmsg, 1);
- dprintk(8, "%s(0x%04x) = 0x%02x\n", __func__, reg, dev->ctrlmsg[0]);
- return dev->ctrlmsg[0];
+ u8 result = 0;
+
+ recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, &result, 1);
+ dprintk(8, "%s(0x%04x) = 0x%02x\n", __func__, reg, result);
+
+ return result;
}
u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32 val)
@@ -67,24 +70,6 @@ u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32 val)
return send_control_msg(dev, CMD_REQUEST_OUT, val, reg);
}
-static void cmd_msg_dump(struct au0828_dev *dev)
-{
- int i;
-
- for (i = 0; i < sizeof(dev->ctrlmsg); i += 16)
- dprintk(2, "%s() %02x %02x %02x %02x %02x %02x %02x %02x "
- "%02x %02x %02x %02x %02x %02x %02x %02x\n",
- __func__,
- dev->ctrlmsg[i+0], dev->ctrlmsg[i+1],
- dev->ctrlmsg[i+2], dev->ctrlmsg[i+3],
- dev->ctrlmsg[i+4], dev->ctrlmsg[i+5],
- dev->ctrlmsg[i+6], dev->ctrlmsg[i+7],
- dev->ctrlmsg[i+8], dev->ctrlmsg[i+9],
- dev->ctrlmsg[i+10], dev->ctrlmsg[i+11],
- dev->ctrlmsg[i+12], dev->ctrlmsg[i+13],
- dev->ctrlmsg[i+14], dev->ctrlmsg[i+15]);
-}
-
static int send_control_msg(struct au0828_dev *dev, u16 request, u32 value,
u16 index)
{
@@ -118,24 +103,23 @@ static int recv_control_msg(struct au0828_dev *dev, u16
request, u32 value,
int status = -ENODEV;
mutex_lock(&dev->mutex);
if (dev->usbdev) {
-
- memset(dev->ctrlmsg, 0, sizeof(dev->ctrlmsg));
-
- /* cp must be memory that has been allocated by kmalloc */
status = usb_control_msg(dev->usbdev,
usb_rcvctrlpipe(dev->usbdev, 0),
request,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
value, index,
- cp, size, 1000);
+ dev->ctrlmsg, size, 1000);
status = min(status, 0);
if (status < 0) {
printk(KERN_ERR "%s() Failed receiving control message,
error %d.\n",
__func__, status);
- } else
- cmd_msg_dump(dev);
+ }
+
+ /* the host controller requires heap allocated memory, which
+ is why we didn't just pass "cp" into usb_control_msg */
+ memcpy(cp, dev->ctrlmsg, size);
}
mutex_unlock(&dev->mutex);
return status;
--
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 21/24] xc5000: show debug version fields in decimal instead of hex
The driver prints out a dotted version number but it's in hex. As a result, the version doesn't visibly match the filename for the firmware, and it caused a bunch of confusion while discussing different versions with the chip manufacturer. Change the firmware printout to be in decimal. 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 3e5f8cd..4bb20fa 100644 --- a/drivers/media/common/tuners/xc5000.c +++ b/drivers/media/common/tuners/xc5000.c @@ -702,7 +702,7 @@ static void xc_debug_dump(struct xc5000_priv *priv) xc_get_version(priv, &hw_majorversion, &hw_minorversion, &fw_majorversion, &fw_minorversion); xc_get_buildversion(priv, &fw_buildversion); - dprintk(1, "*** HW: V%02x.%02x, FW: V%02x.%02x.%04x\n", + dprintk(1, "*** HW: V%d.%d, FW: V %d.%d.%d\n", hw_majorversion, hw_minorversion, fw_majorversion, fw_minorversion, fw_buildversion); -- 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 23/24] au0828: make xc5000 firmware speedup apply to the xc5000c as well
Make the firmware speedup work for the 5000c as well as the original
xc5000. This cuts firmware load time in half.
Thanks to John Casey at Hauppauge for loaning me a board for testing.
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-i2c.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-i2c.c
b/drivers/media/video/au0828/au0828-i2c.c
index 3bc76df..4ded17f 100644
--- a/drivers/media/video/au0828/au0828-i2c.c
+++ b/drivers/media/video/au0828/au0828-i2c.c
@@ -147,7 +147,8 @@ static int i2c_sendbytes(struct i2c_adapter *i2c_adap,
au0828_write(dev, AU0828_I2C_MULTIBYTE_MODE_2FF, 0x01);
/* Set the I2C clock */
- if ((dev->board.tuner_type == TUNER_XC5000) &&
+ if (((dev->board.tuner_type == TUNER_XC5000) ||
+(dev->board.tuner_type == TUNER_XC5000C)) &&
(dev->board.tuner_addr == msg->addr) &&
(msg->len == 64)) {
/* Hack to speed up firmware load. The xc5000 lets us do up
--
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 20/24] au0828: tweak workaround for i2c clock stretching bug
The hack I put in a couple of years ago to avoid clock stretching issues
when talking to the xc5000 worked fine for writes, but intermittently fails
for register reads, because the xc5000 may stretch the clock for longer
between bytes (I was seeing cases of 21 us on the analyzer).
The problem manifested itself as the xc5000 firmware version and PLL lock
register intermittently showing garbage values.
Slow down the i2c bus from 30 KHz to 20 KHz to accommodate.
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-cards.c |4 ++--
drivers/media/video/au0828/au0828-reg.h |1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-cards.c
b/drivers/media/video/au0828/au0828-cards.c
index 1c6015a..4a09b0e 100644
--- a/drivers/media/video/au0828/au0828-cards.c
+++ b/drivers/media/video/au0828/au0828-cards.c
@@ -46,7 +46,7 @@ struct au0828_board au0828_boards[] = {
.name = "Hauppauge HVR850",
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
- .i2c_clk_divider = AU0828_I2C_CLK_30KHZ,
+ .i2c_clk_divider = AU0828_I2C_CLK_20KHZ,
.input = {
{
.type = AU0828_VMUX_TELEVISION,
@@ -77,7 +77,7 @@ struct au0828_board au0828_boards[] = {
stretch fits inside of a normal clock cycle, or else the
au0828 fails to set the STOP bit. A 30 KHz clock puts the
clock pulse width at 18us */
- .i2c_clk_divider = AU0828_I2C_CLK_30KHZ,
+ .i2c_clk_divider = AU0828_I2C_CLK_20KHZ,
.input = {
{
.type = AU0828_VMUX_TELEVISION,
diff --git a/drivers/media/video/au0828/au0828-reg.h
b/drivers/media/video/au0828/au0828-reg.h
index c39f3d2..2140f4c 100644
--- a/drivers/media/video/au0828/au0828-reg.h
+++ b/drivers/media/video/au0828/au0828-reg.h
@@ -63,3 +63,4 @@
#define AU0828_I2C_CLK_250KHZ 0x07
#define AU0828_I2C_CLK_100KHZ 0x14
#define AU0828_I2C_CLK_30KHZ 0x40
+#define AU0828_I2C_CLK_20KHZ 0x60
--
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 15/24] au0828: remove control buffer from send_control_msg
There are no cases where a control message is ever sent to the au0828 with
an actual buffer defined. Remove the reference to dev->ctrlmsg, which
currently requires us to hold a mutex since it is shared with the read
function.
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-core.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-core.c
b/drivers/media/video/au0828/au0828-core.c
index b2c4254..65914bc 100644
--- a/drivers/media/video/au0828/au0828-core.c
+++ b/drivers/media/video/au0828/au0828-core.c
@@ -46,7 +46,7 @@ MODULE_PARM_DESC(disable_usb_speed_check,
#define _BULKPIPESIZE 0x
static int send_control_msg(struct au0828_dev *dev, u16 request, u32 value,
- u16 index, unsigned char *cp, u16 size);
+ u16 index);
static int recv_control_msg(struct au0828_dev *dev, u16 request, u32 value,
u16 index, unsigned char *cp, u16 size);
@@ -64,8 +64,7 @@ u32 au0828_readreg(struct au0828_dev *dev, u16 reg)
u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32 val)
{
dprintk(8, "%s(0x%04x, 0x%02x)\n", __func__, reg, val);
- return send_control_msg(dev, CMD_REQUEST_OUT, val, reg,
- dev->ctrlmsg, 0);
+ return send_control_msg(dev, CMD_REQUEST_OUT, val, reg);
}
static void cmd_msg_dump(struct au0828_dev *dev)
@@ -87,10 +86,10 @@ static void cmd_msg_dump(struct au0828_dev *dev)
}
static int send_control_msg(struct au0828_dev *dev, u16 request, u32 value,
- u16 index, unsigned char *cp, u16 size)
+ u16 index)
{
int status = -ENODEV;
- mutex_lock(&dev->mutex);
+
if (dev->usbdev) {
/* cp must be memory that has been allocated by kmalloc */
@@ -99,8 +98,7 @@ static int send_control_msg(struct au0828_dev *dev, u16
request, u32 value,
request,
USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- value, index,
- cp, size, 1000);
+ value, index, NULL, 0, 1000);
status = min(status, 0);
@@ -110,7 +108,7 @@ static int send_control_msg(struct au0828_dev *dev, u16
request, u32 value,
}
}
- mutex_unlock(&dev->mutex);
+
return status;
}
--
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 13/24] au0828: fix case where STREAMOFF being called on stopped stream causes BUG()
We weren't checking whether the resource was in use before calling res_free(),
so applications which called STREAMOFF on a v4l2 device that wasn't already
streaming would cause a BUG() to be hit (MythTV).
Reported-by: Larry Finger
Reported-by: Jay Harbeston
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-video.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index df92322..4d5b670 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -1702,14 +1702,18 @@ static int vidioc_streamoff(struct file *file, void
*priv,
(AUVI_INPUT(i).audio_setup)(dev, 0);
}
- videobuf_streamoff(&fh->vb_vidq);
- res_free(fh, AU0828_RESOURCE_VIDEO);
+ if (res_check(fh, AU0828_RESOURCE_VIDEO)) {
+ videobuf_streamoff(&fh->vb_vidq);
+ res_free(fh, AU0828_RESOURCE_VIDEO);
+ }
} else if (fh->type == V4L2_BUF_TYPE_VBI_CAPTURE) {
dev->vbi_timeout_running = 0;
del_timer_sync(&dev->vbi_timeout);
- videobuf_streamoff(&fh->vb_vbiq);
- res_free(fh, AU0828_RESOURCE_VBI);
+ if (res_check(fh, AU0828_RESOURCE_VBI)) {
+ videobuf_streamoff(&fh->vb_vbiq);
+ res_free(fh, AU0828_RESOURCE_VBI);
+ }
}
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/24] xc5000: change filename to production/redistributable xc5000c firmware
The original xc5000c driver support was based on a beta version of the
firmware, and there were no redistribution rights. Change over to using the
release version, for which freely redistributable firmware can be found here:
http://kernellabs.com/firmware/xc5000/README.xc5000c
http://kernellabs.com/firmware/xc5000/dvb-fe-xc5000c-4.1.30.7.fw
Thanks to Ramon Cazares from Cresta Technology for making the firmware
available as well as working out the licensing issues.
Signed-off-by: Devin Heitmueller
Cc: Michael Krufky
---
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 4bb20fa..3f7327c 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -226,7 +226,7 @@ static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
};
static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
- .name = "dvb-fe-xc5000c-41.024.5.fw",
+ .name = "dvb-fe-xc5000c-4.1.30.7.fw",
.size = 16497,
.pll_reg = 0x13,
.init_status_supported = 1,
--
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 22/24] au0828: fix a couple of missed edge cases for i2c gate with analog
This patch addresses a couple of cases where I forgot to pop open the gate when in analog mode (a correlary to fix the change made in patch 1c58d5b4a5fca42dce5428bd79b9405878017735). Signed-off-by: Devin Heitmueller --- drivers/media/video/au0828/au0828-video.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/au0828/au0828-video.c b/drivers/media/video/au0828/au0828-video.c index 4d5b670..fa0fa9a 100644 --- a/drivers/media/video/au0828/au0828-video.c +++ b/drivers/media/video/au0828/au0828-video.c @@ -1325,12 +1325,19 @@ static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id * norm) struct au0828_fh *fh = priv; struct au0828_dev *dev = fh->dev; + if (dev->dvb.frontend && dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl) + dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl(dev->dvb.frontend, 1); + /* FIXME: when we support something other than NTSC, we are going to have to make the au0828 bridge adjust the size of its capture buffer, which is currently hardcoded at 720x480 */ v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_std, *norm); dev->std_set_in_tuner_core = 1; + + if (dev->dvb.frontend && dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl) + dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl(dev->dvb.frontend, 0); + return 0; } @@ -1510,9 +1517,18 @@ static int vidioc_s_tuner(struct file *file, void *priv, return -EINVAL; t->type = V4L2_TUNER_ANALOG_TV; + + if (dev->dvb.frontend && dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl) + dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl(dev->dvb.frontend, 1); + v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_tuner, t); + + if (dev->dvb.frontend && dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl) + dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl(dev->dvb.frontend, 0); + dprintk(1, "VIDIOC_S_TUNER: signal = %x, afc = %x\n", t->signal, t->afc); + return 0; } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/24] xc5000: add support for firmware load check and init status
The xc5000c and newer versions of the xc5000a firmware need minor revisions
to their initialization process. Add support for validating the firmware
was properly loaded, as well as checking the init status after initialization.
Based on advice from CrestaTech support as well as xc5000 datasheet v2.3.
Signed-off-by: Devin Heitmueller
---
drivers/media/common/tuners/xc5000.c | 39 ++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index 7c36465..3e5f8cd 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -63,6 +63,8 @@ struct xc5000_priv {
int chip_id;
u16 pll_register_no;
+ u8 init_status_supported;
+ u8 fw_checksum_supported;
};
/* Misc Defines */
@@ -113,6 +115,8 @@ struct xc5000_priv {
#define XREG_BUSY 0x09
#define XREG_BUILD0x0D
#define XREG_TOTALGAIN0x0F
+#define XREG_FW_CHECKSUM 0x12
+#define XREG_INIT_STATUS 0x13
/*
Basic firmware description. This will remain with
@@ -211,6 +215,8 @@ struct xc5000_fw_cfg {
char *name;
u16 size;
u16 pll_reg;
+ u8 init_status_supported;
+ u8 fw_checksum_supported;
};
static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
@@ -223,6 +229,8 @@ static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
.name = "dvb-fe-xc5000c-41.024.5.fw",
.size = 16497,
.pll_reg = 0x13,
+ .init_status_supported = 1,
+ .fw_checksum_supported = 1,
};
static inline const struct xc5000_fw_cfg *xc5000_assign_firmware(int chip_id)
@@ -622,6 +630,8 @@ static int xc5000_fwupload(struct dvb_frontend *fe)
const struct xc5000_fw_cfg *desired_fw =
xc5000_assign_firmware(priv->chip_id);
priv->pll_register_no = desired_fw->pll_reg;
+ priv->init_status_supported = desired_fw->init_status_supported;
+ priv->fw_checksum_supported = desired_fw->fw_checksum_supported;
/* request the firmware, this will block and timeout */
printk(KERN_INFO "xc5000: waiting for firmware upload (%s)...\n",
@@ -1082,6 +1092,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe, int force)
struct xc5000_priv *priv = fe->tuner_priv;
int ret = XC_RESULT_SUCCESS;
u16 pll_lock_status;
+ u16 fw_ck;
if (force || xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
@@ -1093,6 +1104,21 @@ fw_retry:
msleep(20);
+ if (priv->fw_checksum_supported) {
+ if (xc5000_readreg(priv, XREG_FW_CHECKSUM, &fw_ck)
+ != XC_RESULT_SUCCESS) {
+ dprintk(1, "%s() FW checksum reading failed.\n",
+ __func__);
+ goto fw_retry;
+ }
+
+ if (fw_ck == 0) {
+ dprintk(1, "%s() FW checksum failed = 0x%04x\n",
+ __func__, fw_ck);
+ goto fw_retry;
+ }
+ }
+
/* Start the tuner self-calibration process */
ret |= xc_initialize(priv);
@@ -1106,6 +1132,19 @@ fw_retry:
*/
xc_wait(100);
+ if (priv->init_status_supported) {
+ if (xc5000_readreg(priv, XREG_INIT_STATUS, &fw_ck) !=
XC_RESULT_SUCCESS) {
+ dprintk(1, "%s() FW failed reading init
status.\n",
+ __func__);
+ goto fw_retry;
+ }
+
+ if (fw_ck == 0) {
+ dprintk(1, "%s() FW init status failed =
0x%04x\n", __func__, fw_ck);
+ goto fw_retry;
+ }
+ }
+
if (priv->pll_register_no) {
xc5000_readreg(priv, priv->pll_register_no,
&pll_lock_status);
--
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 18/24] xc5000: reset device if encountering PLL lock failure
It's possible for the xc5000 to enter an unknown state such that all
subsequent tuning requests fail. The only way to recover is to reset the
tuner and reload the firmware. This problem was detected after several days
straight of issuing tuning requests every five seconds.
Reset the firmware in the event that the PLL is in an unlocked state. This
solution was provided by the engineer at CrestaTech (the company that acquired
Xceive).
Signed-off-by: Devin Heitmueller
---
drivers/media/common/tuners/xc5000.c | 58 ++---
1 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index 1cfaa7c..7c36465 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -62,6 +62,7 @@ struct xc5000_priv {
u8 radio_input;
int chip_id;
+ u16 pll_register_no;
};
/* Misc Defines */
@@ -209,16 +210,19 @@ static struct XC_TV_STANDARD
XC5000_Standard[MAX_TV_STANDARD] = {
struct xc5000_fw_cfg {
char *name;
u16 size;
+ u16 pll_reg;
};
static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
.name = "dvb-fe-xc5000-1.6.114.fw",
.size = 12401,
+ .pll_reg = 0x806c,
};
static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
.name = "dvb-fe-xc5000c-41.024.5.fw",
.size = 16497,
+ .pll_reg = 0x13,
};
static inline const struct xc5000_fw_cfg *xc5000_assign_firmware(int chip_id)
@@ -232,7 +236,7 @@ static inline const struct xc5000_fw_cfg
*xc5000_assign_firmware(int chip_id)
}
}
-static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe);
+static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe, int force);
static int xc5000_is_firmware_loaded(struct dvb_frontend *fe);
static int xc5000_readreg(struct xc5000_priv *priv, u16 reg, u16 *val);
static int xc5000_TunerReset(struct dvb_frontend *fe);
@@ -617,6 +621,7 @@ static int xc5000_fwupload(struct dvb_frontend *fe)
int ret;
const struct xc5000_fw_cfg *desired_fw =
xc5000_assign_firmware(priv->chip_id);
+ priv->pll_register_no = desired_fw->pll_reg;
/* request the firmware, this will block and timeout */
printk(KERN_INFO "xc5000: waiting for firmware upload (%s)...\n",
@@ -666,6 +671,7 @@ static void xc_debug_dump(struct xc5000_priv *priv)
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
u16 fw_buildversion = 0;
+ u16 regval;
/* Wait for stats to stabilize.
* Frame Lines needs two frame times after initial lock
@@ -705,6 +711,11 @@ static void xc_debug_dump(struct xc5000_priv *priv)
xc_get_totalgain(priv, &totalgain);
dprintk(1, "*** Total gain = %d.%d dB\n", totalgain / 256,
(totalgain % 256) * 100 / 256);
+
+ if (priv->pll_register_no) {
+ xc5000_readreg(priv, priv->pll_register_no, ®val);
+ dprintk(1, "*** PLL lock status = 0x%04x\n", regval);
+ }
}
static int xc5000_set_params(struct dvb_frontend *fe)
@@ -715,7 +726,7 @@ static int xc5000_set_params(struct dvb_frontend *fe)
u32 freq = fe->dtv_property_cache.frequency;
u32 delsys = fe->dtv_property_cache.delivery_system;
- if (xc_load_fw_and_init_tuner(fe) != XC_RESULT_SUCCESS) {
+ if (xc_load_fw_and_init_tuner(fe, 0) != XC_RESULT_SUCCESS) {
dprintk(1, "Unable to load firmware and init tuner\n");
return -EINVAL;
}
@@ -842,6 +853,7 @@ static int xc5000_set_tv_freq(struct dvb_frontend *fe,
struct analog_parameters *params)
{
struct xc5000_priv *priv = fe->tuner_priv;
+ u16 pll_lock_status;
int ret;
dprintk(1, "%s() frequency=%d (in units of 62.5khz)\n",
@@ -922,6 +934,21 @@ tune_channel:
if (debug)
xc_debug_dump(priv);
+ if (priv->pll_register_no != 0) {
+ msleep(20);
+ xc5000_readreg(priv, priv->pll_register_no, &pll_lock_status);
+ if (pll_lock_status > 63) {
+ /* PLL is unlocked, force reload of the firmware */
+ dprintk(1, "xc5000: PLL not locked (0x%x).
Reloading...\n",
+ pll_lock_status);
+ if (xc_load_fw_and_init_tuner(fe, 1) !=
XC_RESULT_SUCCESS) {
+ printk(KERN_ERR "xc5000: Unable to reload
fw\n");
+ return -EREMOTEIO;
+ }
+ goto tune_channel;
+ }
+ }
+
return 0;
}
@@ -992,7 +1019,7 @@ static int xc5000_set_analog_params(struct dvb_frontend
*fe,
if (priv
[PATCH 16/24] au0828: tune retry interval for i2c interaction
Adjust the retry timeout and number of retries to speed up xc5000 firmware
download. With this change it goes from 4.2 seconds to 2.9. The net time
waited is pretty much the same, but we just poll more often.
Tested at 250 KHz as well as 30 KHz.
Signed-off-by: Devin Heitmueller
---
drivers/media/video/au0828/au0828-i2c.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-i2c.c
b/drivers/media/video/au0828/au0828-i2c.c
index d454555..3bc76df 100644
--- a/drivers/media/video/au0828/au0828-i2c.c
+++ b/drivers/media/video/au0828/au0828-i2c.c
@@ -33,8 +33,8 @@ static int i2c_scan;
module_param(i2c_scan, int, 0444);
MODULE_PARM_DESC(i2c_scan, "scan i2c bus at insmod time");
-#define I2C_WAIT_DELAY 512
-#define I2C_WAIT_RETRY 64
+#define I2C_WAIT_DELAY 25
+#define I2C_WAIT_RETRY 1000
static inline int i2c_slave_did_write_ack(struct i2c_adapter *i2c_adap)
{
--
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 12/24] au0828: prevent i2c gate from being kept open while in analog mode
The original implementation of the analog support would use an i2c_gate_ctrl
function when using the digital side of the au8522, but on the analog side
we would always just force the gate open and leave it open all the time.
This can have adverse effects on the xc5000 given the tuner is receiving all
the spurious i2c traffic (a problem which can be exaggerated due to bugs in
the au0828 i2c hardware implementation).
Rework the existing hack to only open/close the gate when actually talking
to the tuner.
This logic might need to be reworked a bit if anybody ever tries to add
support for a board that has the au0828/au8522 but doesn't have digital
support implemented (because the i2c_gate_ctrl callback is being set in
the DVB attach). However given how few different models are in circulation,
this can be deferred until such a situation arises (if ever).
Signed-off-by: Devin Heitmueller
---
drivers/media/dvb/frontends/au8522_common.c | 13 +
drivers/media/dvb/frontends/au8522_decoder.c |5 -
drivers/media/dvb/frontends/au8522_dig.c |2 ++
drivers/media/dvb/frontends/au8522_priv.h|1 +
drivers/media/video/au0828/au0828-video.c|6 ++
5 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/frontends/au8522_common.c
b/drivers/media/dvb/frontends/au8522_common.c
index 8b4da40..3559ff2 100644
--- a/drivers/media/dvb/frontends/au8522_common.c
+++ b/drivers/media/dvb/frontends/au8522_common.c
@@ -99,6 +99,19 @@ int au8522_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
}
EXPORT_SYMBOL(au8522_i2c_gate_ctrl);
+int au8522_analog_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
+{
+ struct au8522_state *state = fe->demodulator_priv;
+
+ dprintk("%s(%d)\n", __func__, enable);
+
+ if (enable)
+ return au8522_writereg(state, 0x106, 1);
+ else
+ return au8522_writereg(state, 0x106, 0);
+}
+EXPORT_SYMBOL(au8522_analog_i2c_gate_ctrl);
+
/* Reset the demod hardware and reset all of the configuration registers
to a default state. */
int au8522_get_state(struct au8522_state **state, struct i2c_adapter *i2c,
diff --git a/drivers/media/dvb/frontends/au8522_decoder.c
b/drivers/media/dvb/frontends/au8522_decoder.c
index f2e786b..5243ba6 100644
--- a/drivers/media/dvb/frontends/au8522_decoder.c
+++ b/drivers/media/dvb/frontends/au8522_decoder.c
@@ -659,11 +659,6 @@ static int au8522_s_video_routing(struct v4l2_subdev *sd,
au8522_reset(sd, 0);
- /* Jam open the i2c gate to the tuner. We do this here to handle the
- case where the user went into digital mode (causing the gate to be
- closed), and then came back to analog mode */
- au8522_writereg(state, 0x106, 1);
-
if (input == AU8522_COMPOSITE_CH1) {
au8522_setup_cvbs_mode(state);
} else if (input == AU8522_SVIDEO_CH13) {
diff --git a/drivers/media/dvb/frontends/au8522_dig.c
b/drivers/media/dvb/frontends/au8522_dig.c
index ee8cf81..a68974f 100644
--- a/drivers/media/dvb/frontends/au8522_dig.c
+++ b/drivers/media/dvb/frontends/au8522_dig.c
@@ -777,6 +777,8 @@ struct dvb_frontend *au8522_attach(const struct
au8522_config *config,
sizeof(struct dvb_frontend_ops));
state->frontend.demodulator_priv = state;
+ state->frontend.ops.analog_ops.i2c_gate_ctrl =
au8522_analog_i2c_gate_ctrl;
+
if (au8522_init(&state->frontend) != 0) {
printk(KERN_ERR "%s: Failed to initialize correctly\n",
__func__);
diff --git a/drivers/media/dvb/frontends/au8522_priv.h
b/drivers/media/dvb/frontends/au8522_priv.h
index 9f44a7b..0529699 100644
--- a/drivers/media/dvb/frontends/au8522_priv.h
+++ b/drivers/media/dvb/frontends/au8522_priv.h
@@ -82,6 +82,7 @@ int au8522_get_state(struct au8522_state **state, struct
i2c_adapter *i2c,
u8 client_address);
void au8522_release_state(struct au8522_state *state);
int au8522_i2c_gate_ctrl(struct dvb_frontend *fe, int enable);
+int au8522_analog_i2c_gate_ctrl(struct dvb_frontend *fe, int enable);
int au8522_led_ctrl(struct au8522_state *state, int led);
/* REGISTERS */
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index f3e6e3f..df92322 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -1541,6 +1541,9 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
dev->ctrl_freq = freq->frequency;
+ if (dev->dvb.frontend &&
dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl)
+
dev->dvb.frontend->ops.analog_ops.i2c_gate_ctrl(dev->dvb.frontend, 1);
+
if (dev->std_set_in_tuner_core == 0) {
/* If we've never sent the standard in tuner core, do so now. We
don't do this at device probe because
[PATCH 11/24] xc5000: don't invoke auto calibration unless we really did reset tuner
The current code invokes the auto calibration of the tuner whenever the
init routine is called (whenever the DVB frontend opens the device).
However we should really only be invoking the calibration if we actually
did reset the device and reload the firmware.
Rework the routine to only do calibration if reset and firmware load was
performed. Also because the called function is now a no-op if the firmware
is already loaded, the caller no longer needs to invoke is_firmware_loaded().
Signed-off-by: Devin Heitmueller
---
drivers/media/common/tuners/xc5000.c | 40 +++--
1 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index a7fa17e..1cfaa7c 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -715,11 +715,9 @@ static int xc5000_set_params(struct dvb_frontend *fe)
u32 freq = fe->dtv_property_cache.frequency;
u32 delsys = fe->dtv_property_cache.delivery_system;
- if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
- if (xc_load_fw_and_init_tuner(fe) != XC_RESULT_SUCCESS) {
- dprintk(1, "Unable to load firmware and init tuner\n");
- return -EINVAL;
- }
+ if (xc_load_fw_and_init_tuner(fe) != XC_RESULT_SUCCESS) {
+ dprintk(1, "Unable to load firmware and init tuner\n");
+ return -EINVAL;
}
dprintk(1, "%s() frequency=%d (Hz)\n", __func__, freq);
@@ -994,11 +992,9 @@ static int xc5000_set_analog_params(struct dvb_frontend
*fe,
if (priv->i2c_props.adap == NULL)
return -EINVAL;
- if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
- if (xc_load_fw_and_init_tuner(fe) != XC_RESULT_SUCCESS) {
- dprintk(1, "Unable to load firmware and init tuner\n");
- return -EINVAL;
- }
+ if (xc_load_fw_and_init_tuner(fe) != XC_RESULT_SUCCESS) {
+ dprintk(1, "Unable to load firmware and init tuner\n");
+ return -EINVAL;
}
switch (params->mode) {
@@ -1057,26 +1053,26 @@ static int xc5000_get_status(struct dvb_frontend *fe,
u32 *status)
static int xc_load_fw_and_init_tuner(struct dvb_frontend *fe)
{
struct xc5000_priv *priv = fe->tuner_priv;
- int ret = 0;
+ int ret = XC_RESULT_SUCCESS;
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
ret = xc5000_fwupload(fe);
if (ret != XC_RESULT_SUCCESS)
return ret;
- }
- /* Start the tuner self-calibration process */
- ret |= xc_initialize(priv);
+ /* Start the tuner self-calibration process */
+ ret |= xc_initialize(priv);
- /* Wait for calibration to complete.
-* We could continue but XC5000 will clock stretch subsequent
-* I2C transactions until calibration is complete. This way we
-* don't have to rely on clock stretching working.
-*/
- xc_wait(100);
+ /* Wait for calibration to complete.
+* We could continue but XC5000 will clock stretch subsequent
+* I2C transactions until calibration is complete. This way we
+* don't have to rely on clock stretching working.
+*/
+ xc_wait(100);
- /* Default to "CABLE" mode */
- ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
+ /* Default to "CABLE" mode */
+ ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
+ }
return ret;
}
--
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
