Re: [DaVinci] patches for linux-media
On Wednesday 17 June 2009 23:01:21 Karicheri, Muralidharan wrote: Hi Hans Mauro, The v3 version of the DaVici VPFE Capture driver and TVP514x driver has been sent to the list for review. I expect this to sail through with out any comments as I have addressed few minor comments from last review. I think Hans will send you the pull request for these patches. Once again, it will be great if this can be merged to 2.6.31. I'll prepare a pull request for this tomorrow. Regards, Hans Murali Karicheri m-kariche...@ti.com I have proposed this before, but I'll do it again: I'm more than happy to be the official person who collects and organizes the omap and davinci patches for you and who does the initial reviews. This is effectively already the case since I've been reviewing both omap and davinci patches pretty much from the beginning. Both the omap2/3 display driver and the davinci drivers are now very close to be ready for inclusion in the kernel as my last reviews only found some minor things. Part of the reason for the delays for both omap and davinci was that they had to be modified for v4l2_subdev, which was an absolute necessity, and because they simply needed quite a bit of work to make them suitable for inclusion in the kernel. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PATCHv7 0/9] FM Transmitter (si4713) and another changes
On Tuesday 16 June 2009 13:07:55 Eduardo Valentin wrote: On Tue, Jun 16, 2009 at 01:01:51PM +0200, ext Hans Verkuil wrote: On Tuesday 16 June 2009 12:47:14 Eduardo Valentin wrote: Hi Hans, On Sun, Jun 14, 2009 at 01:37:20PM +0200, ext Hans Verkuil wrote: snip I think the refactoring should be done first. I don't believe it is that much work and experience shows that it is better to do this right away while you are still motivated :-) hehehe.. Yes, that's what I was expecting :-). No problem. I've started it. I will resend the series once I've completed the re-factoring and I 've made some testing after that. I hope tomorrow or so. The string control support should not go into 2.6.31. I would like to do that only in the v4l-dvb tree (so it will appear in 2.6.32) since I want to give that a bit more time to mature. I implemented it very quickly and I do not feel comfortable queueing this for 2.6.31. Right. Yes, better to test the stuff a bit more. In addition it is still unclear if Mauro will merge my v4l-dvb-subdev2 tree for 2.6.31. I hope so, since otherwise it will hamper the development of this and other embedded platforms. Ok. I also need to add a new V4L2_CAP_MODULATOR (which needs a review as well). And finally I realized that we need to add some v4l2_modulator capabilities for the RDS encoder similar to the upcoming v4l2_tuner RDS capabilities as is described in this RFC: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498. html I haven't had time to implement this RFC and I know that is not going to make 2.6.31. It's now almost at the top of my TODO list, so it should go in soon (pending unforeseen circumstances). Ok. I'll take a look at it. I've worked on this yesterday. You can take a look at my v4l-dvb-rds tree. Both the API and the documentation of it in the v4l2-spec is in there. I started work on updating the few RDS decoders that we have, but that is not yet in that tree. As a result of rereading this RFC I also started to wonder about whether the si4713 supports the MMBS functionality. Do you know anything about that? No. Not that I know. Can you point some link? http://www.rds.org.uk/rdsfrdsrbds.html But I've just read here: http://www.rds.org.uk/rds98/pdf/rdsForum_standards_090414_8.pdf that MMBS is discontinued. I'll need to investigate this further, but if this is indeed true then this can be removed completely from our RDS decoder and encoder APIs. Yes, better to double check. At least with si4713, I haven't heard anything about this. MMBS does definitely not apply to this FM transmitter. In order to transmit MMBS you would need to have a license to do so since it seems to be a proprietary format. I have not been able to confirm that it is indeed discontinued, but since it is a proprietary predecessor format of RDS it is very very likely indeed that this is true. I'm going to remove the MMBS support from my RDS API and I'll just add a note to the spec that if anyone needs this, then they should contact the list. I am glad I found this in time before the final RDS decoding API is in the kernel. 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] New utility program atsc_epg added to dvb-apps utility suite.
2009/6/18 Yufei Yuan yfy...@gmail.com: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Please do send the patch with tabs instead of spaces for indentation. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.
On Thu, Jun 18, 2009 at 12:32 PM, Manu Abrahamabraham.m...@gmail.com wrote: 2009/6/18 Yufei Yuan yfy...@gmail.com: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Please do send the patch with tabs instead of spaces for indentation. Also: * please cleanup the white spaces in the patch, if any. * please use the unified format, diff -u option. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mx31moboard MT9T031 camera support
Hi Guennadi, I am trying to follow your developments at porting soc-camera to v4l2-subdev. However, even if I understand quite correctly soc-camera, it is quite difficult for me to get all the subtleties in your work. That's why I am asking you for a little help: when do you think would be the best timing for me to add the mt9t031 camera support for mx31moboard within your current process ? I guess it should not be too difficult, I had done it before, and I can base myself on what you have done for pcm037: http://download.open-technology.de/soc-camera/20090617/0025-pcm037-add-MT9T031-camera-support.patch Now I have a second question. On our robot, we physically have two cameras (one looking to the front and one looking at a mirror) connected to the i.MX31 physical bus. We have one signal that allows us to control the multiplexer for the bus lines (video signals and I2C) through a GPIO. This now works with a single camera declared in software and choices to the multiplexer done when no image transfer is happening ( /dev/video is not open). What do you think should be the correct way of dealing with these two cameras with the current driver implementation (should I continue to declare only one camera in the software) ? And do you think it could be possible to hot-switch from one camera to the other ? My colleagues ask about it, I tell them that from my point of view this seems not possible without changing the drivers, and even the drivers would have to be changed quite heavily and it is not trivial. Best Regards Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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: mx31moboard MT9T031 camera support
On Thu, 18 Jun 2009, Valentin Longchamp wrote: Hi Guennadi, I am trying to follow your developments at porting soc-camera to v4l2-subdev. However, even if I understand quite correctly soc-camera, it is quite difficult for me to get all the subtleties in your work. That's why I am asking you for a little help: when do you think would be the best timing for me to add the mt9t031 camera support for mx31moboard within your current process ? You can do this now, based either on the v4l tree, or wait for Linus to pull it - a pull request has been sent ba Mauro yesterday, looks like Linus hasn't pulled yet. The way you add your platform is going to change, and the pull, that I'm referring to above makes it possible for both old style and new style board camera data to work. Of course, it would be best for you to implement the new style platform data. You can do this by either looking at my patches, which I've posted to the lists earlier, and which are also included in my patch stack, which I announced yesterday. Or you can wait a bit until I update my pcm037 patch (going to do this now) and post it to arm-kernel. I'll (try not to forget to) add you to cc, that should be quite easy to follow for you. I guess it should not be too difficult, I had done it before, and I can base myself on what you have done for pcm037: http://download.open-technology.de/soc-camera/20090617/0025-pcm037-add-MT9T031-camera-support.patch Yes, use this or wait a bit for an updated version. Now I have a second question. On our robot, we physically have two cameras (one looking to the front and one looking at a mirror) connected to the i.MX31 physical bus. We have one signal that allows us to control the multiplexer for the bus lines (video signals and I2C) through a GPIO. This now works with a single camera declared in software and choices to the multiplexer done when no image transfer is happening ( /dev/video is not open). What do you think should be the correct way of dealing with these two cameras with the current driver implementation (should I continue to declare only one camera in the software) ? And do you think it could be possible to hot-switch from one camera to the other ? My colleagues ask about it, I tell them that from my point of view this seems not possible without changing the drivers, and even the drivers would have to be changed quite heavily and it is not trivial. Do the cameras use different i2c addresses? If they use the same address I don't think you'd be able to register them simultaneously. If they do use different addresses, you can register both of them and use platform .power() callback to switch between them using your multiplexer. See arch/sh/boards/mach-migor/setup.c for an example. There was also a proposal to use switching input to select a data source, but this is currently unsupported by soc-camera. 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: Digital Everywhere FloppyDTV / FireDTV (incl. CI)
Johannes T. K. linuxme...@tangkristensen.dk writes: If anyone has been able to tune the cable adapter under linux I'd like to hear more. I have a firedtv c/ci which I have had some success with in linux. I have no problem tuning and watching/recoding programs as long as they are not scrambled. Same here, the CI part is useless with firedtv driver. I have self-compiled VDR v1.7.7 running with xine-plugin on Debian testing/unstable 2.6.29 x86_64, and there's no CAM menu available in VDR's setup screen. Tested with older SCM Conax and now CAS7 capable NP4 Conax CAM, no success. Both CAMs work fine with Sony Bravia V3000, and SCM card was working fine in a Technotrend T1500+CI (DVB-T) with VDR v1.4.7. Updating firmware of my FloppyDTV C/CI (which can only be done on a Windows box, great) didn't help anything either, but it seems to have made things even worse. Now there's occasional errors like Jun 15 21:40:04 silver kernel: firedtv 00128726020026b2-0: FCP response timed out which didn't show up before firmware update. Now VDR recordings from FTA channels fail sometimes too, and kernel log gets filled with DVB (dvb_dmxdev_filter_start): could not alloc feed -- 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: mx31moboard MT9T031 camera support
Guennadi Liakhovetski wrote: On Thu, 18 Jun 2009, Valentin Longchamp wrote: Hi Guennadi, I am trying to follow your developments at porting soc-camera to v4l2-subdev. However, even if I understand quite correctly soc-camera, it is quite difficult for me to get all the subtleties in your work. That's why I am asking you for a little help: when do you think would be the best timing for me to add the mt9t031 camera support for mx31moboard within your current process ? You can do this now, based either on the v4l tree, or wait for Linus to pull it - a pull request has been sent ba Mauro yesterday, looks like Linus hasn't pulled yet. The way you add your platform is going to change, and the pull, that I'm referring to above makes it possible for both old style and new style board camera data to work. Of course, it would be best for you to implement the new style platform data. You can do this by either looking at my patches, which I've posted to the lists earlier, and which are also included in my patch stack, which I announced yesterday. Or you can wait a bit until I update my pcm037 patch (going to do this now) and post it to arm-kernel. I'll (try not to forget to) add you to cc, that should be quite easy to follow for you. I guess it should not be too difficult, I had done it before, and I can base myself on what you have done for pcm037: http://download.open-technology.de/soc-camera/20090617/0025-pcm037-add-MT9T031-camera-support.patch Yes, use this or wait a bit for an updated version. OK, thanks a lot. Since I am busy at other things at the moment, I am going to wait for you updated version and that things are stabilized a little bit with the 31-rc1. And I will use the new style platform data. Now I have a second question. On our robot, we physically have two cameras (one looking to the front and one looking at a mirror) connected to the i.MX31 physical bus. We have one signal that allows us to control the multiplexer for the bus lines (video signals and I2C) through a GPIO. This now works with a single camera declared in software and choices to the multiplexer done when no image transfer is happening ( /dev/video is not open). What do you think should be the correct way of dealing with these two cameras with the current driver implementation (should I continue to declare only one camera in the software) ? And do you think it could be possible to hot-switch from one camera to the other ? My colleagues ask about it, I tell them that from my point of view this seems not possible without changing the drivers, and even the drivers would have to be changed quite heavily and it is not trivial. Do the cameras use different i2c addresses? If they use the same address I don't think you'd be able to register them simultaneously. If they do use different addresses, you can register both of them and use platform .power() callback to switch between them using your multiplexer. See arch/sh/boards/mach-migor/setup.c for an example. There was also a proposal to use switching input to select a data source, but this is currently unsupported by soc-camera. The sensor chips both are mt9t031 so they have the same i2c address (I have looked at the datasheet, and I don't think this can be changed). So I cannot use them both at the same time. Now you talk about the .power() callback, I could use it so that the multiplexer is managed by it, using a similar mechanism as in mach-migor. If this could allow me one different /dev/video nod for each camera (that of course cannot be used at the same time), it would simplify a lot of things for my users. I will give it a try (hoping that this also works at driver registering ... we will see). Thanks for your answers. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- 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: bttv problem loading takes about several minutes
Hi,
On Mi, Jun 17, 2009 at 10:06:26 +0200, Hans Verkuil wrote:
The log is from bttv version 0.9.17. The new code is only present in version
0.9.18. So this is definitely not related to any of my changes.
The text bttv0: gpio: en=, out= in=003ff502 [init] comes
from the call to bttv_gpio_tracking in bttv_probe, then the next
text bttv0: tuner type=24 comes from early in bttv_init_card2, before any
i2c modules have been loaded.
The code in bttv_probe (bttv-driver.c) does this:
if (bttv_verbose)
bttv_gpio_tracking(btv,init);
/* needs to be done before i2c is registered */
bttv_init_card1(btv);
/* register i2c + gpio */
init_bttv_i2c(btv);
/* some card-specific stuff (needs working i2c) */
bttv_init_card2(btv);
So it looks like it can be either bttv_init_card1 or init_bttv_i2c that is
causing the delay.
Halim, can you try to put some printk() statements in between the calls
above to see which call is taking so long? Actually, it would be nice if
you are able to 'drill-down' as well in whatever function is causing the
delay, since I truly don't see what might be delaying things for you.
So I have tested latest v4l-dvb from hg.
The mentioned code was changed like this:
if (bttv_verbose)
{
printk (bttv_gpio_tracking(bt);
bttv_gpio_tracking(btv,init);
}
/* needs to be done before i2c is registered */
printk(bttv_init_card1(btv););
printk(bttv_init_card1(btv););
bttv_init_card1(btv);
/* register i2c + gpio */
printk(init_bttv_i2c(btv););
init_bttv_i2c(btv);
Result:
[ 1069.277781] bttv: driver version 0.9.18 loaded
[ 1069.277788] bttv: using 8 buffers with 2080k (520 pages) each for capture
[ 1069.277886] bttv: Bt8xx card found (0).
[ 1069.277906] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio
: 0xf780
[ 1069.278105] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm
od option]
[ 1069.278167] bttv_gpio_tracking(bt7bttv0: gpio: en=, out= in
=003ff502 [init]
[ 1069.278173] bttv_init_card1(btv);bttv_init_card1(btv);init_bt
tv_i2c(btv);6bttv0: tuner type=24
Regards,
Hans
Giving this command with current drivers has some problems:
1. it takes several minutes to load bttv module.
2. capturing doesn't work any more (dropped frames etc).
Tested with current v4l-dvb from hg, ubuntu 9.04,
debian lenny.
I have a bt878 based card from leadtek.
Here is my output after loading the driver:
[ 3013.735459] bttv: driver version 0.9.17 loaded
[ 3013.735470] bttv: using 32 buffers with 16k (4 pages) each for
capture [ 3013.735542] bttv: Bt8xx card found (0).
[ 3013.735562] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency:
32, mmio
: 0xf780
[ 3013.737762] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP
[card=34,insm od option]
[ 3013.737825] bttv0: gpio: en=, out= in=003ff502
[init] [ 3148.136017] bttv0: tuner type=24
[ 3148.136029] bttv0: i2c: checking for MSP34xx @ 0x80... not found
[ 3154.536019] bttv0: i2c: checking for TDA9875 @ 0xb0... not found
[ 3160.936018] bttv0: i2c: checking for TDA7432 @ 0x8a... not found
[ 3167.351398] bttv0: registered device video0
[ 3167.351434] bttv0: registered device vbi0
[ 3167.351463] bttv0: registered device radio0
[ 3167.351485] bttv0: PLL: 28636363 = 35468950 . ok
[ 3167.364182] input: bttv IR (card=34) as /class/input/input6
Please help!
Regards
Halim
--
Halim Sahin
E-Mail:
halim.sahin (at) t-online.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
--
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
--
Halim Sahin
E-Mail:
halim.sahin (at) t-online.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: mx31moboard MT9T031 camera support
On Thu, 18 Jun 2009, Valentin Longchamp wrote: The sensor chips both are mt9t031 so they have the same i2c address (I have looked at the datasheet, and I don't think this can be changed). So I cannot use them both at the same time. Right, but I think, there are some i2c ICs, that allow for address translations. Don't remember what they are called, some multiplexers or some such. Now you talk about the .power() callback, I could use it so that the multiplexer is managed by it, using a similar mechanism as in mach-migor. If this could allow me one different /dev/video nod for each camera (that of course cannot be used at the same time), it would simplify a lot of things for my users. I will give it a try (hoping that this also works at driver registering ... we will see). Don't think it would work, at least not with the current stack. With the new stack video devices are registered at host-driver registration time, after i2c devices are registered. It wouldn't work with the old stack either. 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
ok more details: Re: bttv problem loading takes about several minutes
Hi, sorry for the nusable output! I found the time consuming funktion: bttv_init_card2(btv); This takes about 4 min. today. my new testcode: /* needs to be done before i2c is registered */ printk(linke 2:bttv_init_card1(btv);\n); bttv_init_card1(btv); /* register i2c + gpio */ printk(line 3: init_bttv_i2c(btv);\n); init_bttv_i2c(btv); /* some card-specific stuff (needs working i2c) */ printk(line4: some card-specific stuff needs working i2c \n); bttv_init_card2(btv); printk(irq init\n); init_irqreg(btv); dmesg output: [ 2282.430209] bttv: driver version 0.9.18 loaded [ 2282.430216] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 2282.430313] bttv: Bt8xx card found (0). [ 2282.430334] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio : 0xf780 [ 2282.430777] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm od option] [ 2282.430839] bttv_gpio_tracking(bt [ 2282.430843] bttv0: gpio: en=, out= in=003ff502 [init] [ 2282.430845] linke 2:bttv_init_card1(btv); [ 2282.430859] line 3: init_bttv_i2c(btv); [ 2282.430917] line4: some card-specific stuff needs working i2c [ 2282.430922] bttv0: tuner type=24 Ok here is the 4 min dely and after that the following linkes were printed out: [ 2416.836017] bttv0: audio absent, no audio device found! [ 2416.836024] irq init [ 2416.840551] bttv0: registered device video1 [ 2416.840684] bttv0: registered device vbi0 [ 2416.840716] bttv0: registered device radio0 [ 2416.840736] bttv0: PLL: 28636363 = 35468950 .6bttv0: PLL: 28636363 = 3546 8950 . ok [ 2416.856221] input: bttv IR (card=34) as /devices/pci:00/:00:0b.0/inpu t/input10 [ 2416.864069] ok Hope that helps! Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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: OV7670: getting it working with soc-camera.
Guennadi Liakhovetski wrote: On Wed, 17 Jun 2009, Jonathan Cameron wrote: This is purely for info of anyone else wanting to use the ov7670 with Guennadi's recent work on converted soc-camera to v4l2-subdevs. It may not be completely minimal, but it's letting me take pictures ;) Cool, I like it! Not the pictures, but the fact that the required patch turned out to be so small. Of course, you understand this is not what we'll eventually commit, but, I think, this is a good start. In principle, if a device has all parameters fixed, there's no merit in trying to set them. Yup, my intention is to slowly remove elements as they become unnecessary (and push any that actually make sense to the mailing list). Couple of minor queries: Currently it is assumed that there is a means of telling the chip to use particular bus params. In the case of this one it doesn't support anything other than 8 bit. Stuff may get added down the line, but in meantime does anyone mind if we make icd-ops-set_bus_param optional in soc-camera? struct soc_camera_ops will disappear completely anyway, and we don't know yet what the v4l2-subdev counterpart will look like. Sure, I'll wait and see whether this question is relevant down the line. ... Or for that matter why the address is right shifted by 1 in: v4l_info(client, chip found @ 0x%02x (%s)\n, client-addr 1, client-adapter-name); Admittedly the data sheet uses an 'unusual' convention for the address (separate write and read address which correspond to a single address of 0x21 with the relevant write bit set as appropriate). That's exactly the reason, I think. Many (or most?) datasheets specify i2c addresses which are a double of Linux i2c address. IIRC this is just a Linux convention to use the shifted address. Um. I'm not sure I agree with this. The convention when specifying the address in registration is to use correct one (without the write bit) and based on a lot of non video chips I've come across is about 50 / 50 on how they document it (with many using a delightful and random mix of the two) If you are going to have a registration scheme that requires the board code to specify the address as 0x21 then to my mind having the driver declare it as being on 0x42 seems rather odd and misleading. This is particularly true here where the driver is using smbus calls as that specification is very clear indeed on the fact that addresses are 7 bit. Admittedly this chip uses the sccb bus protocol that just 'happens' to bare a startling resemblance to smbus / i2c. Still this isn't exactly a crucial element of the driver! As ever any comments welcome. Thanks to Guennadi Liakhovetski for his soc-camera work and Hans Verkuil for conversion of the ov7670 to soc-dev. Tested against a merge of todays v4l-next tree and Linus' current with the minor pxa-camera bug I posted earlier fixed and Guennadi's extensive patch set applied (this requires a few hand merges, but nothing too nasty). Good to know. A couple of comments: ... +#endif ...and this switching. All this should be done in struct soc_camera_link .power() and .reset() methods in your platform code. Ah, I'd missed those methods, thanks! You are quite right about the i2c_device_table as well, not sure what got into me there. Thanks, Jonathan -- 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 3/9] dm355 ccdc module for vpfe capture driver
Hi,
sorry not to have answered sooner.
On Tuesday 09 June 2009 00:05:10 Karicheri, Muralidharan wrote:
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+ if (offset = ccdc_addr_size)
This should be .
+ return __raw_readl(ccdc_base_addr + offset);
+ else {
+ dev_err(dev, offset exceeds ccdc register address space\n);
+ return -1;
+ }
+}
+
+static inline u32 regw(u32 val, u32 offset)
+{
+ if (offset = ccdc_addr_size) {
This should be .
[MK] I removed above two checks since we are getting the required IO block
mapped and this check is not needed. if some reason there is an offset
outside the valid range, it is a bug and will be caught through oops,
right?.
Not necessarily. I'm not sure how ioremap works exactly, but accessing data
outside the remapped region might end up being a valid access. Anyway this
shouldn't happen unless a bug creeps in the driver. If you want to validate
the size it should be done in ccdc_set_ccdc_base instead, but that's not
really required.
+ __raw_writel(val, ccdc_base_addr + offset);
+ return val;
+ } else {
+ dev_err(dev, offset exceeds ccdc register address space\n);
+ return -1;
+ }
+}
Can't you check that ccdc_addr_size is big enough in ccdc_set_ccdc_base ?
The read/write access functions could then be made much simpler.
[MK] See above comment
+ }
+
+ switch (ctrl-id) {
+ case CCDC_CID_R_GAIN:
+ gain-r_ye = ctrl-value CCDC_GAIN_MASK;
+ break;
+ case CCDC_CID_GR_GAIN:
+ gain-gr_cy = ctrl-value CCDC_GAIN_MASK;
+ break;
+ case CCDC_CID_GB_GAIN:
+ gain-gb_g = ctrl-value CCDC_GAIN_MASK;
+ break;
+
+ case CCDC_CID_B_GAIN:
+ gain-b_mg = ctrl-value CCDC_GAIN_MASK;
+ break;
case CCDC_CID_OFFSET: ?
+ default:
+ ccdc_hw_params_raw.ccdc_offset = ctrl-value
CCDC_OFFSET_MASK;
[MK] default is for offset. We are validating the ids above for any of the
checked values in the switch statement
If you're sure that the control ID is one of the above cases, use
CCDC_CID_OFFSET instead of default, the code will be easier to read.
+
+static void ccdc_reset(void)
+{
+ int i;
+ /* disable CCDC */
+ dev_dbg(dev, \nstarting ccdc_reset...);
+ ccdc_enable(0);
+ /* set all registers to default value */
+ for (i = 0; i = 0x15c; i += 4)
+ regw(0, i);
Ouch ! Not all registers have a 0 default value. Beside, blindly resetting
all registers sounds hackish. According to the documentation, the proper
way to reset the VPFE/VPSS is through the power sleep controller.
[MK] This function actually write default values in the registers since the
implementation assume this. So I have renamed it as ccdc_restore_defaults().
We don't want to reset the ccdc here, only want to write default values.
Some registers have a non-0 default value according to the datasheet.
+/*
+ * ccdc_setwin
+ *
+ * This function will configure the window size to
+ * be capture in CCDC reg
+ */
+static void ccdc_setwin(struct ccdc_imgwin *image_win,
+ enum ccdc_frmfmt frm_fmt, int ppc)
What's does ppc stand for ?
[MK] per pixel count. I documented this.
+{
+ int horz_start, horz_nr_pixels;
Does horz_nr_pixels really store the number of pixels ? It seems to me it
counts the number of bytes. hstart and hsize would then be more
appropriate names.
[MK]. It is storing number of pixels and the documentation say so. So names
used are fine as per hw spec.
Then I'm puzzled by
horz_start = image_win-left (ppc - 1);
image_win-left is a number of pixels. Shifting it left by 1 in the YUV case
will give a number of bytes.
+ int vert_start, vert_nr_lines;
If the above comment is correct, this could become vstart and vsize to be
consistent.
[MK] No change. See above
+ return 0;
+}
+static enum ccdc_buftype ccdc_get_buftype(void)
+{
+ if (ccdc_if_type == VPFE_RAW_BAYER)
+ return ccdc_hw_params_raw.buf_type;
+ return ccdc_hw_params_ycbcr.buf_type;
+}
+
+static int ccdc_enum_pix(enum vpfe_hw_pix_format *hw_pix, int i)
+{
+ int ret = -EINVAL;
+ if (ccdc_if_type == VPFE_RAW_BAYER) {
+ if (i CCDC_MAX_RAW_BAYER_FORMATS) {
+ *hw_pix = ccdc_raw_bayer_hw_formats[i];
How does this compare to memcpy in term of code size and run time ?
[MK] not sure what you are asking here.
I was wondering which of
*hw_pix = ccdc_raw_bayer_hw_formats[i];
and
memcpy(hw_pix, ccdc_raw_bayer_hw_formats[i], sizeof(*hw_pix));
lead to a smaller code size and run time. It's a minor issue, it can always be
changed later if memcpy is found to be smaller and faster.
+ return 0;
+}
+#define CCDC_WIN_PAL {0, 0, 720,
Re: PULL request - http://linuxtv.org/hg/~hgoede/gspca
Em Wed, 17 Jun 2009 08:46:19 +0200 Hans de Goede hdego...@redhat.com escreveu: Hi Mauro, Can you please pull from: http://linuxtv.org/hg/~hgoede/gspca I've asked JF Moine a couple of days ago if he wanted this to go through his tree or directly, but have not received an answer, as there is one important bugfix in this tree I'm now asking you to pull this directly. Hmm... your tree seems to be based on JF Moine one. There are several patches that were already merged appearing again to me, as shown at the enclosed logs. Also, checkpatch is warning about a few troubles at the patches. Could you please create another tree, directly based on mine, fix the coding styles and send another pull request? p.s. Given that I'm currently doing quite a bit of gspca work I think its best for the future if I just send pull requests to you directly is that ok ? For me that's ok. Just avoid touching at gspca core without sync with Jean-Francois, to avoid merge conflicts. Cheers, Mauro. $ ./hgimport http://linuxtv.org/hg/~hgoede/gspca Pushing from remote site http://linuxtv.org/hg/~hgoede/gspca, tree: gspca Number of patches: 30 /tmp/newpatches/hg_gspca_01.patch with cs=b39bf9d2d088 First patch. Patch against an older patch: changeset: 11721:59f970bfcf5f parent: 11707:a6e9c1a8a3c9 parent: 11720:712c57ab2315 user:Mauro Carvalho Chehab mche...@redhat.com date:Sat May 09 06:34:19 2009 -0300 summary: merge: http://linuxtv.org/hg/~jfrancois/v4l-dvb /tmp/newpatches/hg_gspca_02.patch with cs=c52097c4b796 Ok. /tmp/newpatches/hg_gspca_03.patch with cs=352c3fbcbaa7 Nok/Merge: Old node ID: c52097c4b79677ed68dd3cdcc7061c12bbf23628 Node parents c52097c4b79677ed68dd3cdcc7061c12bbf23628 8d37e850566419e7905e66f875b9384d96bf340d Renamed to /tmp/newpatches/hg_gspca_03.merge /tmp/newpatches/hg_gspca_03.patch with cs=74a6228c7d3a Ok. /tmp/newpatches/hg_gspca_04.patch with cs=f453f6641d09 Nok/Merge: Old node ID: 74a6228c7d3a78240a4c8230be79f9d934aedc21 Node parents 74a6228c7d3a78240a4c8230be79f9d934aedc21 315bc4b65b4f527c4f9bc4fe3290e10f07975437 Renamed to /tmp/newpatches/hg_gspca_04.merge /tmp/newpatches/hg_gspca_04.patch with cs=fb857617b17b Ok. /tmp/newpatches/hg_gspca_05.patch with cs=b350bf3c9910 Ok. /tmp/newpatches/hg_gspca_06.patch with cs=891510e73ea7 Ok. /tmp/newpatches/hg_gspca_07.patch with cs=9cb97be16341 Ok. /tmp/newpatches/hg_gspca_08.patch with cs=c4bd8403b042 Nok/Merge: Old node ID: 9cb97be1634149d7a2b91b6bc204e58dc9ee7bcd Node parents 9cb97be1634149d7a2b91b6bc204e58dc9ee7bcd 5ed2a853b69218bf6f6dfdb7f4816ba4e5d78fa4 Renamed to /tmp/newpatches/hg_gspca_08.merge /tmp/newpatches/hg_gspca_08.patch with cs=e42a9739690d Ok. /tmp/newpatches/hg_gspca_09.patch with cs=fff1a04edcd7 Ok. /tmp/newpatches/hg_gspca_10.patch with cs=54b0a6ba6521 Ok. /tmp/newpatches/hg_gspca_11.patch with cs=6a78a10d97e2 Ok. /tmp/newpatches/hg_gspca_12.patch with cs=3e51f723a019 Ok. /tmp/newpatches/hg_gspca_13.patch with cs=d5af2604e915 Nok/Merge: Old node ID: 3e51f723a01942460a3abf8b407d6a818379289f Node parents 3e51f723a01942460a3abf8b407d6a818379289f bff77ec331161c660be7a60bf6139df000758480 Renamed to /tmp/newpatches/hg_gspca_13.merge /tmp/newpatches/hg_gspca_13.patch with cs=0649c95d8cba Ok. /tmp/newpatches/hg_gspca_14.patch with cs=a1e8596544b8 Ok. /tmp/newpatches/hg_gspca_15.patch with cs=ff01a38c70a1 Ok. /tmp/newpatches/hg_gspca_16.patch with cs=91b64d7bc5eb Ok. /tmp/newpatches/hg_gspca_17.patch with cs=3a253f13111b Ok. /tmp/newpatches/hg_gspca_18.patch with cs=dd8139a56412 Ok. /tmp/newpatches/hg_gspca_19.patch with cs=35a3ef2e9da2 Ok. /tmp/newpatches/hg_gspca_20.patch with cs=2881cb04db55 Ok. /tmp/newpatches/hg_gspca_21.patch with cs=bd750ac05a62 Ok. /tmp/newpatches/hg_gspca_22.patch with cs=a6038b3c1749 Ok. /tmp/newpatches/hg_gspca_23.patch with cs=d5a08ff3b0ca Ok. /tmp/newpatches/hg_gspca_24.patch with cs=a3099efabcc0 Ok. /tmp/newpatches/hg_gspca_25.patch with cs=f8a56805e569 Ok. /tmp/newpatches/hg_gspca_26.patch with cs=59da93464e62 Ok. Diffstat of the imported series: linux/Documentation/video4linux/gspca.txt|5 linux/drivers/media/video/Kconfig|6 linux/drivers/media/video/gspca/gspca.c | 165 linux/drivers/media/video/gspca/ov519.c | 1534 ++- linux/drivers/media/video/gspca/ov534.c | 268 - linux/drivers/media/video/gspca/spca505.c| 14 linux/drivers/media/video/gspca/spca508.c| 2048 -- linux/drivers/media/video/gspca/spca561.c| 107 linux/drivers/media/video/gspca/stv06xx/Makefile |3 linux/drivers/media/video/gspca/stv06xx/stv06xx.c| 53 linux/drivers/media/video/gspca/stv06xx/stv06xx.h| 11
Re: PULL request - http://linuxtv.org/hg/~hgoede/gspca
Em Wed, 17 Jun 2009 23:54:40 +0200 Hans de Goede hdego...@redhat.com escreveu: Hi Mauro, Can you please pull from: http://linuxtv.org/hg/~hgoede/gspca I know you haven't even had the chance to do my previous pull request :) New this time: * mark the ov511 driver as deprecated, note: we should really also keep track of this in Documentation/feature-removal-schedule.txt, but that is not part of the v4l-dvb tree. I know. You need to send a separate patch for it. I'll add it directly into my -git tree. * Support for the st6422 bridge + sensor ! Give it a try, I know now you have a cam which uses this bridge :) Good! I'll give a try ;) When you try it be sure to use the latest (just updated my libv4l tree) libv4l, this enables (software) automatic control of the gain and exposure, for a decent image in most lighting conditions. BTW, the latest libv4l also does this (auto expo / gain) for the spca561 based logitech cam I borrowed to you at plumbers last year, works really nice :) That's good news Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ok more details: Re: bttv problem loading takes about several minutes
Hi, sorry for the nusable output! I found the time consuming funktion: bttv_init_card2(btv); This takes about 4 min. today. my new testcode: /* needs to be done before i2c is registered */ printk(linke 2:bttv_init_card1(btv);\n); bttv_init_card1(btv); /* register i2c + gpio */ printk(line 3: init_bttv_i2c(btv);\n); init_bttv_i2c(btv); /* some card-specific stuff (needs working i2c) */ printk(line4: some card-specific stuff needs working i2c \n); bttv_init_card2(btv); printk(irq init\n); init_irqreg(btv); dmesg output: [ 2282.430209] bttv: driver version 0.9.18 loaded [ 2282.430216] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 2282.430313] bttv: Bt8xx card found (0). [ 2282.430334] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio : 0xf780 [ 2282.430777] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm od option] [ 2282.430839] bttv_gpio_tracking(bt [ 2282.430843] bttv0: gpio: en=, out= in=003ff502 [init] [ 2282.430845] linke 2:bttv_init_card1(btv); [ 2282.430859] line 3: init_bttv_i2c(btv); [ 2282.430917] line4: some card-specific stuff needs working i2c [ 2282.430922] bttv0: tuner type=24 Ok here is the 4 min dely and after that the following linkes were printed out: [ 2416.836017] bttv0: audio absent, no audio device found! When you tested this with bttv 0.9.17, wasn't the delay then before the text 'tuner type=24'? Anyway, if you modprobe with the option 'audiodev=-1', will that solve this? If not, then can you do the same printk trick in the bttv_init_card2 function? Regards, Hans [ 2416.836024] irq init [ 2416.840551] bttv0: registered device video1 [ 2416.840684] bttv0: registered device vbi0 [ 2416.840716] bttv0: registered device radio0 [ 2416.840736] bttv0: PLL: 28636363 = 35468950 .6bttv0: PLL: 28636363 = 3546 8950 . ok [ 2416.856221] input: bttv IR (card=34) as /devices/pci:00/:00:0b.0/inpu t/input10 [ 2416.864069] ok Hope that helps! Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v2] zl10353 and qt1010: fix stack corruption bug
This patch fixes stack corruption bug present in dump_regs function of zl10353
and qt1010 drivers:
the buffer buf was one byte smaller than required - there are 4 chars for
address prefix, 16 * 3 chars for dump of 16 eeprom bytes per line and 1 byte
for zero ending the string required, i.e. 53 bytes, but only 52 were provided.
The one byte missing in stack based buffer buf can cause stack corruption
possibly leading to kernel oops, as discovered originally with af9015 driver
(af9015: fix stack corruption bug).
This is second version of the patch for zl10353 and qt1010 that uses continual
printk instead of stack based buffer with proper magic number size.
Signed-off-by: Jan Nikitenko jan.nikite...@gmail.com
---
linux/drivers/media/common/tuners/qt1010.c | 12 +---
linux/drivers/media/dvb/frontends/zl10353.c | 12 +---
2 files changed, 10 insertions(+), 14 deletions(-)
diff -r 722c6faf3ab5 linux/drivers/media/common/tuners/qt1010.c
--- a/linux/drivers/media/common/tuners/qt1010.cWed Jun 17 22:39:23
2009 -0300
+++ b/linux/drivers/media/common/tuners/qt1010.cThu Jun 18 08:49:58
2009 +0200
@@ -65,24 +65,22 @@
/* dump all registers */
static void qt1010_dump_regs(struct qt1010_priv *priv)
{
- char buf[52], buf2[4];
u8 reg, val;
for (reg = 0; ; reg++) {
if (reg % 16 == 0) {
if (reg)
- printk(%s\n, buf);
- sprintf(buf, %02x: , reg);
+ printk(KERN_CONT \n);
+ printk(KERN_DEBUG %02x:, reg);
}
if (qt1010_readreg(priv, reg, val) == 0)
- sprintf(buf2, %02x , val);
+ printk(KERN_CONT %02x, val);
else
- strcpy(buf2, -- );
- strcat(buf, buf2);
+ printk(KERN_CONT --);
if (reg == 0x2f)
break;
}
- printk(%s\n, buf);
+ printk(KERN_CONT \n);
}
static int qt1010_set_params(struct dvb_frontend *fe,
diff -r 722c6faf3ab5 linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c Wed Jun 17 22:39:23
2009 -0300
+++ b/linux/drivers/media/dvb/frontends/zl10353.c Thu Jun 18 08:49:58
2009 +0200
@@ -102,7 +102,6 @@
static void zl10353_dump_regs(struct dvb_frontend *fe)
{
struct zl10353_state *state = fe-demodulator_priv;
- char buf[52], buf2[4];
int ret;
u8 reg;
@@ -110,19 +109,18 @@
for (reg = 0; ; reg++) {
if (reg % 16 == 0) {
if (reg)
- printk(KERN_DEBUG %s\n, buf);
- sprintf(buf, %02x: , reg);
+ printk(KERN_CONT \n);
+ printk(KERN_DEBUG %02x:, reg);
}
ret = zl10353_read_register(state, reg);
if (ret = 0)
- sprintf(buf2, %02x , (u8)ret);
+ printk(KERN_CONT %02x, (u8)ret);
else
- strcpy(buf2, -- );
- strcat(buf, buf2);
+ printk(KERN_CONT --);
if (reg == 0xff)
break;
}
- printk(KERN_DEBUG %s\n, buf);
+ printk(KERN_CONT \n);
}
#endif
--
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] af9015: avoid magically sized temporal buffer in eeprom_dump
Replace printing to magically sized temporal buffer with use of KERN_CONT for
continual printing of eeprom registers dump.
Since deb_info is defined as dprintk, which is defined as printk without
additional parameters, meaning that deb_info is equivalent to direct printk
(without KERN_ facility), we can use KERN_DEBUG and KERN_CONT in there,
eliminating the need for sprintf into temporal buffer with not easily
readable/magical size.
Though it's strange, that deb_info definition uses printk without KERN_
facility and callers don't use it either.
---
I do not see better solution for the magical sized buffer, since print_hex_dump
like functions need dump of registers in memory (so the magical sized temporal
buffer would be needed for a copy anyway).
If deb_info was defined with inside KERN_ facility, then this patch would not
be valid and so the magically sized temporal buffer might be acceptable to keep
there.
This patch depends on 'af9015: fix stack corruption bug' patch.
linux/drivers/media/dvb/dvb-usb/af9015.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff -r 722c6faf3ab5 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Wed Jun 17 22:39:23 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Thu Jun 18 08:49:58 2009 +0200
@@ -541,24 +541,22 @@
/* dump eeprom */
static int af9015_eeprom_dump(struct dvb_usb_device *d)
{
- char buf[4+3*16+1], buf2[4];
u8 reg, val;
for (reg = 0; ; reg++) {
if (reg % 16 == 0) {
if (reg)
- deb_info(%s\n, buf);
- sprintf(buf, %02x: , reg);
+ deb_info(KERN_CONT \n);
+ deb_info(KERN_DEBUG %02x:, reg);
}
if (af9015_read_reg_i2c(d, AF9015_I2C_EEPROM, reg, val) == 0)
- sprintf(buf2, %02x , val);
+ deb_info(KERN_CONT, %02x, val);
else
- strcpy(buf2, -- );
- strcat(buf, buf2);
+ deb_info(KERN_CONT, --);
if (reg == 0xff)
break;
}
- deb_info(%s\n, buf);
+ deb_info(KERN_CONT \n);
return 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
[PATCH] af9015: avoid magically sized temporal buffer in eeprom_dump
Replace printing to magically sized temporal buffer with use of KERN_CONT
for continual printing of eeprom registers dump.
Since deb_info is defined as dprintk, which is defined as printk without
additional parameters, meaning that deb_info is equivalent to direct printk
(without KERN_ facility), we can use KERN_DEBUG and KERN_CONT in there,
eliminating the need for sprintf into temporal buffer with not easily
readable/magical size.
Though it's strange, that deb_info definition uses printk without KERN_
facility and callers don't use it either.
Signed-off-by: Jan Nikitenko jan.nikite...@gmail.com
---
(added missing Singned-off)
I do not see better solution for the magical sized buffer, since print_hex_dump
like functions need dump of registers in memory (so the magical sized temporal
buffer would be needed for a copy anyway).
If deb_info was defined with inside KERN_ facility, then this patch would not
be valid and so the magically sized temporal buffer might be acceptable to keep
there.
This patch depends on 'af9015: fix stack corruption bug' patch.
linux/drivers/media/dvb/dvb-usb/af9015.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff -r 722c6faf3ab5 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Wed Jun 17 22:39:23 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Thu Jun 18 08:49:58 2009 +0200
@@ -541,24 +541,22 @@
/* dump eeprom */
static int af9015_eeprom_dump(struct dvb_usb_device *d)
{
- char buf[4+3*16+1], buf2[4];
u8 reg, val;
for (reg = 0; ; reg++) {
if (reg % 16 == 0) {
if (reg)
- deb_info(%s\n, buf);
- sprintf(buf, %02x: , reg);
+ deb_info(KERN_CONT \n);
+ deb_info(KERN_DEBUG %02x:, reg);
}
if (af9015_read_reg_i2c(d, AF9015_I2C_EEPROM, reg, val) == 0)
- sprintf(buf2, %02x , val);
+ deb_info(KERN_CONT, %02x, val);
else
- strcpy(buf2, -- );
- strcat(buf, buf2);
+ deb_info(KERN_CONT, --);
if (reg == 0xff)
break;
}
- deb_info(%s\n, buf);
+ deb_info(KERN_CONT \n);
return 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
Re: OMAP patches for linux-media
Hi Sakari, Em Wed, 17 Jun 2009 20:40:32 +0300 Sakari Ailus sakari.ai...@nokia.com escreveu: So, I decided to send you this email, c/c a random list of people that I believe are involved on the submit and/or review process of those patches, in the hope to better understand and to discuss what's happening and how can we speedup the merge process of those patches. There are a few reasons for apparent stalling of the development process. I should have sent a status update earlier. The code quality of the ISP driver was originally quite low and from that part it wouldn't have made much sense to repeatedly post that for reviewing. It's been improving since many of the subdrivers have been refactored or rewritten since I last posted the patchset. The end result should be (more?) easily understood by human beings... Ok, makes sense. Another reason for no upstream patches is that we are still depending on the obsolete v4l2-int-device in the camera / sensor / lens / flash driver interface. Hans' opinion was that we must switch to v4l2_subdev instead with which I fully agree. However, due to our internal reasons we have not been able to even start that transition process yet. There is no definite deadline for the v4l2_subdev transition (or even its start) at the moment. I'm planning to update the patchset in Gitorious, however. I also see advantages on porting it to v4l2 dev/subdev. However, I don't see much sense on holding a driver for such a long time just because an internal KABI, especially since the old v4l2-int-device is still supported, and provided that you'll do the conversion anyway. That part is very important. The tvp514x driver went in while still using v4l2-int-device, but the deal was that it would be converted as soon as possible, in principle before the next kernel release. That was indeed the case (and I'll prepare a pull request for that tomorrow), so I was OK with it. So if we accept other v4l2-int-device drivers, then only if we have a solid agreement on when they will be converted to v4l2_subdev. It is very tempting to postpone that once a driver is in, but the only way we can have real reuse of i2c drivers is if they all use the same API. Just my 5 cents... Regards, Hans Whatever you decide, it is up to you do choose the proper snapshot where you consider the code ready for the merge submission. Just be nice with me by avoid sending me all drivers at the same time, on big pull requests ;) Cheers, Mauro -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: OV7670: getting it working with soc-camera.
Updated temporary patch to get ov7670 working with soc camera.
---
Basically this is the original patch with the changes Guennadi
suggested. Again this is only for info, not a formal patch submission.
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..9bea804 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,6 +19,12 @@
#include media/v4l2-chip-ident.h
#include media/v4l2-i2c-drv.h
+#define OV7670_SOC
+
+
+#ifdef OV7670_SOC
+#include media/soc_camera.h
+#endif /* OV7670_SOC */
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
MODULE_DESCRIPTION(A low-level driver for OmniVision ov7670 sensors);
@@ -1239,13 +1245,58 @@ static const struct v4l2_subdev_ops ov7670_ops = {
};
/* --- */
+#ifdef OV7670_SOC
+
+static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device *icd)
+{
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
+ SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+ SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
+
+ return soc_camera_apply_sensor_flags(icl, flags);
+}
+/* This device only supports one bus option */
+static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,
+ unsigned long flags)
+{
+ return 0;
+}
+
+static struct soc_camera_ops ov7670_soc_ops = {
+ .set_bus_param = ov7670_soc_set_bus_param,
+ .query_bus_param = ov7670_soc_query_bus_param,
+};
+#define SETFOURCC(type) .name = (#type), .fourcc = (V4L2_PIX_FMT_ ## type)
+static const struct soc_camera_data_format ov7670_soc_fmt_lists[] = {
+ {
+ SETFOURCC(YUYV),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ }, {
+ SETFOURCC(RGB565),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+
+#endif
static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct v4l2_subdev *sd;
struct ov7670_info *info;
int ret;
+#ifdef OV7670_SOC
+ struct soc_camera_device *icd = client-dev.platform_data;
+ icd-ops = ov7670_soc_ops;
+ icd-rect_max.width = VGA_WIDTH;
+ icd-rect_max.height = VGA_HEIGHT;
+ icd-formats = ov7670_soc_fmt_lists;
+ icd-num_formats = ARRAY_SIZE(ov7670_soc_fmt_lists);
+#endif
info = kzalloc(sizeof(struct ov7670_info), GFP_KERNEL);
if (info == NULL)
--
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: ok more details: Re: bttv problem loading takes about several minutes
Hi, On Do, Jun 18, 2009 at 01:09:56 +0200, Hans Verkuil wrote: Hi, sorry for the nusable output! I found the time consuming funktion: bttv_init_card2(btv); This takes about 4 min. today. my new testcode: /* needs to be done before i2c is registered */ printk(linke 2:bttv_init_card1(btv);\n); bttv_init_card1(btv); /* register i2c + gpio */ printk(line 3: init_bttv_i2c(btv);\n); init_bttv_i2c(btv); /* some card-specific stuff (needs working i2c) */ printk(line4: some card-specific stuff needs working i2c \n); bttv_init_card2(btv); printk(irq init\n); init_irqreg(btv); dmesg output: [ 2282.430209] bttv: driver version 0.9.18 loaded [ 2282.430216] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 2282.430313] bttv: Bt8xx card found (0). [ 2282.430334] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio : 0xf780 [ 2282.430777] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm od option] [ 2282.430839] bttv_gpio_tracking(bt [ 2282.430843] bttv0: gpio: en=, out= in=003ff502 [init] [ 2282.430845] linke 2:bttv_init_card1(btv); [ 2282.430859] line 3: init_bttv_i2c(btv); [ 2282.430917] line4: some card-specific stuff needs working i2c [ 2282.430922] bttv0: tuner type=24 Ok here is the 4 min dely and after that the following linkes were printed out: [ 2416.836017] bttv0: audio absent, no audio device found! When you tested this with bttv 0.9.17, wasn't the delay then before the text 'tuner type=24'? Anyway, if you modprobe with the option 'audiodev=-1', will that solve this? If not, then can you do the same printk trick in the bttv_init_card2 function? I couldn't find a parameter audiodev in bttv module Do you mean audioall?? It has no effect. So I need an older revision of v4l-dvb to test the 17. drivers. Thanks regards Halim Regards, Hans [ 2416.836024] irq init [ 2416.840551] bttv0: registered device video1 [ 2416.840684] bttv0: registered device vbi0 [ 2416.840716] bttv0: registered device radio0 [ 2416.840736] bttv0: PLL: 28636363 = 35468950 .6bttv0: PLL: 28636363 = 3546 8950 . ok [ 2416.856221] input: bttv IR (card=34) as /devices/pci:00/:00:0b.0/inpu t/input10 [ 2416.864069] ok Hope that helps! Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- Halim Sahin E-Mail: halim.sahin (at) t-online.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: Not only TV LV5H hybrid tv card
Hi Devin, do you have some updates on LV5H hybrid tv card? If needed I can help you with some testing Thanks in advance, Mimmo -- 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] New utility program atsc_epg added to dvb-apps utility suite.
Ok, I guess I violated at least coding style rule No.1, :) Will peruse the coding style page tonight and redo the submission. Regards, Yufei On Thu, Jun 18, 2009 at 3:48 AM, Manu Abrahamabraham.m...@gmail.com wrote: On Thu, Jun 18, 2009 at 12:32 PM, Manu Abrahamabraham.m...@gmail.com wrote: 2009/6/18 Yufei Yuan yfy...@gmail.com: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Please do send the patch with tabs instead of spaces for indentation. Also: * please cleanup the white spaces in the patch, if any. * please use the unified format, diff -u option. Regards, Manu -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. -- 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: ok more details: Re: bttv problem loading takes about several minutes
Hi, On Do, Jun 18, 2009 at 01:09:56 +0200, Hans Verkuil wrote: Hi, sorry for the nusable output! I found the time consuming funktion: bttv_init_card2(btv); This takes about 4 min. today. my new testcode: /* needs to be done before i2c is registered */ printk(linke 2:bttv_init_card1(btv);\n); bttv_init_card1(btv); /* register i2c + gpio */ printk(line 3: init_bttv_i2c(btv);\n); init_bttv_i2c(btv); /* some card-specific stuff (needs working i2c) */ printk(line4: some card-specific stuff needs working i2c \n); bttv_init_card2(btv); printk(irq init\n); init_irqreg(btv); dmesg output: [ 2282.430209] bttv: driver version 0.9.18 loaded [ 2282.430216] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 2282.430313] bttv: Bt8xx card found (0). [ 2282.430334] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio : 0xf780 [ 2282.430777] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm od option] [ 2282.430839] bttv_gpio_tracking(bt [ 2282.430843] bttv0: gpio: en=, out= in=003ff502 [init] [ 2282.430845] linke 2:bttv_init_card1(btv); [ 2282.430859] line 3: init_bttv_i2c(btv); [ 2282.430917] line4: some card-specific stuff needs working i2c [ 2282.430922] bttv0: tuner type=24 Ok here is the 4 min dely and after that the following linkes were printed out: [ 2416.836017] bttv0: audio absent, no audio device found! When you tested this with bttv 0.9.17, wasn't the delay then before the text 'tuner type=24'? Anyway, if you modprobe with the option 'audiodev=-1', will that solve this? If not, then can you do the same printk trick in the bttv_init_card2 function? I couldn't find a parameter audiodev in bttv module Do you mean audioall?? It has no effect. So I need an older revision of v4l-dvb to test the 17. drivers. If you installed from the v4l-dvb repository, then 'modinfo bttv' should show the audiodev module option. It does for me. I'm not sure how you can get a bttv version of 0.9.18 without seeing that module option. I'm assuming your v4l-dvb tree is up to date? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: ok more details: Re: bttv problem loading takes about several minutes
Hi, you can see at my dmesg output [ 2282.430209] bttv: driver version 0.9.18 loaded i have done hg clone http://linuxtv.org/hg/v4l-dvb cd v4l-dvb make make install reboot No idea why I don't have the audiodev modparam? Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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
[PATCHv8 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
This patch adds a new class of extended controls. This class
is intended to support FM Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and preemphasis properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/include/linux/videodev2.h | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/linux/include/linux/videodev2.h b/linux/include/linux/videodev2.h
index b8cffc9..7e584ff 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -806,6 +806,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098/* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
+#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1144,6 +1145,39 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Modulator class control IDs */
+#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
+#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
+
+#define V4L2_CID_RDS_TX_ENABLED
(V4L2_CID_FM_TX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_TX_PI (V4L2_CID_FM_TX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_TX_PTY(V4L2_CID_FM_TX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_TX_PS_NAME
(V4L2_CID_FM_TX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_TX_RADIO_TEXT (V4L2_CID_FM_TX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME(V4L2_CID_FM_TX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FM_TX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FM_TX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME (V4L2_CID_FM_TX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FM_TX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED(V4L2_CID_FM_TX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY (V4L2_CID_FM_TX_CLASS_BASE + 16)
+
+#define V4L2_CID_FM_TX_PREEMPHASIS (V4L2_CID_FM_TX_CLASS_BASE + 17)
+enum v4l2_preemphasis {
+ V4L2_PREEMPHASIS_DISABLED = 0,
+ V4L2_PREEMPHASIS_50_uS = 1,
+ V4L2_PREEMPHASIS_75_uS = 2,
+};
+#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FM_TX_CLASS_BASE + 18)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 19)
+
/*
* T U N I N G
*/
--
1.6.2.GIT
--
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
[PATCHv8 5/9] v4l2-spec: Add documentation description for FM TX extended control class
This single patch adds documentation description for FM Modulator (FM_TX) Extended Control Class and its Control IDs. The text was added under Extended Controls section. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- v4l2-spec/Makefile |1 + v4l2-spec/biblio.sgml | 10 +++ v4l2-spec/controls.sgml | 206 +++ 3 files changed, 217 insertions(+), 0 deletions(-) diff --git a/v4l2-spec/Makefile b/v4l2-spec/Makefile index 7a19924..6b46433 100644 --- a/v4l2-spec/Makefile +++ b/v4l2-spec/Makefile @@ -242,6 +242,7 @@ ENUMS = \ v4l2_power_line_frequency \ v4l2_priority \ v4l2_tuner_type \ + v4l2_preemphasis \ STRUCTS = \ v4l2_audio \ diff --git a/v4l2-spec/biblio.sgml b/v4l2-spec/biblio.sgml index b013ece..0921849 100644 --- a/v4l2-spec/biblio.sgml +++ b/v4l2-spec/biblio.sgml @@ -11,6 +11,16 @@ url=http://www.eia.org;http://www.eia.org/ulink)/corpauthor Service/title /biblioentry +biblioentry id=en50067 + abbrevENnbsp;50067/abbrev + authorgroup + corpauthorCENELEC European Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor + /authorgroup + titleEN 50067 Specification of the radio data system (RDS) for +VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz/title +/biblioentry + biblioentry id=en300294 abbrevENnbsp;300nbsp;294/abbrev authorgroup diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..060e7c9 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -458,6 +458,12 @@ video is actually encoded into that format./para paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,206 @@ control must support read access and may support write access./entry /tgroup /table /section + +section id=fm-tx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FM_TX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fm-tx-control-id + titleFM_TX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FM_TX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FM_TX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_PI/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Type field for transmission. +This encodes up to 31 pre-defined programme types./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_TX_PS_NAME/constantnbsp;/entry + entrystring/entry + /row + rowentry spanname=descrSets the Programme Service name (PS_NAME) for transmission. +It is intended for static display on a receiver. It is the primary aid to listeners in programme service +identification and selection. The use of PS to transmit text other than a single eight character name is
[PATCHv8 0/9] FM Transmitter (si4713) and another changes
Hello all, First of all, I'd like to thank you for the good review. The driver is getting better and better. With this new API change, si4713 is looking like a fm transmitter driver. So, I'm resending the FM transmitter driver and the proposed changes in v4l2 api files in order to cover the fmtx extended controls class. Difference from version #7 is that now I've added added lots of comments made by Hans. Here is a list of changes: - A few renames of constant definitions - Updates in proposed documentation - Split of platform data info into 2 header, one for platform driver and other to i2c driver - Use of v4l2_* family of logging/debugging instead of dev_* - Improvement of debug messages - Fix in the use of string controls - Fix in the use of txsubchans - Creation of private ioctl to read rssi - Minor fixes all around the code - Remotion of get/set style of function, previously used for the sysfs interface As before, this series is based on two of Hans' trees: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2. http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-str. The first tree has refactoring of v4l2 i2c helper functions. The second one has string support for extended controls, which is used in this driver. So, now the series includes changes to add the new v4l2 FMTX extended controls (and its documetation) and si4713 i2c and platform drivers (and its documentation as well). Besides that, there is also a patch to add g_modulator to v4l2-subdev and a patch to add support for fm tx class in v4l2-ctl util. BR, Eduardo Valentin (9): v4l2-subdev.h: Add g_modulator callbacks to subdev api v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls v4l2: video device: Add FM_TX controls default configurations v4l2-ctl: Add support for FM TX controls v4l2-spec: Add documentation description for FM TX extended control class FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add files to handle si4713 i2c device FMTx: si4713: Add Kconfig and Makefile entries FMTx: si4713: Add document file linux/Documentation/video4linux/si4713.txt | 169 +++ linux/drivers/media/radio/Kconfig | 22 + linux/drivers/media/radio/Makefile |2 + linux/drivers/media/radio/radio-si4713.c | 367 + linux/drivers/media/radio/si4713-i2c.c | 2015 linux/drivers/media/radio/si4713-i2c.h | 226 linux/drivers/media/video/v4l2-common.c| 50 + linux/include/linux/videodev2.h| 34 + linux/include/media/radio-si4713.h | 30 + linux/include/media/si4713.h | 40 + linux/include/media/v4l2-subdev.h |2 + v4l2-apps/util/v4l2-ctl.cpp| 36 + v4l2-spec/Makefile |1 + v4l2-spec/biblio.sgml | 10 + v4l2-spec/controls.sgml| 206 +++ 15 files changed, 3210 insertions(+), 0 deletions(-) create mode 100644 linux/Documentation/video4linux/si4713.txt create mode 100644 linux/drivers/media/radio/radio-si4713.c create mode 100644 linux/drivers/media/radio/si4713-i2c.c create mode 100644 linux/drivers/media/radio/si4713-i2c.h create mode 100644 linux/include/media/radio-si4713.h create mode 100644 linux/include/media/si4713.h -- 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
[PATCHv8 6/9] FMTx: si4713: Add files to add radio interface for si4713
This patch adds files which creates the radio interface
for si4713 FM transmitter (modulator) devices.
In order to do the real access to device registers, this
driver uses the v4l2 subdev interface exported by si4713 i2c driver.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/drivers/media/radio/radio-si4713.c | 367 ++
linux/include/media/radio-si4713.h | 30 +++
2 files changed, 397 insertions(+), 0 deletions(-)
create mode 100644 linux/drivers/media/radio/radio-si4713.c
create mode 100644 linux/include/media/radio-si4713.h
diff --git a/linux/drivers/media/radio/radio-si4713.c
b/linux/drivers/media/radio/radio-si4713.c
new file mode 100644
index 000..7b3b665
--- /dev/null
+++ b/linux/drivers/media/radio/radio-si4713.c
@@ -0,0 +1,367 @@
+/*
+ * drivers/media/radio/radio-si4713.c
+ *
+ * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
+ *
+ * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
+ * Contact: Eduardo Valentin eduardo.valen...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/radio-si4713.h
+
+/* module parameters */
+static int radio_nr = -1; /* radio device minor (-1 == auto assign) */
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr,
+Minor number for radio device (-1 == auto assign));
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Eduardo Valentin eduardo.valen...@nokia.com);
+MODULE_DESCRIPTION(Platform driver for Si4713 FM Radio Transmitter);
+MODULE_VERSION(0.0.1);
+
+/* Driver state struct */
+struct radio_si4713_device {
+ struct v4l2_device v4l2_dev;
+ struct video_device *radio_dev;
+};
+
+/* radio_si4713_fops - file operations interface */
+static const struct v4l2_file_operations radio_si4713_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = video_ioctl2,
+};
+
+/* Video4Linux Interface */
+static int radio_si4713_fill_audout(struct v4l2_audioout *vao)
+{
+ /* TODO: check presence of audio output */
+ strlcpy(vao-name, FM Modulator Audio Out, 32);
+
+ return 0;
+}
+
+static int radio_si4713_enumaudout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ return radio_si4713_fill_audout(vao);
+}
+
+static int radio_si4713_g_audout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ int rval = radio_si4713_fill_audout(vao);
+
+ vao-index = 0;
+
+ return rval;
+}
+
+static int radio_si4713_s_audout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ return vao-index ? -EINVAL : 0;
+}
+
+/* radio_si4713_querycap - query device capabilities */
+static int radio_si4713_querycap(struct file *file, void *priv,
+ struct v4l2_capability *capability)
+{
+ struct radio_si4713_device *rsdev;
+
+ rsdev = video_get_drvdata(video_devdata(file));
+
+ strlcpy(capability-driver, radio-si4713, sizeof(capability-driver));
+ strlcpy(capability-card, Silicon Labs Si4713 Modulator,
+ sizeof(capability-card));
+ capability-capabilities = V4L2_CAP_MODULATOR;
+
+ return 0;
+}
+
+/* radio_si4713_queryctrl - enumerate control items */
+static int radio_si4713_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+ /* Must be sorted from low to high control ID! */
+ static const u32 user_ctrls[] = {
+ V4L2_CID_USER_CLASS,
+ V4L2_CID_AUDIO_MUTE,
+ 0
+ };
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 fmtx_ctrls[] = {
+ V4L2_CID_FM_TX_CLASS,
+ V4L2_CID_RDS_TX_ENABLED,
+ V4L2_CID_RDS_TX_PI,
+ V4L2_CID_RDS_TX_PTY,
+ V4L2_CID_RDS_TX_PS_NAME,
+
[PATCHv8 8/9] FMTx: si4713: Add Kconfig and Makefile entries
Simple add Makefile and Kconfig entries. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- linux/drivers/media/radio/Kconfig | 22 ++ linux/drivers/media/radio/Makefile |2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/linux/drivers/media/radio/Kconfig b/linux/drivers/media/radio/Kconfig index 3315cac..6c6a409 100644 --- a/linux/drivers/media/radio/Kconfig +++ b/linux/drivers/media/radio/Kconfig @@ -339,6 +339,28 @@ config RADIO_ZOLTRIX_PORT help Enter the I/O port of your Zoltrix radio card. +config I2C_SI4713 + tristate I2C driver for Silicon Labs Si4713 device + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 I2C device. + This device driver supports only i2c bus. + + To compile this driver as a module, choose M here: the + module will be called si4713. + +config RADIO_SI4713 + tristate Silicon Labs Si4713 FM Radio Transmitter support + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 FM Radio Transmitter. + This device can transmit audio through FM. It can transmit + EDS and EBDS signals as well. This module is the v4l2 radio + interface for the i2c driver of this device. + + To compile this driver as a module, choose M here: the + module will be called radio-si4713. + config USB_DSBR tristate D-Link/GemTek USB FM radio support depends on USB VIDEO_V4L2 diff --git a/linux/drivers/media/radio/Makefile b/linux/drivers/media/radio/Makefile index 0f2b35b..34ae761 100644 --- a/linux/drivers/media/radio/Makefile +++ b/linux/drivers/media/radio/Makefile @@ -15,6 +15,8 @@ obj-$(CONFIG_RADIO_ZOLTRIX) += radio-zoltrix.o obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o obj-$(CONFIG_RADIO_GEMTEK_PCI) += radio-gemtek-pci.o obj-$(CONFIG_RADIO_TRUST) += radio-trust.o +obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o +obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_USB_SI470X) += radio-si470x.o -- 1.6.2.GIT -- 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
[PATCHv8 3/9] v4l2: video device: Add FM_TX controls default configurations
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/drivers/media/video/v4l2-common.c | 50 +++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index 5cfd727..fc4d7a8 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -345,6 +345,12 @@ const char **v4l2_ctrl_get_menu(u32 id)
Sepia,
NULL
};
+ static const char *fm_tx_preemphasis[] = {
+ No preemphasis,
+ 50 useconds,
+ 75 useconds,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -383,6 +389,8 @@ const char **v4l2_ctrl_get_menu(u32 id)
return camera_exposure_auto;
case V4L2_CID_COLORFX:
return colorfx;
+ case V4L2_CID_FM_TX_PREEMPHASIS:
+ return fm_tx_preemphasis;
default:
return NULL;
}
@@ -481,6 +489,28 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_ZOOM_CONTINUOUS: return Zoom, Continuous;
case V4L2_CID_PRIVACY: return Privacy;
+ /* FM Radio Modulator control */
+ case V4L2_CID_FM_TX_CLASS: return FM Radio Modulator
Controls;
+ case V4L2_CID_RDS_TX_ENABLED: return RDS Feature Enabled;
+ case V4L2_CID_RDS_TX_PI:return RDS Program ID;
+ case V4L2_CID_RDS_TX_PTY: return RDS Program Type;
+ case V4L2_CID_RDS_TX_PS_NAME: return RDS PS Name;
+ case V4L2_CID_RDS_TX_RADIO_TEXT:return RDS Radio Text;
+ case V4L2_CID_AUDIO_LIMITER_ENABLED:return Audio Limiter Feature
Enabled;
+ case V4L2_CID_AUDIO_LIMITER_RELEASE_TIME: return Audio Limiter Release
Time;
+ case V4L2_CID_AUDIO_LIMITER_DEVIATION: return Audio Limiter
Deviation;
+ case V4L2_CID_AUDIO_COMPRESSION_ENABLED: return Audio Compression
Feature Enabled;
+ case V4L2_CID_AUDIO_COMPRESSION_GAIN: return Audio Compression Gain;
+ case V4L2_CID_AUDIO_COMPRESSION_THRESHOLD: return Audio Compression
Threshold;
+ case V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME: return Audio Compression
Attack Time;
+ case V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME: return Audio Compression
Release Time;
+ case V4L2_CID_PILOT_TONE_ENABLED: return Pilot Tone Feature
Enabled;
+ case V4L2_CID_PILOT_TONE_DEVIATION: return Pilot Tone Deviation;
+ case V4L2_CID_PILOT_TONE_FREQUENCY: return Pilot Tone Frequency;
+ case V4L2_CID_FM_TX_PREEMPHASIS:return Pre-emphasis settings;
+ case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
+ case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return Tune Antenna Capacitor;
+
default:
return NULL;
}
@@ -513,6 +543,10 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
+ case V4L2_CID_RDS_TX_ENABLED:
+ case V4L2_CID_AUDIO_LIMITER_ENABLED:
+ case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
+ case V4L2_CID_PILOT_TONE_ENABLED:
qctrl-type = V4L2_CTRL_TYPE_BOOLEAN;
min = 0;
max = step = 1;
@@ -541,12 +575,18 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
+ case V4L2_CID_FM_TX_PREEMPHASIS:
qctrl-type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
+ case V4L2_CID_RDS_TX_PS_NAME:
+ case V4L2_CID_RDS_TX_RADIO_TEXT:
+ qctrl-type = V4L2_CTRL_TYPE_STRING;
+ break;
case V4L2_CID_USER_CLASS:
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
+ case V4L2_CID_FM_TX_CLASS:
qctrl-type = V4L2_CTRL_TYPE_CTRL_CLASS;
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
@@ -575,6 +615,16 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
+ case V4L2_CID_AUDIO_LIMITER_RELEASE_TIME:
+ case V4L2_CID_AUDIO_LIMITER_DEVIATION:
+ case V4L2_CID_AUDIO_COMPRESSION_GAIN:
+ case V4L2_CID_AUDIO_COMPRESSION_THRESHOLD:
+ case V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME:
+ case V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME:
+ case V4L2_CID_PILOT_TONE_DEVIATION:
+ case V4L2_CID_PILOT_TONE_FREQUENCY:
+ case V4L2_CID_TUNE_POWER_LEVEL:
+
[PATCHv8 4/9] v4l2-ctl: Add support for FM TX controls
This patch adds simple support for FM TX extended controls
on v4l2-ctl utility.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v4l2-apps/util/v4l2-ctl.cpp | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/v4l2-apps/util/v4l2-ctl.cpp b/v4l2-apps/util/v4l2-ctl.cpp
index 2c7290f..45a2310 100644
--- a/v4l2-apps/util/v4l2-ctl.cpp
+++ b/v4l2-apps/util/v4l2-ctl.cpp
@@ -148,6 +148,7 @@ typedef std::vectorstruct v4l2_ext_control ctrl_list;
static ctrl_list user_ctrls;
static ctrl_list mpeg_ctrls;
static ctrl_list camera_ctrls;
+static ctrl_list fm_tx_ctrls;
typedef std::mapstd::string, unsigned ctrl_strmap;
static ctrl_strmap ctrl_str2id;
@@ -2166,6 +2167,8 @@ set_vid_fmt_error:
mpeg_ctrls.push_back(ctrl);
else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_CAMERA)
camera_ctrls.push_back(ctrl);
+ else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_FM_TX)
+ fm_tx_ctrls.push_back(ctrl);
else
user_ctrls.push_back(ctrl);
}
@@ -2212,6 +2215,22 @@ set_vid_fmt_error:
}
}
}
+ if (fm_tx_ctrls.size()) {
+ ctrls.ctrl_class = V4L2_CTRL_CLASS_FM_TX;
+ ctrls.count = fm_tx_ctrls.size();
+ ctrls.controls = fm_tx_ctrls[0];
+ if (doioctl(fd, VIDIOC_S_EXT_CTRLS, ctrls,
VIDIOC_S_EXT_CTRLS)) {
+ if (ctrls.error_idx = ctrls.count) {
+ fprintf(stderr, Error setting FM
Modulator controls: %s\n,
+ strerror(errno));
+ }
+ else {
+ fprintf(stderr, %s: %s\n,
+
ctrl_id2str[fm_tx_ctrls[ctrls.error_idx].id].c_str(),
+ strerror(errno));
+ }
+ }
+ }
}
/* Get options */
@@ -2429,6 +2448,7 @@ set_vid_fmt_error:
mpeg_ctrls.clear();
camera_ctrls.clear();
user_ctrls.clear();
+ fm_tx_ctrls.clear();
for (ctrl_get_list::iterator iter = get_ctrls.begin();
iter != get_ctrls.end(); ++iter) {
struct v4l2_ext_control ctrl = { 0 };
@@ -2443,6 +2463,8 @@ set_vid_fmt_error:
mpeg_ctrls.push_back(ctrl);
else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_CAMERA)
camera_ctrls.push_back(ctrl);
+ else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_FM_TX)
+ fm_tx_ctrls.push_back(ctrl);
else
user_ctrls.push_back(ctrl);
}
@@ -2481,6 +2503,20 @@ set_vid_fmt_error:
printf(%s: %d\n,
ctrl_id2str[ctrl.id].c_str(), ctrl.value);
}
}
+ if (fm_tx_ctrls.size()) {
+ ctrls.ctrl_class = V4L2_CTRL_CLASS_FM_TX;
+ ctrls.count = fm_tx_ctrls.size();
+ ctrls.controls = fm_tx_ctrls[0];
+ doioctl(fd, VIDIOC_G_EXT_CTRLS, ctrls,
VIDIOC_G_EXT_CTRLS);
+ for (unsigned i = 0; i fm_tx_ctrls.size(); i++) {
+ struct v4l2_ext_control ctrl = fm_tx_ctrls[i];
+
+ if (ctrl_id2type[ctrl.id] ==
V4L2_CTRL_TYPE_STRING)
+ printf(%s: '%s'\n,
ctrl_id2str[ctrl.id].c_str(), ctrl.string);
+ else
+ printf(%s: %d\n,
ctrl_id2str[ctrl.id].c_str(), ctrl.value);
+ }
+ }
}
if (options[OptGetTuner]) {
--
1.6.2.GIT
--
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
[PATCHv8 9/9] FMTx: si4713: Add document file
This patch adds a document file for si4713 device driver. It describes the driver interfaces and organization. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- linux/Documentation/video4linux/si4713.txt | 169 1 files changed, 169 insertions(+), 0 deletions(-) create mode 100644 linux/Documentation/video4linux/si4713.txt diff --git a/linux/Documentation/video4linux/si4713.txt b/linux/Documentation/video4linux/si4713.txt new file mode 100644 index 000..8944abe --- /dev/null +++ b/linux/Documentation/video4linux/si4713.txt @@ -0,0 +1,169 @@ +Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters + +Copyright (c) 2009 Nokia Corporation +Contact: Eduardo Valentin eduardo.valen...@nokia.com + + +Information about the Device + +This chip is a Silicon Labs product. It is a I2C device, currently on 0Ã63 address. +Basically, it has transmission and signal noise level measurement features. + +The Si4713 integrates transmit functions for FM broadcast stereo transmission. +The chip also allows integrated receive power scanning to identify low signal +power FM channels. + +The chip is programmed using commands and responses. There are also several +properties which can change the behavior of this chip. + +Users must comply with local regulations on radio frequency (RF) transmission. + +Device driver description += +There are two modules to handle this device. One is a I2C device driver +and the other is a platform driver. + +The I2C device driver exports a v4l2-subdev interface to the kernel. +All properties can also be accessed by v4l2 extended controls interface, by +using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls). + +The platform device driver exports a v4l2 radio device interface to user land. +So, it uses the I2C device driver as a sub device in order to send the user +commands to the actual device. Basically it is a wrapper to the I2C device driver. + +Applications can use v4l2 radio API to specify frequency of operation, mute state, +etc. But mostly of its properties will be present in the extended controls. + +When the v4l2 mute property is set to 1 (true), the driver will turn the chip off. + +Properties description +== + +The properties can be accessed using v4l2 extended controls. +Here is an output from v4l2-ctl util: + +# v4l2-ctl -d /dev/radio0 -l --all +Driver Info: +Driver name : radio-si4713 +Card type : Silicon Labs Si4713 Modulator +Bus info : +Driver version: 0 +Capabilities : 0x0008 +Modulator +Audio output: 0 (FM Modulator Audio Out) +Frequency: 1408000 (88000.00 MHz) +Video Standard = 0x +Modulator: +Name : FM Modulator +Capabilities : 62.5 Hz stereo +Frequency range : 76.0 MHz - 108.0 MHz +Available subchannels: mono stereo + +User Controls + + mute (bool) : default=1 value=0 + +FM Radio Modulator Controls + +rds_feature_enabled (bool) : default=1 value=1 + rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0 + rds_program_type (int) : min=0 max=31 step=1 default=0 value=0 +rds_ps_name (str) : value='Si4713 ' len=8 +' len=9 rds_radio_text (str) : value='Si4713 + audio_limiter_feature_enabled (bool) : default=1 value=1 + audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider +audio_limiter_deviation (int) : min=0 max=9 step=10 default=66250 value=66250 flags=slider +audio_compression_feature_enabl (bool) : default=1 value=1 + audio_compression_gain (int) : min=0 max=20 step=1 default=15 value=15 flags=slider +audio_compression_threshold (int) : min=-40 max=0 step=1 default=-40 value=-40 flags=slider + audio_compression_attack_time (int) : min=0 max=5000 step=500 default=0 value=2000 flags=slider + audio_compression_release_time (int) : min=10 max=100 step=10 default=100 value=100 flags=slider + pilot_tone_feature_enabled (bool) : default=1 value=1 + pilot_tone_deviation (int) : min=0 max=9 step=10 default=6750 value=6750 flags=slider + pilot_tone_frequency (int) : min=0 max=19000 step=1 default=19000 value=19000 flags=slider + pre_emphasis_settings (menu) : min=0 max=2 default=1 value=2 + tune_power_level (int) : min=0 max=120 step=1 default=88 value=88 flags=slider + tune_antenna_capacitor (int) : min=0 max=191 step=1 default=0 value=110 flags=slider + +Here is a summary of them: + +* Pilot is an audible tone sent by the device. + +pilot_frequency - Configures the frequency of the stereo pilot tone. +pilot_deviation - Configures pilot tone frequency deviation level. +pilot_enabled - Enables or disables the pilot
Re: S_FMT vs. S_CROP
Ok, a couple of things have become clearer to me, some others managed to
confuse me again:
On Wed, 10 Jun 2009, Hans Verkuil wrote:
On Wednesday 10 June 2009 18:02:39 Guennadi Liakhovetski wrote:
[snip]
which I now interpret as
S_FMT(640x480) means scale whatever rectangle has been selected on the
sensor to produce an output window of 640x480 and S_CROP(2048x1536)
means take a window of 2048x1536 sensor pixels from the sensor and scale
it to whatever output window has been or will be selected by S_FMT. This
contradicts M1, because you certainly can crop a larger (sensor) window.
Also, I now believe, that [GS]_CROP and, logically, CROPCAP operate in
sensor pixels and shall not depend on any scales, which contradicts (my
understanding of) M2.
It now seems to be quite simple to me:
{G,S,TRY}_FMT configure output geometry in user pixels
[GS]_CROP, CROPCAP configure input window in sensor pixels
Agreed.
The thus configured input window should be mapped (scaled) into the
output window.
Now, which one is correct?
Your interpretation is correct to the best of my knowledge. I think the
cropping API remains one of the worst explained ioctls in the spec. There
are some weird things you can get into when dealing with S-Video (PAL/NTSC)
like signals, but for sensors like this it is as you described.
It seems, my above interpretation contradicts with the following statement
from the description of S_CROP in the spec:
quote
Second the driver adjusts the image size (the opposite rectangle of the
scaling process, source or target depending on the data direction) to the
closest size possible while maintaining the current horizontal and
vertical scaling factor.
/quote
I read this as you crop according to the user request and yor new scaled
image is a result of your new crop area and _old_ scaling factors.
Now, if you set up the crop, and preserve the scaling factors, what the
heck does adjusts the image size ... to the closest size possible...
What else adjustment freedom does one have here? Shall I be bending the
sensor in the third dimension or what?...
And btw, the calculations and reasoning in the example in 1.11.2 I cannot
follow at all. For example this The present scaling factors limit
cropping to 640 × 384 I cannot derive however hard I try. And this the
driver returns the cropping size 608 × 384 and adjusts the image size to
closest possible 304 × 192 means the scaling factors are now both 2:1 as
a result of S_CROP, and before S_CROP the horisontal scale used to be 1:1,
so, it changed, which again contradicts (IMHO) S_CROP definition above.
HELP!
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
OMAP3 ISP and camera drivers (update 2)
Hi, I've again updated the patchset in Gitorious after a long break. It's here. The base is fairly recent linux-omap (May) but I wouldn't expect problems in rebasing on top of newer updates either. URL:http://www.gitorious.org/projects/omap3camera The amount of changes is more or less huge but I'll try to summarise them. The base branch is no longer needed, the patch has been integrated to linux-omap. The v4l2_subdev transition hasn't begun yet, however. - Many ISP subdrivers have been rewritten or refactored. The new code should be easier to understand. - VIDIOC_TRY_FMT has no longer have side effects except perhaps to the resizer. This is being worked on. - Crop has been mostly rewritten. - Locking has been corrected, although probably not definitely fixed. - A separate ispstat module for handling the H3A, AF and HIST statistics. H3A and AF are using it already. - Lots of redundant code has been removed. - Most busy-locked register are should be no longer updated when corresponding modules are busy. There are still some cases this is happening, though. - Configuration of the modules in the interrupt handler is done so that the module is disabled first or used in oneshot mode. - Lots of things I can't remember now. The individual changes can be seen in the omap3isp and omap34xxcam branches. The branches just contain the patches in order so git diff doesn't help, unfortunately. I won't be available for questions for a month or so (holidays). In the meantime you can contact Tuukka Toivonen, David Cohen and Sergio Aguirre for questions. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
PULL request - http://linuxtv.org/hg/~hgoede/gspca
Hi Mauro, As requested: On 06/18/2009 12:44 PM, Mauro Carvalho Chehab wrote: Also, checkpatch is warning about a few troubles at the patches. Could you please create another tree, directly based on mine, fix the coding styles and send another pull request? I've rebased my tree on your latest and fixed the coding style issues, so please pull from: http://linuxtv.org/hg/~hgoede/gspca For: -ov511(+) support -st6422 support -ov519/ov518 fixes -sonixj 0c45:613e support -sonixj fixes -mark v4l1 ov511 driver deprecated -mark v4l1 quickcam_messenger driver deprecated Thanks, Hans -- 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: WARNINGS, 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:Thu Jun 18 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12070:722c6faf3ab5 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK 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-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS 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-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.30-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-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS sparse (linux-2.6.30): 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: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK 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: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Please send an email with this 330e device (Pinnacle hybrid pro stick)
If this information is not sufficient, feel free to contact me. amd64 Debian Lenny with 2.6.30-1 from unstable. v4l-dvb is installed from mercurial just minutes ago ( hg clone http://www.linuxtv.org/hg/v4l-dvb ) Best regards lsusb Bus 001 Device 009: ID eb1a:2881 eMPIA Technology, Inc. dmesg [ 4024.854572] Linux video capture interface: v2.00 [ 4024.916749] usbcore: registered new interface driver em28xx [ 4024.916759] em28xx driver loaded [ 4024.977498] Em28xx: Initialized (Em28xx dvb Extension) extension [ 4035.197266] usb 1-4.1: new high speed USB device using ehci_hcd and address 9 [ 4035.291608] usb 1-4.1: New USB device found, idVendor=eb1a, idProduct=2881 [ 4035.291619] usb 1-4.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 4035.291626] usb 1-4.1: Product: USB 2881 Video [ 4035.291808] usb 1-4.1: configuration #1 chosen from 1 choice [ 4035.292101] em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) [ 4035.292112] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 4035.292219] em28xx #0: chip ID is em2882/em2883 [ 4035.374974] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 [ 4035.375004] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [ 4035.375029] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 [ 4035.375054] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 [ 4035.375078] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375102] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375126] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [ 4035.375150] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [ 4035.375173] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [ 4035.375197] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375221] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375245] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375268] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375292] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375316] em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 [ 4035.375339] em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 [ 4035.375366] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 [ 4035.375371] em28xx #0: EEPROM info: [ 4035.375375] em28xx #0: AC97 audio (5 sample rates) [ 4035.375379] em28xx #0: USB Remote wakeup capable [ 4035.375383] em28xx #0: 500mA max power [ 4035.375389] em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x [ 4035.407347] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 4035.411848] em28xx #0: found i2c device @ 0xb8 [tvp5150a] [ 4035.413718] em28xx #0: found i2c device @ 0xc2 [tuner (analog)] [ 4035.424951] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 4035.424961] em28xx #0: You may try to use card=n insmod option to workaround that. [ 4035.424967] em28xx #0: Please send an email with this log to: [ 4035.424971] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 4035.424977] em28xx #0: Board eeprom hash is 0xb8846b20 [ 4035.424982] em28xx #0: Board i2c devicelist hash is 0x27e10080 [ 4035.424987] em28xx #0: Here is a list of valid choices for the card=n insmod option: [ 4035.424993] em28xx #0: card=0 - Unknown EM2800 video grabber [ 4035.424999] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [ 4035.425025] em28xx #0: card=2 - Terratec Cinergy 250 USB [ 4035.425030] em28xx #0: card=3 - Pinnacle PCTV USB 2 [ 4035.425035] em28xx #0: card=4 - Hauppauge WinTV USB 2 [ 4035.425041] em28xx #0: card=5 - MSI VOX USB 2.0 [ 4035.425046] em28xx #0: card=6 - Terratec Cinergy 200 USB [ 4035.425051] em28xx #0: card=7 - Leadtek Winfast USB II [ 4035.425056] em28xx #0: card=8 - Kworld USB2800 [ 4035.425062] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker [ 4035.425068] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [ 4035.425074] em28xx #0: card=11 - Terratec Hybrid XS [ 4035.425079] em28xx #0: card=12 - Kworld PVR TV 2800 RF [ 4035.425084] em28xx #0: card=13 - Terratec Prodigy XS [ 4035.425090] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 4035.425096] em28xx #0: card=15 - V-Gear PocketTV [ 4035.425101] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [ 4035.425107] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [ 4035.425112] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [ 4035.425118] em28xx #0: card=19 - PointNix Intra-Oral Camera [
Re: ok more details: Re: bttv problem loading takes about several minutes
Hi, Am Donnerstag, den 18.06.2009, 16:01 +0200 schrieb Halim Sahin: Hi, you can see at my dmesg output [ 2282.430209] bttv: driver version 0.9.18 loaded i have done hg clone http://linuxtv.org/hg/v4l-dvb cd v4l-dvb make make install reboot No idea why I don't have the audiodev modparam? Regards Halim Halim, we should get that in sync. parm: autoload:obsolete option, please do not use anymore (int) parm: audiodev:specify audio device: -1 = no audio 0 = autodetect (default) 1 = msp3400 2 = tda7432 3 = tvaudio (array of int) parm: saa6588:if 1, then load the saa6588 RDS module, default (0) is to use the card definition. parm: no_overlay:allow override overlay default (0 disables, 1 enables) [some VIA/SIS chipsets are known to have problem with overlay] (int) Hopefully we don't need to fall back on Konfuzius for it ;) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] af9015: avoid magically sized temporal buffer in eeprom_dump
On Thu, 18 Jun 2009, Jan Nikitenko wrote: Replace printing to magically sized temporal buffer with use of KERN_CONT temporary not temporal. - sprintf(buf2, %02x , val); + deb_info(KERN_CONT, %02x, val); No comma after KERN_CONT else - strcpy(buf2, -- ); - strcat(buf, buf2); + deb_info(KERN_CONT, --); No comma after KERN_CONT Just use printk() instead of deb_info() for the ones that use KERN_CONT. if (reg == 0xff) break; } - deb_info(%s\n, buf); + deb_info(KERN_CONT \n); return 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
Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.
Okay, this one serves as a test as well. It's a trivial one to fix the broken dvb-apps building process with gcc4.4 on kernel 2.6.30, another way to eliminate the packed bitfield warning is to split the field, but that is unwanted. previous build error: make[2]: Entering directory `/home/alex/source/dvb-apps/util/scan' perl section_generate.pl atsc_psip_section.pl CC scan.o In file included from scan.c:48: atsc_psip_section.h:57: note: Offset of packed bit-field ‘reserved2’ has changed in GCC 4.4 CC atsc_psip_section.o In file included from atsc_psip_section.c:2: atsc_psip_section.h:57: note: Offset of packed bit-field ‘reserved2’ has changed in GCC 4.4 CC diseqc.o In file included from diseqc.c:4: /usr/include/time.h:104: error: conflicting types for ‘timer_t’ /usr/include/linux/types.h:22: note: previous declaration of ‘timer_t’ was here make[2]: *** [diseqc.o] Error 1 make[2]: Leaving directory `/home/alex/source/dvb-apps/util/scan' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/alex/source/dvb-apps/util' make: *** [all] Error 2 --- dvb-apps/util/scan/Makefile.orig2009-06-18 19:43:52.397924757 -0500 +++ dvb-apps/util/scan/Makefile 2009-06-18 19:44:34.764925070 -0500 @@ -14,7 +14,7 @@ inst_bin = $(binaries) removing = atsc_psip_section.c atsc_psip_section.h -CPPFLAGS += -DDATADIR=\$(prefix)/share\ +CPPFLAGS += -Wno-packed-bitfield-compat -D__KERNEL_STRICT_NAMES -DDATADIR=\$(prefix)/share\ .PHONY: all -- Even uttering HI or HAO is offensive, sometime, somewhere. Reader discretion is advised. -- 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] New utility program atsc_epg added to dvb-apps utility suite.
This one is about the utility itself. I do apologize for the length
here as inline patch is preferred according to the guide and I don't
have any public online storage. Please let me know if this causes any
inconvenience.
Signed-off-by: Yufei Yuan yfy...@gmail.com
diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0
-0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-18
20:17:24.527925142 -0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT60
+#define RRT_TIMEOUT60
+#define MAX_NUM_EVENT_TABLES 128
+#define TITLE_BUFFER_LEN 4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS 16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum
atsc_section_tag tag,
+ void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+ int buf_len;
+ int buf_pos;
+ char *string;
+};
+
+struct atsc_event_info {
+ uint16_t id;
+ struct tm start;
+ struct tm end;
+ int title_pos;
+ int title_len;
+ int msg_pos;
+ int msg_len;
+};
+
+struct atsc_eit_section_info {
+ uint8_t section_num;
+ uint8_t num_events;
+ uint8_t num_etms;
+ uint8_t num_received_etms;
+ struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+ int num_eit_sections;
+ struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+ uint8_t num_eits;
+ uint8_t service_type;
+ char short_name[8];
+ uint16_t major_num;
+ uint16_t minor_num;
+ uint16_t tsid;
+ uint16_t prog_num;
+ uint16_t src_id;
+ struct atsc_eit_info *eit;
+ struct atsc_event_info *last_event;
+ int event_info_index;
+ struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+ struct atsc_string_buffer title_buf;
+ struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+ int num_channels;
+ uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+ uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+ struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+} guide;
+
+struct mgt_table_name {
+ uint16_t range;
+ const char *string;
+};
+
+struct mgt_table_name mgt_tab_name_array[] = {
+ {0x, terrestrial VCT with current_next_indictor=1},
+ {0x0001, terrestrial VCT with current_next_indictor=0},
+ {0x0002, cable VCT with current_next_indictor=1},
+ {0x0003, cable VCT with current_next_indictor=0},
+ {0x0004, channel ETT},
+ {0x0005, DCCSCT},
+ {0x00FF, reserved for future ATSC use},
+ {0x017F, EIT},
+ {0x01FF, reserved for future ATSC use},
+ {0x027F, event ETT},
+ {0x02FF, reserved for future ATSC use}, /* FIXME */
+ {0x03FF, RRT with rating region},
+ {0x0FFF, user private},
+ {0x13FF, reserved for future ATSC use},
+ {0x14FF, DCCT with dcc_id},
+ {0x, reserved for future ATSC use}
+};
+
+const char *channel_modulation_mode[] = {
+ ,
+ analog,
+ SCTE mode 1,
+ SCTE mode 2,
+ ATSC 8VSB,
+ ATSC 16VSB
+};
+
+const char *channel_service_type[] = {
+ ,
+ analog TV,
+ ATSC digital TV,
+ ATSC audio,
+ ATSC data-only
+};
+
+void *(*table_callback[16])(struct atsc_section_psip *)
Re: Sakar 57379 USB Digital Video Camera...
On Thu, 18 Jun 2009, Andy Walls wrote: My daughter just got one of these toy digital video recorder webcam unit. It normally shows up as a mass storage drive. If I hold down the shutter button while connecting the USB cable, the camera LCD show a webcam mode icon and it shows up as a different USB device. Any chance of this working as a webcam under linux? Regards, Andy lsusb -vvv output: Mass storage mode: Bus 003 Device 003: ID 0979:0371 Jeilin Technology Corp., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0979 Jeilin Technology Corp., Ltd idProduct 0x0371 bcdDevice1.00 iManufacturer 1 Jeilin iProduct2 USB 1.1 Device iSerial 3 09790 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 4 SMC CF SD Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 Device Status: 0x (Bus Powered) Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0979 Jeilin Technology Corp., Ltd idProduct 0x0280 bcdDevice1.00 iManufacturer 1 Jeilin iProduct2 USB 1.1 Device iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 4 SMC CF SD Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0
Re: [PATCH] adding support for setting bus parameters in sub device
On Wed, Jun 17, 2009 at 5:33 PM, Hans Verkuilhverk...@xs4all.nl wrote: I think automatic negotiation is a good thing if it is implemented correctly. Actually, i think modelling software after hardware is a good thing and from that perspective the soc_camera was (and still is) a very good fit for our on-chip SoC. Apart from host/sensor separation, the main benefits in my mind are autonegotiation and separate configuration for camera sensor, capture interface and board. I don't mind doing the same outside soc_camera, and I agree with Hans that in some cases it's nice to hard code and skip the magic negotiation. I'm however pretty sure the soc_camera allows hard coding though, so in that case you get the best of two worlds. It is my strong opinion that while autonegotiation is easy to use, it is not a wise choice to make. Filling in a single struct with the bus settings to use for each board-subdev combination (usually there is only one) is simple, straight-forward and unambiguous. And I really don't see why that should take much time at all. And I consider it a very good point that the programmer is forced to think about this for a bit. I agree that it's good to force the programmer to think. In this case I assume you are talking about the board support engineer or at least the person writing software to attach a camera sensor with capture hardware. You are not against letting drivers export their capabilites at least? I'd like to see drivers that exports capabilites about which signals that are supported and which states that are valid. So for instance, the SuperH CEU driver supports both active high and active low HSYNC and VSYNC signals. I'd like to make sure that the driver writers are forced to think and export a bitmap of capabilites describing all valid pin states. A little bit in the same way that i2c drivers use -functionality() to export a bitmap of capabilites. Then if the assignment of the pin states is automatic or hard coded I don't care about. Cheers, / magnus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Leadtek Winfast DTV-1000S
Hi, I have this card and tried testing the tree at http://kernellabs.com/hg/~mkrufky/dtv1000s revision b0f29c0cff4b No directory was created at /dev/dvb/ 'uname -r' gives: 2.6.28-11-generic which is the Ubuntu 9.04 kernel (I don't know how to get a vanilla kernel .. sorry) I'm new at this so I've probably missed something. Cheers James Moschou dmesg: [8.760626] Linux video capture interface: v2.00 [8.866353] saa7130/34: v4l2 driver version 0.2.15 loaded [8.866402] saa7134 :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [8.866407] saa7130[0]: found at :05:01.0, rev: 1, irq: 19, latency: 32, mmio: 0xfb002000 [8.866412] saa7130[0]: subsystem: 107d:6655, board: UNKNOWN/GENERIC [card=0,autodetected] [8.866446] saa7130[0]: board init: gpio is 22000 [9.003970] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [9.004018] HDA Intel :00:1b.0: setting latency timer to 64 [9.016031] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [9.016040] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff [9.016047] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a ff ff ff ff [9.016055] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016063] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff ff ff ff ff [9.016070] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016078] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016086] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016093] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016101] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016109] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016116] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016124] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016131] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016139] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016147] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.016233] saa7130[0]: registered device video0 [v4l2] [9.016255] saa7130[0]: registered device vbi0 [9.016295] rt2400pci :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [9.023349] phy0: Selected rate control algorithm 'pid' [9.035477] saa7134 ALSA driver for DMA sound loaded [9.035480] saa7130[0]/alsa: UNKNOWN/GENERIC doesn't support digital audio [9.072159] Registered led device: rt2400pci-phy0:radio [9.072188] Registered led device: rt2400pci-phy0:quality [9.160446] lp0: using parport0 (interrupt-driven). [9.215527] Adding 6024332k swap on /dev/sda5. Priority:-1 extents:1 across:6024332k [9.742418] EXT4 FS on sda1, internal journal on sda1:8 [ 10.459797] kjournald starting. Commit interval 5 seconds [ 10.460001] EXT3 FS on sda3, internal journal [ 10.460005] EXT3-fs: mounted filesystem with ordered data mode. [ 10.651876] type=1505 audit(1245383427.708:2): operation=profile_load name=/usr/share/gdm/guest-session/Xsession name2=default pid=2071 [ 10.682712] type=1505 audit(1245383427.740:3): operation=profile_load name=/sbin/dhclient-script name2=default pid=2075 [ 10.682784] type=1505 audit(1245383427.740:4): operation=profile_load name=/sbin/dhclient3 name2=default pid=2075 [ 10.682814] type=1505 audit(1245383427.740:5): operation=profile_load name=/usr/lib/NetworkManager/nm-dhcp-client.action name2=default pid=2075 [ 10.682841] type=1505 audit(1245383427.740:6): operation=profile_load name=/usr/lib/connman/scripts/dhclient-script name2=default pid=2075 [ 10.769197] type=1505 audit(1245383427.828:7): operation=profile_load name=/usr/lib/cups/backend/cups-pdf name2=default pid=2080 [ 10.769316] type=1505 audit(1245383427.828:8): operation=profile_load name=/usr/sbin/cupsd name2=default pid=2080 [ 10.788943] type=1505 audit(1245383427.848:9): operation=profile_load name=/usr/sbin/tcpdump name2=default pid=2084 [ 13.193914] vboxdrv: Trying to deactivate the NMI watchdog permanently... [ 13.193918] vboxdrv: Successfully done. [ 13.193919] vboxdrv: Found 2 processor cores. [ 13.193986] VBoxDrv: dbg - g_abExecMemory=a0cfaaa0 [ 13.194000] vboxdrv: fAsync=0 offMin=0x196 offMax=0x842 [ 13.194034] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. [ 13.194036] vboxdrv: Successfully loaded version 2.1.4_OSE (interface 0x000a0009). [ 13.398592] VBoxNetFlt: dbg - g_abExecMemory=a0e99940 [ 18.940421] r8169: eth0: link down [ 18.940722] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 18.973408] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 30.877161]
cx18: Testing needed on preliminary MPC-718 support - Acer aspire idea 500/510
On Sun, 2009-06-14 at 22:33 -0400, Andy Walls wrote: On Fri, 2009-06-12 at 14:26 -0400, Andy Walls wrote: On Thu, 2009-06-11 at 16:20 +0100, Steve Firth wrote: I've de-lidded the MPC718 card and the chip set is as below. Devices --- Connexant CX23418 MPEG 2 Encoder Zarlink MT352/CG COFDM Demodulator Ugh. There is a linux driver for this chip, but it wants an initialization sequence of registers that are not publicly documented. I think the MPC718 variants might use at least 3 different DVB-T demodulators: Mitel/Zarlink MT352, Zarlink ZL10353, or some DiBcom chip supported by one of the dib7000x drivers. It looks like you might have an older card. Steve, I have a preliminary set of patches for the MPC-718 boards with an MT-352 demodulator here: http://linuxtv.org/hg/~awalls/cx18-mpc718/ Please give it a test. Some warnings: 1. Do not test DVB-T and analog from the antenna at the same time. Both sides of the card try to use the XC3028 silicon tuner for tuning, and the cx18 driver currently has no interlock to stop bad things from happening if you try both at once. 2. Test with 8 MHz DVB-T channels in UHF. Those should be least likely to introduce any unknowns by the xc2028 and mt352 drivers. 3. I mucked with the analog set up of the card too. Let me know if anything is better or newly broken. 4. Test with v4l2-ctl, ivtv-tune, and mplayer. Don't test with MythTV - too many variables. 5. These patches will fail to load DVB-T, if you have an MPC718 with a ZL10353 or DiBcom demodulator. 6. These patches are for testing only. The last patch in the set has dubious origin (an MT352 init sequence pulled out of the Windows driver, but slightly modified by me from what I could figure out). I will likely have to split this sequence out into an annoying cx18-mpc718-mt352.fw file in the final version of this patch, for inclusion into the kernel. Regards, Andy XCeive 3028 Hybrid Tuner + analog demodulator Hynix HY5DU28B DDR RAM Cirrus(?) 5340 CZZ Audio A-D Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Leadtek Winfast DTV-1000S
OK after adding 'options saa7134 card=156' to /etc/modprobe.d/modprobe.conf it loads correctly, thanks Brad. dmesg: [8.438243] Linux video capture interface: v2.00 [8.606434] nvidia :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [8.606440] nvidia :01:00.0: setting latency timer to 64 [8.607114] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.14 Wed May 27 01:23:47 PDT 2009 [8.626542] input: PC Speaker as /devices/platform/pcspkr/input/input6 [8.659879] iTCO_vendor_support: vendor-support=0 [8.26] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05 [8.666736] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0x0460) [8.666811] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [8.742132] saa7130/34: v4l2 driver version 0.2.15 loaded [8.742181] saa7134 :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [8.742186] saa7130[0]: found at :05:01.0, rev: 1, irq: 19, latency: 32, mmio: 0xfb002000 [8.742191] saa7130[0]: subsystem: 107d:6655, board: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option] [8.742214] saa7130[0]: board init: gpio is 22000 [8.852862] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [8.852908] HDA Intel :00:1b.0: setting latency timer to 64 [8.916022] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [8.916031] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff [8.916039] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a ff ff ff ff [8.916046] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916054] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff ff ff ff ff [8.916062] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916069] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916077] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916085] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916092] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916100] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916108] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916115] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916123] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916131] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916138] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.916148] tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. [8.916150] saa7130[0]: warning: unknown hauppauge model #0 [8.916151] saa7130[0]: hauppauge eeprom: model=0 [8.980528] Chip ID is not zero. It is not a TEA5767 [8.980592] tuner 0-0060: chip found @ 0xc0 (saa7130[0]) [9.016010] tda8290: no gate control were provided! [9.016080] tuner 0-0060: Tuner has no way to set tv freq [9.016086] tuner 0-0060: Tuner has no way to set tv freq [9.016171] saa7130[0]: registered device video0 [v4l2] [9.016215] saa7130[0]: registered device vbi0 [9.016251] saa7130[0]: registered device radio0 [9.016387] rt2400pci :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [9.024385] phy0: Selected rate control algorithm 'pid' [9.028685] saa7134 ALSA driver for DMA sound loaded [9.028688] saa7130[0]/alsa: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid doesn't support digital audio [9.060205] dvb_init() allocating 1 frontend [9.093967] Registered led device: rt2400pci-phy0:radio [9.093980] Registered led device: rt2400pci-phy0:quality [9.150392] lp0: using parport0 (interrupt-driven). [9.174892] tda18271 0-0060: creating new instance [9.184029] TDA18271HD/C1 detected @ 0-0060 [9.211513] Adding 6024332k swap on /dev/sda5. Priority:-1 extents:1 across:6024332k [9.588014] DVB: registering new adapter (saa7130[0]) [9.588018] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [9.739258] EXT4 FS on sda1, internal journal on sda1:8 [9.916017] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [9.916022] saa7134 :05:01.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 10.020209] tda10048_firmware_upload: Upload failed. (file not found?) [ 10.466227] kjournald starting. Commit interval 5 seconds [ 10.466428] EXT3 FS on sda3, internal journal [ 10.466432] EXT3-fs: mounted filesystem with ordered data mode. [ 10.616663] type=1505 audit(1245387419.676:2): operation=profile_load name=/usr/share/gdm/guest-session/Xsession name2=default pid=2116 [ 10.647644] type=1505 audit(1245387419.704:3): operation=profile_load name=/sbin/dhclient-script
