Re: [dvb-apps] Updated initial scan file for hr-All
2010/5/2 Samuel Rakitničan samuel.rakitni...@gmail.com: --- hr-All 2010-05-02 01:32:22.0 +0200 +++ hr-All.new 2010-05-02 01:30:14.0 +0200 @@ -12,9 +12,9 @@ T 59400 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 61800 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 64200 8MHz 3/4 NONE QAM64 8k 1/4 NONE -T 65000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65800 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 66600 8MHz 2/3 NONE QAM64 8k 1/4 NONE +T 67400 8MHz 2/3 NONE QAM64 8k 1/8 NONE # HD - Split, Marjan T 68200 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 69000 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 71400 8MHz 3/4 NONE QAM64 8k 1/4 NONE Updated, thanks. Christoph -- To unsubscribe from this list: send the line unsubscribe 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] Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices)
Some (North American) providers use a non-standard mode called 8psk turbo fec. Since there is no flag in the driver that would allow an application to determine whether a particular device can handle turbo fec, the attached patch introduces FE_CAN_TURBO_FEC. Since there is no flag in the SI data that would indicate that a transponder uses turbo fec, VDR will assume that all 8psk transponders on DVB-S use turbo fec. Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-25 14:24:50.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB = 0x40, FE_HAS_EXTENDED_CAPS = 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_TURBO_FEC = 0x800, /* frontend supports turbo fec modulation */ FE_CAN_2G_MODULATION = 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING = 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-25 14:25:18.0 +0200 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 + FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_TURBO_FEC }, .release = gp8psk_fe_release,
Re: [GIT PATCHES FOR 2.6.35]
On Saturday 01 May 2010 23:09:22 Hans Verkuil wrote: On Saturday 01 May 2010 13:32:22 Hans Verkuil wrote: The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc Three fixes and one simplification. The prio changes are trivial but prepare the way for moving prio handling into the core framework. Added another bug fix: em28xx: g_tuner must set type field. Setting a frequency with v4l2-ctl -f freq didn't work with em28xx because of this bug. Added more bug fixes: v4l2-dev: remove unnecessary lock around atomic clear_bit radio-mr800: let v4l2_device_(un)register handle usb_get/set_intfdata hdpvr: fix disconnect sequence usbvision: don't use usb_set_intfdata, let v4l2_device_register handle this. usbvision: add delay before detecting the saa711x. All tested with my mr800, hdpvr and usbvision devices. Regards, Hans Hans Verkuil (4): Documentation: fix small error in the ENUMINPUT doc. bttv: remove bogus prio check in g_frequency. v4l2-common: simplify prio utility functions tvp7002: fix query_dv_preset. Documentation/DocBook/v4l/vidioc-enuminput.xml |2 +- drivers/media/video/bt8xx/bttv-driver.c| 23 +-- drivers/media/video/cpia2/cpia2_v4l.c |4 ++-- drivers/media/video/cx18/cx18-controls.c |2 +- drivers/media/video/cx18/cx18-fileops.c|2 +- drivers/media/video/cx18/cx18-ioctl.c | 16 drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/davinci/vpif_capture.c |8 drivers/media/video/davinci/vpif_display.c |4 ++-- drivers/media/video/ivtv/ivtv-fileops.c|2 +- drivers/media/video/ivtv/ivtv-ioctl.c |2 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c |6 +++--- drivers/media/video/saa7134/saa7134-video.c| 14 +++--- drivers/media/video/tvp7002.c | 13 + drivers/media/video/v4l2-common.c | 22 +- drivers/staging/cx25821/cx25821-audups11.c |6 +++--- drivers/staging/cx25821/cx25821-video.c| 10 +- drivers/staging/cx25821/cx25821-video0.c |6 +++--- drivers/staging/cx25821/cx25821-video1.c |6 +++--- drivers/staging/cx25821/cx25821-video2.c |6 +++--- drivers/staging/cx25821/cx25821-video3.c |6 +++--- drivers/staging/cx25821/cx25821-video4.c |6 +++--- drivers/staging/cx25821/cx25821-video5.c |6 +++--- drivers/staging/cx25821/cx25821-video6.c |6 +++--- drivers/staging/cx25821/cx25821-video7.c |6 +++--- drivers/staging/cx25821/cx25821-videoioctl.c |6 +++--- drivers/staging/cx25821/cx25821-vidups10.c |6 +++--- drivers/staging/cx25821/cx25821-vidups9.c |6 +++--- include/media/v4l2-common.h|8 29 files changed, 100 insertions(+), 112 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe 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: [vdr] externalplayer and xineliboutput plugin
Nobody an idea ? - Can somebody explain to me what a player with
PlayMode pmNone should do ?
This is the problem:
Apr 22 23:41:05 vdr vdr: [3204]
ERROR: /dev/dvb/adapter1/dvr0: Device or resource busy
If some application is started with external player
streamdev/vnsi-plugin with frontend xineliboutput produces below error
.. xine not
Thanks !
Steffen
Steffen Barszus wrote:
/ Hi !
//
// I currently try to track down a problem of externalplayer and
// xineliboutput.
//
// The problem is, that if used with xineliboutput plugin and PlayMode
// pmNone, one device is not available. With xine this does not happen.
// May assumption is that here:
//
// device.c:
// 641 m_PlayMode = PlayMode;
// 642
// 643 TrickSpeed(-1);
// 644 if (m_PlayMode == pmAudioOnlyBlack) {
// 645 TRACE(pmAudioOnlyBlack -- BlankDisplay, NoVideo);
// 646 ForEach(m_clients,cXinelibThread::BlankDisplay);
// 647 ForEach(m_clients,cXinelibThread::SetNoVideo, true);
// 648 } else {
// 649 if(m_liveMode)
// 650 ForEach(m_clients,cXinelibThread::SetNoVideo,
//m_RadioStream); 651 else
// 652 ForEach(m_clients,cXinelibThread::SetNoVideo,
// 653 m_RadioStream (m_AudioCount1));
// 654 Clear();
// 655 }
//
// An action is missing to take care of pmNone, i.e. to stop trying to
// receive and decode something.
//
// This is the Problem:
// Apr 22 23:41:05 vdr vdr: [3204] receiver on device 2 thread started
// (pid=2952, tid=3204)
// Apr 22 23:41:05 vdr vdr: [3204]
// ERROR: /dev/dvb/adapter1/dvr0: Device or resource busy
// Apr 22 23:41:05
// vdr vdr: [3204] receiver on device 2 thread ended (pid=2952,
tid=3204)
//
// This does not happen if i use xine, or if i shut down vdr-sxfe
before i
// try to use streamdev oder VNSI plugin.
//
//
// My understanding is that the frontend device needs to do the
required
// action and let vdr know afterwards in order to free the device.
//
// Would appreciate if someone with more understanding of the internals
// could add his opinion here ...
//
// Kind Regards
//
// Steffen
//
// ___
// vdr mailing list
// vdr at linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
// http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
//
//
/
Hi!
Got the same problem here.
No problem with xine.
xineliboutput 1.0.6+cvs20100331.2000
externalplayer 0.1.0-19
best rgds
Micha
--
To unsubscribe from this list: send the line unsubscribe 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: Reponse from Geniatech Re: X8000A and KWorld ATSC 120
In the past year and a half, my personal life took turns for the crazier and crazier. some time prior to that, I had near perfect support working for all functions of this card, including IR, but it never made it into mercurial due to a disagreement with Mauro about what I saw as fundamental changes needed to the cx88 driver design. However, this vendor support offer has my attention for a different reason: Having successfully added support for the AVerMedia Volar A868R, I've been asked to see what I can do about Geniatech's MyGica A680B stick. There is already a wiki entry on it: http://www.linuxtv.org/wiki/index.php/Sabrent_TV-USBHD If what Fang offered for the X8000A he can provide for the A680B, the longstanding issues could be resolved regarding this tree: http://linuxtv.org/hg/~mkrufky/teledongle Since it has been so long since the quoted message, I thought it best to ask this list whether there was any further communication. Has there been? On Mon, 13 Apr 2009 17:42:17 -0500, Vanessa Ezekowitz wrote: Hi all. As a follow-up to the remote control support issue for the Kworld ATSC 120, Geniatech sent me a very encouraging reply today. Anyone want to take Fang up on his offer? -- Forwarded Message -- Subject: 答复: Technical request regarding the HDTV Thriller X8000A Date: Monday 13 April 2009 From: Fang f...@geniatech.com To: 'Vanessa Ezekowitz' vanessaezekow...@gmail.com Dear Vanessa Ezekowitz: Thanks for your inquiry. My name is Fang, product manager of Geniatech. 1st, we can provide you the remote decoder IC information, including I2C address, r/w API, it is simple, read I2C address every 150ms, and you can get the the key stroke decoding value. 2nd, we have step products and both follow this protocol, so it is useful for all our products. 3rd, we'd like to support you directly from the Geniatech, that card is designed by us. Finnally, I'd like to ask you if you can port more linux drivers if we send you samples and tech informations for our other 2 ATSC products: X8350 and X8550. I will send you more detailed tech information to you about the remote IC whatever your answer is. Best Regards Fang -邮件原件- 发件人: Vanessa Ezekowitz [mailto:vanessaezekow...@gmail.com] 发送时间: 2009年4月10日 5:36 收件人: supp...@geniatech.com 主题: Technical request regarding the HDTV Thriller X8000A THIS IS NOT A USER SUPPORT OR DRIVER REQUEST - WE ALREADY HAVE DRIVERS. THIS IS A PROGRAMMER'S REQUEST FOR TECHNICAL INFORMATION. To whom it may concern, Some time back, I wrote you asking about technical information regarding the Thriller X8000A board. I never received a reply, so I am writing again. I own a card that is a chip-for-chip, wire-for-wire clone of the Thriller X8000A, the Kworld HD PCI 120 (also called the ATSC 120 for short) - it is programmatically indistinguishable from your card. My apologies in advance if I have mistaken which company first made this particular card. Anyway... The manufacturer of my card is refusing to answer my question, claiming that the data I request has been outright lost and can't even be communicated between departments within the company. So now, I turn to you, as the maker of a 100% compatible card. We of the Linux community have successfully written open-source drivers for most of the ATSC120/X8000A's features, except for one: we wish to add support for this card's remote control unit. The Linux Community, whom I am sure you are aware represents a very large, rapidly growing market, cannot in good conscience recommend any cards, Geniatech or otherwise, which lack complete programming information. QUESTION: On my particular card, this appears to be a 20 pin SMD IC near the IR sensor connector. the manufacturer of my cloned card has deliberately removed all the markings from the chip, save for a single green dot of paint, and users who own your card have reported similar circumstances. Is this mystery chip the remote decoder/receiver chip as I suspect? What is the part number of this chip? What I2C address does it occupy? Where can I acquire a datasheet for it? I await your reply. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~vanessa/ Vanessa Ezekowitz vanessaezekow...@gmail.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] tm6000: Prevent Kernel Oops changing channel when stream is still on.
Hi Bee, Bee Hock Goh wrote: do a streamoff before setting standard to prevent kernel oops by irq_callback if changing of channel is done while streaming is still on-going. Signed-off-by: Bee Hock Goh beeh...@gmail.com diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c index c53de47..32f625d 100644 --- a/drivers/staging/tm6000/tm6000-video.c +++ b/drivers/staging/tm6000/tm6000-video.c @@ -1081,8 +1086,8 @@ static int vidioc_s_std (struct file *file, void *priv, v4l2_std_id *norm) struct tm6000_fh *fh=priv; struct tm6000_core *dev = fh-dev; + vidioc_streamoff(file, priv, V4L2_BUF_TYPE_VIDEO_CAPTURE); rc=tm6000_set_standard (dev, norm); - fh-width = dev-width; fh-height = dev-height; This doesn't seem to be the right thing to do. The problem here is that changing a video standard takes a long time to happen. As calling an ioctl is protected by KBL, QBUF/DQBUF won't be called, so, the driver will run out of the buffers, and *buf will become null. This can eventually happen during copy_streams(). --- tm6000: Fix a panic if buffer become NULL Changing a video standard takes a long time to happen on tm6000, since it needs to load another firmware, and the i2c implementation on this device is really slow. As calling an ioctl is protected by KBL, QBUF/DQBUF won't be called, so, the driver will run out of the buffers, and *buf will become NULL. This can eventually happen during copy_streams(). The fix is to leave the URB copy loop, if there's no more buffers available. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/linux/drivers/staging/tm6000/tm6000-video.c b/linux/drivers/staging/tm6000/tm6000-video.c --- a/linux/drivers/staging/tm6000/tm6000-video.c +++ b/linux/drivers/staging/tm6000/tm6000-video.c @@ -539,7 +539,7 @@ static inline int tm6000_isoc_copy(struc } } copied += len; - if (copied=size) + if (copied = size || !buf) break; // } } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AF9015 suspend problem
When I have a af9015 DVB-T stick plugged I can not recover from pc suspend. I must unplug the stick to suspend work. Even if I remove the modules I cannot recover from suspend. Any idea why this happen? Jose Alberto -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tm6000, moving cards name defines
Dmitri Belimov wrote:
Hi
Move TV cards name defines to better place header file.
I prefer if we can keep having all board-specific stuff inside tm6000-cards.
Cheers,
Mauro
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Mon Apr 05 22:56:43
2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Wed Apr 14 11:18:03
2010 +1000
@@ -35,22 +35,6 @@
#include tuner-xc2028.h
#include xc5000.h
-#define TM6000_BOARD_UNKNOWN 0
-#define TM5600_BOARD_GENERIC 1
-#define TM6000_BOARD_GENERIC 2
-#define TM6010_BOARD_GENERIC 3
-#define TM5600_BOARD_10MOONS_UT821 4
-#define TM5600_BOARD_10MOONS_UT330 5
-#define TM6000_BOARD_ADSTECH_DUAL_TV 6
-#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
-#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV8
-#define TM6010_BOARD_HAUPPAUGE_900H 9
-#define TM6010_BOARD_BEHOLD_WANDER 10
-#define TM6010_BOARD_BEHOLD_VOYAGER 11
-#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE 12
-#define TM6010_BOARD_TWINHAN_TU501 13
-
-#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
module_param_array(card, int, NULL, 0444);
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000.h
--- a/linux/drivers/staging/tm6000/tm6000.h Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000.h Wed Apr 14 11:18:03 2010 +1000
@@ -41,6 +41,23 @@
#include dmxdev.h
#define TM6000_VERSION KERNEL_VERSION(0, 0, 2)
+
+#define TM6000_BOARD_UNKNOWN 0
+#define TM5600_BOARD_GENERIC 1
+#define TM6000_BOARD_GENERIC 2
+#define TM6010_BOARD_GENERIC 3
+#define TM5600_BOARD_10MOONS_UT821 4
+#define TM5600_BOARD_10MOONS_UT330 5
+#define TM6000_BOARD_ADSTECH_DUAL_TV 6
+#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
+#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV8
+#define TM6010_BOARD_HAUPPAUGE_900H 9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER 11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE 12
+#define TM6010_BOARD_TWINHAN_TU501 13
+
+#define TM6000_MAXBOARDS16
/* Inputs */
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
With my best regards, Dmitry.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx sliced VBI
On Sat, May 1, 2010 at 5:12 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, I played a bit with my HVR900 and tried the sliced VBI API. Unfortunately I discovered that it is completely broken. Part of it is obvious: lots of bugs and code that does not follow the spec, but I also wonder whether it ever actually worked. Can anyone shed some light on this? And is anyone interested in fixing this driver? I can give pointers and help with background info, but I do not have the time to work on this myself. Regards, Hans Hi Hans, I did the em28xx raw VBI support, and I can confirm that the sliced support is completely broken. I just forgot to send the patch upstream which removes it from the set of v4l2 capabilities advertised for the 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: [PATCH] tm6000: Prevent Kernel Oops changing channel when stream is still on.
Mauro Carvalho Chehab wrote:
Hi Bee,
Bee Hock Goh wrote:
do a streamoff before setting standard to prevent kernel oops by
irq_callback if changing of channel is done while streaming is still
on-going.
This doesn't seem to be the right thing to do. The problem here is that
changing a video standard takes a long time to happen. As calling an
ioctl is protected by KBL, QBUF/DQBUF won't be called, so, the driver
will run out of the buffers, and *buf will become null. This can eventually
happen during copy_streams().
---
tm6000: Fix a panic if buffer become NULL
Changing a video standard takes a long time to happen on tm6000, since it
needs to load another firmware, and the i2c implementation on this device
is really slow. As calling an ioctl is protected by KBL, QBUF/DQBUF won't
be called, so, the driver will run out of the buffers, and *buf will become
NULL. This can eventually happen during copy_streams(). The fix is to leave
the URB copy loop, if there's no more buffers available.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/linux/drivers/staging/tm6000/tm6000-video.c
b/linux/drivers/staging/tm6000/tm6000-video.c
Sorry, I sent the wrong one. That's the proper fix. I've also improved
the comments to better express what's happening.
Tested here with HVR-900H and the Panic disappeared.
---
tm6000: Fix a panic if buffer become NULL
Changing a video standard takes a long time to happen on tm6000, since it
needs to load another firmware, and the i2c implementation on this device
is really slow. When the driver tries to change the video standard, a
kernel panic is produced:
BUG: unable to handle kernel NULL pointer dereference at 0008
IP: [a0c7b48a] tm6000_irq_callback+0x57f/0xac2 [tm6000]
...
Kernel panic - not syncing: Fatal exception in interrupt
By inspecting it with gdb:
(gdb) list *tm6000_irq_callback+0x57f
0x348a is in tm6000_irq_callback (drivers/staging/tm6000/tm6000-video.c:202).
197 /* FIXME: move to tm6000-isoc */
198 static int last_line = -2, start_line = -2, last_field = -2;
199
200 /* FIXME: this is the hardcoded window size
201 */
202 unsigned int linewidth = (*buf)-vb.width 1;
203
204 if (!dev-isoc_ctl.cmd) {
205 c = (header 24) 0xff;
206
Clearly, it was the trial to access *buf, at line 202 that caused the
Panic.
As ioctl is serialized, While S_STD is handled,QBUF/DQBUF won't be called.
So, the driver will run out of the buffers, and *buf will become NULL.
As, on tm6000, the same URB can contain more than one video buffer, it is
likely to hit a condition where no new buffer is available whily copying
the streams. The fix is to leave the URB copy loop, if there's no more buffers
are available.
The same bug could also be produced by an application that is not fast enough
to request new video buffers.
The same bug were reported by Bee Hock Goh beeh...@gmail.com.
Thanks-to: Bee Hock Goh beeh...@gmail.com for reporting the bug
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Index: work.x86-64/drivers/staging/tm6000/tm6000-video.c
===
--- work.x86-64.orig/drivers/staging/tm6000/tm6000-video.c
+++ work.x86-64/drivers/staging/tm6000/tm6000-video.c
@@ -395,6 +395,8 @@ HEADER:
jiffies);
return rc;
}
+ if (!*buf)
+ return 0;
}
return 0;
@@ -528,7 +530,7 @@ static inline int tm6000_isoc_copy(struc
}
}
copied += len;
- if (copied=size)
+ if (copied = size || !buf)
break;
// }
}
--
To unsubscribe from this list: send the line unsubscribe 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 FOR 2.6.35] v4l: event: Export the v4l2_event_init and v4l2_event_dequeue functions
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-event.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Sakari, this should go to 2.6.35 with the V4L2 events patch set. Could you ack
the patch so that Mauro can apply it to his linux-next tree ?
Regards,
Laurent Pinchart
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 170e40f..2e673fb 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -45,6 +45,7 @@ int v4l2_event_init(struct v4l2_fh *fh)
return 0;
}
+EXPORT_SYMBOL_GPL(v4l2_event_init);
int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
{
@@ -144,6 +145,7 @@ int v4l2_event_dequeue(struct v4l2_fh *fh, struct
v4l2_event *event,
return ret;
}
+EXPORT_SYMBOL_GPL(v4l2_event_dequeue);
/* Caller must hold fh-event-lock! */
static struct v4l2_subscribed_event *v4l2_event_subscribed(
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH FOR 2.6.35] v4l: event: Export the v4l2_event_init and v4l2_event_dequeue functions
Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-event.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Sakari, this should go to 2.6.35 with the V4L2 events patch set. Could you
ack
the patch so that Mauro can apply it to his linux-next tree ?
Thanks for the patch, Laurent!
I understand this should go in to allow drivers not using video_ioctl2()
to support events as well, right?
Thus,
Acked-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Regards,
Laurent Pinchart
diff --git a/drivers/media/video/v4l2-event.c
b/drivers/media/video/v4l2-event.c
index 170e40f..2e673fb 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -45,6 +45,7 @@ int v4l2_event_init(struct v4l2_fh *fh)
return 0;
}
+EXPORT_SYMBOL_GPL(v4l2_event_init);
int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
{
@@ -144,6 +145,7 @@ int v4l2_event_dequeue(struct v4l2_fh *fh, struct
v4l2_event *event,
return ret;
}
+EXPORT_SYMBOL_GPL(v4l2_event_dequeue);
/* Caller must hold fh-event-lock! */
static struct v4l2_subscribed_event *v4l2_event_subscribed(
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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 sliced VBI
On Sun, May 2, 2010 at 1:25 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, May 1, 2010 at 5:12 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, I played a bit with my HVR900 and tried the sliced VBI API. Unfortunately I discovered that it is completely broken. Part of it is obvious: lots of bugs and code that does not follow the spec, but I also wonder whether it ever actually worked. Can anyone shed some light on this? And is anyone interested in fixing this driver? I can give pointers and help with background info, but I do not have the time to work on this myself. Regards, Hans Hi Hans, I did the em28xx raw VBI support, and I can confirm that the sliced support is completely broken. I just forgot to send the patch upstream which removes it from the set of v4l2 capabilities advertised for the device. Sorry, I forgot to answer the second half of the email. We've got no plans to get the sliced VBI support working in em28xx. Everybody who has asked KernelLabs to do the work has been perfectly satisfied with the raw VBI support, so it just doesn't feel like there is a benefit worthy of the effort required. Also, as far as I can tell, every Windows application I have seen which uses VBI against the em28xx all do it in raw mode, so I don't even have a way of verifying that the sliced VBI even works with the chip. The time is better spent working on other things, although we should definitely do a one line patch so that the driver doesn't claim to support sliced mode. 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 sliced VBI
On Sunday 02 May 2010 19:49:33 Devin Heitmueller wrote: On Sun, May 2, 2010 at 1:25 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, May 1, 2010 at 5:12 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, I played a bit with my HVR900 and tried the sliced VBI API. Unfortunately I discovered that it is completely broken. Part of it is obvious: lots of bugs and code that does not follow the spec, but I also wonder whether it ever actually worked. Can anyone shed some light on this? And is anyone interested in fixing this driver? I can give pointers and help with background info, but I do not have the time to work on this myself. Regards, Hans Hi Hans, I did the em28xx raw VBI support, and I can confirm that the sliced support is completely broken. I just forgot to send the patch upstream which removes it from the set of v4l2 capabilities advertised for the device. Sorry, I forgot to answer the second half of the email. We've got no plans to get the sliced VBI support working in em28xx. Everybody who has asked KernelLabs to do the work has been perfectly satisfied with the raw VBI support, so it just doesn't feel like there is a benefit worthy of the effort required. Also, as far as I can tell, every Windows application I have seen which uses VBI against the em28xx all do it in raw mode, so I don't even have a way of verifying that the sliced VBI even works with the chip. The time is better spent working on other things, although we should definitely do a one line patch so that the driver doesn't claim to support sliced mode. Why not just nuke everything related to sliced VBI? Just leave a comment saying that you should look at older versions if you want to resurrect sliced vbi. That's what version control systems are for. I hate code that doesn't do anything. It pollutes the source, it confuses the reader and it increases the size for no good reason. And people like me spent time flogging a dead horse :-( Sliced VBI really only makes sense in combination with compressed video streams. Or perhaps on SoCs where you don't want to process the raw VBI. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
saa7146 firmware upload time?
Hi My WinTV NOVA-t PCI card is recognized by the saa7146 driver (ubuntu 9.10 2.6.31-21-generic kernel), but I don't have a /dev/video0. At some point I noticed messages in syslog about missing firmware (below), and rectified that by fetching the firmware and dropping it in /lib/firmware. However, there's a big gap (over an hour and a half) between boot and the time when the driver complains about the firmware: May 2 16:00:28 alice kernel: [ 58.447825] saa7146: register extension 'budget_ci dvb'. May 2 16:00:28 alice kernel: [ 58.449357] budget_ci dvb :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 May 2 16:00:28 alice kernel: [ 58.449394] IRQ 17/: IRQF_DISABLED is not guaranteed on shared IRQs May 2 16:00:28 alice kernel: [ 58.449412] saa7146: found saa7146 @ mem c90011348c00 (revision 1, irq 17) (0x13c2,0x1011). May 2 16:00:28 alice kernel: [ 58.449416] saa7146 (0): dma buffer size 192512 May 2 16:00:28 alice kernel: [ 58.449417] DVB: registering new adapter (TT-Budget/WinTV-NOVA-TPCI) May 2 16:00:28 alice kernel: [ 58.510969] adapter has MAC addr = 00:d0:5c:23:ed:cf May 2 16:00:28 alice kernel: [ 58.511252] input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci:00/:00:1e.0/:05:01.0/input/input7 May 2 16:00:28 alice kernel: [ 58.587617] DVB: registering adapter 0 frontend 0 (Philips TDA10045H DVB-T)... [...] May 2 17:40:39 alice kernel: [ 6057.360792] tda1004x: found firmware revision 0 -- invalid May 2 17:40:39 alice kernel: [ 6057.360795] tda1004x: waiting for firmware upload (dvb-fe-tda10045.fw)... May 2 17:40:39 alice kernel: [ 6057.360800] budget_ci dvb :05:01.0: firmware: requesting dvb-fe-tda10045.fw May 2 17:40:39 alice kernel: [ 6057.449458] tda1004x: no firmware upload (timeout or file not found?) May 2 17:40:39 alice kernel: [ 6057.449461] tda1004x: firmware upload failed May 2 17:40:39 alice firmware.sh[4365]: Cannot find firmware file 'dvb-fe-tda10045.fw' I don't know anything about the kernel but looking at the source seemed to suggest the driver looks for the firmware at modprobe time, but rmmod followed by modprobe doesn't give me any messages about firmware (nor does a reboot). What should I do to trigger this firmware upload process again? Thanks John -- To unsubscribe from this list: send the line unsubscribe 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 sliced VBI
On Sun, May 2, 2010 at 2:13 PM, Hans Verkuil hverk...@xs4all.nl wrote: Why not just nuke everything related to sliced VBI? Just leave a comment saying that you should look at older versions if you want to resurrect sliced vbi. That's what version control systems are for. I would have no objection to this. The sliced VBI support was present long before I added the raw VBI support. I hate code that doesn't do anything. It pollutes the source, it confuses the reader and it increases the size for no good reason. And people like me spent time flogging a dead horse :-( Sliced VBI really only makes sense in combination with compressed video streams. Or perhaps on SoCs where you don't want to process the raw VBI. Agreed, which is why nobody I know who is actively using VBI on em28xx actually cares whether it's sliced or raw. If somebody comes around who has a commercial interest in seeing sliced VBI work on the chip, KernelLabs would be happy to revisit the issue. Otherwise, there are much better things we could be spending our time on. 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 sliced VBI
Hans Verkuil wrote: On Sunday 02 May 2010 19:49:33 Devin Heitmueller wrote: On Sun, May 2, 2010 at 1:25 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, May 1, 2010 at 5:12 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, I played a bit with my HVR900 and tried the sliced VBI API. Unfortunately I discovered that it is completely broken. Part of it is obvious: lots of bugs and code that does not follow the spec, but I also wonder whether it ever actually worked. Can anyone shed some light on this? And is anyone interested in fixing this driver? I can give pointers and help with background info, but I do not have the time to work on this myself. Regards, Hans Hi Hans, I did the em28xx raw VBI support, and I can confirm that the sliced support is completely broken. I just forgot to send the patch upstream which removes it from the set of v4l2 capabilities advertised for the device. Sorry, I forgot to answer the second half of the email. We've got no plans to get the sliced VBI support working in em28xx. Everybody who has asked KernelLabs to do the work has been perfectly satisfied with the raw VBI support, so it just doesn't feel like there is a benefit worthy of the effort required. Also, as far as I can tell, every Windows application I have seen which uses VBI against the em28xx all do it in raw mode, so I don't even have a way of verifying that the sliced VBI even works with the chip. The time is better spent working on other things, although we should definitely do a one line patch so that the driver doesn't claim to support sliced mode. Why not just nuke everything related to sliced VBI? Just leave a comment saying that you should look at older versions if you want to resurrect sliced vbi. That's what version control systems are for. I hate code that doesn't do anything. It pollutes the source, it confuses the reader and it increases the size for no good reason. And people like me spent time flogging a dead horse :-( Sliced VBI really only makes sense in combination with compressed video streams. Or perhaps on SoCs where you don't want to process the raw VBI. The current code is incomplete. It were added to allow exporting the decoded VBI information from tvp5051. However, due to the lack of enough specs on em28xx side, we never found a way to export those decoded VBI info to userspace. So, we can just drop this code. I don't think we should keep any comment about that. If anyone would ever interested on adding sliced VBI support, the code is there anyway. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] UVC gadget driver
Hi everybody, Here's a new version of the UVC gadget driver, rebased on 2.6.34-rc6. There has been no comment so far, so I'll assume that either the code is perfect or (most probably) people are busy doing something else. In either case, this adds a new driver to the kernel without disturbing anything else, so it should be safe to merge. The driver depends on the new V4L2 events API that will be available in 2.6.34 (the code is already available in the v4l-dvb tree on linuxtv.org and should be pushed to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git very soon). I've tested the driver after backporting it to a 2.6.28 kernel, as that's all my current test hardware runs at the moment. The previous version has been tested on a beagle board with 2.6.33, but the performances were limited by the lack of proper DMA support for the MUSB controller in the linux-omap kernel. I'd like the UVC function driver to make it to 2.6.35 if possible. The webcam gadget driver is mostly for example purpose, and doesn't need to be merged if there's any concern with it. Laurent Pinchart (2): USB gadget: video class function driver USB gadget: Webcam device drivers/usb/gadget/Kconfig |9 +- drivers/usb/gadget/Makefile|2 + drivers/usb/gadget/f_uvc.c | 661 drivers/usb/gadget/f_uvc.h | 376 +++ drivers/usb/gadget/uvc.h | 241 +++ drivers/usb/gadget/uvc_queue.c | 583 +++ drivers/usb/gadget/uvc_queue.h | 89 ++ drivers/usb/gadget/uvc_v4l2.c | 374 +++ drivers/usb/gadget/uvc_video.c | 386 +++ drivers/usb/gadget/webcam.c| 399 10 files changed, 3119 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/gadget/f_uvc.c create mode 100644 drivers/usb/gadget/f_uvc.h create mode 100644 drivers/usb/gadget/uvc.h create mode 100644 drivers/usb/gadget/uvc_queue.c create mode 100644 drivers/usb/gadget/uvc_queue.h create mode 100644 drivers/usb/gadget/uvc_v4l2.c create mode 100644 drivers/usb/gadget/uvc_video.c create mode 100644 drivers/usb/gadget/webcam.c -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB gadget: Webcam device
This webcam gadget instantiates a UVC camera (360p and 720p resolutions
in YUYV and MJPEG).
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/gadget/Kconfig |9 +-
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/webcam.c | 399 +++
3 files changed, 409 insertions(+), 1 deletions(-)
create mode 100644 drivers/usb/gadget/webcam.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 11a3e0f..f7da73e 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -866,8 +866,15 @@ config USB_G_MULTI_CDC
# put drivers that need isochronous transfer support (for audio
# or video class gadget drivers), or specific hardware, here.
+config USB_G_WEBCAM
+ tristate USB Webcam Gadget
+ help
+ The Webcam Gadget acts as a composite USB Audio and Video Class
+ device. It provides a userspace API to process UVC control requests
+ and stream video data to the host.
-# - none yet
+ Say y to link the driver statically, or m to build a
+ dynamically linked module called g_webcam.
endchoice
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 43b51da..4dcdc7b 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -44,6 +44,7 @@ g_printer-objs:= printer.o
g_cdc-objs := cdc2.o
g_multi-objs := multi.o
g_nokia-objs := nokia.o
+g_webcam-objs := webcam.o
obj-$(CONFIG_USB_ZERO) += g_zero.o
obj-$(CONFIG_USB_AUDIO)+= g_audio.o
@@ -57,4 +58,5 @@ obj-$(CONFIG_USB_MIDI_GADGET) += g_midi.o
obj-$(CONFIG_USB_CDC_COMPOSITE) += g_cdc.o
obj-$(CONFIG_USB_G_MULTI) += g_multi.o
obj-$(CONFIG_USB_G_NOKIA) += g_nokia.o
+obj-$(CONFIG_USB_G_WEBCAM) += g_webcam.o
diff --git a/drivers/usb/gadget/webcam.c b/drivers/usb/gadget/webcam.c
new file mode 100644
index 000..417fd68
--- /dev/null
+++ b/drivers/usb/gadget/webcam.c
@@ -0,0 +1,399 @@
+/*
+ * webcam.c -- USB webcam gadget driver
+ *
+ * Copyright (C) 2009-2010
+ * Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include linux/kernel.h
+#include linux/device.h
+#include linux/usb/video.h
+
+#include f_uvc.h
+
+/*
+ * Kbuild is not very cooperative with respect to linking separately
+ * compiled library objects into one module. So for now we won't use
+ * separate compilation ... ensuring init/exit sections work to shrink
+ * the runtime footprint, and giving us at least some parts of what
+ * a gcc --combine ... part1.c part2.c part3.c ... build would.
+ */
+#include composite.c
+#include usbstring.c
+#include config.c
+#include epautoconf.c
+
+#include f_uvc.c
+#include uvc_queue.c
+#include uvc_v4l2.c
+#include uvc_video.c
+
+/* --
+ * Device descriptor
+ */
+
+#define WEBCAM_VENDOR_ID 0x1d6b /* Linux Foundation */
+#define WEBCAM_PRODUCT_ID 0x0102 /* Webcam A/V gadget */
+#define WEBCAM_DEVICE_BCD 0x0010 /* 0.10 */
+
+static char webcam_vendor_label[] = Linux Foundation;
+static char webcam_product_label[] = Webcam gadget;
+static char webcam_config_label[] = Video;
+
+/* string IDs are assigned dynamically */
+
+#define STRING_MANUFACTURER_IDX0
+#define STRING_PRODUCT_IDX 1
+#define STRING_DESCRIPTION_IDX 2
+
+static struct usb_string webcam_strings[] = {
+ [STRING_MANUFACTURER_IDX].s = webcam_vendor_label,
+ [STRING_PRODUCT_IDX].s = webcam_product_label,
+ [STRING_DESCRIPTION_IDX].s = webcam_config_label,
+ { }
+};
+
+static struct usb_gadget_strings webcam_stringtab = {
+ .language = 0x0409, /* en-us */
+ .strings = webcam_strings,
+};
+
+static struct usb_gadget_strings *webcam_device_strings[] = {
+ webcam_stringtab,
+ NULL,
+};
+
+static struct usb_device_descriptor webcam_device_descriptor = {
+ .bLength= USB_DT_DEVICE_SIZE,
+ .bDescriptorType= USB_DT_DEVICE,
+ .bcdUSB = cpu_to_le16(0x0200),
+ .bDeviceClass = USB_CLASS_MISC,
+ .bDeviceSubClass= 0x02,
+ .bDeviceProtocol= 0x01,
+ .bMaxPacketSize0= 0, /* dynamic */
+ .idVendor = cpu_to_le16(WEBCAM_VENDOR_ID),
+ .idProduct = cpu_to_le16(WEBCAM_PRODUCT_ID),
+ .bcdDevice = cpu_to_le16(WEBCAM_DEVICE_BCD),
+ .iManufacturer = 0, /* dynamic */
+ .iProduct = 0, /*
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun May 2 19:00:12 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14619:ee9826bc7106 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: d3be2fab3a10b6c798a5f9970146d166d3345c37 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7146 firmware upload time?
Hi, On Sunday 02 May 2010 20:13:08 John J Lee wrote: My WinTV NOVA-t PCI card is recognized by the saa7146 driver (ubuntu 9.10 2.6.31-21-generic kernel), but I don't have a /dev/video0. At some point I noticed messages in syslog about missing firmware (below), and rectified that by fetching the firmware and dropping it in /lib/firmware. However, there's a big gap (over an hour and a half) between boot and the time when the driver complains about the firmware: May 2 16:00:28 alice kernel: [ 58.447825] saa7146: register extension 'budget_ci dvb'. May 2 16:00:28 alice kernel: [ 58.449357] budget_ci dvb :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 May 2 16:00:28 alice kernel: [ 58.449394] IRQ 17/: IRQF_DISABLED is not guaranteed on shared IRQs May 2 16:00:28 alice kernel: [ 58.449412] saa7146: found saa7146 @ mem c90011348c00 (revision 1, irq 17) (0x13c2,0x1011). May 2 16:00:28 alice kernel: [ 58.449416] saa7146 (0): dma buffer size 192512 May 2 16:00:28 alice kernel: [ 58.449417] DVB: registering new adapter (TT-Budget/WinTV-NOVA-TPCI) May 2 16:00:28 alice kernel: [ 58.510969] adapter has MAC addr = 00:d0:5c:23:ed:cf May 2 16:00:28 alice kernel: [ 58.511252] input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci:00/:00:1e.0/:05:01.0/input/input7 May 2 16:00:28 alice kernel: [ 58.587617] DVB: registering adapter 0 frontend 0 (Philips TDA10045H DVB-T)... [...] May 2 17:40:39 alice kernel: [ 6057.360792] tda1004x: found firmware revision 0 -- invalid May 2 17:40:39 alice kernel: [ 6057.360795] tda1004x: waiting for firmware upload (dvb-fe-tda10045.fw)... May 2 17:40:39 alice kernel: [ 6057.360800] budget_ci dvb :05:01.0: firmware: requesting dvb-fe-tda10045.fw May 2 17:40:39 alice kernel: [ 6057.449458] tda1004x: no firmware upload (timeout or file not found?) May 2 17:40:39 alice kernel: [ 6057.449461] tda1004x: firmware upload failed May 2 17:40:39 alice firmware.sh[4365]: Cannot find firmware file 'dvb-fe-tda10045.fw' I don't know anything about the kernel but looking at the source seemed to suggest the driver looks for the firmware at modprobe time, but rmmod followed by modprobe doesn't give me any messages about firmware (nor does a reboot). What should I do to trigger this firmware upload process again? Obviously, the firmware is not loaded at modprobe time. It is loaded when an application opens the frontend for the first time. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe 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: av7110 crash when unloading.
Hi, On Saturday 01 May 2010 21:21:38 VDR User wrote: I just grabbed the latest hg tree and got the following when I tried to unload the drivers for my nexus-s: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077154] Oops: [#1] SMP Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077156] last sysfs file: /sys/devices/virtual/vtconsole/vtcon0/uevent Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077193] Process rmmod (pid: 5099, ti=f6a54000 task=f5311490 task.ti=f6a54000) Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077300] CR2: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077296] EIP: [f98dfeaa] v4l2_device_unregister+0x14/0x4f [videodev] SS:ESP 0068:f6a55e7c Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077273] Code: 89 c3 8b 00 85 c0 74 0d 31 d2 e8 90 91 8c c7 c7 03 00 00 00 00 5b c3 57 85 c0 56 89 c6 53 74 42 e8 da ff ff ff 8b 5e 04 83 c6 04 8b 3b eb 2f 89 d8 e8 fb fe ff ff f6 43 0c 01 74 0c 8b 43 3c 85 Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077195] Stack: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077211] Call Trace: The modules wouldn't unload and a reboot was needed to clear it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html See http://www.mail-archive.com/linux-media@vger.kernel.org/msg16895.html CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe 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: av7110 crash when unloading.
On Sunday 02 May 2010 21:57:07 Oliver Endriss wrote: Hi, On Saturday 01 May 2010 21:21:38 VDR User wrote: I just grabbed the latest hg tree and got the following when I tried to unload the drivers for my nexus-s: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077154] Oops: [#1] SMP Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077156] last sysfs file: /sys/devices/virtual/vtconsole/vtcon0/uevent Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077193] Process rmmod (pid: 5099, ti=f6a54000 task=f5311490 task.ti=f6a54000) Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077300] CR2: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077296] EIP: [f98dfeaa] v4l2_device_unregister+0x14/0x4f [videodev] SS:ESP 0068:f6a55e7c Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077273] Code: 89 c3 8b 00 85 c0 74 0d 31 d2 e8 90 91 8c c7 c7 03 00 00 00 00 5b c3 57 85 c0 56 89 c6 53 74 42 e8 da ff ff ff 8b 5e 04 83 c6 04 8b 3b eb 2f 89 d8 e8 fb fe ff ff f6 43 0c 01 74 0c 8b 43 3c 85 Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077195] Stack: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077211] Call Trace: The modules wouldn't unload and a reboot was needed to clear it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html See http://www.mail-archive.com/linux-media@vger.kernel.org/msg16895.html CU Oliver The patch to fix this is in the git fixes tree for quite some time, but since it hasn't been upstreamed yet it is still not in the v4l-dvb git or hg trees. I've asked Mauro when he is going to do that, I can't do much more. For the time being you can apply the diff from fixes.git: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Save to e.g. fix.diff, go to the linux directory in your v4l-dvb tree and apply it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe 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 03/15] [RFC] Documentation: add v4l2-controls.txt documenting the new controls API.
Hi Hans,
I finally got some time to review your RFC. Let's see until what time it will
keep me awake :-)
On Monday 26 April 2010 09:33:38 Hans Verkuil wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
Documentation/video4linux/v4l2-controls.txt | 543
1 files changed, 543 insertions(+), 0 deletions(-)
create mode 100644 Documentation/video4linux/v4l2-controls.txt
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
new file mode 100644
index 000..29a92b4
--- /dev/null
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -0,0 +1,543 @@
+Introduction
+
+
+The V4L2 control API seems simple enough, but quickly becomes very hard to
+implement correctly in drivers. But much of the code needed to handle
controls
+is actually not driver specific and can be moved to the V4L core framework.
+
+After all, the only part that a driver developer is interested in is:
+
+1) How do I add a control?
Do you think we will need the ability to remove controls ?
+2) How do I set the control? (i.e. s_ctrl)
+
+And occasionally:
+
+3) How do I update the control's value? (i.e. g_ctrl)
The wording of 2 and 3 got me a bit confused. setting a control usually
refers to the operation performed by userspace. Similarly, without the i.e.
g_ctrl comment, I would have thought update meant writing the value to the
hardware.
+4) How do I validate the user's proposed control value? (i.e. try_ctrl)
+
+All the rest is something that can be done centrally.
+
+The control framework was created in order to implement all the rules of
the
+V4L2 specification with respect to controls in a central place. And
to make +life as easy as possible for the driver developer.
+
+
+Objects in the framework
+
+
+There are two main objects:
+
+The v4l2_ctrl object describes the control properties and keeps track of
the
+control's value (both the current value and the proposed new value).
I'm not sure v4l2_ctrl is a good name. We already have a v4l2_control
structure, and using the abbreviated name for the in-kernel version is going
to be confusing.
It's obviously too late to change v4l2_control to something else.
v4l2_control_info and v4l2_control_value are two names that come to my mind.
Actually, it might be a good idea to split the v4l2_ctrl structure into a
static driver-wide structure (v4l2_control_info) and an instance-specific
structure (v4l2_control_value). There's no point in storing the same static
data (function pointers, names, ...) for identical controls in different
devices.
+
+v4l2_ctrl_handler is the object that keeps track of controls. It maintains
a
+list of v4l2_ctrl objects that it owns and another list of references to
+controls, possibly to controls owned by other handlers.
+
+
+Basic usage
+===
+
+1) Prepare the driver:
+
+- Add the handler to your main bridge driver or sub-device driver top-level
+ struct:
+
+ struct foo_dev {
+ ...
+ struct v4l2_ctrl_handler hdl;
Please use more descriptive names in the examples, such as ctrl_handler. I
expect some (many ?) developers to use the same names as the documentation
does, making the driver code a bit difficult to read.
+ ...
+ };
+
+ struct foo_dev *foo;
+
+- Initialize handler:
+
+ v4l2_ctrl_handler_init(foo-hdl, nr_of_controls);
+
+ The second argument is a hint telling the function how many controls
this
+ handled is expected to handle. It will allocate a hashtable based on this
s/handled/handler/
+ information. It is a hint only.
+
+- Hooking the control handler into a driver:
+
+ When a subdevice is being registered with a bridge driver and the
+ ctrl_handler fields of both v4l2_subdev and v4l2_device are set, then
the
+ controls of the subdev will become automatically available in the
bridge
+ driver as well. If the subdev driver contains controls that already exist
in
+ the bridge driver, then those will be skipped (so a bridge driver can
always
+ override a subdev control).
I think you should split the documentation differently. You're mixing video
devices, bridges and subdevs. Developers of drivers that use no subdev will
have trouble understanding the documentation. You should first describe how to
use the framework in a simple driver (no host, bridge, subdev, ... just a
foo_dev and a single video_device), and then add sections to describe bridge-
specific and subdev-specific APIs.
+
+ How to hook the handler into a bridge driver:
+
+ foo-v4l2_dev.ctrl_handler = foo-hdl;
Is v4l2_dev an instance of video_device or v4l2_device ? It would be nice to
add the field to the foo_dev structure in the example.
+
+ And whenever you call video_register_device() you must set the
+ ctrl_handler field of struct video_device as well:
+
+ vdev-ctrl_handler =
Re: [PATCH 08/15] [RFC] cx25840/ivtv: replace ugly priv control with s_config
Hi Hans,
On Monday 26 April 2010 09:33:54 Hans Verkuil wrote:
The cx25840 used a private control CX25840_CID_ENABLE_PVR150_WORKAROUND
to be told whether to enable a workaround for certain pvr150 cards.
This is really config data that it needs to get at load time.
Implemented this in cx25840 and ivtv.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/cx25840/cx25840-core.c | 23 +++
drivers/media/video/cx25840/cx25840-core.h |8
drivers/media/video/ivtv/ivtv-driver.c |9 +
drivers/media/video/ivtv/ivtv-i2c.c|7 +++
include/media/cx25840.h| 11 +++
5 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-core.c
b/drivers/media/video/cx25840/cx25840-core.c index f2461cd..b8aa5d2 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
[snip]
@@ -1601,10 +1593,25 @@ static int cx25840_log_status(struct v4l2_subdev
*sd) return 0;
}
+static int cx25840_s_config(struct v4l2_subdev *sd, int irq, void
*platform_data) +{
+ struct cx25840_state *state = to_state(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ if (platform_data) {
+ struct cx25840_platform_data *pdata = platform_data;
+
+ state-pvr150_workaround = pdata-pvr150_workaround;
+ set_input(client, state-vid_input, state-aud_input);
+ }
+ return 0;
+}
+
You've told me that s_config was only meant for I2C devices in pre-2.6.26
kernels. Shouldn't this be done in the probe function instead ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe 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 02/15] [RFC] v4l2-ctrls: reorder 'case' statements to match order in header.
Hi Hans, On Monday 26 April 2010 09:33:33 Hans Verkuil wrote: To make it easier to determine whether all controls are added in v4l2-ctrls.c the case statements inside the switch are re-ordered to match the header. Signed-off-by: Hans Verkuil hverk...@xs4all.nl This patch should be merged with the previous one. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe 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] Compro Videomate T750F Vista DVB-T support
HI
I have european version of Compro Videomate T750F Vista
hybrid dvb-t + tv (PAL) + FM card. In kernels up to date (2.6.33.3)
it didn't want to initialize in analog mode (tuner xc2028 always failed).
Here's sligthly adapted patch from
http://www.linuxtv.org/pipermail/linux-dvb/2008-May/025945.html
that works for me. It disables analog tuner xc2028 which doesn't
work (maybe because current driver is only for ntsc version of the
card) and enables digital tuner that consists of zarlink 10353 and
qt1010. Tested and works on kernel 2.6.33.3
Best regards, Emard
--- linux-2.6.33.3/drivers/media/video/saa7134/saa7134-cards.c.orig
2010-05-02 00:06:45.0 +0200
+++ linux-2.6.33.3/drivers/media/video/saa7134/saa7134-cards.c
2010-05-02 01:20:50.0 +0200
@@ -4883,10 +4883,11 @@ struct saa7134_board saa7134_boards[] =
/* John Newbigin j...@it.swin.edu.au */
.name = Compro VideoMate T750,
.audio_clock= 0x00187de7,
- .tuner_type = TUNER_XC2028,
+ .tuner_type = TUNER_ABSENT,
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -7192,6 +7193,7 @@ int saa7134_board_init2(struct saa7134_d
case SAA7134_BOARD_AVERMEDIA_SUPER_007:
case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
case SAA7134_BOARD_CREATIX_CTX953:
+case SAA7134_BOARD_VIDEOMATE_T750:
{
/* this is a hybrid board, initialize to analog mode
* and configure firmware eeprom address
--- linux-2.6.33.3/drivers/media/video/saa7134/saa7134-dvb.c.orig
2010-05-01 23:57:08.0 +0200
+++ linux-2.6.33.3/drivers/media/video/saa7134/saa7134-dvb.c
2010-05-02 00:51:44.0 +0200
@@ -55,6 +55,7 @@
#include tda8290.h
#include zl10353.h
+#include qt1010.h
#include zl10036.h
#include zl10039.h
@@ -886,6 +887,17 @@ static struct zl10353_config behold_x7_c
.disable_i2c_gate_ctrl = 1,
};
+static struct zl10353_config videomate_t750_zl10353_config = {
+ .demod_address = 0x0f,
+ .no_tuner = 1,
+ .parallel_ts = 1,
+};
+
+static struct qt1010_config videomate_t750_qt1010_config = {
+ .i2c_address = 0x62
+};
+
+
/* ==
* tda10086 based DVB-S cards, helper functions
*/
@@ -1556,6 +1568,26 @@ static int dvb_init(struct saa7134_dev *
__func__);
break;
+/*FIXME: What frontend does Videomate T750 use? */
+case SAA7134_BOARD_VIDEOMATE_T750:
+printk(Compro VideoMate T750 DVB setup\n);
+fe0-dvb.frontend = dvb_attach(zl10353_attach,
+videomate_t750_zl10353_config,
+dev-i2c_adap);
+if (fe0-dvb.frontend != NULL) {
+printk(Attaching pll\n);
+// if there is a gate function then the i2c
bus breaks.!
+fe0-dvb.frontend-ops.i2c_gate_ctrl = 0;
+
+if (dvb_attach(qt1010_attach,
+ fe0-dvb.frontend,
+ dev-i2c_adap,
+ videomate_t750_qt1010_config) == NULL)
+{
+wprintk(error attaching QT1010\n);
+}
+}
+break;
case SAA7134_BOARD_ZOLID_HYBRID_PCI:
fe0-dvb.frontend = dvb_attach(tda10048_attach,
zolid_tda10048_config,
--
To unsubscribe from this list: send the line unsubscribe 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: [ANNOUNCEMENT] Media controller tree updated
Hi Mauro, On Saturday 01 May 2010 03:08:10 Mauro Carvalho Chehab wrote: Hi Laurent, Laurent Pinchart wrote: Hi everybody, The next version of the media controller patches is available in git at http://git.linuxtv.org/pinchartl/v4l-dvb-media.git To avoid putting too much pressure on the linuxtv.org git server, please make sure you reference an existing mainline Linux git tree when cloning v4l-dvb- media (see the --reference option to git-clone). I've made a small script that added the proper instructions to the existing clones of the kernel tree. Please check if it is ok. Sounds good. Maybe we should also hint that people can clone the git tree using the --reference argument, that saves lots of disk space. The script is not automatic. When I have some time, I'll integrate it with some tool to run it automatically after a new tree is added there, but, for now, I need to run it after I notice that somebody created a new tree. The script has a basic test to discover that the tree is based on Kernel tree: it checks if a v2.6.32 tag exist at the new tree (ok, I confess: I was very lazy when I wrote the script... it works with the current trees, but we need a more reliable way, if we want to run automatically). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe 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: saa7146 firmware upload time?
On Sun, 2 May 2010, Oliver Endriss wrote: [...] Obviously, the firmware is not loaded at modprobe time. It is loaded when an application opens the frontend for the first time. [...] Thanks. Before the frontend can be opened, open(2) must be called on a v4l device file, right? I don't appear to have such a device file (no /dev/video*, no /dev/dvb/adaptor*/video*). I had assumed the missing device file was caused by the failure to load the firmware. So it's still not clear to me how to trigger the firmware loading process again (though clearly something I did today triggered it once), or indeed whether that is the problem I should be trying to solve. Clues welcome John -- To unsubscribe from this list: send the line unsubscribe 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: saa7146 firmware upload time?
On Sun, 2 May 2010, John J Lee wrote: On Sun, 2 May 2010, Oliver Endriss wrote: [...] Obviously, the firmware is not loaded at modprobe time. It is loaded when an application opens the frontend for the first time. [...] Thanks. Before the frontend can be opened, open(2) must be called on a v4l device file, right? I don't appear to have such a device file (no /dev/video*, no /dev/dvb/adaptor*/video*). I had assumed the missing device file was caused by the failure to load the firmware. So it's still not clear to me how to trigger the firmware loading process again (though clearly something I did today triggered it once), or indeed whether that is the problem I should be trying to solve. Clues welcome OK, I still don't understand how it works, but I successfully triggered the firmware loading process by running kaffeine. Thanks for your help. John -- To unsubscribe from this list: send the line unsubscribe 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 03/15] [RFC] Documentation: add v4l2-controls.txt documenting the new controls API.
On Sunday 02 May 2010 22:39:11 Laurent Pinchart wrote:
Hi Hans,
I finally got some time to review your RFC. Let's see until what time it will
keep me awake :-)
On Monday 26 April 2010 09:33:38 Hans Verkuil wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
Documentation/video4linux/v4l2-controls.txt | 543
1 files changed, 543 insertions(+), 0 deletions(-)
create mode 100644 Documentation/video4linux/v4l2-controls.txt
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
new file mode 100644
index 000..29a92b4
--- /dev/null
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -0,0 +1,543 @@
+Introduction
+
+
+The V4L2 control API seems simple enough, but quickly becomes very hard to
+implement correctly in drivers. But much of the code needed to handle
controls
+is actually not driver specific and can be moved to the V4L core framework.
+
+After all, the only part that a driver developer is interested in is:
+
+1) How do I add a control?
Do you think we will need the ability to remove controls ?
I am not aware of any use case. The data structures used will make it hard
to actually remove a control. But you can still disable a control by setting
a flag, should this become necessary.
+2) How do I set the control? (i.e. s_ctrl)
+
+And occasionally:
+
+3) How do I update the control's value? (i.e. g_ctrl)
The wording of 2 and 3 got me a bit confused. setting a control usually
refers to the operation performed by userspace. Similarly, without the i.e.
g_ctrl comment, I would have thought update meant writing the value to the
hardware.
Good point, that was a poor choice of words. I'll fix this.
+4) How do I validate the user's proposed control value? (i.e. try_ctrl)
+
+All the rest is something that can be done centrally.
+
+The control framework was created in order to implement all the rules of
the
+V4L2 specification with respect to controls in a central place. And
to make +life as easy as possible for the driver developer.
+
+
+Objects in the framework
+
+
+There are two main objects:
+
+The v4l2_ctrl object describes the control properties and keeps track of
the
+control's value (both the current value and the proposed new value).
I'm not sure v4l2_ctrl is a good name. We already have a v4l2_control
structure, and using the abbreviated name for the in-kernel version is going
to be confusing.
Originally it was called v4l2_ctrl_info but that became very cumbersome.
It's not really an info object anyway, it really describes a control. When
using this framework the driver no longer sees the v4l2_control anymore, so
from the point of view of the driver there is only v4l2_ctrl.
It's obviously too late to change v4l2_control to something else.
v4l2_control_info and v4l2_control_value are two names that come to my mind.
Actually, it might be a good idea to split the v4l2_ctrl structure into a
static driver-wide structure (v4l2_control_info) and an instance-specific
structure (v4l2_control_value). There's no point in storing the same static
data (function pointers, names, ...) for identical controls in different
devices.
Other than the name there isn't anything that is static. And the name is
already static.
+
+v4l2_ctrl_handler is the object that keeps track of controls. It maintains
a
+list of v4l2_ctrl objects that it owns and another list of references to
+controls, possibly to controls owned by other handlers.
+
+
+Basic usage
+===
+
+1) Prepare the driver:
+
+- Add the handler to your main bridge driver or sub-device driver top-level
+ struct:
+
+ struct foo_dev {
+ ...
+ struct v4l2_ctrl_handler hdl;
Please use more descriptive names in the examples, such as ctrl_handler. I
expect some (many ?) developers to use the same names as the documentation
does, making the driver code a bit difficult to read.
Good point.
+ ...
+ };
+
+ struct foo_dev *foo;
+
+- Initialize handler:
+
+ v4l2_ctrl_handler_init(foo-hdl, nr_of_controls);
+
+ The second argument is a hint telling the function how many controls
this
+ handled is expected to handle. It will allocate a hashtable based on this
s/handled/handler/
Thanks.
+ information. It is a hint only.
+
+- Hooking the control handler into a driver:
+
+ When a subdevice is being registered with a bridge driver and the
+ ctrl_handler fields of both v4l2_subdev and v4l2_device are set, then
the
+ controls of the subdev will become automatically available in the
bridge
+ driver as well. If the subdev driver contains controls that already exist
in
+ the bridge driver, then those will be skipped (so a bridge driver can
always
+ override a subdev control).
Re: [PATCH 08/15] [RFC] cx25840/ivtv: replace ugly priv control with s_config
On Sunday 02 May 2010 22:41:29 Laurent Pinchart wrote:
Hi Hans,
On Monday 26 April 2010 09:33:54 Hans Verkuil wrote:
The cx25840 used a private control CX25840_CID_ENABLE_PVR150_WORKAROUND
to be told whether to enable a workaround for certain pvr150 cards.
This is really config data that it needs to get at load time.
Implemented this in cx25840 and ivtv.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/cx25840/cx25840-core.c | 23 +++
drivers/media/video/cx25840/cx25840-core.h |8
drivers/media/video/ivtv/ivtv-driver.c |9 +
drivers/media/video/ivtv/ivtv-i2c.c|7 +++
include/media/cx25840.h| 11 +++
5 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-core.c
b/drivers/media/video/cx25840/cx25840-core.c index f2461cd..b8aa5d2 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
[snip]
@@ -1601,10 +1593,25 @@ static int cx25840_log_status(struct v4l2_subdev
*sd) return 0;
}
+static int cx25840_s_config(struct v4l2_subdev *sd, int irq, void
*platform_data) +{
+ struct cx25840_state *state = to_state(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ if (platform_data) {
+ struct cx25840_platform_data *pdata = platform_data;
+
+ state-pvr150_workaround = pdata-pvr150_workaround;
+ set_input(client, state-vid_input, state-aud_input);
+ }
+ return 0;
+}
+
You've told me that s_config was only meant for I2C devices in pre-2.6.26
kernels. Shouldn't this be done in the probe function instead ?
s_config is only meant for i2c drivers that have to support pre-2.6.26
kernels (only applicable for the hg tree, of course). And that is definitely
the case for cx25840.
As a side note: we could decide to ditch that backwards compatibility support
in the git tree of course, but I don't know how problematic that may turn out
to be for the hg tree maintenance. Anyway, I have too much to do already :-)
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe 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] tm6000: Don't copy outside the buffer
tm6000 tm6000_irq_callback :urb resubmit failed (error=-1)
BUG: unable to handle kernel paging request at 0100f700
IP: [a007ee79] tm6000_irq_callback+0x51e/0xac7 [tm6000]
(gdb) list * tm6000_irq_callback+0x51e
0x2e79 is in tm6000_irq_callback (drivers/staging/tm6000/tm6000-video.c:363).
358 dev-isoc_ctl.tmp_buf_len--;
359 }
360 if (dev-isoc_ctl.tmp_buf_len) {
361 memcpy (header,p,
362 dev-isoc_ctl.tmp_buf_l$
363 memcpy (((u8 *)header)+
364 dev-isoc_ctl.tmp_buf,
365 ptr,
366 4-dev-isoc_ctl.tmp_buf$
367 ptr+=4-dev-isoc_ctl.tmp_buf_le$
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 3317220..487 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -358,13 +358,13 @@ static int copy_streams(u8 *data, u8 *out_p, unsigned
long len,
dev-isoc_ctl.tmp_buf_len--;
}
if (dev-isoc_ctl.tmp_buf_len) {
- memcpy (header,p,
+ memcpy(header, p,
dev-isoc_ctl.tmp_buf_len);
- memcpy (((u8 *)header)+
- dev-isoc_ctl.tmp_buf,
+ memcpy((u8 *)header +
+ dev-isoc_ctl.tmp_buf_len,
ptr,
- 4-dev-isoc_ctl.tmp_buf_len);
- ptr+=4-dev-isoc_ctl.tmp_buf_len;
+ 4 - dev-isoc_ctl.tmp_buf_len);
+ ptr += 4 - dev-isoc_ctl.tmp_buf_len;
goto HEADER;
}
}
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: av7110 crash when unloading.
Hans Verkuil wrote: On Sunday 02 May 2010 21:57:07 Oliver Endriss wrote: Hi, On Saturday 01 May 2010 21:21:38 VDR User wrote: I just grabbed the latest hg tree and got the following when I tried to unload the drivers for my nexus-s: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077154] Oops: [#1] SMP Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077156] last sysfs file: /sys/devices/virtual/vtconsole/vtcon0/uevent Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077193] Process rmmod (pid: 5099, ti=f6a54000 task=f5311490 task.ti=f6a54000) Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077300] CR2: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077296] EIP: [f98dfeaa] v4l2_device_unregister+0x14/0x4f [videodev] SS:ESP 0068:f6a55e7c Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077273] Code: 89 c3 8b 00 85 c0 74 0d 31 d2 e8 90 91 8c c7 c7 03 00 00 00 00 5b c3 57 85 c0 56 89 c6 53 74 42 e8 da ff ff ff 8b 5e 04 83 c6 04 8b 3b eb 2f 89 d8 e8 fb fe ff ff f6 43 0c 01 74 0c 8b 43 3c 85 Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077195] Stack: Message from sysl...@test at Sat May 1 12:19:23 2010 ... test kernel: [ 814.077211] Call Trace: The modules wouldn't unload and a reboot was needed to clear it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html See http://www.mail-archive.com/linux-media@vger.kernel.org/msg16895.html CU Oliver The patch to fix this is in the git fixes tree for quite some time, but since it hasn't been upstreamed yet it is still not in the v4l-dvb git or hg trees. I've asked Mauro when he is going to do that, I can't do much more. My intention is to finish merging patches and sending the pending stuff upstream tomorrow. That's said, I'll need to adopt a different procedure on -git, on order to better handle merges. With the current way, we would backport from fixes.git only with 2.6.35 stable. I'll probably opt to have some topic branches and commit work into a topic branch, only merging at master after being upstream. With relation to -hg, Douglas is the maintainer. I think he is considering to backport also from fixes.git. For the time being you can apply the diff from fixes.git: http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73 Save to e.g. fix.diff, go to the linux directory in your v4l-dvb tree and apply it. Regards, Hans -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tm6000: Prevent Kernel Oops changing channel when stream is still on.
The two patches fixed the OOPS I was having. The big problem I'm still suffering with HVR-900H is that tm6000 insists on dying: hub 1-0:1.0: port 8 disabled by hub (EMI?), re-enabling... usb 1-8: USB disconnect, address 5 tm6000 tm6000_irq_callback :urb resubmit failed (error=-19) tm6000 tm6000_irq_callback :urb resubmit failed (error=-19) tm6000 tm6000_irq_callback :urb resubmit failed (error=-19) tm6000 tm6000_irq_callback :urb resubmit failed (error=-19) tm6000 tm6000_irq_callback :urb resubmit failed (error=-19) tm6000: disconnecting tm6000 #2 xc2028 2-0061: destroying instance As the chipset stops answering USB, a new, non-fatal bug hits: [ cut here ] WARNING: at lib/list_debug.c:48 list_del+0x30/0x87() Hardware name: list_del corruption. prev-next should be 88003df65ec0, but was (null) Modules linked in: ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder ir_core tm6000(C) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_vmalloc videobuf_core autofs4 hidp rfcomm l2cap crc16 bluetooth iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 powernow_k8 dm_multipath scsi_dh sbs sbshc battery acpi_memhotplug ac lp snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device i2c_algo_bit snd_pcm_oss snd_mixer_oss sg snd_pcm nvidia(P) ide_cd_mod snd_timer serio_raw parport_pc cdrom snd button parport floppy i2c_nforce2 k8temp soundcore snd_page_alloc pcspkr shpchp hwmon forcedeth i2c_core dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod sata_nv libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: tuner_xc2028] Pid: 12402, comm: mplayer Tainted: PWC 2.6.33 #4 Call Trace: [81179c24] ? list_del+0x30/0x87 [8103a43f] ? warn_slowpath_common+0x77/0x8e [8103a4b2] ? warn_slowpath_fmt+0x51/0x59 [810c54a5] ? free_block+0xdf/0xfe [8102c9bc] ? __wake_up_sync_key+0x3a/0x56 [81179c24] ? list_del+0x30/0x87 [a015e9c8] ? videobuf_queue_cancel+0x48/0xba [videobuf_core] [a013e2b3] ? videobuf_vm_close+0x80/0x14d [videobuf_vmalloc] [810b23d1] ? remove_vma+0x2c/0x72 [810b2522] ? exit_mmap+0x10b/0x129 [8103813c] ? mmput+0x34/0xa2 [8103c077] ? exit_mm+0x109/0x114 [8103d2b0] ? do_exit+0x1de/0x66e [8103d7ad] ? do_group_exit+0x6d/0x97 [8103d7e9] ? sys_exit_group+0x12/0x16 [810028ab] ? system_call_fastpath+0x16/0x1b ---[ end trace fed27d3fe75cb89b ]--- [ cut here ] WARNING: at lib/list_debug.c:51 list_del+0x5c/0x87() Hardware name: list_del corruption. next-prev should be 88003df65bc0, but was (null) Modules linked in: ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder ir_core tm6000(C) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_vmalloc videobuf_core autofs4 hidp rfcomm l2cap crc16 bluetooth iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 powernow_k8 dm_multipath scsi_dh sbs sbshc battery acpi_memhotplug ac lp snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device i2c_algo_bit snd_pcm_oss snd_mixer_oss sg snd_pcm nvidia(P) ide_cd_mod snd_timer serio_raw parport_pc cdrom snd button parport floppy i2c_nforce2 k8temp soundcore snd_page_alloc pcspkr shpchp hwmon forcedeth i2c_core dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod sata_nv libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: tuner_xc2028] Pid: 12402, comm: mplayer Tainted: PWC 2.6.33 #4 Call Trace: [81179c50] ? list_del+0x5c/0x87 [8103a43f] ? warn_slowpath_common+0x77/0x8e [8103a4b2] ? warn_slowpath_fmt+0x51/0x59 [810c54a5] ? free_block+0xdf/0xfe [81035d58] ? __wake_up+0x30/0x44 [81179c50] ? list_del+0x5c/0x87 [a015e9c8] ? videobuf_queue_cancel+0x48/0xba [videobuf_core] [a013e2b3] ? videobuf_vm_close+0x80/0x14d [videobuf_vmalloc] [810b23d1] ? remove_vma+0x2c/0x72 [810b2522] ? exit_mmap+0x10b/0x129 [8103813c] ? mmput+0x34/0xa2 [8103c077] ? exit_mm+0x109/0x114 [8103d2b0] ? do_exit+0x1de/0x66e [8103d7ad] ? do_group_exit+0x6d/0x97 [8103d7e9] ? sys_exit_group+0x12/0x16 [810028ab] ? system_call_fastpath+0x16/0x1b ---[ end trace fed27d3fe75cb89c ]--- usbcore: deregistering interface driver tm6000 Cheers, Mauro -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ideal DVB-C PCI/e card?
Oh and to clarify I am aware of this resource http://www.linuxtv.org/wiki/index.php/DVB-C_Devices Just curious to hear peoples real world experiences. On 3/05/10 3:09 PM, Jed wrote: Hi All, I was wondering if someone could recommend a decent DVB-C tuner card? Ideally it would be a dual DVB-C card, but I'm not sure they exist?! I have a subscription to a PayTV provider here in Australia that uses an encryption scheme called NDS or Videoguard2. So I'll also need the right card reader and combo of software in order to decrypt and then capture. This stuff I can mostly work out for myself. But if you have any knowledge or experience in that area, then I'd be most appreciative if you can share. As it definitely isn't for technical minnows! Oh and in case you're worried, doing this sort of thing is not -yet- illegal in Australia. It may be soon though, thanks to the FTA our former Prime Minister established with the U.S. All the best, Jed -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ideal DVB-C PCI/e card?
Hi All, I was wondering if someone could recommend a decent DVB-C tuner card? Ideally it would be a dual DVB-C card, but I'm not sure they exist?! I have a subscription to a PayTV provider here in Australia that uses an encryption scheme called NDS or Videoguard2. So I'll also need the right card reader and combo of software in order to decrypt and then capture. This stuff I can mostly work out for myself. But if you have any knowledge or experience in that area, then I'd be most appreciative if you can share. As it definitely isn't for technical minnows! Oh and in case you're worried, doing this sort of thing is not -yet- illegal in Australia. It may be soon though, thanks to the FTA our former Prime Minister established with the U.S. All the best, Jed -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
