firedtv driver development status
Hi lists, I planned to adapt drivers/media/dvb/firewire/firedtv* to use the drivers/firewire stack alternatively to drivers/ieee1394, and wanted to be done with it sooner than later. But business distracted too much, so nothing happened. This is how far I got, in case anybody is interested in finishing it before I am able to get back to it (don't know exactly when that will be): http://user.in-berlin.de/~s5r6/linux1394/pending/firewire-share-device-id-table-type-with-ieee1394.patch http://user.in-berlin.de/~s5r6/linux1394/pending/firewire-also-use-vendor-id-in-root-directory-for-driver-matches.patch http://user.in-berlin.de/~s5r6/linux1394/work-in-progress/firedtv-port-to-new-firewire-core.patch Device--driver matching, device probe and removal, and AV/C traffic all work. To do: - In firedtv: Implement allocation/initialization + deallocation of an iso reception context; implement iso reception callback. Also to do but independent of the port to firewire: - In firewire-core: Allow multiple users of the FCP register range (kernelspace and userspace users) in order to access more than one AV/C device. (I can do this too when I get the time.) - In firedtv: Implement reception of HD channels. (Somebody else needs to do it since I'm not familiar with the DVB subsystem.) -- Stefan Richter -=-=-=== -=-= -==-= http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)
Hi Theodore,
know where he lives) then perhaps to Thomas Kaiser, who lives a bit
closer to you. I think that all three of us are equally interested but as
Well, looks like I will send it to Thomas then. I'm glad that it can still be
useful.
Judging from the Vendor:Product number which you report, it is one of the
small MR97310 cameras for which the OEM driver was called the CIF
driver. Indeed, these cameras are not supported right now, so the matter
is interesting.
I tried simply adding the usb-id to the list in mr97310a.c, but as that didn't
produce anything useful (green screen), I thought I'll leave it to the pros :)
the SOF marker -- and this with the OEM driver software, too. But you say
that yours actually worked.
Yup, just downloaded some driver from the net (can look up the URL if needed).
Finally, I would ask one question:
In the libgphoto2 driver for these cameras, I have a listing for
{Elta Medi@ digi-cam, GP_DRIVER_STATUS_EXPERIMENTAL, 0x093a, 0x010e},
Do you think this is the same camera, or a different one? Yours has a
I am pretty sure this is the same camera. elta medi@ digi-cam is printed on
the front-side. The model number 8212DC is just on a glued label on the
down-side which may not be present on all charges or may have been removed or
got lost somehow. I could make pictures of the cam if this helps.
Also might you be interested to try it out as a still camera, with
libgphoto2, before surrendering it to someone else?
I am not at home this weekend, so I don't have access to my Linux-machines. I
have the camera with me as I tested it on a Windows machine here; I could
send it like tomorrow. Thomas, is it okay for you, if I leave this to you?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)
Maybe the idea from Theodore to send the cam to me is not such a bad idea ;-) I agree :) Should we discuss here for some days to find out who can make the most progress with this cam? I'd like to have the case closed for me rather sooner than later. If you mail me your address, I'll try to send the package tomorrow. Just in case Kyle has a terribly big need for the cam, you can surely negotiate something. Maybe passing dumps from time to time will help already... Wolfram, thanks for the offer to donate the cam! You are very welcome. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: Support for Skystar S2 and Twinhan AD-SP200/VP-1027
Bob Ingraham wrote: Hi All, Running Fedora Core 10 (2.6.27) and have looked through the wiki for support for: - Skystar S2 (DVB-S2) PCI - Twinhan AD-SP200/VP-1027 (DVB-S) PCI I'm guessing the wiki is out of date with regards to current status. Are there patches or a snapshot I can pull that has stable support for either of these cards? I went though all this like a 7-14 days ago. Everything is on the list, all repositories, all results. I had SkyStar HD2, but the driver is the same. AFAIK these are two very different cards and SkyStar S2 is probably working. I think it is used more frequently than my HD2, which, alas, was a total CRAP. I had 3 SkyStar HD2 cards in total and had to return them all. Why? Low quality HW (interference, no shielding...), Linux driver support exists (some, mainly the author, claim full support), but: DVB-S2 not working at all (unless you want to reboot every few minutes), zero HW sensitivity (90-95% signal strength - broken picture), MythTV cannot cope with it and breaks down all the time, little things like PWR/SNR/BER reporting not working, etc. Look up my mails and reports. There are even links to all the repositories. The newest one: hg clone http://jusst.de/hg/mantis-v4l As for my story: I exchanged the cards for TeVii S640 DVB-S2. After inserting the new cards and booting, my whole setup started to work - out of the box, with the setup I had for SkyStar, which was unusable previously. It was the HW/mantis driver after all. Just issuing my WARNING against TWINHAN chipsets generally. :) -- David -- 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: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)
On 05/01/2009 10:47 AM, Wolfram Sang wrote: Thomas, is it okay for you, if I leave this to you? Yes, I sent you my post address in private mail. Lets see what I can find out with this cam ;-) 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
[PULL] http://linuxtv.org/hg/~stoth/cleanup
Mauro, Please pull from http://www.linuxtv.org/hg/~stoth/cleanup - cx23885: Frontend wasn't locking on HVR-1500 - cx88: Add support for the Hauppauge IROnly board. - cx23885: Don't assume GPIO interrupts are cam related. Documentation/video4linux/CARDLIST.cx88|1 drivers/media/video/cx23885/cx23885-core.c | 10 +-- drivers/media/video/cx23885/cx23885-dvb.c |2 - drivers/media/video/cx88/cx88-cards.c | 13 ++ drivers/media/video/cx88/cx88-input.c |2 + drivers/media/video/cx88/cx88.h|1 6 files changed, 25 insertions(+), 4 deletions(-) Regards, - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Yes, I am working on it. maybe it is caused from ISP big size issue. I am trying to reduce the ISP driver code (around 800k) Xiaolin -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Thursday, April 30, 2009 5:33 PM To: Zhang, Xiaolin Cc: linux-media@vger.kernel.org; Johnson, Charles F; Zhu, Daniel Subject: Re: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers Hello Xiaolin, I think the first patch is missing. Following your description, it may be the Intel Moorestown ISP driver.. Can you re-post it please? BTW, I didn't notice that Atom processor had a camera interface, and even it supports dual camera as well. Can I find some datasheet or user manual to take a look at how it works? Cheers, Nate On Thu, Apr 30, 2009 at 5:18 PM, Zhang, Xiaolin xiaolin.zh...@intel.com wrote: Hi All, Here is the a set of V4L2 camera sensors and ISP drivers to support the Intel Moorestown camera imaging subsystem. The Camera Imaging interface in Moorestown is responsible for capturing both still and video frames. The CI handles demosaicing, color synthesis, filtering, image enhancement functions and JPEG encode. Intel Moorestown platform can support either a single camera or two cameras. A platform with two cameras will have on the same side as this display and the second on the opposite side the display. The camera on the display side will be used for video conferencing (with low resolution SoC cameras) and the other camera is used to still image capture or video recode (with high resolution RAW cameras). In this set of driver patches, I will submit the 5 patches to enable the ISP HW and 3 cameras module (two SoCs: 1.3MP - Omnivision 9665, 2MP - Omnivison 2650 and one RAW: 5MP - Omnivision 5630). 1. Intel Moorestown ISP driver. 2. Intel Moorestown camera sensor pseudo driver. This is to uniform the interfaces for ISP due to supporting dual cameras. 3. Intel Moorestown 2MP camera sensor driver. 4. Intel Moorestown 5MP camera sensor driver. 5. Intel Moorestown 1.3MP camera sensor driver. I will post the above 5 patches in near feature. Regards, Xiaolin xiaolin.zh...@intel.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 -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications 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: [PATCH 2/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Hello, Xiaolin On Fri, May 1, 2009 at 6:57 PM, Zhang, Xiaolin xiaolin.zh...@intel.com wrote: No mind, welcome any comments. Oops, i already did. Probably comments are lost in big letter, please find them :) I am working on this issue why the first patch -isp drive can't send it out. Actually it is a little bit large, size about 800k. I need time to split it. Well, you can send link to it if possible, but yes - spliting it is better. BRs Xiaolin -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri May 1 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11658:83712d149893 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-rc3-armv5: WARNINGS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc3-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc3-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc3-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-rc3-m32r: WARNINGS linux-2.6.22.19-mips: WARNINGS linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29.1-mips: WARNINGS linux-2.6.30-rc3-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc3-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-rc3-x86_64: WARNINGS fw/apps: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)
Hello,
Am Freitag, den 01.05.2009, 12:40 -0500 schrieb Theodore Kilgore:
On Fri, 1 May 2009, Wolfram Sang wrote:
Hi Theodore,
know where he lives) then perhaps to Thomas Kaiser, who lives a bit
closer to you. I think that all three of us are equally interested but as
Well, looks like I will send it to Thomas then. I'm glad that it can still
be
useful.
I am glad that this is so easily resolved. As I said, I do not know where
Kyle lives. If he is somewhere like UK then it would have been possible to
get it to him easily, too. But if he is in the US, like me, then it seems
that sending the camera for such a distance would simply be impractical.
Judging from the Vendor:Product number which you report, it is one of the
small MR97310 cameras for which the OEM driver was called the CIF
driver. Indeed, these cameras are not supported right now, so the matter
is interesting.
I meant, not supported for streaming. The camera ought to be well
supported as a still camera.
I tried simply adding the usb-id to the list in mr97310a.c, but as that
didn't
produce anything useful (green screen), I thought I'll leave it to the pros
:)
Heh. No, that is not enough. Been there. Done that.
snip
Finally, I would ask one question:
In the libgphoto2 driver for these cameras, I have a listing for
{Elta Medi@ digi-cam, GP_DRIVER_STATUS_EXPERIMENTAL, 0x093a, 0x010e},
Do you think this is the same camera, or a different one? Yours has a
I am pretty sure this is the same camera. elta medi@ digi-cam is printed
on
the front-side. The model number 8212DC is just on a glued label on the
down-side which may not be present on all charges or may have been removed
or
got lost somehow. I could make pictures of the cam if this helps.
I have the impression you sent another mail, now, with the picture. I have
not looked at the picture, actually. But the picture would probably not
help me at all, because I myself have never seen one of these cameras.
What I know about the camera is well summarized in the following entry
from libgphoto2/camlibs/mars/ChangeLog:
2004-10-26 Theodore Kilgore kilg...@auburn.edu
* library.c: ID for Haimei HE-501A, reported by
Scott MacKenzie irratio...@poboxes.com
ID for Elta Medi@ digicam, reported by
Nils Naumann, n...@gmx.net
Support patch submitted by Scott, tested by Nils.
* mars.c:Scott's patch applied.
* protocol.txt: byte codes for new 352x288 and 176x144 resolution
settings recorded; section UPDATES and REVISIONS
added.
This is the total extent of my knowledge. It does seem, judging from the
address of the person who sent me the information about it, and from
yours, that the Elta brand is probably local to Europe.
for elta GmbH,
they are originally located in Germany and have a quite good reputation
for fancy lifestyle products, many imported from Asia, these days mostly
China, but started with quality products from Japan.
One of the services they also offer is to create new brands of products
for customers, coordinated over elta Hong Kong, which includes proper
package design, two years warranty and a readable user manual ;)
I have an early appearance of the saa7134 chip as elta medi@ 8682 LV
LifeView FlyVideo 3000 with remote and maybe the first TCL tuner seen
here. Copyright and Trademark Notice in the user manual.
(C) 2001 by Animations Technologies Inc. for this one.
Can be found searching for Elta at the www.bttv-gallery.de.
You can find all contact information for elta here.
http://www.elta.de
Finally, one of the main reasons why I pass this on is to point out that
especially in the cheap camera market there is lots of stuff out there
which just has a name painted on a case, or the case looks kind of weird
(shaped like a plastic dog, dragon, or squishy toy, attached to a pair of
sunglasses as a spy camera or whatever) and the electronics inside is
indistinguishable from 20 or 30 other devices, which do not come from the
same manufacturer and may not even have a similar appearance, at all. Do
I know all the Mars CIF cameras which have the USB ID of 0x093a:0x010e ?
Almost certainly, I do not. Unfortunately, without the cooperation of the
manufacturers of these devices that is practically impossible. Therefore
let us pray that this non-cooperation somehow will get changed.
Theodore Kilgore
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
Re: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)
Hello Theodore, I have the impression you sent another mail, now, with the picture. I I didn't :) Just wanted to offer it, just in case... cameras. What I know about the camera is well summarized in the following entry from libgphoto2/camlibs/mars/ChangeLog: Okay. Well, as said before I am pretty sure it is the same camera. I'll ship it tomorrow. This is the total extent of my knowledge. It does seem, judging from the address of the person who sent me the information about it, and from yours, that the Elta brand is probably local to Europe. I'd think so, too. Finally, one of the main reasons why I pass this on is to point out that especially in the cheap camera market there is lots of stuff out there which just has a name painted on a case, [...] ...which is definately also the case here. Elta just imports stuff. Therefore let us pray that this non-cooperation somehow will get changed. +1! Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)
Am Freitag, den 01.05.2009, 15:33 -0500 schrieb Theodore Kilgore: On Fri, 1 May 2009, hermann pitton wrote: Hello, snip for elta GmbH, they are originally located in Germany and have a quite good reputation for fancy lifestyle products, many imported from Asia, these days mostly China, but started with quality products from Japan. One of the services they also offer is to create new brands of products for customers, coordinated over elta Hong Kong, which includes proper package design, two years warranty and a readable user manual ;) I have an early appearance of the saa7134 chip as elta medi@ 8682 LV LifeView FlyVideo 3000 with remote and maybe the first TCL tuner seen here. Copyright and Trademark Notice in the user manual. (C) 2001 by Animations Technologies Inc. for this one. Can be found searching for Elta at the www.bttv-gallery.de. You can find all contact information for elta here. http://www.elta.de snip Theodore Kilgore Cheers, Hermann Hermann, What exactly are you saying? Is it that here seems to be a manufacturer (more accurately, a packager and importer) who might be willing actually to talk to us? That would be good news. Also, unless I misunderstand, you seem to imply that some such kind of cooperation already exists. Can you say more about this? Theodore Kilgore Theodore, I just try to tell you that they are well known in Germany since decades and that all contact data are publicly available. I did not try to contact them, since in the above case there was no need. The elta medi@ 8682 LV has the the same PCI subsystem like the original LifeView product and the TCL tuner was compatible with Philips and others subsumed under tuner=5. With the positive exception, that this tuner does not need to be tuned to some higher frequencies for charge pump, before using radio, like the compatible Philips types do need it, but on the other hand it had a new huge SAW filter and sensitivity was a little diminished compared to original Philips products. Else it had already known Philips chips and nothing else. To look at the Copyright in the user manual might give one some hint who is behind such a product, like for that elta LifeView 3000. That I'm telling. Animation Technologies in this case. I also think it should be at least always worth a try to contact them, in case you can't identify a product they do some marketing for. 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
dib3000 (dvb) driver bug with ubuntu 9.04 (2.6.28 kernel)?
Hello, Since a couple of years, I use a WinFast DTV Dongle (dib3000mc) on a ASUS (intel) laptop without any trouble. It works with ubuntu 8.04. The quality is perfect I use now the same dongle on a recent laptop PC based on a GA-MA78GM-US2H mother board and the quality of the image is very bad and the soft (me-tv) rebuffer very often. It is unlikely a probleme of signal strength, because on the same antenna plug, the dvb works very well with the laptop, and very bad with the desktop computer. See below some informations about the dvb with the two configrations : laptop and the desktop computer. I noticed that there are some differences between the loaded modules. i2c_core and usbcore are abscent with ubuntu 9.04. Is it normal? Morever if you carefully look at the dvbtraffic, it is lower for the LAPTOP for a same program. This is very repetive behaviour. It is not normal. Does anyone have an idea of whats wrong with the LAPTOP configuration. Thanks. Julien R. *** LAPTOP (GOOD image quality) uname -a : Linux portable 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009 i686 GNU/Linux lsusb: Bus 005 Device 011: ID 0413:6026 Leadtek Research, Inc. WinFast DTV Dongle (warm state) lsmod | grep dvb dvb_usb_dibusb_mc 6400 0 dvb_usb_dibusb_common 10756 1 dvb_usb_dibusb_mc dib3000mc 13960 2 dvb_usb_dibusb_common dvb_usb 19852 2 dvb_usb_dibusb_mc,dvb_usb_dibusb_common dvb_core 81404 1 dvb_usb i2c_core 24832 4 mt2060,dib3000mc,dibx000_common,dvb_usb usbcore 146412 5 dvb_usb_dibusb_mc,dvb_usb,ehci_hcd,uhci_hcd tzap ARTE status 1f | signal c058 | snr | ber | unc | FE_HAS_LOCK dvbtraffic 9 p/s 1 kb/s 14 kbit 0010 5 p/s 0 kb/s 8 kbit 0011 0 p/s 0 kb/s 1 kbit 0012 12 p/s 2 kb/s 19 kbit 0015 1 p/s 0 kb/s 2 kbit 006e 9 p/s 1 kb/s 14 kbit 0078 1697 p/s 311 kb/s 2553 kbit 0082 132 p/s 24 kb/s 198 kbit 008c 32 p/s 5 kb/s 49 kbit 00d2 9 p/s 1 kb/s 14 kbit 00dc 2189 p/s 401 kb/s 3292 kbit 00e6 132 p/s 24 kb/s 198 kbit 00f0 3 p/s 0 kb/s 5 kbit 0136 9 p/s 1 kb/s 14 kbit 0140 1527 p/s 280 kb/s 2296 kbit 014a 131 p/s 24 kb/s 197 kbit 0154 1 p/s 0 kb/s 2 kbit 01fe 9 p/s 1 kb/s 14 kbit 0208 2104 p/s 386 kb/s 3164 kbit 0212 131 p/s 24 kb/s 197 kbit 0213 132 p/s 24 kb/s 198 kbit 021c 1 p/s 0 kb/s 2 kbit 021d 2 p/s 0 kb/s 4 kbit 021e 2 p/s 0 kb/s 4 kbit 0262 9 p/s 1 kb/s 14 kbit 026c 1688 p/s 309 kb/s 2539 kbit 0276 132 p/s 24 kb/s 198 kbit 0280 2 p/s 0 kb/s 4 kbit 0294 13 p/s 2 kb/s 20 kbit 02c6 9 p/s 1 kb/s 14 kbit 02d0 5437 p/s 998 kb/s 8178 kbit 02da 131 p/s 24 kb/s 197 kbit 03f2 9 p/s 1 kb/s 14 kbit 1fff 823 p/s 151 kb/s 1239 kbit 2000 16557 p/s 3039 kb/s 24901 kbit DESKTOP (very bad image) system ubuntu jaunty Linux xxx 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux AMD Mother board GA-MA78GM-US2H (USB controler : amd sb700) lsusb Bus 001 Device 006: ID 0413:6026 Leadtek Research, Inc. WinFast DTV Dongle (warm state) lsmod |grep dvb dvb_usb_dibusb_mc 13056 0 dvb_usb_dibusb_common 16772 1 dvb_usb_dibusb_mc dib3000mc 20488 2 dvb_usb_dibusb_common dvb_usb 24332 2 dvb_usb_dibusb_mc,dvb_usb_dibusb_common dvb_core 92032 1 dvb_usb tzap ARTE tuning to 586167000 Hz video pid 0x0208, audio pid 0x0212 status 1f | signal cbfc | snr | ber 001f | unc 0013 | FE_HAS_LOCK ... dvbtraffic 9 p/s 1 kb/s 14 kbit 0012 10 p/s 1 kb/s 16 kbit 0015 1 p/s 0 kb/s 2 kbit 006e 9 p/s 1 kb/s 14 kbit 0078 1757 p/s 322 kb/s 2643 kbit 0082 127 p/s 23 kb/s 191 kbit 008c 3 p/s 0 kb/s 5 kbit 00d2 9 p/s 1 kb/s 14 kbit 00dc 1380 p/s 253 kb/s 2076 kbit 00e6 124 p/s 22 kb/s 187 kbit 00f0 42 p/s 7 kb/s 63 kbit 0136 9 p/s 1 kb/s 14 kbit 0140 2912 p/s 534 kb/s 4380 kbit 014a 124 p/s 22 kb/s 187 kbit 0154 13 p/s 2 kb/s 20 kbit 01fe 9 p/s 1 kb/s 14 kbit 0208 2641 p/s 484 kb/s 3973 kbit 0212 124 p/s 22 kb/s 187 kbit 0213 127 p/s 23 kb/s 191 kbit 021c 1 p/s 0 kb/s 2 kbit 021d 1 p/s 0 kb/s 2 kbit 021e 1 p/s 0 kb/s 2 kbit 0262 9 p/s 1 kb/s 14 kbit 026c 1509 p/s 277 kb/s 2270 kbit 0276 125 p/s 22 kb/s 188 kbit 0280 3 p/s 0 kb/s 5 kbit 0294 12 p/s 2 kb/s 19 kbit 02c6 9 p/s 1 kb/s 14 kbit 02d0 3913 p/s 718 kb/s 5886 kbit 02da 125 p/s 22 kb/s 188 kbit 03f2 9 p/s 1 kb/s 14 kbit
Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Fri, 1 May 2009, Alexey Klimov wrote: Hello, On Mon, Apr 20, 2009 at 3:59 AM, Mike Isely is...@isely.net wrote: [...] So the kernel already has this; it just needs to be pulled back into v4l-dvb. It's an obvious trivial thing for now and I've acked it there. Obviously we're getting had here because you're compiling against a kernel snapshot that's been changed but v4l-dvb doesn't have the corresponding change in its local copy of the pvrusb2 driver. Part of the fun of synchronizing changes from different trees :-( Well, good to know that this thing is already fixed. I'm very sorry for the mess. No apology needed. Really - this mess wasn't caused by you. If anything I should have just immediately pulled that patch into hg and not waited for it to trickle back to Mauro. That would have avoided the error. So, all I can say is that I'm sorry you had to hit this! -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
Re: [PATCH] FM1216ME_MK3 some changes
On Sat, 2009-05-02 at 01:55 +0200, hermann pitton wrote: Guys, [snip] Do the circuit board traces in the FM1216ME_MK3 support the TDA9887 controlling the gain of the first stage? (I've never opened an equivalent NTSC tuner assembly to take a look.) equivalent NTSC tuners _do not_ exist at all. I don't forget all the time we spend to find out that some of them are Intercarrier only! Also, the tda988x stuff is underneath the tuner PCB. I cut one off for those interested in line tracing ... still on the to do list ;) Thanks. I hope it doesn't cost you too many wasted Euros... Without port2=0 you don't get any SECAM-L into the sound trap. It needs amplification from minus 40 dB AM for the first sound carrier, and then of course you prefer the second with NICAM. If not, then, if I understand things correctly, you need to set the first stage and second stage TOP settings so that they refer to about the same signal level before the IF SAW filter. I would think AGC TOP settings, for both stages of the tuner, are tuner-dependent and relatively constant once you figure out what they should be. Do you have a different understanding or insight? Regards, Andy Hartmut once offered to make contacts with colleagues at Philips Hamburg for such tuners and related tda9887 stuff. Unfortunately he is not active on the lists currently. If I see, how easily someone can get a patch to Andrew and disables all other SECAM stuff, again from Russia, I'm not convinced on anything from there. I seriously doubt that those tuners are meant for fumbling on TOP RF/IF settings from user space. The proper TOP settings should be a function of the input signal TV standard (positive modulation vs. negative modulation vs. FM radio) and the components in the tuner assembly (the IF filter for sure). Setting TOP settings from user space only makes sense for laboratory experimentation. Linux is kind of funny in the way it breaks up the integrated assembly of an analog tuner to be handled by separate drivers: preselector and mixer/osc chip by tuner-simple; IF filter and IF demod by another module like tda9887. Really the two chips should be set with coordinated settings, taking into account the TV standard the tuner is being set to demodulate and the properties of the IF filter and external components to the IF demodulator. The linux analog tuner drivers mostly appear to make some safe, default settings, and don't attempt to get the best performance. I'm assuming that is due to lack of data on the tuners and the tuners working well enough. I'm glad to see Dmitri working at trying to improve analog performance. I wish I had the proper equpment to experiment wih NTSC tiners. If I had a lab with a decent signal generator, oscilliscope, etc. I'd probably have lots of fun playing around with these tuners. :) Regards, Andy 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
Re: [PATCH 2/6] ir-kbd-i2c: Switch to the new-style device binding model
Jean: I have another idea that I think you'll like. I'm putting the finishing touches on the patch right now. What I have implements correct ir_video loading for the pvrusb2 driver. It also includes a lookup table (though with only 1 entry right now) to determine the proper I2C address and I use i2c_new_device() now instead of i2c_new_probed_device(). I've also renamed things to be ir_video everywhere instead of ir_kbd_i2c as was discussed. In particular the disable option is there like before, but now it's called disable_autoload_ir_video. So far this is exactly what I was saying before. But I'm also making one more change: the disable_autoload_ir_video option default value will - for now - be 1, i.e. everything above I just described starts off disabled. This means that the entire patch can be pulled _right_ _now_ without breaking anything at all, because the outward behavior is still unchanged. Then, when you're ready to bring your stuff in, all you need to do is include a 1-line change to pvrusb2-i2c-core.c to switch the default value of disable_autoload_ir_video back to 0, which now enables all the corresponding pvrusb2 changes that you need to avoid any breakage inside my driver. Just to be absolutely crystal clear, here's the change you will be able to do once these changes are in: diff -r 8d2e1361520c linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c --- a/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c Fri May 01 20:23:39 2009 -0500 +++ b/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c Fri May 01 20:24:23 2009 -0500 @@ -43,7 +43,7 @@ module_param_array(ir_mode, int, NULL, 0444); MODULE_PARM_DESC(ir_mode,specify: 0=disable IR reception, 1=normal IR); +static int pvr2_disable_ir_video; -static int pvr2_disable_ir_video = 1; module_param_named(disable_autoload_ir_video, pvr2_disable_ir_video, int, S_IRUGO|S_IWUSR); MODULE_PARM_DESC(disable_autoload_ir_video, So with all this, what I am setting up right now will cause no harm to the existing situation, requires no actual messing with module options, and once you're reading, just include the 1-line change above and you're set. There's no race here, no gap in IR handling. -Mike On Thu, 23 Apr 2009, Mike Isely wrote: Hi Jean, I had actually written out a longer, detailed, point-by-point reply earlier today, but before I could finish it I got interrupted with a crisis. And then another. And that's kind of how my day went. Now I'm finally back to this, but I have another e-mail debacle to immediately deal with (thank you pobox.com, not!) so I'm tossing that unfinished lengthy reply. I think I can sum this whole thing up very simply. Here's what I think should be happening: 1a. Your existing IR changeset, minus the pvrusb2 changes, should be merged. 1b. In parallel with (1a) I modify my pvrusb2 changeset to use the right module name and I adjust the driver option name to match. 2. My pvrusb2 changeset, with changes from (1b) is merged. 3. Andy's proposed change for ir_kbd_i2c to support additional IR devices is investigated and probably merged. 4. I test the changed ir_kbd_i2c against additional pvrusb2 devices known not to work previously with ir_kbd_i2c. If they work, then I will create a pvrusb2 patch to load ir_video in those cases as well as the cases already set up (which still won't cover all possible pvrusb2-driven devices). I think this satisfies the remaining issues, except that from between steps 1 and 2 ir_kbd_i2c won't work with the pvrusb2 driver. But you know, I'm OK with that. I expect (2) to happen within a few days after (1) so the impact should be minimal. It certainly won't escape into the kernel tree that way. In addition, my impression from the community of pvrusb2 users is that the preferred IR strategy is lirc anyway, and it's a foregone conclusion that they are all going to be, uh, impacted once your compatibility parts are gone from i2c. From where I'm sitting the gap from (1) to (2) is trivial compared to that impending mess - realize I'm not complaining since after all (a) it really falls to the lirc developers to fix that, (b) you do need to get your changes in, and (c) there's little I can do for lirc there except to keep it working as long as possible with the pvrusb2 driver. I'm just pointing out that I'm OK with the step 1 - 2 gap for the pvrusb2 driver because it's small and will be nothing compared to what's about to happen with lirc. If you still don't like any of that, well, then I give up. In that case, then merge your changes with the pvrusb2 changes included. I won't ack them, but I'll just deal with it later. Because while your changes might keep ir_kbd_i2c going, they will also immediately break the more-useful and apparently more-used lirc (by always binding ir_kbd_i2c even in cases in the pvrusb2 driver where it's known
Re: [PATCH] FM1216ME_MK3 some changes
Am Freitag, den 01.05.2009, 20:52 -0400 schrieb Andy Walls: On Sat, 2009-05-02 at 01:55 +0200, hermann pitton wrote: Guys, [snip] Do the circuit board traces in the FM1216ME_MK3 support the TDA9887 controlling the gain of the first stage? (I've never opened an equivalent NTSC tuner assembly to take a look.) equivalent NTSC tuners _do not_ exist at all. I don't forget all the time we spend to find out that some of them are Intercarrier only! Also, the tda988x stuff is underneath the tuner PCB. I cut one off for those interested in line tracing ... still on the to do list ;) Thanks. I hope it doesn't cost you too many wasted Euros... Seven years later it is just trash and i hope to provide enough for everyone ;) Cheers, Hermann Without port2=0 you don't get any SECAM-L into the sound trap. It needs amplification from minus 40 dB AM for the first sound carrier, and then of course you prefer the second with NICAM. If not, then, if I understand things correctly, you need to set the first stage and second stage TOP settings so that they refer to about the same signal level before the IF SAW filter. I would think AGC TOP settings, for both stages of the tuner, are tuner-dependent and relatively constant once you figure out what they should be. Do you have a different understanding or insight? Regards, Andy Hartmut once offered to make contacts with colleagues at Philips Hamburg for such tuners and related tda9887 stuff. Unfortunately he is not active on the lists currently. If I see, how easily someone can get a patch to Andrew and disables all other SECAM stuff, again from Russia, I'm not convinced on anything from there. I seriously doubt that those tuners are meant for fumbling on TOP RF/IF settings from user space. The proper TOP settings should be a function of the input signal TV standard (positive modulation vs. negative modulation vs. FM radio) and the components in the tuner assembly (the IF filter for sure). Setting TOP settings from user space only makes sense for laboratory experimentation. Linux is kind of funny in the way it breaks up the integrated assembly of an analog tuner to be handled by separate drivers: preselector and mixer/osc chip by tuner-simple; IF filter and IF demod by another module like tda9887. Really the two chips should be set with coordinated settings, taking into account the TV standard the tuner is being set to demodulate and the properties of the IF filter and external components to the IF demodulator. The linux analog tuner drivers mostly appear to make some safe, default settings, and don't attempt to get the best performance. I'm assuming that is due to lack of data on the tuners and the tuners working well enough. I'm glad to see Dmitri working at trying to improve analog performance. I wish I had the proper equpment to experiment wih NTSC tiners. If I had a lab with a decent signal generator, oscilliscope, etc. I'd probably have lots of fun playing around with these tuners. :) Regards, Andy 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
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
Here's the updated patch with the requested changes.
Frank
Signed-off-by: Frank Dischner phaedrus...@gmail.com
diff -urN v4l-dvb/linux/drivers/media/dvb/frontends/au8522_dig.c
v4l-dvb.new/linux/drivers/media/dvb/frontends/au8522_dig.c
--- v4l-dvb/linux/drivers/media/dvb/frontends/au8522_dig.c 2009-05-01
20:14:47.0 -0600
+++ v4l-dvb.new/linux/drivers/media/dvb/frontends/au8522_dig.c 2009-05-01
20:19:25.0 -0600
@@ -367,11 +367,90 @@
{ 0x8231, 0x13 },
};
-/* QAM Modulation table */
+/* QAM64 Modulation table */
static struct {
u16 reg;
u16 data;
-} QAM_mod_tab[] = {
+} QAM64_mod_tab[] = {
+ { 0x00a3, 0x09 },
+ { 0x00a4, 0x00 },
+ { 0x0081, 0xc4 },
+ { 0x00a5, 0x40 },
+ { 0x00aa, 0x77 },
+ { 0x00ad, 0x77 },
+ { 0x00a6, 0x67 },
+ { 0x0262, 0x20 },
+ { 0x021c, 0x30 },
+ { 0x00b8, 0x3e },
+ { 0x00b9, 0xf0 },
+ { 0x00ba, 0x01 },
+ { 0x00bb, 0x18 },
+ { 0x00bc, 0x50 },
+ { 0x00bd, 0x00 },
+ { 0x00be, 0xea },
+ { 0x00bf, 0xef },
+ { 0x00c0, 0xfc },
+ { 0x00c1, 0xbd },
+ { 0x00c2, 0x1f },
+ { 0x00c3, 0xfc },
+ { 0x00c4, 0xdd },
+ { 0x00c5, 0xaf },
+ { 0x00c6, 0x00 },
+ { 0x00c7, 0x38 },
+ { 0x00c8, 0x30 },
+ { 0x00c9, 0x05 },
+ { 0x00ca, 0x4a },
+ { 0x00cb, 0xd0 },
+ { 0x00cc, 0x01 },
+ { 0x00cd, 0xd9 },
+ { 0x00ce, 0x6f },
+ { 0x00cf, 0xf9 },
+ { 0x00d0, 0x70 },
+ { 0x00d1, 0xdf },
+ { 0x00d2, 0xf7 },
+ { 0x00d3, 0xc2 },
+ { 0x00d4, 0xdf },
+ { 0x00d5, 0x02 },
+ { 0x00d6, 0x9a },
+ { 0x00d7, 0xd0 },
+ { 0x0250, 0x0d },
+ { 0x0251, 0xcd },
+ { 0x0252, 0xe0 },
+ { 0x0253, 0x05 },
+ { 0x0254, 0xa7 },
+ { 0x0255, 0xff },
+ { 0x0256, 0xed },
+ { 0x0257, 0x5b },
+ { 0x0258, 0xae },
+ { 0x0259, 0xe6 },
+ { 0x025a, 0x3d },
+ { 0x025b, 0x0f },
+ { 0x025c, 0x0d },
+ { 0x025d, 0xea },
+ { 0x025e, 0xf2 },
+ { 0x025f, 0x51 },
+ { 0x0260, 0xf5 },
+ { 0x0261, 0x06 },
+ { 0x021a, 0x00 },
+ { 0x0546, 0x40 },
+ { 0x0210, 0xc7 },
+ { 0x0211, 0xaa },
+ { 0x0212, 0xab },
+ { 0x0213, 0x02 },
+ { 0x0502, 0x00 },
+ { 0x0121, 0x04 },
+ { 0x0122, 0x04 },
+ { 0x052e, 0x10 },
+ { 0x00a4, 0xca },
+ { 0x00a7, 0x40 },
+ { 0x0526, 0x01 },
+};
+
+/* QAM256 Modulation table */
+static struct {
+ u16 reg;
+ u16 data;
+} QAM256_mod_tab[] = {
{ 0x80a3, 0x09 },
{ 0x80a4, 0x00 },
{ 0x8081, 0xc4 },
@@ -464,12 +543,19 @@
au8522_set_if(fe, state-config-vsb_if);
break;
case QAM_64:
+ dprintk(%s() QAM 64\n, __func__);
+ for (i = 0; i ARRAY_SIZE(QAM64_mod_tab); i++)
+ au8522_writereg(state,
+ QAM64_mod_tab[i].reg,
+ QAM64_mod_tab[i].data);
+ au8522_set_if(fe, state-config-qam_if);
+ break;
case QAM_256:
- dprintk(%s() QAM 64/256\n, __func__);
- for (i = 0; i ARRAY_SIZE(QAM_mod_tab); i++)
+ dprintk(%s() QAM 256\n, __func__);
+ for (i = 0; i ARRAY_SIZE(QAM256_mod_tab); i++)
au8522_writereg(state,
- QAM_mod_tab[i].reg,
- QAM_mod_tab[i].data);
+ QAM256_mod_tab[i].reg,
+ QAM256_mod_tab[i].data);
au8522_set_if(fe, state-config-qam_if);
break;
default:
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: remove driver_data direct access of struct device
Acked-By: Mike Isely is...@pobox.com
Note #1: I am just acking the pvrusb2 part of this.
Note #2: I am immediately pulling the pvrusb2 part of these changes into
that driver.
-Mike
On Thu, 30 Apr 2009, Greg Kroah-Hartman wrote:
From: Greg Kroah-Hartman gre...@suse.de
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/media/dvb/firewire/firedtv-1394.c |4 ++--
drivers/media/dvb/firewire/firedtv-dvb.c|2 +-
drivers/media/video/pvrusb2/pvrusb2-sysfs.c | 22 +++---
3 files changed, 14 insertions(+), 14 deletions(-)
--- a/drivers/media/dvb/firewire/firedtv-1394.c
+++ b/drivers/media/dvb/firewire/firedtv-1394.c
@@ -225,7 +225,7 @@ fail_free:
static int node_remove(struct device *dev)
{
- struct firedtv *fdtv = dev-driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(dev);
fdtv_dvb_unregister(fdtv);
@@ -242,7 +242,7 @@ static int node_remove(struct device *de
static int node_update(struct unit_directory *ud)
{
- struct firedtv *fdtv = ud-device.driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(ud-device);
if (fdtv-isochannel = 0)
cmp_establish_pp_connection(fdtv, fdtv-subunit,
--- a/drivers/media/dvb/firewire/firedtv-dvb.c
+++ b/drivers/media/dvb/firewire/firedtv-dvb.c
@@ -268,7 +268,7 @@ struct firedtv *fdtv_alloc(struct device
if (!fdtv)
return NULL;
- dev-driver_data= fdtv;
+ dev_set_drvdata(dev, fdtv);
fdtv-device= dev;
fdtv-isochannel= -1;
fdtv-voltage = 0xff;
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -539,7 +539,7 @@ static void class_dev_destroy(struct pvr
sfp-attr_unit_number);
}
pvr2_sysfs_trace(Destroying class_dev id=%p,sfp-class_dev);
- sfp-class_dev-driver_data = NULL;
+ dev_set_drvdata(sfp-class_dev, NULL);
device_unregister(sfp-class_dev);
sfp-class_dev = NULL;
}
@@ -549,7 +549,7 @@ static ssize_t v4l_minor_number_show(str
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -561,7 +561,7 @@ static ssize_t bus_info_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_bus_info(sfp-channel.hdw));
@@ -572,7 +572,7 @@ static ssize_t hdw_name_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_type(sfp-channel.hdw));
@@ -583,7 +583,7 @@ static ssize_t hdw_desc_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_desc(sfp-channel.hdw));
@@ -595,7 +595,7 @@ static ssize_t v4l_radio_minor_number_sh
char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -607,7 +607,7 @@ static ssize_t unit_number_show(struct d
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_get_unit_number(sfp-channel.hdw));
@@ -635,7 +635,7 @@ static void class_dev_create(struct pvr2
Re: [PATCH] v4l2: fill the reserved fields of VIDIOC_REQBUFS ioctl
From: Trent Piepho xy...@speakeasy.org
Some ioctls have structs that are a different size depending on what type
of buffer is being used. If the buffer type leaves a field unused or has
padding space at the end, this space should be zeroed out. This patch modifies
the VIDIOC_S_FMT, VIDIOC_TRY_FMT and VIDIOC_REQBUFS ioctls [1].
The problems with S_FMT and REQBUFS were original identified and patched by
Márton Németh.
The patch was tested with v4l-test 0.13 [2] with vivi driver.
References:
[1] V4L2 API specification, revision 0.24
http://v4l2spec.bytesex.org/spec/r10944.htm
http://v4l2spec.bytesex.org/spec/r13696.htm
[2] v4l-test: Test environment for Video For Linux Two API
http://v4l-test.sourceforge.net/
Priority: normal
Signed-off-by: Trent Piepho xy...@speakeasy.org
Signed-off-by: Márton Németh nm...@freemail.hu
---
--- linux-2.6.30-rc4/drivers/media/video/v4l2-ioctl.c.orig 2009-05-01
23:31:22.0 +0200
+++ linux-2.6.30-rc4/drivers/media/video/v4l2-ioctl.c 2009-05-02
07:14:11.0 +0200
@@ -42,6 +42,12 @@
printk(KERN_DEBUG %s: fmt, vfd-name, ## arg);\
} while (0)
+/* Zero out the end of the struct pointed to by p. Everthing after, but
+ * not including, the specified field is cleared. */
+#define CLEAR_AFTER_FIELD(p, field) \
+ memset((u8 *)(p) + offsetof(typeof(*(p)), field) + sizeof((p)-field), \
+ 0, sizeof(*(p)) - offsetof(typeof(*(p)), field) - sizeof((p)-field))
+
struct std_descr {
v4l2_std_id std;
const char *descr;
@@ -782,44 +788,53 @@
switch (f-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
+ CLEAR_AFTER_FIELD(f, fmt.pix);
v4l_print_pix_fmt(vfd, f-fmt.pix);
if (ops-vidioc_s_fmt_vid_cap)
ret = ops-vidioc_s_fmt_vid_cap(file, fh, f);
break;
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
+ CLEAR_AFTER_FIELD(f, fmt.win);
if (ops-vidioc_s_fmt_vid_overlay)
ret = ops-vidioc_s_fmt_vid_overlay(file,
fh, f);
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+ CLEAR_AFTER_FIELD(f, fmt.pix);
v4l_print_pix_fmt(vfd, f-fmt.pix);
if (ops-vidioc_s_fmt_vid_out)
ret = ops-vidioc_s_fmt_vid_out(file, fh, f);
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
+ CLEAR_AFTER_FIELD(f, fmt.win);
if (ops-vidioc_s_fmt_vid_out_overlay)
ret = ops-vidioc_s_fmt_vid_out_overlay(file,
fh, f);
break;
case V4L2_BUF_TYPE_VBI_CAPTURE:
+ CLEAR_AFTER_FIELD(f, fmt.vbi);
if (ops-vidioc_s_fmt_vbi_cap)
ret = ops-vidioc_s_fmt_vbi_cap(file, fh, f);
break;
case V4L2_BUF_TYPE_VBI_OUTPUT:
+ CLEAR_AFTER_FIELD(f, fmt.vbi);
if (ops-vidioc_s_fmt_vbi_out)
ret = ops-vidioc_s_fmt_vbi_out(file, fh, f);
break;
case V4L2_BUF_TYPE_SLICED_VBI_CAPTURE:
+ CLEAR_AFTER_FIELD(f, fmt.sliced);
if (ops-vidioc_s_fmt_sliced_vbi_cap)
ret = ops-vidioc_s_fmt_sliced_vbi_cap(file,
fh, f);
break;
case V4L2_BUF_TYPE_SLICED_VBI_OUTPUT:
+ CLEAR_AFTER_FIELD(f, fmt.sliced);
if (ops-vidioc_s_fmt_sliced_vbi_out)
ret = ops-vidioc_s_fmt_sliced_vbi_out(file,
fh, f);
break;
case V4L2_BUF_TYPE_PRIVATE:
+ /* CLEAR_AFTER_FIELD(f, fmt.raw_data); - does nothing
*/
if (ops-vidioc_s_fmt_type_private)
ret = ops-vidioc_s_fmt_type_private(file,
fh, f);
@@ -836,46 +851,55 @@
v4l2_type_names));
switch (f-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
+ CLEAR_AFTER_FIELD(f, fmt.pix);
if (ops-vidioc_try_fmt_vid_cap)
ret = ops-vidioc_try_fmt_vid_cap(file, fh, f);
if (!ret)
v4l_print_pix_fmt(vfd, f-fmt.pix);
