Re: Problem with gspca and zc3xx
On Sat, 9 Jan 2010 00:15:31 +0100 Jose Alberto Reguero jaregu...@telefonica.net wrote: When capturing with mplayer I have this erros and the bottom of the image is black. [mjpeg @ 0xd2f300]error y=29 x=0 [mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0) [snip] gspca: main v2.8.0 registered gspca: probing 046d:08dd zc3xx: Sensor MC501CB gspca: video0 created gspca: probing 046d:08dd gspca: intf != 0 gspca: probing 046d:08dd gspca: intf != 0 usbcore: registered new interface driver zc3xx zc3xx: registered Hello Jose Alberto, May you send me a raw image done by my program svv? (look in my web page below - run it by 'svv -rg' and send me the generated image.dat) Regards -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe 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: IR device at I2C address 0x7a
On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote: Hi, Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare: On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote: W dniu 06.01.2010 21:21, Jean Delvare pisze: On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? You could try loading the saa7134 driver with option card=146 and see if it helps. It works! [ 15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as /devices/pci:00/:00:1e.0/:05:00.0/input/input8 Thank you very much fo your help. Then I would suggest the following patch: * * * * * From: Jean Delvare kh...@linux-fr.org Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 Analog (card=146). However, by the time we find out, some card-specific initialization is missed. In particular, the fact that the IR is GPIO-based. Set it when we change the card type. Signed-off-by: Jean Delvare kh...@linux-fr.org Tested-by: Daro ghost-ri...@aster.pl just to note it, the ASUS TV-FM 7135 with USB remote is different to the Asus My Cinema P7134 Analog only, not only for the remote, but also for inputs, but they have the same PCI subsystem. --- linux/drivers/media/video/saa7134/saa7134-cards.c |1 + 1 file changed, 1 insertion(+) --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-12-11 09:47:47.0 +0100 +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-09 16:23:17.0 +0100 @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d printk(KERN_INFO %s: P7131 analog only, using entry of %s\n, dev-name, saa7134_boards[dev-board].name); + dev-has_remote = SAA7134_REMOTE_GPIO; } break; case SAA7134_BOARD_HAUPPAUGE_HVR1150: * * * * * Must have been broken at that time, IIRC. What must have been broken, and when? You are confusing. Only moving saa7134_input_init1(dev) to static int saa7134_hwinit2 in saa7134-core.c did help, AFAIK, but I might be wrong. I admit I don't quite get why dev-has_remove should be set early (in saa7134_board_init1) given that for one board (SAA7134_BOARD_FLYDVB_TRIO) it is set later (in saa7134_board_init2) and apparently it works OK. It would make more sense to do it at the same time for all boards IMHO, possibly in a separate function to make it clearer. I am also curious if it wouldn't be even clearer and more efficient to store the default value of has_remote in struct saa7134_board. As far as I can see, only the SAA7134_BOARD_FLYDVB_TRIO needs a run-time check. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] media: video/cx18, fix potential null dereference
Stanse found a potential null dereference in cx18_dvb_start_feed
and cx18_dvb_stop_feed. There is a check for stream being NULL,
but it is dereferenced earlier. Move the dereference after the
check.
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
drivers/media/video/cx18/cx18-dvb.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-dvb.c
b/drivers/media/video/cx18/cx18-dvb.c
index 71ad2d1..0ad5b63 100644
--- a/drivers/media/video/cx18/cx18-dvb.c
+++ b/drivers/media/video/cx18/cx18-dvb.c
@@ -213,10 +213,14 @@ static int cx18_dvb_start_feed(struct dvb_demux_feed
*feed)
{
struct dvb_demux *demux = feed-demux;
struct cx18_stream *stream = (struct cx18_stream *) demux-priv;
- struct cx18 *cx = stream-cx;
+ struct cx18 *cx;
int ret;
u32 v;
+ if (!stream)
+ return -EINVAL;
+
+ cx = stream-cx;
CX18_DEBUG_INFO(Start feed: pid = 0x%x index = %d\n,
feed-pid, feed-index);
@@ -253,9 +257,6 @@ static int cx18_dvb_start_feed(struct dvb_demux_feed *feed)
if (!demux-dmx.frontend)
return -EINVAL;
- if (!stream)
- return -EINVAL;
-
mutex_lock(stream-dvb.feedlock);
if (stream-dvb.feeding++ == 0) {
CX18_DEBUG_INFO(Starting Transport DMA\n);
@@ -279,13 +280,14 @@ static int cx18_dvb_stop_feed(struct dvb_demux_feed *feed)
{
struct dvb_demux *demux = feed-demux;
struct cx18_stream *stream = (struct cx18_stream *)demux-priv;
- struct cx18 *cx = stream-cx;
+ struct cx18 *cx;
int ret = -EINVAL;
- CX18_DEBUG_INFO(Stop feed: pid = 0x%x index = %d\n,
- feed-pid, feed-index);
-
if (stream) {
+ cx = stream-cx;
+ CX18_DEBUG_INFO(Stop feed: pid = 0x%x index = %d\n,
+ feed-pid, feed-index);
+
mutex_lock(stream-dvb.feedlock);
if (--stream-dvb.feeding == 0) {
CX18_DEBUG_INFO(Stopping Transport DMA\n);
--
1.6.5.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] MAINTAINERS: ivtv-devel is moderated
Mark ivtv-de...@ivtvdriver.org as 'moderated for non-subscribers'. Signed-off-by: Jiri Slaby jsl...@suse.cz Cc: linux-media@vger.kernel.org --- MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d4baf3d..6f088ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1649,7 +1649,7 @@ F:sound/pci/cs5535audio/ CX18 VIDEO4LINUX DRIVER M: Hans Verkuil hverk...@xs4all.nl M: Andy Walls awa...@radix.net -L: ivtv-de...@ivtvdriver.org +L: ivtv-de...@ivtvdriver.org (moderated for non-subscribers) L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git W: http://linuxtv.org @@ -3037,7 +3037,7 @@ F:drivers/isdn/hardware/eicon/ IVTV VIDEO4LINUX DRIVER M: Hans Verkuil hverk...@xs4all.nl -L: ivtv-de...@ivtvdriver.org +L: ivtv-de...@ivtvdriver.org (moderated for non-subscribers) L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git W: http://www.ivtvdriver.org -- 1.6.5.7 -- To unsubscribe from this list: send the line unsubscribe 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 with gspca and zc3xx
El Domingo, 10 de Enero de 2010, Jean-Francois Moine escribió: On Sat, 9 Jan 2010 00:15:31 +0100 Jose Alberto Reguero jaregu...@telefonica.net wrote: When capturing with mplayer I have this erros and the bottom of the image is black. [mjpeg @ 0xd2f300]error y=29 x=0 [mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0) [snip] gspca: main v2.8.0 registered gspca: probing 046d:08dd zc3xx: Sensor MC501CB gspca: video0 created gspca: probing 046d:08dd gspca: intf != 0 gspca: probing 046d:08dd gspca: intf != 0 usbcore: registered new interface driver zc3xx zc3xx: registered Hello Jose Alberto, May you send me a raw image done by my program svv? (look in my web page below - run it by 'svv -rg' and send me the generated image.dat) Regards Jose Alberto attachment: image.dat
Re: [PULL] soc-camera and mediabus
Guennadi Liakhovetski wrote:
Hi Mauro
On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:
Guennadi Liakhovetski wrote:
So, is the doc patch, that I've sent to the list ok? Ok, the hunk for the
automatically (in hg) generated file will get dropped, and otherwise does
it look correct?
It looks correctly on my eyes. The only thing I noticed is that you've added
emacs headers at the end of the new patches:
+
+ !--
+Local Variables:
+mode: sgml
+sgml-parent-document: pixfmt.sgml
+indent-tabs-mode: nil
+End:
+ --
Please remove those tags when submitting the final version.
I tried to just through away the media-specs/media-entities.tmpl hunk, as
that file should be auto-generated, but the new version doesn't include
the new formats either. What am I doing wrong? The patch attached below.
As you're adding new files, you need to tell Makefile to take a look on them
also. So, just add the new files to V4L_SGMLS list at Makefile should do
the job.
Cheers,
Mauro.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
# HG changeset patch
# User Guennadi Liakhovetski g.liakhovet...@gmx.de
# Date 1261648434 -3600
# Node ID 52e14d4799279a860fe158e8bf4f1993d6c6
# Parent 4506e2d541265bfa0c0fd5187c6a39d39a456559
document new pixel formats
Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
8-bit Bayer formats.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
diff -r 4506e2d54126 -r 52e14d479927
linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml Thu Dec 24
10:53:54 2009 +0100
@@ -0,0 +1,90 @@
+refentry
+ refmeta
+ refentrytitleV4L2_PIX_FMT_SRGGB10 ('RG10'),
+ V4L2_PIX_FMT_SGRBG10 ('BA10'),
+ V4L2_PIX_FMT_SGBRG10 ('GB10'),
+ V4L2_PIX_FMT_SBGGR10 ('BG10'),
+ /refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname
id=V4L2-PIX-FMT-SRGGB10constantV4L2_PIX_FMT_SRGGB10/constant/refname
+ refname
id=V4L2-PIX-FMT-SGRBG10constantV4L2_PIX_FMT_SGRBG10/constant/refname
+ refname
id=V4L2-PIX-FMT-SGBRG10constantV4L2_PIX_FMT_SGBRG10/constant/refname
+ refname
id=V4L2-PIX-FMT-SBGGR10constantV4L2_PIX_FMT_SBGGR10/constant/refname
+ refpurpose10-bit Bayer formats expanded to 16 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThe following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green
samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats/para
+
+example
+ titleconstantV4L2_PIX_FMT_SBGGR10/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte, high 6 bits in high bytes are 0.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryBsubscript00low/subscript/entry
+ entryBsubscript00high/subscript/entry
+ entryGsubscript01low/subscript/entry
+ entryGsubscript01high/subscript/entry
+ entryBsubscript02low/subscript/entry
+ entryBsubscript02high/subscript/entry
+ entryGsubscript03low/subscript/entry
+ entryGsubscript03high/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryGsubscript10low/subscript/entry
+ entryGsubscript10high/subscript/entry
+ entryRsubscript11low/subscript/entry
+ entryRsubscript11high/subscript/entry
+ entryGsubscript12low/subscript/entry
+ entryGsubscript12high/subscript/entry
+ entryRsubscript13low/subscript/entry
+ entryRsubscript13high/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;16:/entry
+ entryBsubscript20low/subscript/entry
+ entryBsubscript20high/subscript/entry
+ entryGsubscript21low/subscript/entry
+ entryGsubscript21high/subscript/entry
+ entryBsubscript22low/subscript/entry
+ entryBsubscript22high/subscript/entry
+ entryGsubscript23low/subscript/entry
+ entryGsubscript23high/subscript/entry
+ /row
+ row
+
Re: pull request: http://linuxtv.org/hg/~hgoede/gspca
Hans de Goede wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For: 1) A high priority (should go to 2.6.33) mr97310a driver fix 2) A new driver for streaming from sn9c2028 cams 3) Some gspca documentation updates Hmm... your tree has 10 patches instead of 3.: /tmp/newpatches/hg_gspca_01.patch with cs=47d5a57b0183 First patch. /tmp/newpatches/hg_gspca_02.patch with cs=04eee693d37b Ok. /tmp/newpatches/hg_gspca_03.patch with cs=c7f961161530 Ok. /tmp/newpatches/hg_gspca_04.patch with cs=da3d3538b4c4 Ok. /tmp/newpatches/hg_gspca_05.patch with cs=98cecfa3c4f1 Ok. /tmp/newpatches/hg_gspca_06.patch with cs=bfe405de18aa Ok. /tmp/newpatches/hg_gspca_07.patch with cs=325c97ecffd2 Ok. /tmp/newpatches/hg_gspca_08.patch with cs=2e531e32ca6f Ok. /tmp/newpatches/hg_gspca_09.patch with cs=3563e7b617fe Ok. /tmp/newpatches/hg_gspca_10.patch with cs=21d70b6ed9f6 Ok. As I'm not sure if all of them are ready for merging, the better is to wait for a new pull request. Next time, please avoid add newer patches on a tree you've asked me to pull, or reply your pull email warning me that you've added more patches on your tree. 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 2/2] gspca pac7302: add support for camera button
Németh Márton wrote: From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200 (USB ID 093a:2626 This patch breaks compilation against current -tip: /home/v4l/master/v4l/pac7302.c:74:19: error: input.h: No such file or directory /home/v4l/master/v4l/pac7302.c: In function 'sd_int_pkt_scan': /home/v4l/master/v4l/pac7302.c:1255: error: 'struct gspca_dev' has no member named 'input_dev' /home/v4l/master/v4l/pac7302.c:1256: error: 'struct gspca_dev' has no member named 'input_dev' /home/v4l/master/v4l/pac7302.c:1257: error: 'struct gspca_dev' has no member named 'input_dev' /home/v4l/master/v4l/pac7302.c:1258: error: 'struct gspca_dev' has no member named 'input_dev' /home/v4l/master/v4l/pac7302.c: At top level: /home/v4l/master/v4l/pac7302.c:1284: error: unknown field 'int_pkt_scan' specified in initializer /home/v4l/master/v4l/pac7302.c:1284: warning: excess elements in struct initializer /home/v4l/master/v4l/pac7302.c:1284: warning: (near initialization for 'sd_desc') make[3]: *** [/home/v4l/master/v4l/pac7302.o] Error 1 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 2/2] gspca pac7302: add support for camera button
Mauro Carvalho Chehab worte: Németh Márton wrote: From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200 (USB ID 093a:2626 This patch breaks compilation against current -tip: There was several versions of adding support to pac7302. The last version still have some problems which I haven't addressed, yet. So the camera button support for pac7302 is not yet ready for inclusion. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This includes the codingstyle fixes Mauro reported as well as the changes Takashi Iwai suggested for the ALSA config and buffer handling. Hi Devin, Unfortunately, I got some merge conflicts with cx18 code from Andy, due to the buffer handling changes. Could you please rebase your tree against tip, solving those conflicts? 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 2/2] gspca pac7302: add support for camera button
Németh Márton wrote: Mauro Carvalho Chehab worte: Németh Márton wrote: From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200 (USB ID 093a:2626 This patch breaks compilation against current -tip: There was several versions of adding support to pac7302. The last version still have some problems which I haven't addressed, yet. So the camera button support for pac7302 is not yet ready for inclusion. Ok. While you don't have a final version, please add an RFC at the patch, for me to know, when dealing with patchwork queue, that the patch is not ok yet. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gspca pac7302: add support for camera button
Mauro Carvalho Chehab írta: Németh Márton wrote: Mauro Carvalho Chehab worte: Németh Márton wrote: From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200 (USB ID 093a:2626 This patch breaks compilation against current -tip: There was several versions of adding support to pac7302. The last version still have some problems which I haven't addressed, yet. So the camera button support for pac7302 is not yet ready for inclusion. Ok. While you don't have a final version, please add an RFC at the patch, for me to know, when dealing with patchwork queue, that the patch is not ok yet. I thought every time it was the final version ;-), but I get some comments which may make the code quality and acceptance better. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL http://jusst.de/hg/stv090x
Hi Mauro,
Am 10.01.2010 13:52, schrieb Mauro Carvalho Chehab:
Manu Abraham wrote:
Mauro,
Please pull http://jusst.de/hg/stv090x changesets: from 13880 - 13891
inclusive of both.
The third changeset has some locking troubles:
# Node ID 4dd17a6a5ecc320eab58590a8567e5ba03b9d53a
[STV090x] Added mutex protection around tuner I2C access.
After the patch, the code will look like:
static int stv090x_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
if (enable)
mutex_lock(state-internal-tuner_lock);
reg = STV090x_READ_DEMOD(state, I2CRPT);
if (enable) {
dprintk(FE_DEBUG, 1, Enable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 1);
if (STV090x_WRITE_DEMOD(state, I2CRPT, reg) 0)
goto err;
} else {
dprintk(FE_DEBUG, 1, Disable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 0);
if ((STV090x_WRITE_DEMOD(state, I2CRPT, reg)) 0)
goto err;
}
if (!enable)
mutex_unlock(state-internal-tuner_lock);
return 0;
err:
dprintk(FE_ERROR, 1, I/O error);
mutex_unlock(state-internal-tuner_lock);
return -1;
}
As the err: is called on both enable and disable conditions, the error
code will try to unlock an already unlocked mutex, if !enable.
Also, it doesn't make sense to lock only if the gate is enabled,
since it seems that the lock is meant to protect the i2c gate bus and
both conditions will call STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, enable ? 1 :
0);
The better would be simply to remove the if (enable)/if (!enable) tests
on the above code.
The lock shall protect the access to the tuners and not to the registers
itself, so it is locked when enable is set and unlocked when enable isn't.
The code between a call to stv090x_i2c_gate_ctrl(..., 1)
and stv090x_i2c_gate_ctrl(..., 0) shall be exclusive in case both tuners
have the same I2C address.
Regards,
Andreas
--
To unsubscribe from this list: send the line unsubscribe 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: CI USB
Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. Also some card (at least for DVB-S) are really good but targeted towards free channels, and in France for example, alot of good channels are not. If the price is right (tm) I am sure a lot of people would be interested. Bye Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL http://jusst.de/hg/stv090x
Mauro,
On Sun, Jan 10, 2010 at 4:52 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Manu Abraham wrote:
Mauro,
Please pull http://jusst.de/hg/stv090x changesets: from 13880 - 13891
inclusive of both.
The third changeset has some locking troubles:
# Node ID 4dd17a6a5ecc320eab58590a8567e5ba03b9d53a
[STV090x] Added mutex protection around tuner I2C access.
After the patch, the code will look like:
static int stv090x_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
if (enable)
mutex_lock(state-internal-tuner_lock);
reg = STV090x_READ_DEMOD(state, I2CRPT);
if (enable) {
dprintk(FE_DEBUG, 1, Enable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 1);
if (STV090x_WRITE_DEMOD(state, I2CRPT, reg) 0)
goto err;
} else {
dprintk(FE_DEBUG, 1, Disable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 0);
if ((STV090x_WRITE_DEMOD(state, I2CRPT, reg)) 0)
goto err;
}
if (!enable)
mutex_unlock(state-internal-tuner_lock);
return 0;
err:
dprintk(FE_ERROR, 1, I/O error);
mutex_unlock(state-internal-tuner_lock);
return -1;
}
As the err: is called on both enable and disable conditions, the error
code will try to unlock an already unlocked mutex, if !enable.
Also, it doesn't make sense to lock only if the gate is enabled,
since it seems that the lock is meant to protect the i2c gate bus and
both conditions will call STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, enable ? 1
: 0);
The better would be simply to remove the if (enable)/if (!enable) tests
on the above code.
It looks okay to my eyes. Any other pitfalls in the tuner operations
can you think of ?
Oliver,
any thoughts that comes to your mind on this one ?
Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] MAINTAINERS: ivtv-devel is moderated
On Sun, 2010-01-10 at 10:03 +0100, Jiri Slaby wrote: Mark ivtv-de...@ivtvdriver.org as 'moderated for non-subscribers'. Yes, that is true. I don't know why it matters after years of not being marked as such, especially since the moderator will push through on-topic posts. I don't know the implications that such an annotation will have on scripts that try to parse MAINTAINERS for e-mail addresses. But anyway: Acked-by: Andy Walls awa...@radix.net Signed-off-by: Jiri Slaby jsl...@suse.cz Cc: linux-media@vger.kernel.org --- MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d4baf3d..6f088ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1649,7 +1649,7 @@ F: sound/pci/cs5535audio/ CX18 VIDEO4LINUX DRIVER M: Hans Verkuil hverk...@xs4all.nl M: Andy Walls awa...@radix.net -L: ivtv-de...@ivtvdriver.org +L: ivtv-de...@ivtvdriver.org (moderated for non-subscribers) L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git W: http://linuxtv.org @@ -3037,7 +3037,7 @@ F: drivers/isdn/hardware/eicon/ IVTV VIDEO4LINUX DRIVER M: Hans Verkuil hverk...@xs4all.nl -L: ivtv-de...@ivtvdriver.org +L: ivtv-de...@ivtvdriver.org (moderated for non-subscribers) L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git W: http://www.ivtvdriver.org -- To unsubscribe from this list: send the line unsubscribe 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: CI USB
On Sun, Jan 10, 2010 at 5:09 PM, Emmanuel eall...@gmail.com wrote: Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But then you would be better of buying multiple CAM's for a home use purpose. Also some card (at least for DVB-S) are really good but targeted towards free channels, and in France for example, alot of good channels are not. If the price is right (tm) I am sure a lot of people would be interested. Bye Manu Regards, Mmanu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-misc
On Sun, 2010-01-10 at 09:35 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
Mauro,
If no one has any objections, please pull from
http://linuxtv.org/hg/~awalls/v4l-dvb-misc
for the following 12 changesets.
Of note:
02-04 are from Jean Delvare and fix up the cx23885 i2c routines
05-17 and 12 add and use a new v4l2_subdev core op for configuring I/O pin
muxes
08-10 are some minor cx23885 ir fixes noted when trying to get the TeVii
S470 working
10/12: cx23885: Convert from struct card_ir to struct cx23885_ir_input for
IR Rx
http://linuxtv.org/hg/~awalls/v4l-dvb-misc?cmd=changeset;node=aa62944baa92
Hmm... This doesn't sound right:
+struct cx23885_ir_input {
+ struct input_dev*dev;
+ struct ir_input_state ir;
+ charname[48];
+ charphys[48];
+
+ /* Cooked code processing */
+ int start; /* Allowed start symbols */
+ u32 addr;/* Expected remote address */
+ u32 last_code; /* last good cooked code seen */
+ int key_timeout; /* ms until we force a key up */
+ struct timer_list timer_keyup; /* timer for key release */
+
+ /* Raw code collection and construction */
+ int active; /* building code */
+ int last_bit; /* last bit seen */
+ u32 code; /* code under construction */
+};
Why are you creating a name[] and phys[] chars here? It should be using the
names already
defined at struct input_dev.
Well two reasons:
1. That's what the previous, common card ir struct did. (Not a good
reason of course.) When I needed to reimplement specific fields (in
anticipation of NEC decoding for the TeVii S470) I just carried them
over.
2. The strings in the old card ir struct were too short: the card names
in cx23885-cards.c are pretty long and would get truncated.
I'll reexamine if the strings in input_dev are long enough to do the
job, and get back to you.
Regards,
Andy
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: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-misc
Andy Walls wrote:
On Sun, 2010-01-10 at 09:35 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
Mauro,
If no one has any objections, please pull from
http://linuxtv.org/hg/~awalls/v4l-dvb-misc
for the following 12 changesets.
Of note:
02-04 are from Jean Delvare and fix up the cx23885 i2c routines
05-17 and 12 add and use a new v4l2_subdev core op for configuring I/O pin
muxes
08-10 are some minor cx23885 ir fixes noted when trying to get the TeVii
S470 working
10/12: cx23885: Convert from struct card_ir to struct cx23885_ir_input for
IR Rx
http://linuxtv.org/hg/~awalls/v4l-dvb-misc?cmd=changeset;node=aa62944baa92
Hmm... This doesn't sound right:
+struct cx23885_ir_input {
+ struct input_dev*dev;
+ struct ir_input_state ir;
+ charname[48];
+ charphys[48];
+
+ /* Cooked code processing */
+ int start; /* Allowed start symbols */
+ u32 addr;/* Expected remote address */
+ u32 last_code; /* last good cooked code seen */
+ int key_timeout; /* ms until we force a key up */
+ struct timer_list timer_keyup; /* timer for key release */
+
+ /* Raw code collection and construction */
+ int active; /* building code */
+ int last_bit; /* last bit seen */
+ u32 code; /* code under construction */
+};
Why are you creating a name[] and phys[] chars here? It should be using the
names already
defined at struct input_dev.
Well two reasons:
1. That's what the previous, common card ir struct did. (Not a good
reason of course.) When I needed to reimplement specific fields (in
anticipation of NEC decoding for the TeVii S470) I just carried them
over.
2. The strings in the old card ir struct were too short: the card names
in cx23885-cards.c are pretty long and would get truncated.
I'll reexamine if the strings in input_dev are long enough to do the
job, and get back to you.
The better is to rely on input_dev stuff, since they can easily be used by
ir-core
sysfs to provide device naming for loading keytables from userspace during udev
handling.
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: building v4l-dvb - compilation error
Mauro, I ran the build using my ubunto linux box at home and it has succeeded the build. make[2]: Leaving directory `/usr/src/kernels/2.6.9-55.0.12.EL-smp-i686' The minimum supported version by the backport is 2.6.16. Hmm. Does that means, the build is using the kernel source code natively available at /usr/src/kernel. Is there a way to force it use a specific kernel source code? -- Murali Karicheri mkarich...@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: PULL http://jusst.de/hg/stv090x
Andreas Regel wrote:
Hi Mauro,
Am 10.01.2010 13:52, schrieb Mauro Carvalho Chehab:
Manu Abraham wrote:
Mauro,
Please pull http://jusst.de/hg/stv090x changesets: from 13880 - 13891
inclusive of both.
The third changeset has some locking troubles:
# Node ID 4dd17a6a5ecc320eab58590a8567e5ba03b9d53a
[STV090x] Added mutex protection around tuner I2C access.
After the patch, the code will look like:
static int stv090x_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
if (enable)
mutex_lock(state-internal-tuner_lock);
reg = STV090x_READ_DEMOD(state, I2CRPT);
if (enable) {
dprintk(FE_DEBUG, 1, Enable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 1);
if (STV090x_WRITE_DEMOD(state, I2CRPT, reg) 0)
goto err;
} else {
dprintk(FE_DEBUG, 1, Disable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 0);
if ((STV090x_WRITE_DEMOD(state, I2CRPT, reg)) 0)
goto err;
}
if (!enable)
mutex_unlock(state-internal-tuner_lock);
return 0;
err:
dprintk(FE_ERROR, 1, I/O error);
mutex_unlock(state-internal-tuner_lock);
return -1;
}
As the err: is called on both enable and disable conditions, the error
code will try to unlock an already unlocked mutex, if !enable.
Also, it doesn't make sense to lock only if the gate is enabled,
since it seems that the lock is meant to protect the i2c gate bus and
both conditions will call STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD,
enable ? 1 : 0);
The better would be simply to remove the if (enable)/if (!enable) tests
on the above code.
The lock shall protect the access to the tuners and not to the registers
itself, so it is locked when enable is set and unlocked when enable isn't
Ok.
The code between a call to stv090x_i2c_gate_ctrl(..., 1)
and stv090x_i2c_gate_ctrl(..., 0) shall be exclusive in case both tuners
have the same I2C address.
By just looking at the i2c_gate_ctrl, it is not clear how do you expect that
the locking will work. You should add a comment better explaining it.
Also, as I pointed, if STV090x_WRITE_DEMOD fails, the unlock code will be called
even if the gate is not enabled.
As the lock should be used only if gate is enabled, it would be cleaner if you
code the routine as:
static int stv090x_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
int rc = -EINVAL;
if (enable) {
/*
* (please better explain the lock - something like:
* Tuner access should be locked to avoid
* concurrent access when reading/writing to I2CRPT,
* since those calls do tuner access)
*/
mutex_lock(state-internal-tuner_lock);
reg = STV090x_READ_DEMOD(state, I2CRPT);
dprintk(FE_DEBUG, 1, Enable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 1);
rc = STV090x_WRITE_DEMOD(state, I2CRPT, reg)
mutex_unlock(state-internal-tuner_lock);
if (rc 0)
goto err;
} else {
dprintk(FE_DEBUG, 1, Disable Gate);
reg = STV090x_READ_DEMOD(state, I2CRPT);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 0);
rc = STV090x_WRITE_DEMOD(state, I2CRPT, reg);
if (rc 0)
goto err;
}
return 0;
err:
dprintk(FE_ERROR, 1, I/O error);
return -rc;
}
This way, you avoid the risks of having lock troubles.
A side effect of the above code is that the routine will properly
propagate the error code produced at STV090x_WRITE_DEMOD(), instead
of returning -1. We should really avoid using -1 for errors, using, instead
an error code that it is defined on errors.h headers.
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: PULL http://jusst.de/hg/stv090x
Hi Mauro,
Am 10.01.2010 15:15, schrieb Mauro Carvalho Chehab:
Andreas Regel wrote:
Hi Mauro,
Am 10.01.2010 13:52, schrieb Mauro Carvalho Chehab:
Manu Abraham wrote:
Mauro,
Please pull http://jusst.de/hg/stv090x changesets: from 13880 - 13891
inclusive of both.
The third changeset has some locking troubles:
# Node ID 4dd17a6a5ecc320eab58590a8567e5ba03b9d53a
[STV090x] Added mutex protection around tuner I2C access.
After the patch, the code will look like:
static int stv090x_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
if (enable)
mutex_lock(state-internal-tuner_lock);
reg = STV090x_READ_DEMOD(state, I2CRPT);
if (enable) {
dprintk(FE_DEBUG, 1, Enable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 1);
if (STV090x_WRITE_DEMOD(state, I2CRPT, reg) 0)
goto err;
} else {
dprintk(FE_DEBUG, 1, Disable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 0);
if ((STV090x_WRITE_DEMOD(state, I2CRPT, reg)) 0)
goto err;
}
if (!enable)
mutex_unlock(state-internal-tuner_lock);
return 0;
err:
dprintk(FE_ERROR, 1, I/O error);
mutex_unlock(state-internal-tuner_lock);
return -1;
}
As the err: is called on both enable and disable conditions, the error
code will try to unlock an already unlocked mutex, if !enable.
Also, it doesn't make sense to lock only if the gate is enabled,
since it seems that the lock is meant to protect the i2c gate bus and
both conditions will call STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD,
enable ? 1 : 0);
The better would be simply to remove the if (enable)/if (!enable) tests
on the above code.
The lock shall protect the access to the tuners and not to the registers
itself, so it is locked when enable is set and unlocked when enable isn't
Ok.
The code between a call to stv090x_i2c_gate_ctrl(..., 1)
and stv090x_i2c_gate_ctrl(..., 0) shall be exclusive in case both tuners
have the same I2C address.
By just looking at the i2c_gate_ctrl, it is not clear how do you expect that
the locking will work. You should add a comment better explaining it.
Also, as I pointed, if STV090x_WRITE_DEMOD fails, the unlock code will be called
even if the gate is not enabled.
you don't have to look at stv090x_i2c_gate_ctrl alone. stv090x driver
contains code like this:
if (stv090x_i2c_gate_ctrl(fe, 1) 0)
goto err;
tuner access
if (stv090x_i2c_gate_ctrl(fe, 0) 0)
goto err;
Intention of the patch is to make the tuner access exclusive. Thats the
reason why the mutex is locked when gate is opened and unlocked when the
gate is closed.
In case the opening fails the close call is not made und thus mutex is
not unlocked twice.
There one problem pending with: when there is an error during tuner
access the gate will not be closed and thus the mutex will not be
unlocked. For this case a patch from Oliver Endriss is attached.
Regards,
Andreas
# HG changeset patch
# User Oliver Endriss o.endr...@gmx.de
# Date 1263097942 -3600
# Node ID fefb0eb3c442f8ab1e446c6f275c914a99495312
# Parent b1e950fefc1ac04f3ef67d274d6a72859afd734f
stv090x: Disable I2C gate on error
From: Oliver Endriss o.endr...@gmx.de
The I2C gate must also be disabled, if a tuner command failed.
Otherwise the tuner mutex would be locked forever.
Priority: normal
Signed-off-by: Oliver Endriss o.endr...@gmx.de
diff -r b1e950fefc1a -r fefb0eb3c442 linux/drivers/media/dvb/frontends/stv090x.c
--- a/linux/drivers/media/dvb/frontends/stv090x.c Wed Jan 06 02:24:56
2010 +0400
+++ b/linux/drivers/media/dvb/frontends/stv090x.c Sun Jan 10 05:32:22
2010 +0100
@@ -2514,12 +2514,12 @@ static u32 stv090x_srate_srch_coarse(str
if (state-config-tuner_set_frequency) {
if (state-config-tuner_set_frequency(fe,
freq) 0)
- goto err;
+ goto err_gateoff;
}
if (state-config-tuner_set_bandwidth) {
if (state-config-tuner_set_bandwidth(fe,
state-tuner_bw) 0)
- goto err;
+ goto err_gateoff;
}
if (stv090x_i2c_gate_ctrl(fe, 0) 0)
@@ -2532,7 +2532,7 @@ static u32 stv090x_srate_srch_coarse(str
if (state-config-tuner_get_status) {
if (state-config-tuner_get_status(fe, reg)
0)
- goto err;
+ goto err_gateoff;
}
Re: PULL http://jusst.de/hg/stv090x
On Sun, Jan 10, 2010 at 6:43 PM, Andreas Regel andreas.re...@gmx.de wrote:
Hi Mauro,
Am 10.01.2010 15:15, schrieb Mauro Carvalho Chehab:
Andreas Regel wrote:
Hi Mauro,
Am 10.01.2010 13:52, schrieb Mauro Carvalho Chehab:
Manu Abraham wrote:
Mauro,
Please pull http://jusst.de/hg/stv090x changesets: from 13880 - 13891
inclusive of both.
The third changeset has some locking troubles:
# Node ID 4dd17a6a5ecc320eab58590a8567e5ba03b9d53a
[STV090x] Added mutex protection around tuner I2C access.
After the patch, the code will look like:
static int stv090x_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
if (enable)
mutex_lock(state-internal-tuner_lock);
reg = STV090x_READ_DEMOD(state, I2CRPT);
if (enable) {
dprintk(FE_DEBUG, 1, Enable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 1);
if (STV090x_WRITE_DEMOD(state, I2CRPT, reg) 0)
goto err;
} else {
dprintk(FE_DEBUG, 1, Disable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 0);
if ((STV090x_WRITE_DEMOD(state, I2CRPT, reg)) 0)
goto err;
}
if (!enable)
mutex_unlock(state-internal-tuner_lock);
return 0;
err:
dprintk(FE_ERROR, 1, I/O error);
mutex_unlock(state-internal-tuner_lock);
return -1;
}
As the err: is called on both enable and disable conditions, the error
code will try to unlock an already unlocked mutex, if !enable.
Also, it doesn't make sense to lock only if the gate is enabled,
since it seems that the lock is meant to protect the i2c gate bus and
both conditions will call STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD,
enable ? 1 : 0);
The better would be simply to remove the if (enable)/if (!enable) tests
on the above code.
The lock shall protect the access to the tuners and not to the registers
itself, so it is locked when enable is set and unlocked when enable isn't
Ok.
The code between a call to stv090x_i2c_gate_ctrl(..., 1)
and stv090x_i2c_gate_ctrl(..., 0) shall be exclusive in case both tuners
have the same I2C address.
By just looking at the i2c_gate_ctrl, it is not clear how do you expect
that
the locking will work. You should add a comment better explaining it.
Also, as I pointed, if STV090x_WRITE_DEMOD fails, the unlock code will be
called
even if the gate is not enabled.
you don't have to look at stv090x_i2c_gate_ctrl alone. stv090x driver
contains code like this:
if (stv090x_i2c_gate_ctrl(fe, 1) 0)
goto err;
tuner access
if (stv090x_i2c_gate_ctrl(fe, 0) 0)
goto err;
Intention of the patch is to make the tuner access exclusive. Thats the
reason why the mutex is locked when gate is opened and unlocked when the
gate is closed.
In case the opening fails the close call is not made und thus mutex is not
unlocked twice.
There one problem pending with: when there is an error during tuner access
the gate will not be closed and thus the mutex will not be unlocked. For
this case a patch from Oliver Endriss is attached.
Mauro, Andreas,
Ok, I will queue up the other patch as well and issue another pull request.
Mauro,
Ignore the pull request for the moment.
Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe 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 v4l/dvb] firedtv: add forgotten __exit annotation
Stefan Richter wrote on 2009-12-26:
fdtv_fw_exit() is part of the firedtv driver's .exit.text section.
...
--- linux-2.6.33-rc2.orig/drivers/media/dvb/firewire/firedtv-fw.c
+++ linux-2.6.33-rc2/drivers/media/dvb/firewire/firedtv-fw.c
@@ -332,7 +332,7 @@ int __init fdtv_fw_init(void)
return driver_register(fdtv_driver.driver);
}
-void fdtv_fw_exit(void)
+void __exit fdtv_fw_exit(void)
{
driver_unregister(fdtv_driver.driver);
fw_core_remove_address_handler(fcp_handler);
This patch is bogus. fdtv_fw_exit() is also called from firedtv's init.
--
Stefan Richter
-=-==-=- ---= -=-=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL http://jusst.de/hg/stv090x
Hi,
Manu Abraham wrote:
On Sun, Jan 10, 2010 at 4:52 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Manu Abraham wrote:
Mauro,
Please pull http://jusst.de/hg/stv090x changesets: from 13880 - 13891
inclusive of both.
The third changeset has some locking troubles:
# Node ID 4dd17a6a5ecc320eab58590a8567e5ba03b9d53a
[STV090x] Added mutex protection around tuner I2C access.
After the patch, the code will look like:
static int stv090x_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct stv090x_state *state = fe-demodulator_priv;
u32 reg;
if (enable)
mutex_lock(state-internal-tuner_lock);
reg = STV090x_READ_DEMOD(state, I2CRPT);
if (enable) {
dprintk(FE_DEBUG, 1, Enable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 1);
if (STV090x_WRITE_DEMOD(state, I2CRPT, reg) 0)
goto err;
} else {
dprintk(FE_DEBUG, 1, Disable Gate);
STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, 0);
if ((STV090x_WRITE_DEMOD(state, I2CRPT, reg)) 0)
goto err;
}
if (!enable)
mutex_unlock(state-internal-tuner_lock);
return 0;
err:
dprintk(FE_ERROR, 1, I/O error);
mutex_unlock(state-internal-tuner_lock);
return -1;
}
As the err: is called on both enable and disable conditions, the error
code will try to unlock an already unlocked mutex, if !enable.
Nak. stv090x_i2c_gate_ctrl will only be called with enable==false,
if it has previously been called successfully with enable==true.
Also, it doesn't make sense to lock only if the gate is enabled,
since it seems that the lock is meant to protect the i2c gate bus and
both conditions will call STV090x_SETFIELD_Px(reg, I2CT_ON_FIELD, enable ?
1 : 0);
The better would be simply to remove the if (enable)/if (!enable) tests
on the above code.
It looks okay to my eyes. Any other pitfalls in the tuner operations
can you think of ?
Oliver,
any thoughts that comes to your mind on this one ?
The purpuse of tuner_lock is to allow for 2 tuners with equal I2C
address on one I2C bus. Each one is behind its own I2C gate.
The code is a bit tricky. Lets analyse what may happen:
1. no error, enable==true:
lock mutex - return 0
- ok
2. no error, enable==false:
unlock mutex (which has been locked by a previous call), return 0
- ok
3. error on enable:
mutex lock, mutex unlock, return -1
- ok
4. error on disable:
unlock mutex (which has been locked by a previous call), return -1
- ok
The code looks ok to me.
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: CI USB
I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. /Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gspca_sunplus problem: more than one device is created
Hi, I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [31636.528184] usb 3-2: new full speed USB device using uhci_hcd and address 5 [31636.740722] usb 3-2: New USB device found, idVendor=06d6, idProduct=0031 [31636.740744] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [31636.740760] usb 3-2: Product: Trust 610 LCD pow...@m ZOOM [31636.740772] usb 3-2: Manufacturer: Trust [31636.744229] usb 3-2: configuration #1 chosen from 1 choice [31636.747584] gspca: probing 06d6:0031 [31636.760176] gspca: video0 created [31636.760643] gspca: probing 06d6:0031 [31636.772063] gspca: video1 created The /dev/video0 is working correctly but the /dev/video1 just causes error: $ ./svv -d /dev/video1 raw pixfmt: JPEG 464x480 pixfmt: RGB3 464x480 mmap method VIDIOC_STREAMON error 5, Input/output error Here is the USB descriptor of the device: Trust 610 LCD pow...@m ZOOM Manufacturer: Trust Speed: 12Mb/s (full) USB Version: 1.00 Device Class: 00(ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 8 Number of Configurations: 1 Vendor Id: 06d6 Product Id: 0031 Revision Number: 1.00 Config Number: 1 Number of Interfaces: 2 Attributes: 80 MaxPower Needed: 500mA Interface Number: 0 Name: sunplus Alternate Number: 0 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 0 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 1 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 128 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 2 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 384 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 3 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 512 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 4 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 640 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 5 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 768 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 6 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 896 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 7 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81
gspca_pac7302: sporatdic problem when plugging the device
Hi, I have sporadic problem with Labtec Webcam 2200 (0x093a:0x2626). I'm using gspca_pac7302 driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. I executed the following command in an xterm window: $ while true; do ./svv; done Then I plugged and unplugged the device 16 times. When I last plugged the device I get the following error in the dmesg: [32393.421313] gspca: probing 093a:2626 [32393.426193] gspca: video0 created [32393.426958] gspca: probing 093a:2626 [32393.426968] gspca: Interface class 1 not handled here [32394.005917] pac7302: reg_w_page(): Failed to write register to index 0x49, value 0x0, error -71 [32394.067799] gspca: set alt 8 err -71 [32394.090792] gspca: set alt 8 err -71 [32394.118159] gspca: set alt 8 err -71 The 17th plug was working correctly again. I executed this test on an EeePC 901. This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. I don't know what is the real problem, but I am afraid that slowing down reg_w_page() would make the time longer when the device can be used starting from the event when it is plugged. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe 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: gspca_sunplus problem: more than one device is created
Did that happen with the included version on the kernel?. The kernel is calling the probe for the isoch and the bulk, i really dont have a sunplus webcam to test, and ignore the older behavior, that's why i am asking. Best Regards 2010/1/10 Németh Márton nm...@freemail.hu: Hi, I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [31636.528184] usb 3-2: new full speed USB device using uhci_hcd and address 5 [31636.740722] usb 3-2: New USB device found, idVendor=06d6, idProduct=0031 [31636.740744] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [31636.740760] usb 3-2: Product: Trust 610 LCD pow...@m ZOOM [31636.740772] usb 3-2: Manufacturer: Trust [31636.744229] usb 3-2: configuration #1 chosen from 1 choice [31636.747584] gspca: probing 06d6:0031 [31636.760176] gspca: video0 created [31636.760643] gspca: probing 06d6:0031 [31636.772063] gspca: video1 created The /dev/video0 is working correctly but the /dev/video1 just causes error: $ ./svv -d /dev/video1 raw pixfmt: JPEG 464x480 pixfmt: RGB3 464x480 mmap method VIDIOC_STREAMON error 5, Input/output error Here is the USB descriptor of the device: Trust 610 LCD pow...@m ZOOM Manufacturer: Trust Speed: 12Mb/s (full) USB Version: 1.00 Device Class: 00(ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 8 Number of Configurations: 1 Vendor Id: 06d6 Product Id: 0031 Revision Number: 1.00 Config Number: 1 Number of Interfaces: 2 Attributes: 80 MaxPower Needed: 500mA Interface Number: 0 Name: sunplus Alternate Number: 0 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 0 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 1 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 128 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 2 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 384 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 3 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 512 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 4 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 640 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 5 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 768 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 6 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 896
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sun, Jan 10, 2010 at 7:33 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, Unfortunately, I got some merge conflicts with cx18 code from Andy, due to the buffer handling changes. Could you please rebase your tree against tip, solving those conflicts? Sure, I'll try to do that tonight. I should probably retest anyway to make sure that the buffer changes don't introduce any regressions in the audio code (not that I have any reason to suspect it will). You didn't forget about the em28xx PAL VBI tree, right? I'm just mentioning it because the PULL has been pending for several weeks and came long before the PULL for the HVR-1600 ALSA changes. 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: Regression - OOPS when connecting devices with IR support
On Sun, Jan 10, 2010 at 2:49 AM, Francesco Lavra francescola...@interfree.it wrote: Yes, the IR core is broken, a patch has been submitted by myself some time ago (http://patchwork.kernel.org/patch/70126/), but hasn't made it to v4l-dvb yet. Thanks for the heads up. I actually didn't see that patch, so I appreciate you pointing it out (since it will allow me to continue my development). 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: CI USB
HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. Hiya, I've been reading this mailing list with regards to using a USB CI, but hadn't found anything to help until I found the posts from Luc and Steve sometime ago about getting the WinTV-CI to work under Linux. Coincidently, at the end of last year I had e-mailed Luc about the WinTV-CI, to see if I can help. I'm in the process of purchasing some hardware to start testing. He had managed to grab the firmware from the Windows driver but had so far been unable to get it to load correctly in his new driver. Regards, Ian Wilkinson -- To unsubscribe from this list: send the line unsubscribe 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: CI USB]
Manu Abraham wrote: On Sun, Jan 10, 2010 at 5:09 PM, Emmanuel eall...@gmail.com wrote: Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But then you would be better of buying multiple CAM's for a home use purpose. Also some card (at least for DVB-S) are really good but targeted towards free channels, and in France for example, alot of good channels are not. If the price is right (tm) I am sure a lot of people would be interested. Bye Manu Regards, Mmanu Here in Belgium and the Netherlands all channels are encrypted and besides the economics, I have very little possibility to view those channels. (not since my nexus-S with dual CI is not keeping up with the latest developments anymore). I now own a HVR4000, but Hauppauge are only supporting the USB CI for all new cards and apparently dropped the flatcable direct connection to a CI interface. There is software available to use a USB cardreader, which I am using now. This software however permits illegal distribution of keys as well. Interesting though is that this software doesn't use the official CI, nor a CAM, but a generic USB smartcard reader. If a solution could be developed, which is manufacturer independent, does not use a CAM and does not permit illegal use that would be great... regards, Johan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] MAINTAINERS: ivtv-devel is moderated
On Sun, 2010-01-10 at 08:29 -0500, Andy Walls wrote: On Sun, 2010-01-10 at 10:03 +0100, Jiri Slaby wrote: Mark ivtv-de...@ivtvdriver.org as 'moderated for non-subscribers'. Yes, that is true. I don't know why it matters after years of not being marked as such, especially since the moderator will push through on-topic posts. I don't know the implications that such an annotation will have on scripts that try to parse MAINTAINERS for e-mail addresses. I think it's just for people that use MAINTAINERS by hand. As far as I know, scripts/get_maintainer.pl is the only script that parses MAINTAINERS. This annotation doesn't change what lists are returned by the script. The script does filter lists with a subscribers-only annotation from other lists and only includes them when the command line argument --s is set. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Terratec Cinergy Hybrid XE (TM6010 Mediachip)
hello linuxtv.org developers, I have the TerraTec Cinergy Hybrid XE. (idVendor=0x0ccd, idProduct=0x0086). lsusb: Bus 001 Device 004: ID 0ccd:0086 TerraTec Electronic GmbH Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0086 bcdDevice0.01 iManufacturer 16 iProduct 32 iSerial64 0008CA123456 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 129 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 48 2.0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x1400 3x 1024 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 2 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval
Unstable LifeView Fl yDVB Hybrid PCI supp ort
Hy, I've a serious problem with my LifeView FlyDVB Hybrid PCI card. I've tried many different settings (i2c_scan, card, and all other suggestions found on the web) but the dvb-t card functionality is still very random. Here is the 'Everyday' dmesg saa7134 log: --- ... saa7130/34: v4l2 driver version 0.2.15 loaded saa7134 :05:02.0: PCI INT A - GSI 18 (level, low) - IRQ 18 saa7133[0]: found at :05:02.0, rev: 209, irq: 18, latency: 64, mmio: 0xfebff800 saa7133[0]: subsystem: 5168:3306, board: LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [card=94,autodetected] saa7133[0]: board init: gpio is 21 IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: 68 51 06 33 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 00 62 08 ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 16 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 05 01 01 16 32 15 ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 0-004b: chip found @ 0x96 (saa7133[0]) nvidia :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 nvidia :01:00.0: setting latency timer to 64 NVRM: loading NVIDIA UNIX x86_64 Kernel Module 190.53 Wed Dec 9 15:29:46 PST 2009 tda829x 0-004b: setting tuner address to 61 tda829x 0-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision ea -- invalid tda1004x: trying to boot from eeprom tda1004x: found firmware revision ea -- invalid tda1004x: waiting for firmware upload... saa7134 :05:02.0: firmware: requesting dvb-fe-tda10046.fw tda1004x: Error during firmware upload tda1004x: found firmware revision ea -- invalid tda1004x: firmware upload failed tda827x_probe_version: could not read from tuner at addr: 0xc2 saa7134 ALSA driver for DMA sound loaded IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/alsa: saa7133[0] at 0xfebff800 irq 18 registered as card -1 ... --- But sometime, (rarely), my card is correctly loaded:
Re: gspca_sunplus problem: more than one device is created
On Sun, 10 Jan 2010 17:38:00 +0100 Németh Márton nm...@freemail.hu wrote: I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [snip] OK, this is a bug. I did not imagine that some webcams had the same interface class for two different devices. I am fixing it. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe 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: gspca_sunplus problem: more than one device is created
leandro Costantino wrote:
Did that happen with the included version on the kernel?.
The kernel is calling the probe for the isoch and the bulk, i really
dont have a sunplus webcam to test, and ignore the older behavior,
that's why i am asking.
I tested with 2.6.33-rc2 on a Clevo D4J model D410J laptop. There only one
device is created. Not counting the circular locking that version is working
properly:
[ 280.578560] usb 3-1: new full speed USB device using uhci_hcd and address 2
[ 281.177675] Linux video capture interface: v2.00
[ 281.229464] gspca: main v2.8.0 registered
[ 281.260399] gspca: probing 06d6:0031
[ 281.286724] gspca: video0 created
[ 281.286909] gspca: probing 06d6:0031
[ 281.286914] gspca: intf != 0
[ 281.295106] usbcore: registered new interface driver sunplus
[ 281.295122] sunplus: registered
[ 581.086743]
[ 581.086753] ===
[ 581.086770] [ INFO: possible circular locking dependency detected ]
[ 581.086783] 2.6.33-rc2 #1
[ 581.086790] ---
[ 581.086800] svv/3409 is trying to acquire lock:
[ 581.086811] (sysfs_mutex){+.+.+.}, at: [c03338e3]
sysfs_get_dirent+0x23/0xe0
[ 581.086846]
[ 581.086849] but task is already holding lock:
[ 581.086858] (gspca_dev-usb_lock){+.+...}, at: [f80f7019]
gspca_init_transfer+0x29/0x840 [gspca_main]
[ 581.086888]
[ 581.086891] which lock already depends on the new lock.
[ 581.086895]
[ 581.086903]
[ 581.086905] the existing dependency chain (in reverse order) is:
[ 581.086915]
[ 581.086917] - #3 (gspca_dev-usb_lock){+.+...}:
[ 581.086935][c01bd1da] validate_chain+0x12ea/0x1e40
[ 581.086953][c01be064] __lock_acquire+0x334/0x15a0
[ 581.086968][c01bf39a] lock_acquire+0xca/0x220
[ 581.086982][c0649d9a] mutex_lock_interruptible_nested+0xaa/0xa20
[ 581.087002][f80f7019] gspca_init_transfer+0x29/0x840 [gspca_main]
[ 581.087020][f80f79ad] vidioc_streamon+0xfd/0x180 [gspca_main]
[ 581.087037][f80e6abc] __video_do_ioctl+0x29ec/0x71c0 [videodev]
[ 581.087057][f80eb36d] video_ioctl2+0xdd/0x980 [videodev]
[ 581.087074][f80e22e7] v4l2_unlocked_ioctl+0x37/0x70 [videodev]
[ 581.087091][c02bd6ed] vfs_ioctl+0x3d/0x130
[ 581.087109][c02bda60] do_vfs_ioctl+0x80/0xb10
[ 581.087111][c02be539] sys_ioctl+0x49/0xc0
[ 581.087111][c010484c] sysenter_do_call+0x12/0x32
[ 581.087111]
[ 581.087111] - #2 (gspca_dev-queue_lock){+.+.+.}:
[ 581.087111][c01bd1da] validate_chain+0x12ea/0x1e40
[ 581.087111][c01be064] __lock_acquire+0x334/0x15a0
[ 581.087111][c01bf39a] lock_acquire+0xca/0x220
[ 581.087111][c0649d9a] mutex_lock_interruptible_nested+0xaa/0xa20
[ 581.087111][f80fa4ad] dev_mmap+0x4d/0x3e0 [gspca_main]
[ 581.087111][f80e238a] v4l2_mmap+0x6a/0x80 [videodev]
[ 581.087111][c027b234] mmap_region+0x7a4/0x890
[ 581.087111][c027b8aa] do_mmap_pgoff+0x58a/0x5c0
[ 581.087111][c0267296] sys_mmap_pgoff+0xf6/0x240
[ 581.087111][c010484c] sysenter_do_call+0x12/0x32
[ 581.087111]
[ 581.087111] - #1 (mm-mmap_sem){++}:
[ 581.087111][c01bd1da] validate_chain+0x12ea/0x1e40
[ 581.087111][c01be064] __lock_acquire+0x334/0x15a0
[ 581.087111][c01bf39a] lock_acquire+0xca/0x220
[ 581.087111][c026ccef] might_fault+0xdf/0x120
[ 581.087111][c0427670] copy_to_user+0x60/0x1c0
[ 581.087111][c02bf0cf] filldir64+0x17f/0x210
[ 581.087111][c03334b4] sysfs_readdir+0x174/0x320
[ 581.087111][c02bf5fc] vfs_readdir+0xec/0x130
[ 581.087111][c02bf6c7] sys_getdents64+0x87/0x150
[ 581.087111][c010484c] sysenter_do_call+0x12/0x32
[ 581.087111]
[ 581.087111] - #0 (sysfs_mutex){+.+.+.}:
[ 581.087111][c01bdb3a] validate_chain+0x1c4a/0x1e40
[ 581.087111][c01be064] __lock_acquire+0x334/0x15a0
[ 581.087111][c01bf39a] lock_acquire+0xca/0x220
[ 581.087111][c064b210] mutex_lock_nested+0xa0/0x820
[ 581.087111][c03338e3] sysfs_get_dirent+0x23/0xe0
[ 581.087111][c0337220] sysfs_remove_group+0x30/0x220
[ 581.087111][c050e5be] dpm_sysfs_remove+0x1e/0x30
[ 581.087111][c0501711] device_del+0x71/0x310
[ 581.087111][c05019c9] device_unregister+0x19/0x40
[ 581.087111][f899d1c1] usb_remove_ep_devs+0x31/0x50 [usbcore]
[ 581.087111][f898fa13] remove_intf_ep_devs+0x43/0xa0 [usbcore]
[ 581.087111][f8991c83] usb_set_interface+0x1e3/0x430 [usbcore]
[ 581.087111][f80f6f33] get_ep+0x293/0x350 [gspca_main]
[ 581.087111][f80f70c8] gspca_init_transfer+0xd8/0x840 [gspca_main]
[ 581.087111][f80f79ad] vidioc_streamon+0xfd/0x180 [gspca_main]
[ 581.087111][f80e6abc] __video_do_ioctl+0x29ec/0x71c0 [videodev]
[ 581.087111][f80eb36d] video_ioctl2+0xdd/0x980 [videodev]
[ 581.087111]
Re: gspca_pac7302: sporatdic problem when plugging the device
On Sun, 10 Jan 2010 17:58:58 +0100 Németh Márton nm...@freemail.hu wrote: Then I plugged and unplugged the device 16 times. When I last plugged the device I get the following error in the dmesg: [32393.421313] gspca: probing 093a:2626 [32393.426193] gspca: video0 created [32393.426958] gspca: probing 093a:2626 [32393.426968] gspca: Interface class 1 not handled here [32394.005917] pac7302: reg_w_page(): Failed to write register to index 0x49, value 0x0, error -71 [32394.067799] gspca: set alt 8 err -71 [32394.090792] gspca: set alt 8 err -71 [32394.118159] gspca: set alt 8 err -71 The 17th plug was working correctly again. I executed this test on an EeePC 901. This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. I don't know what is the real problem, but I am afraid that slowing down reg_w_page() would make the time longer when the device can be used starting from the event when it is plugged. Hi again, I don't understand what you mean by: This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. Indeed the delay will slow down the webcam start (256 * 4 ms = 1s). If having a delay fixes the problem, then, as the error always occurs at the same index 0x49 (3 reports), a single delay could be set before writing to this index. Do you want I code this for test? Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
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 Jan 10 19:00:08 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13914:dd3338c55018 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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
PULL http://jusst.de/hg/stv090x
Mauro, Following the changesets 13830 - 13894 from my earlier pull request, Please pull the following changeset as well http://jusst.de/hg/stv090x/rev/80c74966d955 It fixes a nasty bug as described at http://osdir.com/ml/linux-media/2009-11/msg00643.html Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL http://jusst.de/hg/stv090x
On Mon, Jan 11, 2010 at 12:17 AM, Manu Abraham abraham.m...@gmail.com wrote: Mauro, Following the changesets 13830 - 13894 from my earlier pull request, Correction, 13880 - 13894 inclusive of both. Please pull the following changeset as well http://jusst.de/hg/stv090x/rev/80c74966d955 It fixes a nasty bug as described at http://osdir.com/ml/linux-media/2009-11/msg00643.html Regards, Manu -- To unsubscribe from this list: send the line unsubscribe 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: gspca_pac7302: sporatdic problem when plugging the device
Jean-Francois Moine wrote: On Sun, 10 Jan 2010 17:58:58 +0100 Németh Márton nm...@freemail.hu wrote: Then I plugged and unplugged the device 16 times. When I last plugged the device I get the following error in the dmesg: [32393.421313] gspca: probing 093a:2626 [32393.426193] gspca: video0 created [32393.426958] gspca: probing 093a:2626 [32393.426968] gspca: Interface class 1 not handled here [32394.005917] pac7302: reg_w_page(): Failed to write register to index 0x49, value 0x0, error -71 [32394.067799] gspca: set alt 8 err -71 [32394.090792] gspca: set alt 8 err -71 [32394.118159] gspca: set alt 8 err -71 The 17th plug was working correctly again. I executed this test on an EeePC 901. This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. I don't know what is the real problem, but I am afraid that slowing down reg_w_page() would make the time longer when the device can be used starting from the event when it is plugged. Hi again, I don't understand what you mean by: This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. I tought that the msleep(4) call introduced recently fixed the plug-in problem. It seems I misunderstood something. Indeed the delay will slow down the webcam start (256 * 4 ms = 1s). If having a delay fixes the problem, then, as the error always occurs at the same index 0x49 (3 reports), a single delay could be set before writing to this index. Do you want I code this for test? I tested the behaviour a little bit more. Out of 100 plug-ins: OK: 81 times pac7302: reg_w_page(): Failed to write register to index 0x49, value 0x0, error -71: 19 times Other error message I haven't got, so 19% of the time writing to register index 0x49 fails in reg_w_page(). So let's try doing fixing the way you described. If you send me a patch I can test it. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe 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: gspca_sunplus problem: more than one device is created
Jean-Francois Moine wrote: On Sun, 10 Jan 2010 17:38:00 +0100 Németh Márton nm...@freemail.hu wrote: I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [snip] OK, this is a bug. I did not imagine that some webcams had the same interface class for two different devices. I am fixing it. rev 13917 from http://linuxtv.org/hg/~jfrancois/gspca/ works correctly with Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031): only one device is created. Thanks for the fix. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe 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] drivers/media/video/saa7134: Add support for Leadtek Winfast TV2100 FM card
Added support for Leadtek Winfast TV2100 FM card. Support for remote
control is missing.
Signed-off-by: Darek Zielski dz-...@wp.pl
---
diff -r dd3338c55018 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.cSun Jan 10
10:20:28 2010 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.cSun Jan 10
21:42:27 2010 +0100
@@ -5359,6 +5359,43 @@
.vmux = 8,
} },
},
+[SAA7134_BOARD_LEADTEK_WINFAST_TV2100_FM] = {
+.name = Leadtek Winfast 2100 FM,
+.audio_clock= 0x00187de7,
+.tuner_type = TUNER_TNF_5335MF,
+.radio_type = UNSET,
+.tuner_addr= ADDR_UNSET,
+.radio_addr= ADDR_UNSET,
+
+.gpiomask = 0x0d,
+.inputs = {{
+.name = name_tv,
+.vmux = 1,
+.amux = LINE1,
+.gpio = 0x00,
+.tv = 1,
+}, {
+.name = name_comp1,
+.vmux = 3,
+.amux = LINE2,
+.gpio = 0x08,
+}, {
+.name = name_svideo,
+.vmux = 8,
+.amux = LINE2,
+.gpio = 0x08,
+} },
+.radio = {
+.name = name_radio,
+.amux = LINE1,
+.gpio = 0x04,
+},
+.mute = {
+.name = name_mute,
+.amux = LINE1,
+.gpio = 0x08,
+},
+},
};
@@ -6510,6 +6547,12 @@
.subdevice= 0x6655,
.driver_data = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
}, {
+.vendor = PCI_VENDOR_ID_PHILIPS,
+.device = PCI_DEVICE_ID_PHILIPS_SAA7130,
+.subvendor= 0x107d,
+.subdevice= 0x6f3a,
+.driver_data = SAA7134_BOARD_LEADTEK_WINFAST_TV2100_FM,
+}, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
diff -r dd3338c55018 linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.hSun Jan 10 10:20:28
2010 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134.hSun Jan 10 21:42:27
2010 +0100
@@ -300,6 +300,7 @@
#define SAA7134_BOARD_ZOLID_HYBRID_PCI173
#define SAA7134_BOARD_ASUS_EUROPA_HYBRID174
#define SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S 175
+#define SAA7134_BOARD_LEADTEK_WINFAST_TV2100_FM 176
#define SAA7134_MAXBOARDS 32
#define SAA7134_INPUT_MAX 8
--
To unsubscribe from this list: send the line unsubscribe 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: Leadtek Winfast TV2100
Hi, On 09.01.2010 18:14, hermann pitton wrote: Hi, Am Samstag, den 09.01.2010, 17:23 +0100 schrieb dz-tor: Hi Pavle, On 09.01.2010 15:46, Pavle Predic wrote: Hey Darek, Great job of making the card work. I was really thrilled when I saw your post. However, I am a total newbie, so I couldn't apply the changes you wrote about. Could you please be a bit more specific? What I did is downloaded the driver from here: http://dl.bytesex.org/releases/video4linux/saa7134-0.2.12.tar.gz and made the changes to those two files, as described. But I have no clue how to compile it. I installed linux-headers for my kernel version and tried to run make, but I'm getting an error. Are there any configuration options that I need to set in Makefile or Make.config? I'm not sure whether downloading and compiling driver is good idea. v4l drivers (which includes saa7134) are included in mainline kernel, so compiling kernel is what you have to do. From what I know, in Debian there should be package in repositories with kernel sources (linux-source or similar) - this option you should use if you want to stick to the kernel version provided by your distribution. Another option is to download kernel sources from kernel.org and use them (I've done so - I'm using latest stable release). Here you have link to how-to about kernel compiling: https://help.ubuntu.com/6.10/ubuntu/installation-guide/i386/kernel-baking.html. It's for Ubuntu, but for you it should be also applicable (on bottom there is also link to Debian documentation). Before compilation you should make changes which I gave earlier. All files which should be modified are in kernel_src_path/drivers/media/video/saa7134/ directory. Have in mind that what I've done is that I've changed existing card configuration - it's not proper solution. When I'll manage remote control to work, I'll try to prepare patch with new card configuration. You can apply my changes now or wait until I'll prepare the patch. Regards, Darek Great! So Pavle's regspy results and following my instructions did the trick. Patches must go to LMMLlinux-media@vger.kernel.org and be against latest v4l-dvb master at linuxtv.org. Done You can use what I prepared already yesterday for testing and is attached. You have only to change the clock and use LINE1 for external audio input. I suggest to use also LINE1 for mute then, gpio 0x08 is that input anyway. We can send that modified patch already and add IR support later. You must find the up/down gpio and with mask_keycode = 0x00 all the other gpios which do change on keypresses and create unique keycodes. Then you either need to add a new keytable or can use an already existing one. I understand what have to be done to get support for remote control - problem lays somewhere else. Later I'll send more details with code and outputs from dmesg and description of the problem. Regards, Darek -- To unsubscribe from this list: send the line unsubscribe 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: IR device at I2C address 0x7a
Am Sonntag, den 10.01.2010, 09:51 +0100 schrieb Jean Delvare: On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote: Hi, Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare: On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote: W dniu 06.01.2010 21:21, Jean Delvare pisze: On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? You could try loading the saa7134 driver with option card=146 and see if it helps. It works! [ 15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as /devices/pci:00/:00:1e.0/:05:00.0/input/input8 Thank you very much fo your help. Then I would suggest the following patch: * * * * * From: Jean Delvare kh...@linux-fr.org Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 Analog (card=146). However, by the time we find out, some card-specific initialization is missed. In particular, the fact that the IR is GPIO-based. Set it when we change the card type. Signed-off-by: Jean Delvare kh...@linux-fr.org Tested-by: Daro ghost-ri...@aster.pl just to note it, the ASUS TV-FM 7135 with USB remote is different to the Asus My Cinema P7134 Analog only, not only for the remote, but also for inputs, but they have the same PCI subsystem. --- linux/drivers/media/video/saa7134/saa7134-cards.c |1 + 1 file changed, 1 insertion(+) --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-12-11 09:47:47.0 +0100 +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-09 16:23:17.0 +0100 @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d printk(KERN_INFO %s: P7131 analog only, using entry of %s\n, dev-name, saa7134_boards[dev-board].name); + dev-has_remote = SAA7134_REMOTE_GPIO; } break; case SAA7134_BOARD_HAUPPAUGE_HVR1150: * * * * * Must have been broken at that time, IIRC. What must have been broken, and when? You are confusing. Sorry, I missed that thread until now. The above patch was tried previously by Roman. For the record, here is a link. http://www.spinics.net/lists/vfl/msg38869.html Only moving saa7134_input_init1(dev) to static int saa7134_hwinit2 in saa7134-core.c did help, AFAIK, but I might be wrong. Maybe some regression was involved for him, at least I followed his assumption, that in case of auto detection, when first a board without remote is detected, and then that late is switched to another board with remote through eeprom detection, input_init1 would not happen again. I admit I don't quite get why dev-has_remove should be set early (in saa7134_board_init1) given that for one board (SAA7134_BOARD_FLYDVB_TRIO) it is set later (in saa7134_board_init2) and apparently it works OK. It would make more sense to do it at the same time for all boards IMHO, possibly in a separate function to make it clearer. I am also curious if it wouldn't be even clearer and more efficient to store the default value of has_remote in struct saa7134_board. As far as I can see, only the SAA7134_BOARD_FLYDVB_TRIO needs a run-time check. Patches are welcome. Thanks, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CI USB
Manu Abraham a écrit : On Sun, Jan 10, 2010 at 5:09 PM, Emmanuel eall...@gmail.com wrote: Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But then you would be better of buying multiple CAM's for a home use purpose. Well my Astoncrypt is able to descramble 2 channels simultanueously, but here the good thing would be that you could descramble after the recording, so that you would be able for example to capture 4 channels on the same transponder only to descramble one by one later on. Bye Manu -- To unsubscribe from this list: send the line unsubscribe 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: building v4l-dvb - compilation error
Muralidharan Karicheri wrote: Mauro, I ran the build using my ubunto linux box at home and it has succeeded the build. make[2]: Leaving directory `/usr/src/kernels/2.6.9-55.0.12.EL-smp-i686' The minimum supported version by the backport is 2.6.16. Hmm. Does that means, the build is using the kernel source code natively available at /usr/src/kernel. Is there a way to force it use a specific kernel source code? Yes: make release DIR=some dir After that, all subsequent compilations will use the new dir, provided that you don't do a make distclean. 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
Mosaico ITV 300 not work with GNU/Linux
Hi, people. My 1st post is on Mosaico ITV 300' suport into Linux. Dmesg display that the chipset card's is detected (SAA7130), but properly no. You see these messages: http://www.lindrix.xpg.com.br/log_saa7130_description.txt Excuse me, they are many messages... The Mosaico's home page was: http://www.mosaico.com.tw But it is out. Images: http://www.multimidia.inf.br/media/catalog/product/cache/1/small_image/135x135/5e06319eda06f020e43594a9c230972d/i/m/image_5131_99.jpg Thanks to all. Humberto, Brazilian. -- José Humberto da Silva Soares Licenciado em Computação - UEPB; Técnico em Informática. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~mkrufky/tda8295
Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/tda8295 for: - tda8290: Fix FM radio easy programming standard selection for TDA8295 tda8290.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Cheers, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, January 08, 2010 8:40 PM To: Hiremath, Vaibhav Cc: Karicheri, Muralidharan; davinci-linux-open- sou...@linux.davincidsp.com; linux-media@vger.kernel.org Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Hiremath, Vaibhav hvaib...@ti.com writes: [Hiremath, Vaibhav] Hi Kevin and Murali, Sorry for jumping into this discussion so late, Can we use clk_add_alias() function exported by clkdev.c file here? With this board specific file can define aliases for all required platform_data keeping CLK() entry generic. Yes, this would be a good use case clk_add_alias() [Hiremath, Vaibhav] Thanks Kevin, actually I am already using the clk_add_alias in AM3517 which used same VPFE_Capture driver. But I was not sure whether this is acceptable or not, since nobody in the kernel is using this API. Thanks for conforming/clarifying; I will submit the patch now for this. Thanks, Vaibhav Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] OMAP3: Add V4L2 display driver support
-Original Message- From: Hiremath, Vaibhav Sent: Monday, January 04, 2010 8:12 PM To: linux-media@vger.kernel.org Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; t...@atomide.com; Hiremath, Vaibhav Subject: [PATCH 0/2] OMAP3: Add V4L2 display driver support From: Vaibhav Hiremath hvaib...@ti.com This series of patch-set adds support for V4L2 display driver ontop of DSS2 framework. Please note that this patch is dependent on patch which add ti-media directory (submitted earlier to this patch series) Vaibhav Hiremath (2): OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 OMAP2/3: Add V4L2 DSS driver support in device.c arch/arm/plat-omap/devices.c| 29 + drivers/media/video/ti-media/Kconfig| 10 + drivers/media/video/ti-media/Makefile |4 + drivers/media/video/ti-media/omap_vout.c| 2654 +++ drivers/media/video/ti-media/omap_voutdef.h | 148 ++ drivers/media/video/ti-media/omap_voutlib.c | 258 +++ drivers/media/video/ti-media/omap_voutlib.h | 34 + 7 files changed, 3137 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ti-media/omap_vout.c create mode 100644 drivers/media/video/ti-media/omap_voutdef.h create mode 100644 drivers/media/video/ti-media/omap_voutlib.c create mode 100644 drivers/media/video/ti-media/omap_voutlib.h [Hiremath, Vaibhav] Hans and others, Since we do not have any comments on this, can we merge this patch series? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe 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] Feature enhancement of VPFE/CCDC Capture driver
-Original Message- From: Hiremath, Vaibhav Sent: Monday, January 04, 2010 7:33 PM To: linux-media@vger.kernel.org Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux- open-sou...@linux.davincidsp.com; Karicheri, Muralidharan; Hiremath, Vaibhav Subject: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver From: Vaibhav Hiremath hvaib...@ti.com While adding support for AM3517/05 devices I have implemented/came- across these features/enhancement/bug-fixes for VPFE-Capture driver. Also the important change added is, to introduced ti-media directory for all TI devices. Vaibhav Hiremath (9): Makfile:Removed duplicate entry of davinci TVP514x:Switch to automode for querystd tvp514x: add YUYV format support Introducing ti-media directory DMx:Update board files for ti-media directory change Davinci VPFE Capture:Return 0 from suspend/resume DM644x CCDC : Add Suspend/Resume Support VPFE Capture: Add call back function for interrupt clear to vpfe_cfg DM644x CCDC: Add 10bit BT support arch/arm/mach-davinci/include/mach/dm355.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- drivers/media/video/Kconfig | 84 +- drivers/media/video/Makefile|4 +- drivers/media/video/davinci/Makefile| 17 - drivers/media/video/davinci/ccdc_hw_device.h| 110 -- drivers/media/video/davinci/dm355_ccdc.c| 1081 --- drivers/media/video/davinci/dm355_ccdc_regs.h | 310 drivers/media/video/davinci/dm644x_ccdc.c | 966 -- drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- drivers/media/video/davinci/vpfe_capture.c | 2055 - drivers/media/video/davinci/vpif.c | 296 --- drivers/media/video/davinci/vpif.h | 642 --- drivers/media/video/davinci/vpif_capture.c | 2168 --- drivers/media/video/davinci/vpif_capture.h | 165 -- drivers/media/video/davinci/vpif_display.c | 1654 - drivers/media/video/davinci/vpif_display.h | 175 -- drivers/media/video/davinci/vpss.c | 301 drivers/media/video/ti-media/Kconfig| 88 + drivers/media/video/ti-media/Makefile | 17 + drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ drivers/media/video/ti-media/dm355_ccdc.c | 1081 +++ drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 drivers/media/video/ti-media/dm644x_ccdc.c | 1090 drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ drivers/media/video/ti-media/vpfe_capture.c | 2067 + drivers/media/video/ti-media/vpif.c | 296 +++ drivers/media/video/ti-media/vpif.h | 642 +++ drivers/media/video/ti-media/vpif_capture.c | 2168 +++ drivers/media/video/ti-media/vpif_capture.h | 165 ++ drivers/media/video/ti-media/vpif_display.c | 1654 + drivers/media/video/ti-media/vpif_display.h | 175 ++ drivers/media/video/ti-media/vpss.c | 301 drivers/media/video/tvp514x.c | 15 + include/media/davinci/ccdc_types.h | 43 - include/media/davinci/dm355_ccdc.h | 321 include/media/davinci/dm644x_ccdc.h | 184 -- include/media/davinci/vpfe_capture.h| 200 --- include/media/davinci/vpfe_types.h | 51 - include/media/davinci/vpss.h| 69 - include/media/ti-media/ccdc_types.h | 43 + include/media/ti-media/dm355_ccdc.h | 321 include/media/ti-media/dm644x_ccdc.h| 184 ++ include/media/ti-media/vpfe_capture.h | 202 +++ include/media/ti-media/vpfe_types.h | 51 + include/media/ti-media/vpss.h | 69 + 46 files changed, 11207 insertions(+), 11040 deletions(-) delete mode 100644 drivers/media/video/davinci/Makefile delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c delete mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/dm644x_ccdc.c delete mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/vpfe_capture.c delete mode 100644 drivers/media/video/davinci/vpif.c delete mode 100644 drivers/media/video/davinci/vpif.h delete mode 100644 drivers/media/video/davinci/vpif_capture.c delete mode 100644 drivers/media/video/davinci/vpif_capture.h delete mode 100644 drivers/media/video/davinci/vpif_display.c delete mode 100644 drivers/media/video/davinci/vpif_display.h delete mode 100644 drivers/media/video/davinci/vpss.c create mode 100644 drivers/media/video/ti-media/Kconfig
