saa716x driver for DNTV Live! Dual Hybrid PCI-Express S3
Hello, I recently purchased a pair of DNTV Live! Dual Hybrid PCI-Express S3 cards (see http://www.digitalnow.com.au/product_pages/DNTVDualS3.html) without properly checking that they were supported under Linux. Silly me. I see that Manu Abraham is currently working on a saa716x driver, so I have begun trying to get the driver working with my cards. I understand that this is still a work in progress so if I am too premature please tell me to rack off. However if I can be any help testing the driver (or whatever) I would like to contribute. Currently I have managed to load the saa716x_hybrid module - although I'm not seeing any relevant traces in the kernel logs. Also no adapter devices are being created. Anyway thanks for the saa716x driver and v4l/dvb in general. regards, Damien. P.S results of lsmod and lspci. abraxas tmp # lsmod Module Size Used by saa716x_hybrid 10824 0 saa716x_core 59508 1 saa716x_hybrid dvb_core 87916 2 saa716x_hybrid,saa716x_core tda1004x 15748 1 saa716x_hybrid nvidia 7800392 26 abraxas tmp # lspci -s 07:00.0 -vvxxx 07:00.0 Multimedia controller: Philips Semiconductors Device 7162 (rev 01) Subsystem: KWorld Computer Co. Ltd. Device 7523 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 5 Region 0: Memory at fbd0 (64-bit, non-prefetchable) [size=1M] Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Count=1/32 Enable- Address: Data: Capabilities: [50] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 256ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 4us, L1 64us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [74] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Vendor Specific Information ? Capabilities: [100] Vendor Specific Information ? 00: 31 11 62 71 07 01 10 00 01 00 80 04 10 00 00 00 10: 04 00 d0 fb 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 17 23 75 30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 00 00 40: 05 50 8a 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 10 74 01 00 80 00 28 00 10 00 0a 00 11 6c 03 01 60: 08 00 11 00 00 0a 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 01 80 02 3e 00 00 00 00 00 00 00 00 80: 09 00 50 00 03 0c 00 00 02 02 00 00 00 00 00 00 90: 00 07 00 00 00 00 00 08 00 00 10 00 00 00 00 00 a0: 01 00 00 04 03 00 00 00 00 00 01 07 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 20 01 2a 00 00 c0: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- To unsubscribe from this list: send the line unsubscribe 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] [PATCH] New frequency table for Cadiz (Andalusia, Spain)
2009/2/20 xiter...@gmail.com: # HG changeset patch # User ter...@xiterrex.net # Date 1235153250 -3600 # Node ID 078bd274de0d26a92ccff6c7da050edbc299f0b7 # Parent f83a2a650df2bcf2ce659012f011ee5dcd7b1d74 New frequency table for Cadiz (Andalusia, Spain) Thanks, added :) Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
Hi Trent,
On Sun, 1 Mar 2009 06:38:03 -0800 (PST), Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans Verkuil wrote:
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran for the
following:
I have some questions about your changes.
(...)
- zoran: remove broken BIGPHYS_AREA and BUZ_HIMEM code, and allow for
kmallocs 128 kB
It looks like the last time the bigphys_area patch was updated was to
2.6.11 so there probably isn't much point is supporting that anymore. But
is the highmem code broken? Trying to allocate multiple megabyte buffers
on systems without gigabytes of memory doesn't work very well. You get
nice things like this in your kernel log:
tvtime: page allocation failure. order:8, mode:0x40d0
[b0138243] __alloc_pages+0x29b/0x2aa
[b014a371] __slab_alloc+0x192/0x343
This can be fixed with the following patch:
Subject: zoran: Don't frighten users with failed buffer allocation
kmalloc() can fail for large video buffers. By default the kernel
complains loudly about allocation failures, but we don't want to
frighten the user, so ask kmalloc() to keep quiet on such failures.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/zoran/zoran_driver.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- v4l-dvb-zoran.orig/linux/drivers/media/video/zoran/zoran_driver.c
2009-02-23 09:48:49.0 +0100
+++ v4l-dvb-zoran/linux/drivers/media/video/zoran/zoran_driver.c
2009-02-23 12:51:21.0 +0100
@@ -212,7 +212,8 @@ v4l_fbuffer_alloc (struct file *file)
ZR_DEVNAME(zr), i);
//udelay(20);
- mem = kmalloc(fh-v4l_buffers.buffer_size, GFP_KERNEL);
+ mem = kmalloc(fh-v4l_buffers.buffer_size,
+ GFP_KERNEL | __GFP_NOWARN);
if (!mem) {
dprintk(1,
KERN_ERR
Some other v4l drivers do that already. Of course the allocation still
fails. But I doubt that restoring the highmem code is the right fix. For
one thing, it didn't work for me when I tried it. Did it ever work for
you? For another, I remember the big fat warning next to that piece of
code, which said that if any other piece of kernel code tried to do the
same, everything would break into pieces.
So, if the allocation failures are really an issue for anyone out there,
I'd rather have the zr36067 driver (optionally) pre-allocate buffers so
that it stands are greater chance to get them. This should be fairly
easy to implement, and safe too.
I am curious if the allocation problem really bothers anyone though. I
suspect that users that have a Zoran adapter on low-memory machines use
the MJPEG interface (lavrec/lavplay) and not the V4L2 interface.
- zoran: use slider flag with volume etc. controls.
Volume control? zoran has no audio.
- zoran: fix field typo.
Why not merge this patch into the patch that created the typo? It only
takes seconds if you use the features of modern SCMs.
- zoran: set bytesperline to 0 when using MJPEG.
Why not merge this patch into the one that created the bug?
While I tend to agree with you, I fear it is too late in this case, as
Mauro as already pulled Hans' changes.
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
On Sun, 22 Feb 2009, Hans Verkuil wrote:
Also the v4l1 ioctls have been removed and instead zoran relies on the v4l1
compat layer.
I tried testing v4l1 with mplayer and it doesn't seem to work correctly.
[pid 29030] ioctl(3, VIDIOCSYNC, 0x884d790) = -1 EBUSY (Device or resource busy)
[pid 29030] gettimeofday({1235920259, 869629}, NULL) = 0
[pid 29030] ioctl(3, VIDIOCMCAPTURE, 0x884d790) = -1 EBUSY (Device or resource
busy)
[pid 29030] write(2, \nioctl mcapture failed: Device o..., 48
VIDIOCSYNC and VIDIOCMCAPTURE always return EBUSY. Though, it does appear
that mplayer and the driver actually do work and capture video.
It looks like this is because v4l1-compat calls VIDIOC_STREAMON for each
call to VIDIOCMCAPTURE or VIDIOCSYNC. The zoran driver returns EBUSY if
you try to do that while streaming is already on.
Maybe the zoran driver should detect stream on from a file handle that
already has streaming on as a no-op? Or maybe v4l1-compat should ignore
EBUSY errors from VIDIOC_STREAMON in those compat functions?
Fixing this in correctly in v4l1-compat is hard because that module doesn't
have any device state so it can't keep track if it needs to call
VIDIOC_STREAMON or not. Lots of v4l1 apps expect that the driver will
start streaming automatically when they call VIDIOCMCAPTURE.
--
To unsubscribe from this list: send the line unsubscribe 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: Topro 6800 driver
Hi Anders and others, I have already tried to create a module for my webcam (Topro TP6800). It have the same usb id (06a2:0003). But I have the same problem as you about the image data. I don't know what is the comment tag (FF:FE). I tried to skip the tag or to skip the comment with the length after this tag but the image is never good. I don't know where start the image. If you want an example of the bad result you can download this image : http://lafeuil.free.fr/webcam/images/1.jpg So, I am also in the dark. If you want to take a look to my code, you can download this file : http://lafeuil.free.fr/webcam/tp6800.c If somebody have an idea how can I transform the data, Tell me ! Good luck Thomas Champagne 2009/2/28 Anders Blomdell anders.blomd...@control.lth.se: Jean-Francois Moine wrote: On Fri, 27 Feb 2009 23:15:54 +0100 Anders Blomdell anders.blomd...@control.lth.se wrote: Hi, I'm trying to write a driver for a webcam based on Topro TP6801/CX0342 (06a2:0003). My first attempt (needs gspca) can be found on: http://www.control.lth.se/user/andersb/tp6800.c Unfortunately the JPEG images (one example dump is in http://www.control.lth.se/user/andersb/topro_img_dump.txt), seems to be bogus, they start with (data is very similar to windows data): : 0xff,0xd8,0xff,0xfe,0x28,0x3c,0x01,0xe8,... ... c340: ...,0xf4,0xc0,0xff,0xd9 Anybody who has a good idea of how to find a DQT/Huffman table that works with this image data? Hi Anders, Thomas Champagne (See To:) was also writing a driver for this webcam. Maybe you may merge your codes... Thomas, if you have DQT/Huffman tables for this camera, please drop me a note. About the JPEG images, the Huffman table is always the same Does this mean that it's the same for all JPEG images or only for one camera? If it's the same for all images, it should mean that I have a way to determine how much I have to chop off after the 0xfffe tag (no illegal huffman codes - possibly chop at the correct position). Comments anyone? and the quantization tables depend on the compression quality. From the USB trace I had from Thomas, I saw that: - when a packet starts with '55 ff d8', it is the first part of the image. This one should start at the offset 8 of the packet. - when a packet starts with 'cc', it is the next part of the image. This is even in the docs, and is implemented in the driver. In the function pkt_scan, when finding the image start, you must add the JPEG header: 'ff d8', DQT, huffman table, SOF0 and SOS. OK, will see if I can find the DQT (and possibly the Huffman table) in the windows driver (as suggested by Thomas Kaiser). As we don't know the quality used by the webcam, in my test repository, I added a control for that: the JPEG header is created at streamon time, and the quantization tables may be modified by the control on the fly (have a look at stk014.c for an example). This solution is not the right one: the JPEG quality must be set by the VIDIOC_S_JPEGCOMP ioctl instead of VIDIOC_S_CTRL. I think I will update the concerned subdrivers next week. I'll look into that monday. BTW, don't use the video4linux-l...@redhat.com mailing-list anymore: all the video discussions are now done in linux-me...@vger.kernel.org. OK, so Google hit http://www.linuxtv.org/v4lwiki/index.php/Main_Page is no hit then... Thanks Anders Blomdell -- To unsubscribe from this list: send the line unsubscribe 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://linuxtv.org/hg/~mkrufky/mxl5007t
Mauro, Please pull from: http://linuxtv.org/hg/~mkrufky/mxl5007t for the following: - mxl5007t: remove analog tuning code - mxl5007t: remove function mxl5007t_check_rf_input_power - mxl5007t: mxl5007t_get_status should report if tuner is locked - mxl5007t: warn when unknown revisions are detected - mxl5007t: fix devname for hybrid_tuner_request_state - mxl5007t: update driver for MxL 5007T V4 mxl5007t.c | 445 + 1 file changed, 146 insertions(+), 299 deletions(-) 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
On Sunday 01 March 2009 15:38:03 Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans Verkuil wrote:
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran for
the following:
I have some questions about your changes.
- zoran: convert to video_ioctl2 and remove 'ready_to_be_freed' hack.
It looks like this patch deleted the code relating to this comment:
* We don't free the buffers right on munmap() because that
* causes oopses (kfree() inside munmap() oopses for no
* apparent reason - it's also not reproduceable in any way,
* but moving the free code outside the munmap() handler fixes
* all this... If someone knows why, please explain me (Ronald)
Do you have an explanation of why it's safe to do this? There's nothing
in the patch description (there is no patch description) about it.
I should have expanded on that. There were several reasons for doing this:
1) the hack itself wouldn't work anymore if you convert to video_ioctl2
since there is no easy entrypoint for all the ioctls. It's not the reason
for removing it, but it is what brought it to my attention.
2) it's a really ancient hack and I'm convinced whatever bug caused this has
long since been fixed.
3) if there still is a bug, then this code isn't the way to do it, you need
to fix the real bug.
Rather than do difficult things to keep a highly questionable patch alive I
removed it in its entirely. Should it crop up, then I'll fix it the right
way. This driver is full of cruft and stuff like this only makes it hard to
maintain. Note that in all the testing that this driver got it hasn't been
seen at all.
- zoran: remove broken BIGPHYS_AREA and BUZ_HIMEM code, and allow for
kmallocs 128 kB
It looks like the last time the bigphys_area patch was updated was to
2.6.11 so there probably isn't much point is supporting that anymore.
But is the highmem code broken? Trying to allocate multiple megabyte
buffers on systems without gigabytes of memory doesn't work very well.
You get nice things like this in your kernel log:
tvtime: page allocation failure. order:8, mode:0x40d0
[b0138243] __alloc_pages+0x29b/0x2aa
[b014a371] __slab_alloc+0x192/0x343
See Jean's answer. I couldn't get highmem to work either, although I admit
that I didn't spend much time on it.
- zoran: use slider flag with volume etc. controls.
Volume control? zoran has no audio.
My mistake. I meant brightness, contrast, etc.
- zoran: fix field typo.
Why not merge this patch into the patch that created the typo? It only
takes seconds if you use the features of modern SCMs.
A typo in the zoran driver before I started work on it, not a typo in one of
my patches.
- zoran: set bytesperline to 0 when using MJPEG.
Why not merge this patch into the one that created the bug?
Also a bug in the zoran driver before I started to work on it.
- zoran: fix G_FMT
You sure about that? Each jpeg buffer only has one field.
It brings it in line with the behavior of S_FMT and TRY_FMT. Whether those
are correct is questionable, but with this fix in I at least get back the
same format with G_FMT as I set with S_FMT. Before I would get back half
the height.
- zoran: if reqbufs is called with count == 0, do a streamoff.
Did you mean to change the debug level of those printks? It's not in
your patch description.
Yes, that was intentional. These messages are fine at higher debug levels,
but I don't want to see them during normal operation.
- zoran: TRY_FMT and S_FMT now do the same parameter checks.
Is this is mistake that was left off of a previous patch? No patch
description so I'm not sure.
No, this is a real fix for pre-existing zoran driver bugs.
- bt819: convert to v4l2_subdev.
- bt819: that delay include is needed after all.
Can these two not be folded?
Yes.
- zoran: convert to v4l2_device/v4l2_subdev.
+static const unsigned short adv717x_addrs[] = { 0x6a, 0x6b, 0x2a, 0x2b,
I2C_CLIENT_END };
adv7171/5 are at 0x2a and 0x2b, while adv7170 is at 0x6a and 0x6b.
Is this from the datasheets? The drivers say that adv7170/5 are at 0x6a/6b,
while adv7171/6 are at 0x2a/b. In other words, they both use the same four
addresses. I didn't check the datasheets, though.
- zoran: increase bufsize to a value suitable for 768x576.
How about folding this into the first patch that changed v4l_bufsize to
810?
A bit too late :-(
This is a huge patch series that brings the zoran driver completely up
to date with the latest v4l2 framework. In particular it converts it to
use video_ioctl2, the communication with the i2c modules is converted
to from v4l1 to v4l2 and that made the conversion to
v4l2_device/v4l2_subdev possible.
As a result of this the saa7111.c and saa7114.c drivers are removed and
instead the saa7115.c driver is used which can handle these older
saa711x devices as well.
Any figures for driver size before and after?
Which driver? saa7115 is of course unchanged, but
[PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx
Mauro, Please pull from: http://linuxtv.org/hg/~mkrufky/sms1xxx for the following: - smsusb: whitespace cleanups - smscore: whitespace cleanups - smsusb: add autodetection for nice and venice boards sms-cards.c |8 + sms-cards.h |2 smscoreapi.c | 138 -- smscoreapi.h | 289 +++ smsusb.c | 47 +++--- 5 files changed, 242 insertions(+), 242 deletions(-) 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
WinTV HVR-1800 analog Satus
Any update on the status of analouge for this card? I really would like to switch back to Linux as my mce solution, but last time I did, the analouge was terrible, and I was getting no answers on the list... Thanks, Dustin Coates Sent from my iPhone On Mar 1, 2009, at 10:36 AM, David Woitkowski ja...@campus.upb.de wrote: Hi out there I'm in the unfortunate position of having bought a 900H instead of a 900 and now I'm fiddling with the driver. Details: $ lsusb | grep Hauppauge Bus 008 Device 004: ID 2040:6600 Hauppauge My machine is running Ubuntu 8.10 with a 2.6.27-11-generic kernel. The correct kernel-headers are installed. As far as I've read there is (limited) support for the device with the tm6010 driver. Putting together some info from the web I did the following: $ hg clone http://linuxtv.org/hg/v4l-dvb $ cd v4l-dvb $ hg pull -u http://linuxtv.org/hg/~mchehab/tm6010 Inserted into v4l-dvb/v4l/.config three lines: CONFIG_VIDEO_TM6000_ALSA=m CONFIG_VIDEO_TM6000=m CONFIG_VIDEO_TM6000_DVB=m $ hg merge $ make and as root: # make install This far everything worked without error. Then I got the Firmware the card was requesting in the dmesg-output from http://steventoth.net/linux/hvr1400/xc3028L-v36.fw and copied it to / lib /firmware Since there is no Module tm6000 I did # modprobe -v tm6000 insmod /lib/modules/2.6.27-11-generic/kernel/drivers/media/video/videobuf- core.ko insmod /lib/modules/2.6.27-11-generic/kernel/drivers/media/video/videobuf- vmalloc.ko insmod /lib/modules/2.6.27-11-generic/kernel/drivers/i2c/i2c-core.ko insmod /lib/modules/2.6.27-11-generic/kernel/drivers/media/video/tm6000/ tm6000.ko $ dmesg [ 187.646908] tm6000 v4l2 driver version 0.0.1 loaded [ 187.647898] usbcore: registered new interface driver tm6000 (tail /var/log/messages gives the same info) Now - as I hope the module is loaded correctly - I attacht the USB- Device: $ dmesg [ 373.881042] usb 8-1: new high speed USB device using ehci_hcd and address 3 [ 374.019648] usb 8-1: configuration #1 chosen from 1 choice [ 374.023090] tm6000: alt 0, interface 0, class 255 [ 374.023102] tm6000: alt 0, interface 0, class 255 [ 374.023107] tm6000: Bulk IN endpoint: 0x82 (max size=512 bytes) [ 374.023111] tm6000: alt 0, interface 0, class 255 [ 374.023116] tm6000: alt 1, interface 0, class 255 [ 374.023120] tm6000: ISOC IN endpoint: 0x81 (max size=3072 bytes) [ 374.023125] tm6000: alt 1, interface 0, class 255 [ 374.023129] tm6000: alt 1, interface 0, class 255 [ 374.023133] tm6000: alt 2, interface 0, class 255 [ 374.023137] tm6000: alt 2, interface 0, class 255 [ 374.023141] tm6000: alt 2, interface 0, class 255 [ 374.023145] tm6000: alt 3, interface 0, class 255 [ 374.023149] tm6000: alt 3, interface 0, class 255 [ 374.023153] tm6000: alt 3, interface 0, class 255 [ 374.023158] tm6000: New video device @ 480 Mbps (2040:6600, ifnum 0) [ 374.023162] tm6000: Found Hauppauge HVR-900H [ 374.884058] Error -32 while retrieving board version [ 375.184050] tm6000 #0: i2c eeprom 00: 01 59 54 45 12 01 00 02 00 00 00 40 40 20 00 66 .YTE...@@ .f [ 375.380112] tm6000 #0: i2c eeprom 10: 69 00 10 20 40 01 02 03 48 00 79 00 62 00 72 00 i.. @...H.y.b.r. [ 375.572058] tm6000 #0: i2c eeprom 20: ff 00 64 ff ff ff ff ff ff ff ff ff ff ff ff ff ..d. [ 375.764038] tm6000 #0: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 375.956103] tm6000 #0: i2c eeprom 40: 10 03 48 00 56 00 52 00 39 00 30 00 30 00 48 00 ..H.V.R.9.0.0.H. [ 376.148062] tm6000 #0: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 376.344055] tm6000 #0: i2c eeprom 60: 30 ff ff ff 0f ff ff ff ff ff 0a 03 32 00 2e 00 0...2... [ 376.536039] tm6000 #0: i2c eeprom 70: 3f 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ?... [ 376.728041] tm6000 #0: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 376.920041] tm6000 #0: i2c eeprom 90: 35 ff ff ff 16 03 34 00 30 00 33 00 32 00 31 00 5.4.0.3.2.1. [ 377.112039] tm6000 #0: i2c eeprom a0: 33 00 35 00 33 00 39 00 39 00 00 00 00 00 ff ff 3.5.3.9.9... [ 377.308054] tm6000 #0: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 377.500046] tm6000 #0: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 377.692053] tm6000 #0: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 377.885037] tm6000 #0: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 378.076042] tm6000 #0: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 378.260374] [ 378.260531] Trident TVMaster TM5600/TM6000 USB2 board (Load status: 0) [ 378.320709] Hack: enabling device at addr 0xc2 [ 378.320722] tuner' 0-0061: chip found @ 0xc2 (tm6000 #0) [ 378.362555] xc2028 0-0061: creating
[PATCH] libv4lconvert support for SQ905C decompression
Hans,
Below is a patch for libv4lconvert, to support the decompression used by
the SQ905C cameras (0x2770:0x905C) and some other related cameras. There
is at the moment no support module for these cameras in streaming mode,
but I intend to submit one.
This contribution was created in whole by me, based upon code in
libgphoto2 which was created in whole by me, and which was licensed for
libgphoto2 under the LGPL license.
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
The content of the file sq905c.patch follows
---
diff -uprN libv4lconvert-old/Makefile libv4lconvert-new/Makefile
--- libv4lconvert-old/Makefile 2009-03-01 15:37:38.0 -0600
+++ libv4lconvert-new/Makefile 2009-03-01 14:19:14.0 -0600
@@ -12,7 +12,7 @@ endif
CONVERT_OBJS = libv4lconvert.o tinyjpeg.o sn9c10x.o sn9c20x.o pac207.o \
mr97310a.o flip.o crop.o jidctflt.o spca561-decompress.o \
- rgbyuv.o spca501.o bayer.o
+ rgbyuv.o spca501.o sq905c.o bayer.o
TARGETS = $(CONVERT_LIB) libv4lconvert.pc
INCLUDES = ../include/libv4lconvert.h
diff -uprN libv4lconvert-old/libv4lconvert-priv.h
libv4lconvert-new/libv4lconvert-priv.h
--- libv4lconvert-old/libv4lconvert-priv.h 2009-03-01 15:37:38.0
-0600
+++ libv4lconvert-new/libv4lconvert-priv.h 2009-03-01 17:12:02.0
-0600
@@ -47,6 +47,10 @@
#define V4L2_PIX_FMT_MR97310A v4l2_fourcc('M','3','1','0')
#endif
+#ifndef V4L2_PIX_FMT_SQ905C
+#define V4L2_PIX_FMT_SQ905C v4l2_fourcc('9','0','5','C')
+#endif
+
#ifndef V4L2_PIX_FMT_PJPG
#define V4L2_PIX_FMT_PJPG v4l2_fourcc('P', 'J', 'P', 'G')
#endif
@@ -180,6 +184,9 @@ void v4lconvert_decode_pac207(const unsi
void v4lconvert_decode_mr97310a(const unsigned char *src, unsigned char *dst,
int width, int height);
+void v4lconvert_decode_sq905c(const unsigned char *src, unsigned char *dst,
+ int width, int height);
+
void v4lconvert_bayer_to_rgb24(const unsigned char *bayer,
unsigned char *rgb, int width, int height, unsigned int pixfmt);
diff -uprN libv4lconvert-old/libv4lconvert.c libv4lconvert-new/libv4lconvert.c
--- libv4lconvert-old/libv4lconvert.c 2009-03-01 15:37:38.0 -0600
+++ libv4lconvert-new/libv4lconvert.c 2009-03-01 17:13:42.0 -0600
@@ -61,6 +61,7 @@ static const struct v4lconvert_pixfmt su
{ V4L2_PIX_FMT_SN9C10X, V4LCONVERT_COMPRESSED },
{ V4L2_PIX_FMT_PAC207, V4LCONVERT_COMPRESSED },
{ V4L2_PIX_FMT_MR97310A, V4LCONVERT_COMPRESSED },
+ { V4L2_PIX_FMT_SQ905C, V4LCONVERT_COMPRESSED },
{ V4L2_PIX_FMT_PJPG, V4LCONVERT_COMPRESSED },
};
@@ -608,6 +609,7 @@ static int v4lconvert_convert_pixfmt(str
case V4L2_PIX_FMT_SN9C10X:
case V4L2_PIX_FMT_PAC207:
case V4L2_PIX_FMT_MR97310A:
+case V4L2_PIX_FMT_SQ905C:
{
unsigned char *tmpbuf;
@@ -633,6 +635,10 @@ static int v4lconvert_convert_pixfmt(str
v4lconvert_decode_mr97310a(src, tmpbuf, width, height);
src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
break;
+ case V4L2_PIX_FMT_SQ905C:
+ v4lconvert_decode_sq905c(src, tmpbuf, width, height);
+ src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
+ break;
}
src = tmpbuf;
/* Deliberate fall through to raw bayer fmt code! */
diff -uprN libv4lconvert-old/sq905c.c libv4lconvert-new/sq905c.c
--- libv4lconvert-old/sq905c.c 1969-12-31 18:00:00.0 -0600
+++ libv4lconvert-new/sq905c.c 2009-03-01 17:08:12.0 -0600
@@ -0,0 +1,222 @@
+/*
+ * sq905c.c
+ *
+ * Here is the decompression function for the SQ905C cameras. The functions
+ * used are adapted from the libgphoto2 functions for the same cameras,
+ * which was
+ * Copyright (c) 2005 and 2007 Theodore Kilgore kilg...@auburn.edu
+ * This version for libv4lconvert is
+ * Copyright (c) 2009 Theodore Kilgore kilg...@auburn.edu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include stdlib.h
+
+#include libv4lconvert-priv.h
+
+
+#define CLIP(x) ((x)0?0:((x)0xff)?0xff:(x))
+
+
+static int
+sq905c_first_decompress (unsigned char *output, unsigned char *input,
+ unsigned int outputsize)
+{
+ unsigned char parity = 0;
+
[OMAPZOOM][PATCH] CAM: Make omap3 camera interface driver more generic for external camera devices.
Hello.
Since I was working on omap3 and external ISP device, I found some
hard coded thing in camera interface codes which make dependency on
sensor or ISP device. With that code, we cannot make omap3 camera
interface driver generic for every target board.
It makes dependency on camera device mounted on target board, and
therefore we need to modify omap3 camera interface driver when we do
our porting job.
Please find following patch which I tried to make more generic for
omap3 camera interface driver. Just designate expecting colorspace
from external camera module in board file, then no need to modify
try_pix_parm() function.
Any comments will be welcomed.
Cheers,
Nate
From f8062b8678fa8f8d9e694fb796431cf340112fa3 Mon Sep 17 00:00:00 2001
From: Dongsoo Kim dongsoo45@samsung.com
Date: Thu, 26 Feb 2009 20:32:18 +0900
Subject: [PATCH] CAM: Make try_pix_parm() negotiable with board
specific sensor config.
Removed hard coded pixelformat in camera interface driver
Signed-off-by: Dongsoo Kim dongsoo45@samsung.com
---
arch/arm/mach-omap2/board-3430sdp.c |6 ++
arch/arm/mach-omap2/board-ldp.c |2 ++
arch/arm/mach-omap2/board-zoom2.c |2 ++
drivers/media/video/omap34xxcam.c |5 +++--
drivers/media/video/omap34xxcam.h |1 +
5 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index b96954f..b075568 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -604,6 +604,7 @@ static void __iomem *fpga_map_addr;
static struct omap34xxcam_sensor_config cam_hwc = {
.sensor_isp = 0,
.xclk = OMAP34XXCAM_XCLK_A,
+ .pixelformat = V4L2_PIX_FMT_SGRBG10,
.capture_mem = PAGE_ALIGN(2592 * 1944 * 2) * 4,
};
@@ -640,6 +641,7 @@ static int mt9p012_sensor_set_prv_data(void *priv)
hwc-u.sensor.xclk = cam_hwc.xclk;
hwc-u.sensor.sensor_isp = cam_hwc.sensor_isp;
+ hwc-u.sensor.pixelformat = cam_hwc.pixelformat;
hwc-u.sensor.capture_mem = cam_hwc.capture_mem;
hwc-dev_index = 0;
hwc-dev_minor = 0;
@@ -769,6 +771,7 @@ static struct omap34xxcam_sensor_config ov3640_hwc = {
#else
.xclk = OMAP34XXCAM_XCLK_A,
#endif
+ .pixelformat = V4L2_PIX_FMT_RGB565,
.capture_mem = PAGE_ALIGN(2048 * 1536 * 2) * 2,
};
@@ -804,6 +807,7 @@ static int ov3640_sensor_set_prv_data(void *priv)
hwc = priv;
hwc-u.sensor.xclk = ov3640_hwc.xclk;
hwc-u.sensor.sensor_isp = ov3640_hwc.sensor_isp;
+ hwc-u.sensor.pixelformat = ov3640_hwc.pixelformat;
hwc-u.sensor.capture_mem = ov3640_hwc.capture_mem;
hwc-dev_index = 1;
hwc-dev_minor = 4;
@@ -953,6 +957,7 @@ static struct ov3640_platform_data
sdp3430_ov3640_platform_data = {
static struct omap34xxcam_sensor_config imx046_hwc = {
.sensor_isp = 0,
.xclk= OMAP34XXCAM_XCLK_B,
+ .pixelformat = V4L2_PIX_FMT_SGRBG10,
.capture_mem = PAGE_ALIGN(3280 * 2464 * 2) * 2,
};
@@ -962,6 +967,7 @@ static int imx046_sensor_set_prv_data(void *priv)
hwc-u.sensor.xclk = imx046_hwc.xclk;
hwc-u.sensor.sensor_isp = imx046_hwc.sensor_isp;
+ hwc-u.sensor.pixelformat = imx046_hwc.pixelformat;
hwc-dev_index = 2;
hwc-dev_minor = 5;
hwc-dev_type = OMAP34XXCAM_SLAVE_SENSOR;
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index f8a9e47..5b01e76 100755
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -610,6 +610,7 @@ static struct omap34xxcam_sensor_config ov3640_hwc = {
#else
.xclk = OMAP34XXCAM_XCLK_A,
#endif
+ .pixelformat = V4L2_PIX_FMT_RGB565,
.capture_mem = 2592 * 1944 * 2 * 2,
};
@@ -644,6 +645,7 @@ static int ov3640_sensor_set_prv_data(void *priv)
hwc = priv;
hwc-u.sensor.xclk = ov3640_hwc.xclk;
+ hwc-u.sensor.pixelformat = ov3640_hwc.pixelformat;
hwc-u.sensor.sensor_isp = ov3640_hwc.sensor_isp;
hwc-dev_index = 1;
hwc-dev_minor = 4;
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 5ecc71e..806a4a5 100755
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -331,6 +331,7 @@ static struct twl4030_keypad_data ldp_kp_twl4030_data = {
static struct omap34xxcam_sensor_config imx046_hwc = {
.sensor_isp = 0,
.xclk= OMAP34XXCAM_XCLK_B,
+ .pixelformat = V4L2_PIX_FMT_SGRBG10,
.capture_mem = PAGE_ALIGN(3280 * 2464 * 2) * 2,
};
@@ -340,6 +341,7 @@ static int imx046_sensor_set_prv_data(void *priv)
hwc-u.sensor.xclk = imx046_hwc.xclk;
hwc-u.sensor.sensor_isp = imx046_hwc.sensor_isp;
+ hwc-u.sensor.pixelformat = imx046_hwc.pixelformat;
hwc-dev_index = 2;
hwc-dev_minor = 5;
hwc-dev_type = OMAP34XXCAM_SLAVE_SENSOR;
diff --git
[OMAPZOOM][PATCH] CAM: Make PACK8 mode on CCDC work only with CCIR-656
Hello,
Besides the patch I've posted couple of hours ago, there is one more
thing in omap3 ispccdc.c.
According to omap3 datasheet, PACK8 could be enabled only when
CCDC_SYN_MODE is with CCIR-656 mode.
If you try to use external camera module with ITU-R.601 mode without
this patch, you could face weird data from your camera interface.
Please find following patch, and any comments will be welcomed.
Cheers,
Nate
From 23425c97233c93f9b572351d8a93a13ae3cb3188 Mon Sep 17 00:00:00 2001
From: Dongsoo Kim dongsoo45@samsung.com
Date: Mon, 2 Mar 2009 11:01:14 +0900
Subject: [PATCH 2/2] CAM: Make PACK8 mode on CCDC work only with CCIR-656
Signed-off-by: Dongsoo Kim dongsoo45@samsung.com
---
drivers/media/video/isp/ispccdc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index 8f7e896..2945c6f 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -762,7 +762,8 @@ void ispccdc_config_sync_if(struct ispccdc_syncif syncif)
switch (syncif.datsz) {
case DAT8:
syn_mode |= ISPCCDC_SYN_MODE_DATSIZ_8;
- syn_mode |= ISPCCDC_SYN_MODE_PACK8; /* Added by MMS */
+ if (syncif.bt_r656_en)
+ syn_mode |= ISPCCDC_SYN_MODE_PACK8; /* Added by MMS */
break;
case DAT10:
syn_mode |= ISPCCDC_SYN_MODE_DATSIZ_10;
--
1.5.4.3
--
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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] soc-camera queue including a fix for 2.6.29
Dear Guennadi, Mauro, Paul Mauro, Guennadi When does following patch will be applyed ? 07/14: ov772x: Add image flip support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=859f610843c1 Because ALGO board (SH7723) needs platform patch. And 09/14: sh_mobile_ceu: SOCAM flags are not platform dependent http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=0928a1be9d4e MigoR and ALGO board needs new flags setting patches. I'm not sure when should I send patch to Paul ? 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: [PULL] soc-camera queue including a fix for 2.6.29
Hello Morimoto-san, On Mon, 2 Mar 2009, morimoto.kunin...@renesas.com wrote: Dear Guennadi, Mauro, Paul Mauro, Guennadi When does following patch will be applyed ? 07/14: ov772x: Add image flip support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=859f610843c1 Because ALGO board (SH7723) needs platform patch. And 09/14: sh_mobile_ceu: SOCAM flags are not platform dependent http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=0928a1be9d4e MigoR and ALGO board needs new flags setting patches. I'm not sure when should I send patch to Paul ? They are already in this tree: http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=tree;hb=HEAD 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
