Re: cx88-dvb broken since 2.6.29-rc1
On Sun, 1 Feb 2009 11:42:57 -0200, Mauro Carvalho Chehab wrote: On Sun, 1 Feb 2009 14:29:27 +0100 Jean Delvare kh...@linux-fr.org wrote: On Thu, 29 Jan 2009 19:24:31 -0200, Mauro Carvalho Chehab wrote: I have already a pull request almost ready that will fix this issue. I'll likely send it today or tomorrow. Did it happen? I've just tested kernel 2.6.29-rc3-git3 and the problem is still present. I just sent today a pull request with this fix included: Great, thanks. From: Mauro Carvalho Chehab mche...@redhat.com To: Linus Torvalds torva...@linux-foundation.org Cc: Andrew Morton a...@linux-foundation.org, linux-ker...@vger.kernel.org, linux-me...@vger.linuxtv.org The last address looks like a typo. -- 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
Re: CinergyT2 not working with newer alternative driver
Hi Jason, Jason Harvey wrote: I have been successfully using VDR with two CinergyT2s for 18 months. After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping to get S2 capability and test a newer VDR for HD reception. The CinergyT2s stopped working. The kernel module loads, the blue leds flash as expected but they don't lock on to a signal for long. Signal strength shown in femon is erratic and a lock only rarely achieved. I checked through the mercurial tree to see what had changed. It looks like the following change is the one that stops the CinergyT2s working on my system. http://git.kernel.org/?p=linux/kernel/git/mchehab/devel.git;a=commit;h=986bd1e58b18c09b753f797df19251804bfe3e84 I deleted the newer version of the module and replace it with the previous deleted code. Make'd and installed the old version works as expected. Machine they're plugged into is running Fedora 10, 2.6.27.12-170.2.5.fc10.i686 I downloaded the current v4l-dvb today (31Jan2009) and tried it all again before posting this message. Not sure where to look next, I did start to capture the USB traffic to see if I could spot the difference... Please take a look at the message logs (dmesg). You can follow the instructions described here http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device and report where it fails. I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r -o output.mpg SomeChannel I am able to play with mplayer too. Regards, Thierry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
LinuxTv issue with Hauppauge WinTV-NOVA-TD-Stick - very near (but not quite ) working]
Hi, I have been following the good instructions for getting the above work with my fedora 9 64bit machine from : http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-TD-Stick#Firmware It is very nearly working, and I seem to have a bug which is manifesting itself in 2 ways. 1. If I try : scandvb /usr/share/doc/dvb-apps-1.1.1/channels.conf-dvbt-sandy_heath I get the following ERROR which I can not locate on the web: scanning /usr/share/doc/dvb-apps-1.1.1/channels.conf-dvbt-sandy_heath using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ERROR: cannot parse'BBC-Choice:64184:INVERSION_OFF:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:620:621 ' 2. When I enter kaffeine, I can scan the dvb device and all of the channels appear in the menu. But I can not get any to display (audio or video) , when selected. If I run Kaffeine from the command line, I get: kaffeine /dev/dvb/adapter0/frontend0 : opened ( DiBcom 7000PC ) /dev/dvb/adapter1/frontend0 : opened ( DiBcom 7000PC ) 0 EPG plugins loaded for device 0:0. 0 EPG plugins loaded for device 1:0. Loaded epg data : 0 events (0 msecs) The when I select a channel from the kaffeine menu I get on the command line Tuning to: BBC ONE / autocount: 0 Using DVB device 0:0 DiBcom 7000PC tuning DVB-T to 64200 Hz inv:2 bw:3 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed Tuning delay: 2688 ms The dvb-app have been installed, along with the firmaware and the modprobe.d/options file have been created with the LNA option as required. If I run dmesg | grep dvb I am getting dvb-usb: found a 'Hauppauge Nova-TD Stick/Elgato Eye-TV Diversity' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. dvb-usb: Hauppauge Nova-TD Stick/Elgato Eye-TV Diversity successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 I amn running the NOVA device with an external aerial cable: with good signal and S/N ratios, so am not using their mini aerial Any thoughts to the missing piece of the jigsaw would be most welcome. Best regards Colin Thomas -- To unsubscribe from this list: send the line unsubscribe 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] saa7146_i2c: saa7146_i2c_transfer() wrong?
On Sat, 31 Jan 2009 17:52:05 +0100, Roel Kluin wrote:
vi drivers/media/common/saa7146_i2c.c +292
in saa7146_i2c_transfer(..., int retries)
{
int address_err = 0;
do {
...
if (...)
address_err++;
...
} while (retries--);
/* if every retry had an address error, exit right away */
if (address_err == retries) {
goto out;
}
...
}
this is wrong, isn't it?
Yes, it looks pretty wrong, however the linux-i2c list isn't the right
place to discuss this.
--
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
Re: CinergyT2 not working with newer alternative driver
Thierry Merle wrote: Hi Jason, Jason Harvey wrote: I have been successfully using VDR with two CinergyT2s for 18 months. After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping to get S2 capability and test a newer VDR for HD reception. The CinergyT2s stopped working. The kernel module loads, the blue leds flash as expected but they don't lock on to a signal for long. Signal strength shown in femon is erratic and a lock only rarely achieved. I checked through the mercurial tree to see what had changed. It looks like the following change is the one that stops the CinergyT2s working on my system. http://git.kernel.org/?p=linux/kernel/git/mchehab/devel.git;a=commit;h=986bd1e58b18c09b753f797df19251804bfe3e84 I deleted the newer version of the module and replace it with the previous deleted code. Make'd and installed the old version works as expected. Machine they're plugged into is running Fedora 10, 2.6.27.12-170.2.5.fc10.i686 I downloaded the current v4l-dvb today (31Jan2009) and tried it all again before posting this message. Not sure where to look next, I did start to capture the USB traffic to see if I could spot the difference... Please take a look at the message logs (dmesg). You can follow the instructions described here http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device and report where it fails. I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r -o output.mpg SomeChannel I am able to play with mplayer too. Regards, Thierry Hi Thierry, Thank you for the quick reply. I should have looked in dmesg before... Checking dmesg before I used tzap shows a problem. dvb-usb: recv bulk message failed: -110 Extract of dmesg dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/input/input8 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-5/input/input9 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. usbcore: registered new interface driver cinergyT2 dvb-usb: recv bulk message failed: -110 dvb-usb: recv bulk message failed: -110 Running tzap fails to tune/lock #tzap -a 0 -c channels.conf_dvbt -s -t 120 -r -o output.mpg BBC ONE using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf_dvbt' tuning to 50580 Hz video pid 0x0258, audio pid 0x0259 status 01 | signal c11f | snr | ber | unc | No more messages in dmesg. I shut down the PC, removed all power, unplugged the CinergyT2s, gave it twenty seconds and powered back up. Once it had booted I plugged in one of the devices and the dmesg output below. usb 2-5: new high speed USB device using ehci_hcd and address 3 usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64 usb 2-5: configuration #1 chosen from 1 choice usb 2-5: New USB device found, idVendor=0ccd, idProduct=0038 usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-5: Product: Cinergy T? usb 2-5: Manufacturer: TerraTec GmbH dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-5/input/input9 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. usbcore: registered new interface driver cinergyT2 dvb-usb: recv bulk message failed: -110 Cannot tzap or scan. With the old version of the driver I don't have any trouble at all. Hope this helps. Regards, Jason -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
[PATCH] Leadtek WinFast DTV-1800H and DTV-2000H
Hi, few months ago I sent the patch for Leadtek WinFast DTV-1800H card, but it wasn't merged to repository yet. Maybe it's because of the merging of mailing lists. I'm sending it again. These are the original messages: http://linuxtv.org/pipermail/linux-dvb/2008-October/029859.html http://linuxtv.org/pipermail/linux-dvb/2008-November/030362.html Briefly, patch adds support for analog tv, radio, dvb-t and remote control. About three people already confirmed the functionality. The second patch I attached (leadtek_winfast_dtv2000h.patch) is from Mirek Slugeň and it adds support for some revisions of Leadtek WinFast DTV-2000H. I don't have any of DTV-2000H cards, so I cannot confirm its correctness. Here is the original message from Mirek Slugeň: http://linuxtv.org/pipermail/linux-dvb/2008-November/030644.html (The patch is dependent on 1800H patch.) I hope this is the last time I'm bothering you with this thing. ;) - Miroslav Šustek leadtek_winfast_dtv1800h.patch Description: Binary data leadtek_winfast_dtv2000h.patch Description: Binary data
Re: LinuxTv issue with Hauppauge WinTV-NOVA-TD-Stick - very near (but not quite ) working]
I amn running the NOVA device with an external aerial cable: with good signal and S/N ratios, so am not using their mini aerial Any thoughts to the missing piece of the jigsaw would be most welcome. Best regards Colin Thomas please try http://mercurial.intuxication.org/hg/s2-liplianin with scan-s2 http://mercurial.intuxication.org/hg/scan-s2 with ini files from http://www.vdr-settings.com/download/channels/CLyngsatSP.tar.bz2 (folder scan-s2) and http://hg.kewl.org/dvb2010/ with xml files from http://www.vdr-settings.com/download/channels/CLyngsatSP.tar.bz2 I hope it will help you sorry I was wrong. You have dvb-t version of Nova, not dvb-s Goga -- To unsubscribe from this list: send the line unsubscribe 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] tw9910: color format check is added on set_fmt
On Tue, 27 Jan 2009, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
Why is this needed? Do you see any possibility for tw9910 to be called
with an unsupported format?
Thanks
Guennadi
---
drivers/media/video/tw9910.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 1a9c6fd..57027c0 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -647,6 +647,19 @@ static int tw9910_set_fmt(struct soc_camera_device *icd,
__u32 pixfmt,
struct tw9910_priv *priv = container_of(icd, struct tw9910_priv, icd);
int ret = -EINVAL;
u8 val;
+ int i;
+
+ /*
+ * check color format
+ */
+ for (i = 0 ; i ARRAY_SIZE(tw9910_color_fmt) ; i++) {
+ if (pixfmt == tw9910_color_fmt[i].fourcc) {
+ ret = 0;
+ break;
+ }
+ }
+ if (ret 0)
+ goto tw9910_set_fmt_error;
/*
* select suitable norm
--
1.5.6.3
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] soc_camera: Add FLDPOL flags
On Fri, 30 Jan 2009, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
include/media/soc_camera.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 7440d92..2c7ecdf 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -231,6 +231,8 @@ static inline struct v4l2_queryctrl const
*soc_camera_find_qctrl(
#define SOCAM_PCLK_SAMPLE_FALLING(1 13)
#define SOCAM_DATA_ACTIVE_HIGH (1 14)
#define SOCAM_DATA_ACTIVE_LOW(1 15)
+#define SOCAM_FLDPOL_ACTIVE_HIGH (1 16)
+#define SOCAM_FLDPOL_ACTIVE_LOW (1 17)
#define SOCAM_DATAWIDTH_MASK (SOCAM_DATAWIDTH_4 | SOCAM_DATAWIDTH_8 | \
SOCAM_DATAWIDTH_9 | SOCAM_DATAWIDTH_10 | \
FLDPOL is the name of a field in the register, and it means field ID
polarity, i.e., the polarity of the field ID signal. Hence the name
you're proposing reads: field ID polarity active {low,high}, which seems
redundant to me. What about SOCAM_FIELD_ID_ACTIVE_{HIGH,LOW}? Following
the scheme SOCAM_signal name_ACTIVE_*.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line unsubscribe 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] sh_mobile_ceu: Add FLDPOL operation
On Fri, 30 Jan 2009, Kuninori Morimoto wrote: Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com --- drivers/media/video/sh_mobile_ceu_camera.c |7 +++ include/media/sh_mobile_ceu.h |2 ++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c index 07b7b4c..366e5f5 100644 --- a/drivers/media/video/sh_mobile_ceu_camera.c +++ b/drivers/media/video/sh_mobile_ceu_camera.c @@ -118,6 +118,12 @@ static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev) if (pcdev-pdata-flags SH_CEU_FLAG_USE_16BIT_BUS) flags |= SOCAM_DATAWIDTH_16; + if (pcdev-pdata-flags SH_CEU_FLAG_USE_FLDPOL_HIGH) + flags |= SOCAM_FLDPOL_ACTIVE_HIGH; + + if (pcdev-pdata-flags SH_CEU_FLAG_USE_FLDPOL_LOW) + flags |= SOCAM_FLDPOL_ACTIVE_LOW; + if (flags SOCAM_DATAWIDTH_MASK) return flags; @@ -474,6 +480,7 @@ static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd, icd-current_fmt-fourcc == V4L2_PIX_FMT_NV61) value ^= 0x0100; /* swap U, V to change from NV1x-NVx1 */ + value |= common_flags SOCAM_FLDPOL_ACTIVE_LOW ? 1 16 : 0; value |= common_flags SOCAM_VSYNC_ACTIVE_LOW ? 1 1 : 0; value |= common_flags SOCAM_HSYNC_ACTIVE_LOW ? 1 0 : 0; value |= buswidth == 16 ? 1 12 : 0; Why are you basing your decision to use active low or high level of the Field ID signal upon the platform data? Doesn't it depend on the configuration of the connected device, and, possibly, an inverter between them? So, looks like it should be handled in exactly the same way as all other signals - negotiate with the connected device (sensor / decoder / ...) and apply platform-defined inverters if any? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe 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: cx88-dvb broken since 2.6.29-rc1
On Sun, 1 Feb 2009, Jean Delvare wrote: On Sun, 1 Feb 2009 11:42:57 -0200, Mauro Carvalho Chehab wrote: On Sun, 1 Feb 2009 14:29:27 +0100 Jean Delvare kh...@linux-fr.org wrote: On Thu, 29 Jan 2009 19:24:31 -0200, Mauro Carvalho Chehab wrote: I have already a pull request almost ready that will fix this issue. I'll likely send it today or tomorrow. Did it happen? I've just tested kernel 2.6.29-rc3-git3 and the problem is still present. I just sent today a pull request with this fix included: Great, thanks. From: Mauro Carvalho Chehab mche...@redhat.com To: Linus Torvalds torva...@linux-foundation.org Cc: Andrew Morton a...@linux-foundation.org, linux-ker...@vger.kernel.org, linux-me...@vger.linuxtv.org The last address looks like a typo. Yes. It were a typo on my patchbomb script. Fixed, thanks! -- Cheers, Mauro Carvalho Chehab http://linuxtv.org mche...@infradead.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: PAC7302 disassembly
christopherwander...@columbus.rr.com wrote: Can I get as much disassembly of the PAC7302 drivers with your comments next to it? I am trying to improve my webcam and currently disassembling the driver, in Vista64 with IDA Pro. (I still have the 32 bit driver files as I upgraded from xp32) I am helping on the gAIM/Pidgin voice/video chat and this driver isn't where I would like it to be. I need better color balance, even after changing alot of options I still turn out orange quite a bit. I have Assembly expierence, I own the Intel Instruction Manuals, so figuring out the actual given driver with a little bit of help based on the current progress should not be difficult Christopher W. Anderson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hello Christopher Thanks for posting to linux-me...@vger.kernel.org. As I wrote you back on the private mail you send me, I don't really understand what you try to tell or ask me! What do you mean with disassembly? Converting the binary Windoz drive to assemble code? Or looking with a hex editor into the Windowz driver and figure out what the opcode is doing? The PAC7302 Linux driver was develop by re-engineering the Windoz drive with the help of usb snoop. Usb snoop (http://benoit.papillault.free.fr/usbsnoop/) is a program which can log the usb traffic on a Windoz box. By looking at this logs, I could figure out how to control the cam (PAC7302 bridge). To find out the compression Pixart is using in this chip was a long journey, too. I suggest you get the newest driver from linuxtv.org or from Jean-Francois Moine site (http://moinejf.free.fr/). Don't forget to get the newest libv4l lib from Hans de Geode. After you installed this and tested the webcam, please report back how the driver is working. Anyway, when you are able to disassemble the Windowz drive, please post your results here. There are some people around here how can comment your outcome. Thomas -- To unsubscribe from this list: send the line unsubscribe 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: PAC7302 disassembly
Thomas Kaiser wrote: christopherwander...@columbus.rr.com wrote: Can I get as much disassembly of the PAC7302 drivers with your comments next to it? I am trying to improve my webcam and currently disassembling the driver, in Vista64 with IDA Pro. (I still have the 32 bit driver files as I upgraded from xp32) I am helping on the gAIM/Pidgin voice/video chat and this driver isn't where I would like it to be. I need better color balance, even after changing alot of options I still turn out orange quite a bit. I have Assembly expierence, I own the Intel Instruction Manuals, so figuring out the actual given driver with a little bit of help based on the current progress should not be difficult Christopher W. Anderson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hello Christopher Thanks for posting to linux-me...@vger.kernel.org. As I wrote you back on the private mail you send me, I don't really understand what you try to tell or ask me! What do you mean with disassembly? Converting the binary Windoz drive to assemble code? Or looking with a hex editor into the Windowz driver and figure out what the opcode is doing? The PAC7302 Linux driver was develop by re-engineering the Windoz drive with the help of usb snoop. Usb snoop (http://benoit.papillault.free.fr/usbsnoop/) is a program which can log the usb traffic on a Windoz box. By looking at this logs, I could figure out how to control the cam (PAC7302 bridge). To find out the compression Pixart is using in this chip was a long journey, too. I suggest you get the newest driver from linuxtv.org or from Jean-Francois Moine site (http://moinejf.free.fr/). Don't forget to get the newest libv4l lib from Hans de Geode. After you installed this and tested the webcam, please report back how the driver is working. Anyway, when you are able to disassemble the Windowz drive, please post your results here. There are some people around here how can comment your outcome. Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Sorry for replying to my own post. I forgot to tell that there is no documentation available from Pixart. I tried to meet them (Pixart) the last time I was in Taiwan but they refused to meet me :-( (Looks like they are not interested to have there products running with Linux) Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Driver for WinTV-NOVA-S-USB2
Hello all, Just a quick question to everyone is anyone writing a driver for WinTV-NOVA-S-USB2? It seems to be made up from already supported devices so the driver looks straight forward. I'm happy to dive in and give it a go as long as I'm not treading on any ones toes :) I see someone wrote the wiki page for the device (http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-S-USB2) so I was wondering if anyone got any further? (I've done C coding for 16 years, this won't be my first kernel driver, but will be my first Linux kernel driver) -- Stephen Brooks -- To unsubscribe from this list: send the line unsubscribe 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] Leadtek WinFast DTV-1800H and DTV-2000H
Hi, Am Sonntag, den 01.02.2009, 17:37 +0100 schrieb Miroslav Šustek: Hi, few months ago I sent the patch for Leadtek WinFast DTV-1800H card, but it wasn't merged to repository yet. Maybe it's because of the merging of mailing lists. I'm sending it again. These are the original messages: http://linuxtv.org/pipermail/linux-dvb/2008-October/029859.html http://linuxtv.org/pipermail/linux-dvb/2008-November/030362.html Briefly, patch adds support for analog tv, radio, dvb-t and remote control. About three people already confirmed the functionality. The second patch I attached (leadtek_winfast_dtv2000h.patch) is from Mirek Slugeň and it adds support for some revisions of Leadtek WinFast DTV-2000H. I don't have any of DTV-2000H cards, so I cannot confirm its correctness. Here is the original message from Mirek Slugeň: http://linuxtv.org/pipermail/linux-dvb/2008-November/030644.html (The patch is dependent on 1800H patch.) I hope this is the last time I'm bothering you with this thing. ;) - Miroslav Šustek Miroslav, Mirek, looks OK so far, but biggest problem is that all patches have no Signed-off-by line. Try README.patches in v4l-dvb and related. The not at all working radio on the DTV2000H_J could indicate that it is a FMD1216MEX with different radio IF, which was recently added by Darron Broad. Good idea how they did expand the antenna input connectors. Also, for the unsupported XCeive4000 on the DTV2000H_PLUS I guess TUNER_ABSENT should be used until support for it is ready and all related ? There is another patch from Mirek for saa7134 with multiple multi frontend boards from Nov. 28 2008 where I asked for his SOB, but no response. It has at least a tested-by from me and an updated version against recent v4l-dvb can be provided. http://www.linuxtv.org/pipermail/linux-dvb/2009-January/031217.html Mauro seems to prefer to have v4l-dvb related e-mails at infradead.org. Changed to it. Cheers, 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
Driver for WinTV-NOVA-S-USB2
Hello all, Just a quick question to everyone is anyone writing a driver for WinTV-NOVA-S-USB2? It seems to be made up from already supported devices so the driver looks straight forward. I'm happy to dive in and give it a go as long as I'm not treading on any ones toes :) I see someone wrote the wiki page for the device (http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-S-USB2) so I was wondering if anyone got any further? (I've done C coding for 16 years, this won't be my first kernel driver, but will be my first Linux kernel driver) -- Stephen Brooks -- To unsubscribe from this list: send the line unsubscribe 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] sh_mobile_ceu: SOCAM flags are prepared at itself.
On Sun, 1 Feb 2009, Guennadi Liakhovetski wrote:
On Fri, 30 Jan 2009, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
Signed-off-by: Magnus Damm d...@igel.co.jp
---
drivers/media/video/sh_mobile_ceu_camera.c | 27
+--
include/media/sh_mobile_ceu.h |5 +++--
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 9cde91a..07b7b4c 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -101,6 +101,29 @@ struct sh_mobile_ceu_dev {
const struct soc_camera_data_format *camera_fmt;
};
+static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev)
+{
+ unsigned long flags;
+
+ flags = SOCAM_SLAVE |
Guys, are you both sure this should be SLAVE, not MASTER? Have you tested
it? Both tw9910 and ov772x register themselves as MASTER and from the
datasheet the interface seems to be a typical master parallel to me... I
think with this patch you would neither be able to use your driver with
tw9910 nor with ov772x...
Ok, sorry, you, probably, did test it and it worked, but just because the
SLAVE / MASTER flag is not tested in soc_camera_bus_param_compatible(),
which I should fix with the next pull, but this does look wrong. Please,
fix.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line unsubscribe 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] DAB: fix typo
From: Márton Németh nm...@freemail.hu Fix typo in DAB adapters section in Kconfig. Signed-off-by: Márton Németh nm...@freemail.hu --- --- linux-2.6.29-rc3/drivers/media/Kconfig.orig 2008-12-25 00:26:37.0 +0100 +++ linux-2.6.29-rc3/drivers/media/Kconfig 2009-02-01 13:30:54.0 +0100 @@ -117,7 +117,7 @@ source drivers/media/dvb/Kconfig config DAB boolean DAB adapters ---help--- - Allow selecting support for for Digital Audio Broadcasting (DAB) + Allow selecting support for Digital Audio Broadcasting (DAB) Receiver adapters. if DAB -- To unsubscribe from this list: send the line unsubscribe 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: PXA Quick capture interface with HV7131RP-Camera
On Sat, 31 Jan 2009, Bennet Fischer wrote: Hi I am trying to get a camera to work together with an PXA270 processor. My system has the following specs: Platform: Gumstix Verdex Pro Camera: HV7131RP OS: Linux 2.6.28 I wrote a simple driver for the camera which omits all the i2c-stuff because the camera starts already in a default configuration which works fine for me. A V4L2-device is generated and everything looks fine. But when i start to capture, no data arrives BUT the Quick Capture Interface outputs a MCLK and the camera responds with a PCLK, LV and FV (and data of couse). For getting a bit closer to the origin of the problem I disabled DMA in pxa_camera.c and enabled all Interrupts in the CICR0 register. No interrupt is generated. Even by disabling DMA and IRQ and looking into CISR nothing happens. I checked all the CIF registers bitwise. The polarity of the LV and FV is correct, the alternate pin functions are correct, the interrupt bit is non-masked, the size of the pixel matrix is correct. I'm a bit desperate because at the moment I have no idea what to do next. I would be thankful for any hint. Maybe you could post your platform data, i.e., your struct pxacamera_platform_data? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] general protection fault: 0000 [1] SMP with 2.6.27 and 2.6.28
Andy Walls wrote:
On Sat, 2009-01-31 at 15:01 +, Chris Mayo wrote:
I've been seeing general protection fault's with 2.6.27 and 2.6.28
(gentoo-sources, amd64) used with vdr. Unfortunately I can't reproduce
them on demand.
Two more of these with 2.6.28 so I switched back to 2.6.25 and now four
weeks with no more
vdr: [5577] switching device 2 to channel 2
DVB: frontend 1 frequency limits undefined - fix the driver
general protection fault: [1] SMP
CPU 0
Modules linked in: snd_pcm_oss snd_mixer_oss it87 hwmon_vid r8169
dvb_ttpci saa7146_vv videobuf_dma_sg videobuf_core sp8870 budget l64781
ves1x93 budget_ci lnbp21 budget_core saa7146 ttpci_eeprom tda1004x
ir_common tda10023 stv0299 k8temp snd_hda_intel snd_pcm snd_timer snd
snd_page_alloc forcedeth i2c_nforce2
Pid: 5721, comm: kdvb-fe-1 Not tainted 2.6.27-gentoo-r5 #1
RIP: 0010:[a00e8a79] [a00e8a79]
grundig_29504_401_tuner_set_params+0x39/0x100 [budget]
RSP: 0018:88003d3edda0 EFLAGS: 00010202
RAX: 88003d3eddb0 RBX: 88003e0de000 RCX:
RDX: 28020004 RSI: 88003efe5808 RDI: 88003efe4010
RBP: R08: R09:
R10: R11: R12: 88003efe5808
vdr: [5720] changing pids of channel 30 from 203+203:407=eng,408=und:0:0
to 203+203:407=eng,408=und:603=eng:0
R13: 88003efe4000 R14: 1d324372 R15: 88003efe59d8
FS: 45a17950() GS:80710600()
knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 00f86000 CR3: 00201000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process kdvb-fe-1 (pid: 5721, threadinfo 88003d3ec000, task
88003f2cd890)
Stack: 0004 88003d3eddb0 88003f2cd890
7fff
88003efe4010 a00e5660 88003d3edec0 88003efe59d8
88003efe59b0 8059815d 88003efe5800
Call Trace:
[a00e5660] apply_frontend_param+0x40/0x3e0 [l64781]
[8059815d] schedule_timeout+0xad/0xf0
[8041c45d] dvb_frontend_swzigzag_autotune+0xcd/0x220
[80598a2c] __down_interruptible+0x9c/0xd0
[8041ceba] dvb_frontend_swzigzag+0x19a/0x290
[802549b6] down_interruptible+0x36/0x60
[8041d3b8] dvb_frontend_thread+0x408/0x4c0
[80250570] autoremove_wake_function+0x0/0x30
[8041cfb0] dvb_frontend_thread+0x0/0x4c0
[802501b7] kthread+0x47/0x80
[80232887] schedule_tail+0x27/0x70
[8020ca49] child_rip+0xa/0x11
[80250170] kthread+0x0/0x80
[8020ca3f] child_rip+0x0/0x11
Code: 97 d0 02 00 00 48 8b 58 38 48 8d 44 24 10 48 85 d2 48 c7 04 24 00
00 00 00 66 c7 44 24 04 04 00 48 89 44 24 08 0f 84 af 00 00 00 0f b6
02 66 89 04 24 8b 0e b8 05 3d 95 0c 44 8d 81 48 39 27 02
RIP [a00e8a79] grundig_29504_401_tuner_set_params+0x39/0x100
[budget]
RSP 88003d3edda0
---[ end trace 33ec88b18fe8a71a ]---
This one and the two other are all suffering from the same error a
derefernce of the %rdx register that points to garbage.
The source code in question is in
linux/drivers/media/dvb/ttpci/budget.c:grundig_29504_401_tuner_set_params():
static int grundig_29504_401_tuner_set_params(struct dvb_frontend* fe, struct
dvb_frontend_parameters* params)
{
struct budget *budget = fe-dvb-priv;
u8 *tuner_addr = fe-tuner_priv;
u32 div;
u8 cfg, cpump, band_select;
u8 data[4];
struct i2c_msg msg = { .flags = 0, .buf = data, .len = sizeof(data) };
if (tuner_addr)
msg.addr = *tuner_addr;
else
msg.addr = 0x61;
div = (36125000 + params-frequency) / 16;
[...]
The oops code disassembles to this
13: 48 8b 58 38 mov0x38(%rax),%rbx
17: 48 8d 44 24 10 lea0x10(%rsp),%rax
1c: 48 85 d2test %rdx,%rdx if (tuner_addr) ...
1f: 48 c7 04 24 00 00 00movq $0x0,(%rsp) msg.flags = 0
26: 00
27: 66 c7 44 24 04 04 00movw $0x4,0x4(%rsp) msg.len = sizeof(data)
2e: 48 89 44 24 08 mov%rax,0x8(%rsp) msg.buf = data
33: 0f 84 af 00 00 00 je 0xe8if (tuner_addr) ...
39: 0f b6 02movzbl (%rdx),%eax *tuner_addr --- Ooops
is here
3c: 66 89 04 24 mov%ax,(%rsp)
40: 8b 0e mov(%rsi),%ecx
42: b8 05 3d 95 0c mov$0xc953d05,%eax1/16 (times
0x2000)
47: 44 8d 81 48 39 27 02lea0x2273948(%rcx),%r8d 36125000 +
params-frequency
So tuner_addr is non-NULL and is not a valid pointer
Re: [PATCH] tw9910: color format check is added on set_fmt
Dear Guennadi Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com Why is this needed? Do you see any possibility for tw9910 to be called with an unsupported format? for example, capture_example -f use V4L2_PIX_FMT_YUYV. but tw9910 support only V4L2_PIX_FMT_VYUY now. If you think this patch is unnecessary, please ignore it. Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe 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] sh_mobile_ceu: SOCAM flags are prepared at itself.
Dear Guennadi Thank your for checking patch. Guys, are you both sure this should be SLAVE, not MASTER? Have you tested it? Both tw9910 and ov772x register themselves as MASTER and from the Of course I tested it. Ok, sorry, you, probably, did test it and it worked, but just because the SLAVE / MASTER flag is not tested in soc_camera_bus_param_compatible(), which I should fix with the next pull, but this does look wrong. Please, fix. Hmm. I should have asked you what is MASTER/SLAVE before sending patch. I suspect it it about who generates the clock signal either the camera or the host. Our CEU does not support any clock generation so it is always SLAVE. Therefore I didn't support MASTER for CEU. But it seems wrong understanding... I would like ask you What MASTER/SLAVE means ? Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] general protection fault: 0000 [1] SMP with 2.6.27 and 2.6.28
On Sun, 2009-02-01 at 23:38 +0100, Oliver Endriss wrote: Andy Walls wrote: On Sat, 2009-01-31 at 15:01 +, Chris Mayo wrote: So tuner_addr is non-NULL and is not a valid pointer either. It looks like linux/drivers/media/dvb/ttpci/budget.c:frontend_init() is setting the pointer up properly. So something else is trashing the struct dvb_frontend structure pointed to by the variable fe. Finding what's doing that will be difficult. Without a device nor steps to reliably reproduce, that's about all I can help with. Regards, Andy Afaik this bug was fixed in changeset http://linuxtv.org/hg/v4l-dvb/rev/f4d7d0b84940 CU Oliver Thanks. I didn't realize the initialization to NULL was a recent fix. I was looking at very recent v4l-dvb source code with that change in place (which is why I thought tracking down the problem would be hard). I agree that that change likely fixes the problem, if Chris doesn't have it in place. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TinyTwin (af9015) - tuner 0 not working
I've had a DigitalNow TinyTwin dual usb tuner working on my mythbox for a week now (latest v4l-dvb trunk). A odd problem with the tuner has surfaced. Today Tuner 0 stopped getting a lock on any channel. Signal strength is 95%+, Bit Errors are Zero. However Tuner 1 is locking on and displaying channels just fine. Tuner 0 used to work fine. I've rebooted, but the problem hasn't gone away. Any suggestions? Thanks - Lindsay Lindsay Mathieson http://members.optusnet.com.au/~blackpaw1/album -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
Hi, this change set is wrong. The affected functions cannot be called from an interrupt context, because they may process large buffers. In this case, interrupts are disabled for a long time. Functions, like dvb_dmx_swfilter_packets(), could be called only from a tasklet. This change set does hide some strong design bugs in dm1105.c and au0828-dvb.c. Please revert this change set and do fix the bugs in dm1105.c and au0828-dvb.c (and other files). Regards, Hartmut -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kernel-2.6.28 probs
Hi all, I have been trying to get my box's dvb card working in kernel 2.6.28 and have had only failures so far. It all works quite well in 2.6.27, just doesn't seem to want lock onto channels when using updated kernel. I have tried 2.6.28 with the inbuilt drivers as well as the latest hg drivers which I use for the 2.6.27 kernel. My card is the LeadTek WinFast PxDVR3200-H Here is the relevent dmesg section (ignore the gspa, thats for my cam) cx23885 driver version 0.0.1 loaded ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 cx23885 :02:00.0: PCI INT A - Link[APC5] - GSI 16 (level, low) - IRQ 16 CORE cx23885[0]: subsystem: 107d:6681, board: Leadtek Winfast PxDVR3200 H [card=12,insmod option] i2c-adapter i2c-2: adapter [cx23885[0]] registered i2c-dev: adapter [cx23885[0]] registered as minor 2 i2c-adapter i2c-3: adapter [cx23885[0]] registered i2c-dev: adapter [cx23885[0]] registered as minor 3 i2c-adapter i2c-4: adapter [cx23885[0]] registered i2c-dev: adapter [cx23885[0]] registered as minor 4 i2c-adapter i2c-2: master_xfer[0] W, addr=0x50, len=1 i2c-adapter i2c-2: master_xfer[0] R, addr=0x50, len=256 firewire_core: created device fw0: GUID 001a4d5600e248b0, S400 i2c-core: driver [cx25840'] registered i2c-adapter i2c-2: found normal entry for adapter 2, addr 0x44 i2c-adapter i2c-2: master_xfer[0] W, addr=0x44, len=0 i2c-adapter i2c-3: found normal entry for adapter 3, addr 0x44 i2c-adapter i2c-3: master_xfer[0] W, addr=0x44, len=0 i2c-adapter i2c-4: found normal entry for adapter 4, addr 0x44 i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=0 i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=2 i2c-adapter i2c-4: master_xfer[0] R, addr=0x44, len=1 i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=2 i2c-adapter i2c-4: master_xfer[0] R, addr=0x44, len=1 cx25840' 4-0044: cx25 0-21 found @ 0x88 (cx23885[0]) i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=2 i2c-adapter i2c-4: master_xfer[0] R, addr=0x44, len=1 i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=3 i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=3 i2c-adapter i2c-4: client [cx25840'] registered with bus id 4-0044 i2c-core: driver [cx25840] registered cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card spca561 2-10:1.0: usb_probe_interface spca561 2-10:1.0: usb_probe_interface - got id gspca: probing 046d:092f gspca: probe ok usbcore: registered new interface driver spca561 spca561: registered nvidia: module license 'NVIDIA' taints kernel. ACPI: PCI Interrupt Link [APC6] enabled at IRQ 16 nvidia :03:00.0: PCI INT A - Link[APC6] - GSI 16 (level, low) - IRQ 16 nvidia :03:00.0: setting latency timer to 64 NVRM: loading NVIDIA UNIX x86 Kernel Module 180.27 Tue Jan 27 12:16:07 PST 2009 i2c-adapter i2c-2: master_xfer[0] W, addr=0x0f, len=1 i2c-adapter i2c-2: master_xfer[1] R, addr=0x0f, len=1 xc2028 3-0061: creating new instance xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner DVB: registering new adapter (cx23885[0]) DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... cx23885_dev_checkrevision() Hardware revision = 0xb0 cx23885[0]/0: found at :02:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xee00 cx23885 :02:00.0: setting latency timer to 64 -- Regards,Robert . Some people can tell what time it is by looking at the sun, but I have never been able to make out the numbers. --- Errata: Spelling mistakes are not intentional, however, I don't use spell checkers because it's too easy to allow the spell checker to make the decisions and use words that are out of context for that being written, i.e. their/there, your/you're, threw/through and even accept/except, not to mention foreign (I'm Australian) English spelling, i.e. colour/color, socks/sox, etc,. -- To unsubscribe from this list: send the line unsubscribe 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: [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)
On Mon, 2009-02-02 at 02:46 +0100, e9hack wrote: Hi, this change set is wrong. The affected functions cannot be called from an interrupt context, because they may process large buffers. In this case, interrupts are disabled for a long time. Functions, like dvb_dmx_swfilter_packets(), could be called only from a tasklet. I agree with Hartmut that these functions should not be called from an interrupt context. Although for deferrable work, I thought tasklets were deprecated and that work handlers were the preferred mechanism: http://lwn.net/Articles/23634/ This change set does hide some strong design bugs in dm1105.c and au0828-dvb.c. Please revert this change set and do fix the bugs in dm1105.c and au0828-dvb.c (and other files). BTW dm1105.c does use a tasklet for IR keypresses. However, since it is only imlemented with one struct infrared, and hence only one ir_command, per device and not a queue, it is possible to lose button presses that happen very close together. That probably doesn't matter practically for IR button presses, but the same strategy cannot be used for TS packets. Regards, Andy Regards, Hartmut -- To unsubscribe from this list: send the line unsubscribe 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: [REVIEW PATCH 13/14] OMAP: CAM: Add DW9710 Lens Driver
Hello, guys
Sorry me, answering to old letter. May i suggest two small points
described below ?
On Mon, 2009-01-12 at 20:03 -0600, Aguirre Rodriguez, Sergio Alberto
wrote:
This adds the DW9710 Lens driver
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/dw9710.c | 548
+
drivers/media/video/dw9710_priv.h | 57
include/media/dw9710.h| 35 +++
5 files changed, 649 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/dw9710.c
create mode 100644 drivers/media/video/dw9710_priv.h
create mode 100644 include/media/dw9710.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 1616c32..10075c3 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -313,6 +313,14 @@ config VIDEO_MT9P012
MT9P012 camera. It is currently working with the TI OMAP3
camera controller.
+config VIDEO_DW9710
+ tristate Lens driver for DW9710
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 lens driver for the Dongwoon
+ DW9710 coil. It is currently working with the TI OMAP3
+ camera controller and micron MT9P012 sensor.
+
config VIDEO_SAA7110
tristate Philips SAA7110 video decoder
depends on VIDEO_V4L1 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f73b65c..41c71d5 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_MT9P012)+= mt9p012.o
+obj-$(CONFIG_VIDEO_DW9710) += dw9710.o
obj-$(CONFIG_VIDEO_OMAP3) += omap34xxcam.o isp/
diff --git a/drivers/media/video/dw9710.c b/drivers/media/video/dw9710.c
new file mode 100644
index 000..362cb0d
--- /dev/null
+++ b/drivers/media/video/dw9710.c
@@ -0,0 +1,548 @@
+/*
+ * drivers/media/video/dw9710.c
+ *
+ * DW9710 Coil Motor (LENS) driver
+ *
+ * Copyright (C) 2008 Texas Instruments.
+ *
+ * Contributors:
+ * Troy Laramy t-lar...@ti.com
+ * Mohit Jalori mjal...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/cdev.h
+#include linux/device.h
+
+#include mach/gpio.h
+
+#include media/v4l2-int-device.h
+#include media/dw9710.h
+
+#include dw9710_priv.h
+
+static struct dw9710_device dw9710 = {
+ .state = DW9710_LENS_NOT_DETECTED,
+ .current_lens_posn = DW9710_DEF_LENS_POSN,
+};
+
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+ int current_value;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_FOCUS_ABSOLUTE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Focus, Absolute,
+ .minimum = 0,
+ .maximum = DW9710_MAX_FOCUS_POS,
+ .step = DW9710_LENS_POSN_STEP,
+ .default_value = DW9710_DEF_LENS_POSN,
+ },
+ .current_value = DW9710_DEF_LENS_POSN,
+ }
+};
+
+/**
+ * find_vctrl - Finds the requested ID in the video control structure array
+ * @id: ID of control to search the video control array for
+ *
+ * Returns the index of the requested ID from the control structure array
+ */
+static int find_vctrl(int id)
+{
+ int i;
+
+ if (id V4L2_CID_BASE)
+ return -EDOM;
+
+ for (i = (ARRAY_SIZE(video_control) - 1); i = 0; i--) {
+ if (video_control[i].qc.id == id)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * dw9710_reg_read - Reads a value from a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Pointer to u16 for returning value of register to read.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_read(struct i2c_client *client, u16 *value)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[2];
+
+ if (!client-adapter)
+ return -ENODEV;
+
+ msg-addr = client-addr;
+ msg-flags = I2C_M_RD;
+ msg-len = 2;
+ msg-buf = data;
+
+ data[0] = 0;
+ data[1] = 0;
+
+ err = i2c_transfer(client-adapter, msg, 1);
+
+ if (err = 0) {
+ err = ((data[0] 0xFF) 8) | (data[1]);
+ *value = err;
+ return 0;
+ }
+ return
Re: CinergyT2 not working with newer alternative driver
Jason Harvey wrote: Thierry Merle wrote: Hi Jason, Jason Harvey wrote: I have been successfully using VDR with two CinergyT2s for 18 months. After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping to get S2 capability and test a newer VDR for HD reception. The CinergyT2s stopped working. The kernel module loads, the blue leds flash as expected but they don't lock on to a signal for long. Signal strength shown in femon is erratic and a lock only rarely achieved. I checked through the mercurial tree to see what had changed. It looks like the following change is the one that stops the CinergyT2s working on my system. http://git.kernel.org/?p=linux/kernel/git/mchehab/devel.git;a=commit;h=986bd1e58b18c09b753f797df19251804bfe3e84 I deleted the newer version of the module and replace it with the previous deleted code. Make'd and installed the old version works as expected. Machine they're plugged into is running Fedora 10, 2.6.27.12-170.2.5.fc10.i686 I downloaded the current v4l-dvb today (31Jan2009) and tried it all again before posting this message. Not sure where to look next, I did start to capture the USB traffic to see if I could spot the difference... Please take a look at the message logs (dmesg). You can follow the instructions described here http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device and report where it fails. I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r -o output.mpg SomeChannel I am able to play with mplayer too. Regards, Thierry Hi Thierry, Thank you for the quick reply. I should have looked in dmesg before... Checking dmesg before I used tzap shows a problem. dvb-usb: recv bulk message failed: -110 Extract of dmesg dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/input/input8 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-5/input/input9 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. usbcore: registered new interface driver cinergyT2 dvb-usb: recv bulk message failed: -110 dvb-usb: recv bulk message failed: -110 Running tzap fails to tune/lock #tzap -a 0 -c channels.conf_dvbt -s -t 120 -r -o output.mpg BBC ONE using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf_dvbt' tuning to 50580 Hz video pid 0x0258, audio pid 0x0259 status 01 | signal c11f | snr | ber | unc | No more messages in dmesg. I shut down the PC, removed all power, unplugged the CinergyT2s, gave it twenty seconds and powered back up. Once it had booted I plugged in one of the devices and the dmesg output below. usb 2-5: new high speed USB device using ehci_hcd and address 3 usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64 usb 2-5: configuration #1 chosen from 1 choice usb 2-5: New USB device found, idVendor=0ccd, idProduct=0038 usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-5: Product: Cinergy T? usb 2-5: Manufacturer: TerraTec GmbH dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-5/input/input9 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. usbcore: registered new interface driver cinergyT2 dvb-usb: recv bulk message failed: -110 Cannot tzap or scan. With the old version of the driver I don't have any trouble at all. I do have this bulk message error too,
Re: [PATCH] tw9910: color format check is added on set_fmt
On Mon, 2 Feb 2009, morimoto.kunin...@renesas.com wrote: Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com Why is this needed? Do you see any possibility for tw9910 to be called with an unsupported format? for example, capture_example -f use V4L2_PIX_FMT_YUYV. but tw9910 support only V4L2_PIX_FMT_VYUY now. But are you actually getting this set_fmt(V4L2_PIX_FMT_YUYV) in your tw9910 driver? If yes, then this is a bug elsewhere. It shouldn't get this far. It should be caught earlier along the path soc_camera_s_fmt_vid_cap() soc_camera_try_fmt_vid_cap() sh_mobile_ceu_try_fmt() soc_camera_xlate_by_fourcc() error If you think this patch is unnecessary, please ignore it. Could you please test whether you indeed can get an unsupported format in your driver. If so, this is a bug at a higher level and we'll have to fix it there. I'll drop this patch for now. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe 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] tw9910: color format check is added on set_fmt
Dear Guennadi If you think this patch is unnecessary, please ignore it. Could you please test whether you indeed can get an unsupported format in your driver. If so, this is a bug at a higher level and we'll have to fix it there. I'll drop this patch for now. tw9910 driver can not get an unsupported format. host driver (sh_mobile_ceu) check it and return error. I just thought double check is important. sorry. Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
