V4L-DVB Summit Day 3
Hi all, Well, that was another very successful day here in Portland. I started off presenting the work we did in the past year and our plans for the next year during the BoF this morning. It was quite a big crowd and the talk was well received. The presentation is available from my website: http://www.xs4all.nl/~hverkuil/lpc/bof.odp The nice thing was that this presentation was hot off the press as it presented all the things we discussed in the two preceding days of the summit. Two additional presentations from Samsung regarding their SoCs and their implementation of a memory pool-like API are also available from my website: http://www.xs4all.nl/~hverkuil/lpc/Samsung_SoCs.ppt http://www.xs4all.nl/~hverkuil/lpc/Unified_media_buffers.pdf Unfortunately I couldn't attend the presentation from Hans de Goede and Brandon Philips, so I can't comment on that. It would be great if someone can post a report of that presentation (and links to the presentation itself, if possible). During the afternoon we worked on assigning people to the various tasks that need to be done. I made the following list: - We created a new mc mailinglist: linux...@googlegroups.com This is a temporary mailinglist where we can post and review patches during prototyping of the mc API. We don't want to flood the linux-media list with those patches since that is already quite high-volume. The mailinglist should be active, although I couldn't find it yet from www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did something wrong. - implement sensor v4l2_subdev support (Laurent). We are still missing some v4l2_subdev sensor ops for setting up the bus config and data format. Laurent will look into implementing those. An RFC for the bus config already exists and will function as the basis of this. - when done, remove the v4l2-int-device API (Nokia, target 2.6.33). It's important to finally remove this non-standard API. When we can setup sensors properly using subdevs, then Nokia can convert the final two users of this API to v4l2_subdev. - subdev migration omap3: - ISP (Laurent) - video decoder (Vaibhav) - display (Vaibhav) These are the initial test implementations for the media controller: converting the various parts of the omap3 driver to subdevs and see how these can be controller via the mc. - subdev migration Moorestown (Intel): - sensors - LED driver - video decoder/encoder - more... Intel will do something similar for their Moorestown platform. - Samsung: investigate V4L2 API and mc concept. Samsung needs to investigate the V4L2 API and the mc proposal first before they can commit to anything. - HDTV timings API (Murali, 2.6.33). This is an important API that we should be able to get into 2.6.33. - Event handling API (RFC: Laurent, code: Guru Raj, 2.6.33). Ditto. Laurent will update the RFC, Guru Raj from Intel will write the code for it (Laurent already has a lot on his plate). - Memory pool API (Laurent, Vaibhav). Laurent and Vaibhav will do the research needed for this API. - Control framework (Hans). In November I hope to finish the control framework. - Media Controller testbed: create device nodes for subdevs and cleanup (Hans) (http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-mc). My tree needs updating to reflect the discussions during this summit. I hope to do this in two weeks from now. It will create a decent starting point for the various mc prototyping efforts. - Associating alsa and video (esp. USB) (Devin). Devin will do more research on how to associate alsa and video nodes. In particular for USB webcam devices. - Research a new ioctl that just enums device nodes to get audio/video association solved quickly. Will be subset of v4l2_mc_entity struct. (Devin). Devin raised the valid concern that it will probably take many months before the mc and all related ioctls will be implemented. But there is a very urgent need for applications to be able to find related alsa/video nodes. A possible approach is to create an ioctl for the mc that basically will just enumerate device nodes and will give a subset of what the final entity enumeration ioctl will return. Just enough to let applications use it to figure out these alsa/vbi/video relationships. Devin will do more research into this. - Userspace libraries for the SoCs (TBD). Not discussed yet is how to create the userspace libraries that contain the SoC specific code: should they conform to certain requirements? Or is it free-for-all? Should we have a central repository for these libraries? It is to early to tell. We also listed the criteria when to decide that the mc API is ready for submission to the v4l-dvb repository: - Implemented in UVC - Implemented in ivtv - Without modifying bttv the code framework should setup workable entities by default. - Implemented in omap3 together with a test userspace library. These three days
Re: V4L-DVB Summit Day 1
On Fri, Sep 25, 2009 at 3:07 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Hans Thanks for keeping us updated. One comment: On Wed, 23 Sep 2009, Hans Verkuil wrote: In the afternoon we discussed the proposed timings API. There was no opposition to this API. The idea I had to also use this for sensor setup turned out to be based on a misconception on how the S_FMT relates to sensors. ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler hidden inside the bridge can scale the native sensor resolution. It does not enumerate the various native sensor resolutions, since there is only one. So S_FMT really sets up the scaler. Just as Jinlu Yu noticed in his email, this doesn't reflect the real situation, I am afraid. You can use binning and skipping on the sensor to scale the image, and you can also use the bridge to do the scaling, as you say. Worth than that, there's also a case, where there _several_ ways to perform scaling on the sensor, among which one can freely choose, and the host can scale too. And indeed it makes sense to scale on the source to save the bandwidth and thus increase the framerate. So, what I'm currently doing on sh-mobile, I try to scale on the client - in the best possible way. And then use bridge scaling to provide the exact result. Yes I do agree with you. And it is highly necessary to provide a clear method which obviously indicates which device to use in scaling job. When I use some application processors which provide camera peripherals with scaler inside and external ISP attached, there is no way to use both scaler features inside them. I just need to choose one of them. Cheers, Nate -- = 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: V4L-DVB Summit Day 1
On Sat, 26 Sep 2009, Dongsoo, Nathaniel Kim wrote: On Fri, Sep 25, 2009 at 3:07 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Hans Thanks for keeping us updated. One comment: On Wed, 23 Sep 2009, Hans Verkuil wrote: In the afternoon we discussed the proposed timings API. There was no opposition to this API. The idea I had to also use this for sensor setup turned out to be based on a misconception on how the S_FMT relates to sensors. ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler hidden inside the bridge can scale the native sensor resolution. It does not enumerate the various native sensor resolutions, since there is only one. So S_FMT really sets up the scaler. Just as Jinlu Yu noticed in his email, this doesn't reflect the real situation, I am afraid. You can use binning and skipping on the sensor to scale the image, and you can also use the bridge to do the scaling, as you say. Worth than that, there's also a case, where there _several_ ways to perform scaling on the sensor, among which one can freely choose, and the host can scale too. And indeed it makes sense to scale on the source to save the bandwidth and thus increase the framerate. So, what I'm currently doing on sh-mobile, I try to scale on the client - in the best possible way. And then use bridge scaling to provide the exact result. Yes I do agree with you. And it is highly necessary to provide a clear method which obviously indicates which device to use in scaling job. When I use some application processors which provide camera peripherals with scaler inside and external ISP attached, there is no way to use both scaler features inside them. I just need to choose one of them. Well, I don't necessarily agree, in fact, I do use both scaling engines in my sh setup. The argument is as mentioned above - bus usage and framerate optimisation. So, what I am doing is: I try to scale on the sensor as close as possible, and then scale further on the host (SoC). This works well, only calculations are not very trivial. But you only have to perform them once during setup, so, it's not time-critical. Might be worth implementing such calculations somewhere centrally to reduce error chances in specific drivers. Same with cropping. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: V4L-DVB Summit Day 1
On Sat, Sep 26, 2009 at 6:32 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Sat, 26 Sep 2009, Dongsoo, Nathaniel Kim wrote: On Fri, Sep 25, 2009 at 3:07 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Hans Thanks for keeping us updated. One comment: On Wed, 23 Sep 2009, Hans Verkuil wrote: In the afternoon we discussed the proposed timings API. There was no opposition to this API. The idea I had to also use this for sensor setup turned out to be based on a misconception on how the S_FMT relates to sensors. ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler hidden inside the bridge can scale the native sensor resolution. It does not enumerate the various native sensor resolutions, since there is only one. So S_FMT really sets up the scaler. Just as Jinlu Yu noticed in his email, this doesn't reflect the real situation, I am afraid. You can use binning and skipping on the sensor to scale the image, and you can also use the bridge to do the scaling, as you say. Worth than that, there's also a case, where there _several_ ways to perform scaling on the sensor, among which one can freely choose, and the host can scale too. And indeed it makes sense to scale on the source to save the bandwidth and thus increase the framerate. So, what I'm currently doing on sh-mobile, I try to scale on the client - in the best possible way. And then use bridge scaling to provide the exact result. Yes I do agree with you. And it is highly necessary to provide a clear method which obviously indicates which device to use in scaling job. When I use some application processors which provide camera peripherals with scaler inside and external ISP attached, there is no way to use both scaler features inside them. I just need to choose one of them. Well, I don't necessarily agree, in fact, I do use both scaling engines in my sh setup. The argument is as mentioned above - bus usage and framerate optimisation. So, what I am doing is: I try to scale on the sensor as close as possible, and then scale further on the host (SoC). This works well, only calculations are not very trivial. But you only have to perform them once during setup, so, it's not time-critical. Might be worth implementing such calculations somewhere centrally to reduce error chances in specific drivers. Same with cropping. I think that is a good approach. And considering the image quality, I should make bypass the scaler when user is requesting the exact resolution supported by the external camera ISP. Because some of camera interface embedded scalers are very poor in image quality and performance thus they may reduce in framerate as well. So, user can choose with scaler or without scaler. Cheers, Nate -- = 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: V4L-DVB Summit Day 3
On Fri, 25 Sep 2009, Hans Verkuil wrote: - implement sensor v4l2_subdev support (Laurent). We are still missing some v4l2_subdev sensor ops for setting up the bus config and data format. Laurent will look into implementing those. An RFC for the bus config already exists and will function as the basis of this. Good, obviously, I'm veryinterested in both these APIs, and I hope Laurent will have a look at my earlier imagebus proposal and use that API as a basis for the data format API. My RFC, probably, didn't cover all possible cases, but it should be a reasonable starting point with easy enough extensibility. I did get a couple of positive feedbacks regarding that API, and I have converted the whole soc-camera stack to it and am working on some new drivers with that API. So far I didn't have a single case where I would have to amend or extend it. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] Fix adv7180 build failures with old kernels
The adv7180 driver is a new-style i2c driver, unconditionally using struct i2c_device_id. As such, it can't be built on kernels older than 2.6.26. Signed-off-by: Jean Delvare kh...@linux-fr.org --- v4l/versions.txt |1 + 1 file changed, 1 insertion(+) --- v4l-dvb.orig/v4l/versions.txt 2009-09-26 13:10:09.0 +0200 +++ v4l-dvb/v4l/versions.txt2009-09-26 14:37:43.0 +0200 @@ -38,6 +38,7 @@ SOC_CAMERA_PLATFORM [2.6.26] # Requires struct i2c_device_id VIDEO_TVP514X +VIDEO_ADV7180 # requires id_table and new i2c stuff RADIO_TEA5764 VIDEO_THS7303 -- 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
[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:Sat Sep 26 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13044:6b7617d4a0be gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): 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: ERRORS 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: ERRORS 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/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec 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: Fwd: ATI HDTV Wonder not always recognized
On Tue, 2009-09-22 at 16:40 -0500, Dreher, Eric wrote: I am need of opinions on whether this is a driver or motherboard issue (or something else). I originally had an ATI HDTV Wonder card working perfectly along with a PVR-150 in my two PCI slots of a Asus M2NPV-VM motherboard. Driver for the HDTV Wonder is cx88_dvb, and the PVR, ivtv The PVR-150 recently started to deteriorate with a poor picture quality ( I can describe more if relevant). So I purchased a replacement PVR-150 and popped into place. The new PVR-150 worked without a hitch itself. But...the HDTV Wonder isn't even recognized. Does not show up in lspci. modprobe cx88_dvb reports no such device I have tried swapping PCI slots with no luck, replaced the old PVR-150 with no luck. But the HDTV Wonder is recognized in one slot only with the other slot empty. So I can currently run with either card, but not both. Motherboard has the most recent firmware. I've updated Ubuntu to 9.10 and v4l-dvb drivers to most recent 0.0.7. (No noticable difference from 0.0.6 as far as what I need). Is my logic correct in blaming the motherboard? Any suggestions? Take out all your PCI cards, blow all the dust out of all the slots, replace the cards, and try again. The PCI bus uses refelected waves to get the proper signaling voltage levels. Dust in any of ther slots can have an effect on a sensitive card. I know the bttv supported cards are sensitive to this; I don't know about cx88 supported devices. Regards, Andy Thanks, Eric -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L-DVB Summit Day 1
On Sat, Sep 26, 2009 at 6:32 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Sat, 26 Sep 2009, Dongsoo, Nathaniel Kim wrote: On Fri, Sep 25, 2009 at 3:07 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Hans Thanks for keeping us updated. One comment: On Wed, 23 Sep 2009, Hans Verkuil wrote: In the afternoon we discussed the proposed timings API. There was no opposition to this API. The idea I had to also use this for sensor setup turned out to be based on a misconception on how the S_FMT relates to sensors. ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler hidden inside the bridge can scale the native sensor resolution. It does not enumerate the various native sensor resolutions, since there is only one. So S_FMT really sets up the scaler. Just as Jinlu Yu noticed in his email, this doesn't reflect the real situation, I am afraid. You can use binning and skipping on the sensor to scale the image, and you can also use the bridge to do the scaling, as you say. Worth than that, there's also a case, where there _several_ ways to perform scaling on the sensor, among which one can freely choose, and the host can scale too. And indeed it makes sense to scale on the source to save the bandwidth and thus increase the framerate. So, what I'm currently doing on sh-mobile, I try to scale on the client - in the best possible way. And then use bridge scaling to provide the exact result. Yes I do agree with you. And it is highly necessary to provide a clear method which obviously indicates which device to use in scaling job. When I use some application processors which provide camera peripherals with scaler inside and external ISP attached, there is no way to use both scaler features inside them. I just need to choose one of them. Well, I don't necessarily agree, in fact, I do use both scaling engines in my sh setup. The argument is as mentioned above - bus usage and framerate optimisation. So, what I am doing is: I try to scale on the sensor as close as possible, and then scale further on the host (SoC). This works well, only calculations are not very trivial. But you only have to perform them once during setup, so, it's not time-critical. Might be worth implementing such calculations somewhere centrally to reduce error chances in specific drivers. Same with cropping. I think that is a good approach. And considering the image quality, I should make bypass the scaler when user is requesting the exact resolution supported by the external camera ISP. Because some of camera interface embedded scalers are very poor in image quality and performance thus they may reduce in framerate as well. So, user can choose with scaler or without scaler. There are two ways of doing this: one is to have a smart driver that will attempt to do the best thing (soc-camera, uvc, gspca), the other will be to give the application writer full control of the SoC capabilities through the media controller. Through a media controller you will be able to setup the sensor scaler and a SoC scaler independently. For a digital camera for example you probably want to be able to control the hardware from the application in order to get the very best results, rather than let the driver do it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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] cx25840 6.5MHz carrier detection fixes
On Sat, 2009-09-26 at 00:16 +0300, Aleksandr V. Piskunov wrote:
cx25840:
Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
system DK and L.
Signed-off-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com
Aleksandr,
I would like a little more time to look at your patch.
However, in the mean time, could you test the DK vs. L autodetection,
without your patch, using the cx25840 firmware in
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20070217.tar.gz
?
The MD5 sum of that firmware is:
$ md5sum /lib/firmware/v4l-cx25840.fw
99836e41ccb28c7b373e87686f93712a /lib/firmware/v4l-cx25840.fw
The cx25840 firmware in
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20080701.tar.gz
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware.tar.gz
is probably wrong to use for the CX2584[0123] chips as it it actually
CX23148 A/V core firmware - very similar but not the same.
Hans or Axel,
Could one of you put the correct v4l-cx25840.fw image found in
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20070217.tar.gz
in the archive at:
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware.tar.gz
?
The v4l-cx25840.fw image currently in that archive, which is actually
for the CX23418, is not good to use with CX2584[0123].
Regards,
Andy
diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c
b/linux/drivers/media/video/cx25840/cx25840-core.c
--- a/linux/drivers/media/video/cx25840/cx25840-core.c
+++ b/linux/drivers/media/video/cx25840/cx25840-core.c
@@ -647,13 +647,30 @@
}
cx25840_write(client, 0x80b, 0x00);
} else if (std V4L2_STD_PAL) {
- /* Follow tuner change procedure for PAL */
+ /* Autodetect audio standard and audio system */
cx25840_write(client, 0x808, 0xff);
- cx25840_write(client, 0x80b, 0x10);
+ /* Since system PAL-L is pretty much non-existant and
+ not used by any public broadcast network, force
+ 6.5 MHz carrier to be interpreted as System DK,
+ this avoids DK audio detection instability */
+ cx25840_write(client, 0x80b, 0x00);
} else if (std V4L2_STD_SECAM) {
- /* Select autodetect for SECAM */
+ /* Autodetect audio standard and audio system */
cx25840_write(client, 0x808, 0xff);
- cx25840_write(client, 0x80b, 0x10);
+ /* If only one of SECAM-DK / SECAM-L is required, then force
+ 6.5MHz carrier, else autodetect it */
+ if ((std V4L2_STD_SECAM_DK)
+ !(std (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
+ /* 6.5 MHz carrier to be interpreted as System DK */
+ cx25840_write(client, 0x80b, 0x00);
+ } else if (!(std V4L2_STD_SECAM_DK)
+ (std (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
+ /* 6.5 MHz carrier to be interpreted as System L */
+ cx25840_write(client, 0x80b, 0x08);
+ } else {
+ /* 6.5 MHz carrier to be autodetected */
+ cx25840_write(client, 0x80b, 0x10);
+ }
}
cx25840_and_or(client, 0x810, ~0x01, 0);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
EvolutePC TvWay+ USB ISDB-Tb fullseg device support
Patch for EvolutePC TvWay+ USB ISDB-Tb fullseg device support
==
diff -r 6b7617d4a0be linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.cSat Sep 26 13:45:03
2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.cSat Sep 26 17:18:45
2009 -0300
@@ -1917,6 +1917,7 @@
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XPVR) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XP) },
{ USB_DEVICE(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD) },
+{ USB_DEVICE(USB_VID_EVOLUTEPC, USB_PID_TVWAY_PLUS) },
{ 0 }/* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -2422,7 +2423,7 @@
},
},
-.num_device_descs = 2,
+.num_device_descs = 3,
.devices = {
{ DiBcom STK807xP reference design,
{ dib0700_usb_id_table[62], NULL },
@@ -2432,6 +2433,10 @@
{ dib0700_usb_id_table[63], NULL },
{ NULL },
},
+{ EvolutePC TVWay+,
+{ dib0700_usb_id_table[64], NULL },
+{ NULL },
+},
},
.rc_interval = DEFAULT_RC_INTERVAL,
diff -r 6b7617d4a0be linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.hSat Sep 26 13:45:03 2009
-0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.hSat Sep 26 17:18:45 2009
-0300
@@ -61,6 +61,7 @@
#define USB_VID_XTENSIONS0x1ae7
#define USB_VID_HUMAX_COEX0x10b9
#define USB_VID_7740x7a69
+#define USB_VID_EVOLUTEPC0x1e59
/* Product IDs */
#define USB_PID_ADSTECH_USB2_COLD0xa333
@@ -276,5 +277,6 @@
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD0x5000
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM0x5001
#define USB_PID_FRIIO_WHITE0x0001
+#define USB_PID_TVWAY_PLUS0x0002
#endif
===
Signed-off-by: Sérgio C Fortier sergiofort...@yahoo.com.br
Regards,
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.comdiff -r 6b7617d4a0be linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sat Sep 26 13:45:03 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sat Sep 26 17:18:45 2009 -0300
@@ -1917,6 +1917,7 @@
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XPVR) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XP) },
{ USB_DEVICE(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD) },
+ { USB_DEVICE(USB_VID_EVOLUTEPC, USB_PID_TVWAY_PLUS) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -2422,7 +2423,7 @@
},
},
- .num_device_descs = 2,
+ .num_device_descs = 3,
.devices = {
{ DiBcom STK807xP reference design,
{ dib0700_usb_id_table[62], NULL },
@@ -2432,6 +2433,10 @@
{ dib0700_usb_id_table[63], NULL },
{ NULL },
},
+ { EvolutePC TVWay+,
+{ dib0700_usb_id_table[64], NULL },
+{ NULL },
+ },
},
.rc_interval = DEFAULT_RC_INTERVAL,
diff -r 6b7617d4a0be linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Sep 26 13:45:03 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Sep 26 17:18:45 2009 -0300
@@ -61,6 +61,7 @@
#define USB_VID_XTENSIONS 0x1ae7
#define USB_VID_HUMAX_COEX 0x10b9
#define USB_VID_7740x7a69
+#define USB_VID_EVOLUTEPC 0x1e59
/* Product IDs */
#define USB_PID_ADSTECH_USB2_COLD 0xa333
@@ -276,5 +277,6 @@
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD 0x5000
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM 0x5001
#define USB_PID_FRIIO_WHITE0x0001
+#define USB_PID_TVWAY_PLUS0x0002
#endif
Re: Questions about Terratec Hybrid XS (em2882) [0ccd:005e]
On Fri, Sep 25, 2009 at 6:10 PM, Uros Vampl mobile.leec...@gmail.com wrote: Alright, success!!! Since it seems everything for this tuner is set up the same as for the Hauppauge WinTV HVR 900, I figured let's set things up *exactly* the same. So, like it's there for the Hauppauge, I added .mts_firmware = 1 to the definition of the hybrid XS em2882. And well, working TV audio!! dmesg output this time: xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id . MTS (4), id 00ff: xc2028 4-0061: Loading firmware for type=MTS (4), id 00010007. So now with the attached patch, everything (analog, digital, remote) works! Regards, Uroš Hello Uros, Please test out the following tree, which has all the relevant fixes (enabling dvb, your audio fix, proper gpio setting, etc). http://kernellabs.com/hg/~dheitmueller/misc-fixes2/ If you have any trouble, please let me know. Otherwise I would like to issue a PULL request for this tree. Thanks, -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx25840 6.5MHz carrier detection fixes
On Sat, Sep 26, 2009 at 04:12:59PM -0400, Andy Walls wrote: On Sat, 2009-09-26 at 00:16 +0300, Aleksandr V. Piskunov wrote: cx25840: Disable 6.5MHz carrier autodetection for PAL, always assume its DK. Only try to autodetect 6.5MHz carrier for SECAM if user accepts both system DK and L. Signed-off-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com Aleksandr, I would like a little more time to look at your patch. PAL part of the patch shouldn't affect any users IMHO, its the SECAM part where we got SECAM-L users in France and SECAM-DK in Russia. However, in the mean time, could you test the DK vs. L autodetection, without your patch, using the cx25840 firmware in http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20070217.tar.gz ? The MD5 sum of that firmware is: $ md5sum /lib/firmware/v4l-cx25840.fw 99836e41ccb28c7b373e87686f93712a /lib/firmware/v4l-cx25840.fw The cx25840 firmware in http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20080701.tar.gz http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware.tar.gz is probably wrong to use for the CX2584[0123] chips as it it actually CX23148 A/V core firmware - very similar but not the same. Tested following versions of v4l-cx25840.fw, no patch: 99836e41ccb28c7b373e87686f93712a b3704908fd058485f3ef136941b2e513 647d818c6fc82f385ebfbbd4fb2def6d (comes as makoaudc.rom with win driver) Same issue with all 3 versions of firmware tested, cold shutdown between every test. Quick description: PAL-DK source from cable, strong and clear signal. On channel switch there are 3 typical outcomes a) ~50% - DK audio system detected b) ~40 - controller fails to detect standard, muted, may detect something later c) ~10% - AM-L audio detected, playing some bogus static, may detect DK later Of course there is a possibility that CX25843 doesn't like something in IF that comes from xc2028 tuner, but as I said, signal ir very good and picture/audio on every of 50+ channels is crisp and clear. -- 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
[no subject]
subscribe linux-media -- 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: Questions about Terratec Hybrid XS (em2882) [0ccd:005e]
On 26.09.09 16:59, Devin Heitmueller wrote: On Fri, Sep 25, 2009 at 6:10 PM, Uros Vampl mobile.leec...@gmail.com wrote: Alright, success!!! Since it seems everything for this tuner is set up the same as for the Hauppauge WinTV HVR 900, I figured let's set things up *exactly* the same. So, like it's there for the Hauppauge, I added .mts_firmware = 1 to the definition of the hybrid XS em2882. And well, working TV audio!! dmesg output this time: xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id . MTS (4), id 00ff: xc2028 4-0061: Loading firmware for type=MTS (4), id 00010007. So now with the attached patch, everything (analog, digital, remote) works! Regards, Uroš Hello Uros, Please test out the following tree, which has all the relevant fixes (enabling dvb, your audio fix, proper gpio setting, etc). http://kernellabs.com/hg/~dheitmueller/misc-fixes2/ If you have any trouble, please let me know. Otherwise I would like to issue a PULL request for this tree. Hi, Your tree does not work, no audio. I quickly found the problem though: gpio is set to default_analog, but it needs to be set to hauppauge_wintv_hvr_900_analog. So I guess treating the EM2880 and EM2882 as the same will not work, because they require different gpio settings. Regards, Uroš -- 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: Questions about Terratec Hybrid XS (em2882) [0ccd:005e]
On Sat, Sep 26, 2009 at 8:23 PM, Uros Vampl mobile.leec...@gmail.com wrote: On 26.09.09 16:59, Devin Heitmueller wrote: On Fri, Sep 25, 2009 at 6:10 PM, Uros Vampl mobile.leec...@gmail.com wrote: Alright, success!!! Since it seems everything for this tuner is set up the same as for the Hauppauge WinTV HVR 900, I figured let's set things up *exactly* the same. So, like it's there for the Hauppauge, I added .mts_firmware = 1 to the definition of the hybrid XS em2882. And well, working TV audio!! dmesg output this time: xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id . MTS (4), id 00ff: xc2028 4-0061: Loading firmware for type=MTS (4), id 00010007. So now with the attached patch, everything (analog, digital, remote) works! Regards, Uroš Hello Uros, Please test out the following tree, which has all the relevant fixes (enabling dvb, your audio fix, proper gpio setting, etc). http://kernellabs.com/hg/~dheitmueller/misc-fixes2/ If you have any trouble, please let me know. Otherwise I would like to issue a PULL request for this tree. Hi, Your tree does not work, no audio. I quickly found the problem though: gpio is set to default_analog, but it needs to be set to hauppauge_wintv_hvr_900_analog. So I guess treating the EM2880 and EM2882 as the same will not work, because they require different gpio settings. Regards, Uroš Hmm.. Interesting. That does make me wonder whether the GPIOs are setup for audio properly on the em2880 version of the profile, or whether the user in question just never tested it. I'll have to go back and check the USB trace. Nonetheless, I'll just check in your version of the patch, and scrap my version entirely for now. Could you please add your SOB to the patch? Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] V4L/DVB: DaVinci: remove unused #include linux/version.h
Remove unused #include linux/version.h('s) in
drivers/media/video/davinci/vpfe_capture.c
drivers/media/video/davinci/vpif_capture.c
drivers/media/video/davinci/vpif_display.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
drivers/media/video/davinci/vpfe_capture.c |1 -
drivers/media/video/davinci/vpif_capture.c |1 -
drivers/media/video/davinci/vpif_display.c |1 -
3 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 402ce43..5c08ae2 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -70,7 +70,6 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/interrupt.h
-#include linux/version.h
#include media/v4l2-common.h
#include linux/io.h
#include media/davinci/vpfe_capture.h
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index d947ee5..5b494c5 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -33,7 +33,6 @@
#include linux/i2c.h
#include linux/platform_device.h
#include linux/io.h
-#include linux/version.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index c015da8..1f232eb 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -29,7 +29,6 @@
#include linux/i2c.h
#include linux/platform_device.h
#include linux/io.h
-#include linux/version.h
#include asm/irq.h
#include asm/page.h
--
1.6.1.3
--
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/~awalls/cx23888-ir-part1
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 for the following 8 changesets: 01/08: v4l2-chip-ident: Add ID's needed for the cx23885 and cx25840 modules http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5b2b33f2e3d7 02/08: cx23885: Fix support for v4l2-dbg access to CX2388[578] and CX23417 regs http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f652c361b61d 03/08: cx23885: Add skeleton v4l2_subdev for the CX23888 integrated IR controller http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f153c30da5c5 04/08: cx25840: Improve detection of CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=0efbeb807ff0 05/08: cx25840: Convert chip/core family checks to static inline functions http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=80d278a74d8a 06/08: cx25840: Separate set_audclk_freq functionality for the different chips http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5f58b345e32e 07/08: cx25840: Init PLLs properly for CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=b1ebfabe9c60 08/08: cx23885: Enable HVR-1850 CX23888 A/V core to get VID_CLK running for IR http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=7d99cae94fe5 b/linux/drivers/media/video/cx23885/cx23885-ioctl.c | 197 b/linux/drivers/media/video/cx23885/cx23885-ioctl.h | 39 + b/linux/drivers/media/video/cx23885/cx23888-ir.c | 233 + b/linux/drivers/media/video/cx23885/cx23888-ir.h | 28 + linux/drivers/media/video/cx23885/Makefile |3 linux/drivers/media/video/cx23885/cx23885-417.c | 10 linux/drivers/media/video/cx23885/cx23885-cards.c| 12 linux/drivers/media/video/cx23885/cx23885-core.c | 20 linux/drivers/media/video/cx23885/cx23885-ioctl.c| 11 linux/drivers/media/video/cx23885/cx23885-video.c| 34 - linux/drivers/media/video/cx23885/cx23885.h | 12 linux/drivers/media/video/cx25840/cx25840-audio.c| 461 ++- linux/drivers/media/video/cx25840/cx25840-core.c | 258 +++--- linux/drivers/media/video/cx25840/cx25840-core.h | 22 linux/drivers/media/video/cx25840/cx25840-firmware.c | 10 linux/include/media/v4l2-chip-ident.h| 16 16 files changed, 1140 insertions(+), 226 deletions(-) These changes are the first part in a set of changes that get IR receive working for the HVR-1850 with the Hauppaugue grey RC-5 remote, and starts laying the foundation for using the integrated IR controller in CX2388[57], CX2310[012], CX2584[0123], and CX23418 chips. I have 25 other small changes to consolidate and clean up, that I will submit as a follow up pull request later that get IR working for the HVR-1850. I am submitting this CX23888 IR work in two parts, instead of one complete set, for two reasons: 1. Steve is waiting on these particular cx25840 module changes to move forward on work for analog video for some cards supported by the cx23885 driver. I don't want to hold up that work. 2. the second half of this set will include my v4l2_subdev_ir_ops definition, which has the potential for discussion or rework (I hope not though). Since this first half of the changes don't depend on that being finalized, I wanted to get these 1366 changes moving forward, before too many unrelated changes happen to the cx25840 and cx23885 modules. Thanks, 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
