Re: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Em Sun, 05 Jul 2009 21:25:09 +0200
Erik Andrén escreveu:
>
>
> Mauro Carvalho Chehab wrote:
> > Em Sat, 4 Jul 2009 21:58:31 +0200
> > Erik Andrén escreveu:
> >
> >> 08/24: gspca - m5602-ov7660: Create blue gain control
> >> http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=5675978999c5
> >>
> >> 09/24: gspca - m5602-ov7660: Add red gain control
> >> http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=802e9a025e93
> >
> > +#define RED_BALANCE_IDX 3
> > + {
> > + {
> > + .id = V4L2_CID_RED_BALANCE,
> > + .type = V4L2_CTRL_TYPE_INTEGER,
> > + .name = "red balance",
> > + .minimum= 0x00,
> > + .maximum= 0x7f,
> > + .step = 0x1,
> > + .default_value = OV7660_DEFAULT_RED_GAIN,
> > + .flags = V4L2_CTRL_FLAG_SLIDER
> > + },
> > + .set = ov7660_set_red_gain,
> > + .get = ov7660_get_red_gain
> > + },
> > };
> > x
> > Hmm... as far as I understand, "Red Balance" and "Red gain" are different
> > ways
> > to see the same measure. Unfortunately, the V4L2 API is not clear about
> > those
> > controls.
> >
> > According with the spec, we have:
> >
> > V4L2_CID_CONTRAST integer Picture contrast or luma gain.
> > V4L2_CID_SATURATION integer Picture color saturation or chroma gain.
> > V4L2_CID_HUEinteger Hue or color balance.
> > V4L2_CID_RED_BALANCEinteger Red chroma balance.
> > V4L2_CID_BLUE_BALANCE integer Blue chroma balance.
> > V4L2_CID_GAIN integer Gain control.
> >
> > From what I'm understanding from the term "balance", it should be a shift
> > over
> > the gain control (so, 0 means normal colors, like on HUE balance).
> >
> > So, in order to convert from a RED GAIN into a RED BALANCE, we need to
> > calculate it as a function of the V4L2_CID_GAIN or V4L2_CID_SATURATION.
> > Positive values should mean more gain than the other colors, while negative
> > values would mean the opposite.
>
> Is such a function defined somewhere? Do you have an example
> implementing it?
No, I don't have. We should better analize it, since drivers are doing
different things with the gains.
> I've done the same thing in the m5602 ov9650 sensor cod
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
[PULL] http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881 for the following: em28xx: set GPIO properly for Pinnacle Hybrid Pro analog support em28xx: make support work for the Pinnacle Hybrid Pro (eb1a:2881) Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] SAA713x setting audio capture frequency (ALSA)
Hi Oldřich, this needs to be looked up during day time, preferably with the register settings for all involved saa713x devices, which I do not have ... Am Sonntag, den 12.07.2009, 19:48 +0200 schrieb Oldřich Jedlička: > Hi all, > > I had a look at the audio code in saa7134 directory once again > (saa7134-alsa.c and saa7134-tvaudio.c). It has one major problem - the > frequency for SAA7134 isn't set during startup, only during the capture > source change (that is another problem). But let's start from beginning, > please comment what you find interresting, I will create a patch after the > discussion for another discussion :-). ;) > 1. SAA7133/SAA7135 > > SAA7133/SAA7135 always use DDEP (DemDec Easy Programming) mode which runs > on 32kHz only. There is no need to change the frequency at all, so > everything works except that the info coming from ALSA reports both > frequencies 32kHz and 48kHz as available for recording. This can be easily > changed in snd_card_saa7134_hw_params to report only 32kHz for > SAA7133/SAA7135. So, for now, agreed. But you should try to talk to Ricardo and Hartmut in this case. I can tell you about the three years it did not work. > 2. SAA7134 > > SAA7134 is special in the way it programs the frequency by hand. It uses > 32kHz > DemDec mode for TV (DemDec works only in 32kHz mode), 32kHz for radio (this > is locked), and 32kHz/48kHz for S-Video and Composite inputs. ALSA again > reports both frequencies 32kHz and 48kHz as available for recording - this > can be changed accordingly. Agreed. > The problem is that the frequency is never changed during inicialization like > it was in OSS code (see 2.6.24 kernel, saa7134_oss_init1 calls mixer_recsrc). > I think that this responsibility is now on the > snd_card_saa7134_capture_prepare method - it should set the frequency in > SAA7134_SIF_SAMPLE_FREQ register correctly, possibly also > SAA7134_ANALOG_IO_SELECT. Note that the tvaudio's mute_input_7134 sets the > frequency to 32kHz, this can be thrown away I think. Agreed. If any, that is the only "regression" to report compared to saa7134-oss. > I tried to set SAA7134_SIF_SAMPLE_FREQ in snd_card_saa7134_capture_prepare > and the capturing works correctly with 48kHz from my digital camera > (Composite > input). OK, that should be previous behaviour then. > 3. Changing the capture source > > The ALSA interface has three capture sources, all of them have left and right > channels (boolean values) - LINE1, LINE2 and TV. The user can select any > source - ALSA calls snd_saa7134_capsrc_put. Note, without looking any further, LINE1 and LINE2 are left/right _pairs_ of stereo inputs. In saa7134-oss it was needed to select them card specific. > The ALSA controls are not updated, so it is possible to select both LINE1 and > LINE2 at the same time, but recording will use only one of them - the last > changed control wins. Moreover the left/right selection doesn't make any > difference, the code ignores it. For saa7133/35/31e that was exactly Hartmut's plan. You don't have to care to select the right inputs anymore. And with Ricardo exporting the mute symbol from saa7134-tvaudio to saa7134-alsa, you don't have to care for this either. (mythtv v4l1, except you do ambiguous stuff from user side) > Here comes also the frequency problem of SAA7134. If the user starts with > LINE1 and 48kHz and tries to switch to TV, the frequency will change to 32kHz > (DemDec mode) - the application will not know, I guess there will be some > buffer underruns. Anyway, to switch to 32kHz for TV is right currently, but it doesn't stop since years, that it is claimed, more is possible. No proof for any standard yet and A2 and NICAM won't do at least. > Note that any change of capture source control is overriden by the call to > snd_card_saa7134_capture_prepare (called by ALSA before the capture source is > opened) that takes the current input as set by saa7134_tvaudio_setinput > (called by v4l interface). I think this is actually expected behaviour and > can stay as it is now. There are also cards with mpeg encoders and you can't just mute or do what you want. > > The easiest solution would be to throw away the capture source control and > let > the capture source initialization on the snd_card_saa7134_capture_prepare > method (the source would be controlled by saa7134_tvaudio_setinput only - > through v4l interface only), or limit the frequency to 32kHz only so that any > source can be freely selected on any SAA713x hardware. I'm not sure, in case we are talking about all sources, talk about the same things already. Also, you might have noticed or not, there are also mute calls depending on having a signal. > Any other ideas, comments, corrections (I could be wrong in what I wrote, I'm > not the SAA713x programming expert!), suggestions? > > Cheers, > Oldrich. Given the problems we had previously, I'm not right sure, if we really have some now at all,
TBS 8920 DVB-S2 Satellite card
Greetings: Is the TBS 8920 card supported? It is not present in the supported cards list in the wiki, but I saw it mentioned in an article about S2API. I just wanted to check before I bought one. Thanks, -- Mark -- 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: About v4l2 subdev s_config (for core) API?
On Mon, Jul 13, 2009 at 2:34 AM, Guennadi Liakhovetski wrote: > On Sun, 12 Jul 2009, Dongsoo, Nathaniel Kim wrote: > >> 2009/7/12 Hans Verkuil : >> > On Saturday 11 July 2009 13:02:33 Dongsoo, Nathaniel Kim wrote: >> >> Hi, >> >> >> >> The thing is - Is it possible to make the subdev device not to be >> >> turned on in registering process using any of v4l2_i2c_new_subdev*** ? >> >> You can say that I can ignore the i2c errors in booting process, but I >> >> think it is not a pretty way. >> >> >> >> And for the reason I'm asking you about this, I need you to consider >> >> following conditions I carry. >> >> >> >> 1. ARM embedded platform especially mobile handset. >> >> 2. Mass production which is very concerned about power consumption. >> >> 3. Strict and automated test process in product line. >> >> >> >> So, what I want to ask you is about s_config subdev call which is >> >> called from every single I2C subdev load in some kind of probe >> >> procedure. As s_config is supposed to do, it tries to initialize >> >> subdev device. which means it needs to turn on the subdev to make that >> >> initialized. >> > >> > Actually, all s_config does is to pass the irq and platform_data arguments >> > to the subdev driver. The subdev driver can just store that information >> > somewhere and only use it when needed. It does not necessarily have to turn >> > on the sub-device. >> > >> > Whether to just store this info or turn on the sub-device is something that >> > each subdev driver writer has to decide. >> > >> > Note that this really has nothing to do with the existance of s_config: >> > s_config was only introduced in order to support legacy v4l2 drivers and >> > subdev drivers. In the (far?) future this will probably disappear and this >> > information will always be passed via struct i2c_board_info. >> > >> >> But as I mentioned above if we make the product go through the product >> >> line, it turns on the subdev device even though nobody intended to >> >> turn the subdev on. It might be an issue in product vendor's point of >> >> view, because there should be a crystal clear reason for the >> >> consumption of power the subdev made. I'm working on camera device and >> >> speaking of which, camera devices are really power consuming device >> >> and some camera devices even take ages to be initialized as well. >> >> >> >> So far I hope I made a good explanation about why I'm asking you about >> >> following question. >> >> By the way, it seems to be similar to the issue I've faced whe using >> >> old i2c driver model..I mean probing i2c devices on boot up sequence. >> > >> > That at least should no longer be a problem anymore (as long as you don't >> > use the address-probing variants). >> > >> > Regards, >> > >> > Hans >> > >> > -- >> > Hans Verkuil - video4linux developer - sponsored by TANDBERG >> > >> >> Hello Hans, >> >> I just needed an API for initializing soc camera device ;-( but after >> reading your mail, it seems to be that I'm using a wrong API. >> As you know, almost every cmos camera module needs to be programmed >> through I2C(or SPI) when it is turned on to be initialized. And I >> thought that s_config is the one which could be used. >> If I'm getting wrong, which one can I use for that initialization >> purpose? I referenced every v4l2 device driver in linuxtv repository >> and cherry-picked the API in my own way. > > Hi Nate > > You might want to have a look at my latest soc-camera (quilt) patch stack > at downloads.open-technology.de. There I do the same as what soc-camera > has been doing pretty much since the beginning - turn the device on for > probing, and then turn it off again - until open(). > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > Hi Guennadi, Thank you, and I'll check for your patch. Actually I didn't mean to turn on the devices on probing time mandatorily. Honestly I need to take a look at the subdev APIs more precisely and take the appropriate one for initializing sensor devices. Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-T Initial scan file es-Vitoria-Gasteiz
In the file I commented to remove special characters like í in the generated channels.conf to work with totem but is also possible to mantain them converiting the file from ISO-8859-15 to UTF-8. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352
On Sun, Jul 12, 2009 at 5:34 PM, Andy Walls wrote:
> On Sun, 2009-07-12 at 17:03 -0400, Devin Heitmueller wrote:
>> Mauro,
>>
>> Please pull from
>> http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352 for the
>> following:
>>
>> em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant)
>
> Did you intend to write 0x5d to register 0x5d?:
>
> + static u8 tuner_go[] = { TUNER_GO, 0x5d}
>
> Regards,
> Andy
>
>> Thanks,
>>
>> Devin
Mauro,
The tree has been updated with a fix suggested by Andy. Please PULL
both of these
patches:
em28xx: fix typo in mt352 init sequence for Terratec Cinergy T XS USB
em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant)
Thanks,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352
On Sun, Jul 12, 2009 at 5:34 PM, Andy Walls wrote:
> On Sun, 2009-07-12 at 17:03 -0400, Devin Heitmueller wrote:
>> Mauro,
>>
>> Please pull from
>> http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352 for the
>> following:
>>
>> em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant)
>
> Did you intend to write 0x5d to register 0x5d?:
>
> + static u8 tuner_go[] = { TUNER_GO, 0x5d}
>
> Regards,
> Andy
Nope, that's a typo (although it works). It should write 0x01 to that register.
Thanks for noticing. Will update the tree now and submit a second PULL.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Report: Compro Videomate Vista T750F
Hi Samuel, Am Sonntag, den 12.07.2009, 13:30 +0200 schrieb Samuel Rakitnican: > As the card=139 (Compro Videomate T750) > > DVB: Not working, not implemented > Analog: Not working > Audio In: ? (my T750F has additional connector ?) if amux LINE2 doesn't work it is usually LINE1. If both don't work, there is a external gpio controlled switch/mux chip. Default is loop through for external audio in. Means, if the saa7134 driver is unloaded, should be passed through to audio out. If not, there is such a mux chip involved. > Composite In: Working > S-Video In: Working > IR: Works with T300 codes and different keymap (needs to be implemented) > (http://www.spinics.net/lists/linux-media/msg07705.html) Should not be a problem anymore, since you have already unique codes for all keys. It works with the same gpios, but generates different codes and the MCE remote has more and different buttons. We likely need a new entry for the T750F later and will have auto detection problems, because of the same PCI subsystem. Detecting from eeprom does not work well with two different remotes. This is currently because the ir init happens already at hardware init level 1, but epprom detection nedds working i2c at hardware level init 2. Unless ir init is not moved to hardware init 2, it needs to set the card=number option to get the right keymap then. > > Analog TV and XCeive: > > Although John Newbigins reported that Analog is working in Apr 25 2007 > with a patch. I did not try to implement this patch (by hand) because tree > changed big from that date, so it seems that this can not be done. At > least I can't. > (http://www.linuxtv.org/pipermail/linux-dvb/2007-April/017449.html) > > With stock Slackware 12.2 it's showing a single channel (although tuner > does't work) that previously was selected in a windows application and > restarted. > Thought I had to select in tvtime: Input configuration > Television > standard > PAL (Default was NTSC). And then Restart with new settings to > show up that channel. Otherwise it would still remain blue. XCeive is > recognized at 0xc2 > > With new v4l-dvb tree channel is not showing up any more no mather what I > do. > New v4l also recognizes XCeive at 0xc2: > tuner' 0-0061: chip found @ 0xc2 (saa7133[0]) > xc2028 0-0061: creating new instance > xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner > > > tvtime startup and shuting off: > (Complete dump: http://pastebin.com/f376a8272) > xc2028 1-0061: Loading firmware for type=BASE F8MHZ MTS (7), id > . > xc2028 1-0061: i2c output error: rc = -5 (should be 64) > xc2028 1-0061: -5 returned from send > xc2028 1-0061: Error -22 while loading base firmware > (and then shutting off tvtime gives a line) > xc2028 1-0061: Error on line 1141: -5 Hm, if I get it right, without using windows previously the XCeive at 0x61 is not found and then it is tried in vain to use the qt1010 at 0x62. Also, after using windows gpio20 seems to be high. Maybe that is the gpio to get the tuner out of reset. Please try the attached patch as a shot into the dark. > > eeproms T750 and T750F (maybe needed for automatic IR keymap selection) > > T750 > saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 03 01 08 ff 00 89 ff ff ff ff > saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 ff ff ff ff > saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb > saa7133[0]: i2c eeprom 60: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > T750F > saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 03 01 08 ff 00 87 ff ff ff ff > saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 c6 ff 05 ff -^^ > saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb > saa7133[0]: i2c eepr
[RFC] SAA713x setting audio capture frequency (ALSA)
Hi all, I had a look at the audio code in saa7134 directory once again (saa7134-alsa.c and saa7134-tvaudio.c). It has one major problem - the frequency for SAA7134 isn't set during startup, only during the capture source change (that is another problem). But let's start from beginning, please comment what you find interresting, I will create a patch after the discussion for another discussion :-). 1. SAA7133/SAA7135 SAA7133/SAA7135 always use DDEP (DemDec Easy Programming) mode which runs on 32kHz only. There is no need to change the frequency at all, so everything works except that the info coming from ALSA reports both frequencies 32kHz and 48kHz as available for recording. This can be easily changed in snd_card_saa7134_hw_params to report only 32kHz for SAA7133/SAA7135. 2. SAA7134 SAA7134 is special in the way it programs the frequency by hand. It uses 32kHz DemDec mode for TV (DemDec works only in 32kHz mode), 32kHz for radio (this is locked), and 32kHz/48kHz for S-Video and Composite inputs. ALSA again reports both frequencies 32kHz and 48kHz as available for recording - this can be changed accordingly. The problem is that the frequency is never changed during inicialization like it was in OSS code (see 2.6.24 kernel, saa7134_oss_init1 calls mixer_recsrc). I think that this responsibility is now on the snd_card_saa7134_capture_prepare method - it should set the frequency in SAA7134_SIF_SAMPLE_FREQ register correctly, possibly also SAA7134_ANALOG_IO_SELECT. Note that the tvaudio's mute_input_7134 sets the frequency to 32kHz, this can be thrown away I think. I tried to set SAA7134_SIF_SAMPLE_FREQ in snd_card_saa7134_capture_prepare and the capturing works correctly with 48kHz from my digital camera (Composite input). 3. Changing the capture source The ALSA interface has three capture sources, all of them have left and right channels (boolean values) - LINE1, LINE2 and TV. The user can select any source - ALSA calls snd_saa7134_capsrc_put. The ALSA controls are not updated, so it is possible to select both LINE1 and LINE2 at the same time, but recording will use only one of them - the last changed control wins. Moreover the left/right selection doesn't make any difference, the code ignores it. Here comes also the frequency problem of SAA7134. If the user starts with LINE1 and 48kHz and tries to switch to TV, the frequency will change to 32kHz (DemDec mode) - the application will not know, I guess there will be some buffer underruns. Note that any change of capture source control is overriden by the call to snd_card_saa7134_capture_prepare (called by ALSA before the capture source is opened) that takes the current input as set by saa7134_tvaudio_setinput (called by v4l interface). I think this is actually expected behaviour and can stay as it is now. --- The easiest solution would be to throw away the capture source control and let the capture source initialization on the snd_card_saa7134_capture_prepare method (the source would be controlled by saa7134_tvaudio_setinput only - through v4l interface only), or limit the frequency to 32kHz only so that any source can be freely selected on any SAA713x hardware. Any other ideas, comments, corrections (I could be wrong in what I wrote, I'm not the SAA713x programming expert!), suggestions? Cheers, Oldrich. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352
On Sun, 2009-07-12 at 17:03 -0400, Devin Heitmueller wrote:
> Mauro,
>
> Please pull from
> http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352 for the
> following:
>
> em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant)
Did you intend to write 0x5d to register 0x5d?:
+ static u8 tuner_go[] = { TUNER_GO, 0x5d}
Regards,
Andy
> Thanks,
>
> Devin
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352
Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352 for the following: em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant) Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/media/video/gspca: Add kmalloc NULL tests
From: Julia Lawall Check that the result of kmalloc is not NULL before passing it to other functions. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // @@ expression *x; identifier f; constant char *C; @@ x = \(kmalloc\|kcalloc\|kzalloc\)(...); ... when != x == NULL when != x != NULL when != (x || ...) ( kfree(x) | f(...,C,...,x,...) | *f(...,x,...) | *x->f ) // Signed-off-by: Julia Lawall --- drivers/media/video/gspca/conex.c |2 ++ drivers/media/video/gspca/mars.c|2 ++ drivers/media/video/gspca/sonixj.c |2 ++ drivers/media/video/gspca/spca500.c |2 ++ drivers/media/video/gspca/stk014.c |2 ++ drivers/media/video/gspca/sunplus.c |2 ++ drivers/media/video/gspca/zc3xx.c |2 ++ 7 files changed, 14 insertions(+) diff --git a/drivers/media/video/gspca/conex.c b/drivers/media/video/gspca/conex.c index 219cfa6..8d48ea1 100644 --- a/drivers/media/video/gspca/conex.c +++ b/drivers/media/video/gspca/conex.c @@ -846,6 +846,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ sd->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (!sd->jpeg_hdr) + return -ENOMEM; jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x22); /* JPEG 411 */ jpeg_set_qual(sd->jpeg_hdr, sd->quality); diff --git a/drivers/media/video/gspca/mars.c b/drivers/media/video/gspca/mars.c index 75e8d14..de769ca 100644 --- a/drivers/media/video/gspca/mars.c +++ b/drivers/media/video/gspca/mars.c @@ -201,6 +201,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ sd->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (!sd->jpeg_hdr) + return -ENOMEM; jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x21); /* JPEG 422 */ jpeg_set_qual(sd->jpeg_hdr, sd->quality); diff --git a/drivers/media/video/gspca/sonixj.c b/drivers/media/video/gspca/sonixj.c index 0d02f41..db425cc 100644 --- a/drivers/media/video/gspca/sonixj.c +++ b/drivers/media/video/gspca/sonixj.c @@ -1735,6 +1735,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ sd->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (!sd->jpeg_hdr) + return -ENOMEM; jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x21); /* JPEG 422 */ jpeg_set_qual(sd->jpeg_hdr, sd->quality); diff --git a/drivers/media/video/gspca/spca500.c b/drivers/media/video/gspca/spca500.c index 8806b2f..fab7ef8 100644 --- a/drivers/media/video/gspca/spca500.c +++ b/drivers/media/video/gspca/spca500.c @@ -670,6 +670,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ sd->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (!sd->jpeg_hdr) + return -ENOMEM; jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x22); /* JPEG 411 */ jpeg_set_qual(sd->jpeg_hdr, sd->quality); diff --git a/drivers/media/video/gspca/stk014.c b/drivers/media/video/gspca/stk014.c index f25be20..4762896 100644 --- a/drivers/media/video/gspca/stk014.c +++ b/drivers/media/video/gspca/stk014.c @@ -333,6 +333,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ sd->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (!sd->jpeg_hdr) + return -ENOMEM; jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x22); /* JPEG 411 */ jpeg_set_qual(sd->jpeg_hdr, sd->quality); diff --git a/drivers/media/video/gspca/sunplus.c b/drivers/media/video/gspca/sunplus.c index 9623f29..5127bbf 100644 --- a/drivers/media/video/gspca/sunplus.c +++ b/drivers/media/video/gspca/sunplus.c @@ -973,6 +973,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ sd->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (!sd->jpeg_hdr) + return -ENOMEM; jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x22); /* JPEG 411 */ jpeg_set_qual(sd->jpeg_hdr, sd->quality); diff --git a/drivers/media/video/gspca/zc3xx.c b/drivers/media/video/gspca/zc3xx.c index 08422d3..3d2756f 100644 --- a/drivers/media/video/gspca/zc3xx.c +++ b/drivers/media/video/gspca/zc3xx.c @@ -7243,6 +7243,8 @@ static int sd_start(struct gspca_dev *gspca_dev) /* create the JPEG header */ sd->jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); + if (!sd->jpeg_hdr) + return -ENOMEM; jpeg_define(sd->jpeg_hdr, gspca_dev->height, gspca_dev->width, 0x21); /* JPEG 422 */ jpeg_set_qual(sd->jpeg_hdr, sd
[PULL] http://kernellabs.com/hg/~dheitmueller/hvr-900-tuning-fix
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/hvr-900-tuning-fix for the following: em28xx: fix tuning problem in HVR-900 (R1) Thank you, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB-T Initial scan file es-Vitoria-Gasteiz
Looking in the wiki I have seen that the nomenclature is country-town, if this could be the area covered this file can be es-Alava, Álava is the region, also, the complete name of the town is Vitoria-Gasteiz, if this broke the nomenclature of the file because the second '-' could be changed to es-Vitoria without problem because won't be confusion with another town in Spain. es-Vitoria-Gasteiz Description: Binary data
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jul 12 19:00:07 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12236:d277b05c41fe gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-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.31-rc1-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.31-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK 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.31-rc1-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-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.31-rc1-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS 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 linux-2.6.31-rc1-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About v4l2 subdev s_config (for core) API?
On Sun, 12 Jul 2009, Dongsoo, Nathaniel Kim wrote: > 2009/7/12 Hans Verkuil : > > On Saturday 11 July 2009 13:02:33 Dongsoo, Nathaniel Kim wrote: > >> Hi, > >> > >> The thing is - Is it possible to make the subdev device not to be > >> turned on in registering process using any of v4l2_i2c_new_subdev*** ? > >> You can say that I can ignore the i2c errors in booting process, but I > >> think it is not a pretty way. > >> > >> And for the reason I'm asking you about this, I need you to consider > >> following conditions I carry. > >> > >> 1. ARM embedded platform especially mobile handset. > >> 2. Mass production which is very concerned about power consumption. > >> 3. Strict and automated test process in product line. > >> > >> So, what I want to ask you is about s_config subdev call which is > >> called from every single I2C subdev load in some kind of probe > >> procedure. As s_config is supposed to do, it tries to initialize > >> subdev device. which means it needs to turn on the subdev to make that > >> initialized. > > > > Actually, all s_config does is to pass the irq and platform_data arguments > > to the subdev driver. The subdev driver can just store that information > > somewhere and only use it when needed. It does not necessarily have to turn > > on the sub-device. > > > > Whether to just store this info or turn on the sub-device is something that > > each subdev driver writer has to decide. > > > > Note that this really has nothing to do with the existance of s_config: > > s_config was only introduced in order to support legacy v4l2 drivers and > > subdev drivers. In the (far?) future this will probably disappear and this > > information will always be passed via struct i2c_board_info. > > > >> But as I mentioned above if we make the product go through the product > >> line, it turns on the subdev device even though nobody intended to > >> turn the subdev on. It might be an issue in product vendor's point of > >> view, because there should be a crystal clear reason for the > >> consumption of power the subdev made. I'm working on camera device and > >> speaking of which, camera devices are really power consuming device > >> and some camera devices even take ages to be initialized as well. > >> > >> So far I hope I made a good explanation about why I'm asking you about > >> following question. > >> By the way, it seems to be similar to the issue I've faced whe using > >> old i2c driver model..I mean probing i2c devices on boot up sequence. > > > > That at least should no longer be a problem anymore (as long as you don't > > use the address-probing variants). > > > > Regards, > > > > Hans > > > > -- > > Hans Verkuil - video4linux developer - sponsored by TANDBERG > > > > Hello Hans, > > I just needed an API for initializing soc camera device ;-( but after > reading your mail, it seems to be that I'm using a wrong API. > As you know, almost every cmos camera module needs to be programmed > through I2C(or SPI) when it is turned on to be initialized. And I > thought that s_config is the one which could be used. > If I'm getting wrong, which one can I use for that initialization > purpose? I referenced every v4l2 device driver in linuxtv repository > and cherry-picked the API in my own way. Hi Nate You might want to have a look at my latest soc-camera (quilt) patch stack at downloads.open-technology.de. There I do the same as what soc-camera has been doing pretty much since the beginning - turn the device on for probing, and then turn it off again - until open(). Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add support for Humax/Coex DVB-T USB Stick 2.0 High Speed
This patch adds support for Humax/Coex DVB-T USB Stick 2.0 High Speed
which is a very popular tuner sold in Vietnam.
Tested with at least 3 tuners.
It's very likely that this patch will not cause any regression.
Thanks
Signed-off-by: Pham Thanh Nam
diff -ur a/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c
b/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c
--- a/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c 2009-07-12
20:52:32.0 +0700
+++ b/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c 2009-07-12
20:12:56.0 +0700
@@ -42,6 +42,8 @@
/* 11 */ { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC,
USB_PID_ARTEC_T14_WARM) },
/* 12 */ { USB_DEVICE(USB_VID_LEADTEK,
USB_PID_WINFAST_DTV_DONGLE_COLD) },
/* 13 */ { USB_DEVICE(USB_VID_LEADTEK,
USB_PID_WINFAST_DTV_DONGLE_WARM) },
+/* 14 */ { USB_DEVICE(USB_VID_HUMAX_COEX,
USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD) },
+/* 15 */ { USB_DEVICE(USB_VID_HUMAX_COEX,
USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, dibusb_dib3000mc_table);
@@ -66,7 +68,7 @@
/* parameter for the MPEG2-data transfer */
.stream = {
.type = USB_BULK,
- .count = 7,
+ .count = 8,
.endpoint = 0x06,
.u = {
.bulk = {
@@ -88,7 +90,7 @@
.generic_bulk_ctrl_endpoint = 0x01,
- .num_device_descs = 7,
+ .num_device_descs = 8,
.devices = {
{ "DiBcom USB2.0 DVB-T reference design (MOD3000P)",
{ &dibusb_dib3000mc_table[0], NULL },
@@ -119,6 +121,10 @@
{ &dibusb_dib3000mc_table[12], NULL },
{ &dibusb_dib3000mc_table[13], NULL },
},
+ { "Humax/Coex DVB-T USB Stick 2.0 High Speed",
+ { &dibusb_dib3000mc_table[14], NULL },
+ { &dibusb_dib3000mc_table[15], NULL },
+ },
{ NULL },
}
};
diff -ur a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-07-12
20:52:32.0 +0700
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-07-12
21:23:29.0 +0700
@@ -58,6 +58,7 @@
#define USB_VID_GIGABYTE 0x1044
#define USB_VID_YUAN 0x1164
#define USB_VID_XTENSIONS 0x1ae7
+#define USB_VID_HUMAX_COEX 0x10b9
/* Product IDs */
#define USB_PID_ADSTECH_USB2_COLD 0xa333
@@ -259,5 +260,7 @@
#define USB_PID_SONY_PLAYTV0x0003
#define USB_PID_ELGATO_EYETV_DTT 0x0021
#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x0020
+#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD0x5000
+#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM0x5001
#endif
Signed-off-by: Pham Thanh Nam
Add support for Humax/Coex DVB-T USB Stick 2.0 High Speed (popular in Vietnam)
diff -ur a/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c b/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c
--- a/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c 2009-07-12 20:52:32.0 +0700
+++ b/linux/drivers/media/dvb/dvb-usb/dibusb-mc.c 2009-07-12 20:12:56.0 +0700
@@ -42,6 +42,8 @@
/* 11 */ { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, USB_PID_ARTEC_T14_WARM) },
/* 12 */ { USB_DEVICE(USB_VID_LEADTEK, USB_PID_WINFAST_DTV_DONGLE_COLD) },
/* 13 */ { USB_DEVICE(USB_VID_LEADTEK, USB_PID_WINFAST_DTV_DONGLE_WARM) },
+/* 14 */ { USB_DEVICE(USB_VID_HUMAX_COEX, USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD) },
+/* 15 */ { USB_DEVICE(USB_VID_HUMAX_COEX, USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, dibusb_dib3000mc_table);
@@ -66,7 +68,7 @@
/* parameter for the MPEG2-data transfer */
.stream = {
.type = USB_BULK,
-.count = 7,
+.count = 8,
.endpoint = 0x06,
.u = {
.bulk = {
@@ -88,7 +90,7 @@
.generic_bulk_ctrl_endpoint = 0x01,
- .num_device_descs = 7,
+ .num_device_descs = 8,
.devices = {
{ "DiBcom USB2.0 DVB-T reference design (MOD3000P)",
{ &dibusb_dib3000mc_table[0], NULL },
@@ -119,6 +121,10 @@
{ &dibusb_dib3000mc_table[12], NULL },
{ &dibusb_dib3000mc_table[13], NULL },
},
+ { "Humax/Coex DVB-T USB Stick 2.0 High Speed",
+ { &dibusb_dib3000mc_table[14], NULL },
+ { &dibusb_dib3000mc_table[15], NULL },
+ },
{ NULL },
}
};
diff -ur a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-07-12 20:52:32.0 +0700
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-07
Re: eMpia Microscope Camera
Hi Wally,
Em Mon, 6 Jul 2009 10:15:05 -0300
Mauro Carvalho Chehab escreveu:
> Em Fri, 3 Jul 2009 20:35:08 +0200 (CEST)
> Guennadi Liakhovetski escreveu:
>
> > (re-adding the mailing list)
> >
> > On Fri, 3 Jul 2009, Wally wrote:
> >
> > > Hello Guennadi, hello Mauro
> > >
> > > that's means i have to wait
> > > or is there a workaround or something else i can do for now ?
> >
> > you can either wait, or hack the mt9m001 driver to work for you, or help
> > with development.
>
> The change at em28xx for it should be trivial. The enclosed patch should
> provide the mt9v001 glue, once having it ported to v4l2 dev/subdev.
>
> You'll need to use this patch _and_ the v4l dev/subdev version of mt9m001
> driver.
>
> Change Huaqi to use mt9m001 driver.
>
> Signed-off-by: Mauro Carvalho Chehab
I did a few changes on em28xx that will help to have a better webcam support.
Due to that, the patch I've sent before won't apply anymore.
Could you please test the enclosed patch? It adds a hack that may work with
mt9m001 sensor.
Cheers,
Mauro
---
linux/drivers/media/video/em28xx/em28xx-cards.c | 55
linux/drivers/media/video/em28xx/em28xx.h |1
2 files changed, 56 insertions(+)
--- master.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
+++ master/linux/drivers/media/video/em28xx/em28xx-cards.c
@@ -1778,6 +1778,46 @@ static inline void em28xx_set_model(stru
EM28XX_I2C_FREQ_100_KHZ;
}
+/* FIXME: Should be replaced by a proper mt9m001 driver */
+static int em28xx_initialize_mt9m001(struct em28xx *dev)
+{
+ int i;
+ unsigned char regs[][3] = {
+ { 0x0d, 0x00, 0x01 },
+ { 0x0d, 0x00, 0x00 },
+ { 0x01, 0x00, 0x08 }, /* ROWSTART */
+ { 0x02, 0x00, 0x14 }, /* COLSTART */
+ { 0x03, 0x01, 0xe0 }, /* WINDOW HEIGHT */
+ { 0x04, 0x02, 0x80 }, /* WINDOW WIDTH */
+ { 0x05, 0x00, 0x01 }, /* HORIZONTAL BLANKING */
+ { 0x06, 0x00, 0x01 }, /* VERTICAL BLANKING */
+ { 0x0d, 0x00, 0x02 },
+ { 0x0a, 0x00, 0x00 },
+ { 0x0c, 0x00, 0x00 },
+ { 0x11, 0x00, 0x00 },
+ { 0x1e, 0x80, 0x00 },
+ { 0x5f, 0x89, 0x04 },
+ { 0x60, 0x00, 0x00 },
+ { 0x61, 0x00, 0x00 },
+ { 0x62, 0x04, 0x98 },
+ { 0x63, 0x00, 0x00 },
+ { 0x64, 0x00, 0x00 },
+ { 0x20, 0x11, 0x1d },
+ { 0x06, 0x00, 0xf2 },
+ { 0x05, 0x00, 0x13 },
+ { 0x09, 0x10, 0xf2 },
+ { 0x07, 0x00, 0x03 },
+ { 0x2b, 0x00, 0x2a },
+ { 0x2d, 0x00, 0x2a },
+ { 0x2c, 0x00, 0x2a },
+ { 0x2e, 0x00, 0x29 },
+ { 0x07, 0x00, 0x02 },
+ };
+
+ for (i = 0; i < ARRAY_SIZE(regs); i++)
+ i2c_master_send(&dev->i2c_client, ®s[i][0], 3);
+}
+
/* HINT method: webcam I2C chips
*
* This method work for webcams with Micron sensors
@@ -1809,6 +1849,14 @@ static int em28xx_hint_sensor(struct em2
sensor_name = "mt9v011";
dev->em28xx_sensor = EM28XX_MT9V011;
break;
+ case 0x8411:
+ case 0x8421:
+ case 0x8431:
+ dev->model = EM2750_BOARD_UNKNOWN;
+ sensor_name = "mt9m001";
+ dev->em28xx_sensor = EM28XX_MT9M001;
+ em28xx_initialize_mt9m001(dev);
+ break;
default:
printk("Unknown Micron Sensor 0x%04x\n", be16_to_cpu(version));
return -EINVAL;
@@ -2376,6 +2424,13 @@ void em28xx_card_setup(struct em28xx *de
v4l2_i2c_new_probed_subdev(&dev->v4l2_dev, &dev->i2c_adap,
"mt9v011", "mt9v011", mt9v011_addrs);
+#if 0
+ /* FIXME: use mt9m001 after their conversion to v4l dev/subdev */
+ if (dev->em28xx_sensor == EM28XX_MT9M001)
+ v4l2_i2c_new_probed_subdev(&dev->v4l2_dev, &dev->i2c_adap,
+ "mt9m001", "mt9m001", mt9v011_addrs);
+#endif
+
if (dev->board.adecoder == EM28XX_TVAUDIO)
v4l2_i2c_new_subdev(&dev->v4l2_dev, &dev->i2c_adap,
"tvaudio", "tvaudio", dev->board.tvaudio_addr);
--- master.orig/linux/drivers/media/video/em28xx/em28xx.h
+++ master/linux/drivers/media/video/em28xx/em28xx.h
@@ -367,6 +367,7 @@ enum em28xx_decoder {
enum em28xx_sensor {
EM28XX_NOSENSOR = 0,
EM28XX_MT9V011,
+ EM28XX_MT9M001,
};
enum em28xx_adecoder {
--
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: [GIT PATCHES for 2.6.31] V4L/DVB fixes
Hi kernel folks! Problem: Since kernel-2.6.31-rc* my dvb-s adapter (Technisat SkyStar2 DVB card) refuses to work (worked fine in every kernel up to 2.6.30.1). So anything pulled into the new kernel seems to have broken something (at least for me :/). I opened a detailed bug report here: http://bugzilla.kernel.org/show_bug.cgi?id=13709 Please let me know if i can help in finding a solution or testing a patch /whatever. Thank you for your attention ;) PS: As i'm not subscribed to this mailing list, please answer to my address or cc me. -- http://boris64.net 20xx ;) signature.asc Description: This is a digitally signed message part.
Report: Compro Videomate Vista T750F
As the card=139 (Compro Videomate T750) DVB: Not working, not implemented Analog: Not working Audio In: ? (my T750F has additional connector ?) Composite In: Working S-Video In: Working IR: Works with T300 codes and different keymap (needs to be implemented) (http://www.spinics.net/lists/linux-media/msg07705.html) Analog TV and XCeive: Although John Newbigins reported that Analog is working in Apr 25 2007 with a patch. I did not try to implement this patch (by hand) because tree changed big from that date, so it seems that this can not be done. At least I can't. (http://www.linuxtv.org/pipermail/linux-dvb/2007-April/017449.html) With stock Slackware 12.2 it's showing a single channel (although tuner does't work) that previously was selected in a windows application and restarted. Thought I had to select in tvtime: Input configuration > Television standard > PAL (Default was NTSC). And then Restart with new settings to show up that channel. Otherwise it would still remain blue. XCeive is recognized at 0xc2 With new v4l-dvb tree channel is not showing up any more no mather what I do. New v4l also recognizes XCeive at 0xc2: tuner' 0-0061: chip found @ 0xc2 (saa7133[0]) xc2028 0-0061: creating new instance xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner tvtime startup and shuting off: (Complete dump: http://pastebin.com/f376a8272) xc2028 1-0061: Loading firmware for type=BASE F8MHZ MTS (7), id . xc2028 1-0061: i2c output error: rc = -5 (should be 64) xc2028 1-0061: -5 returned from send xc2028 1-0061: Error -22 while loading base firmware (and then shutting off tvtime gives a line) xc2028 1-0061: Error on line 1141: -5 eeproms T750 and T750F (maybe needed for automatic IR keymap selection) T750 saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 03 01 08 ff 00 89 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb saa7133[0]: i2c eeprom 60: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff T750F saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 03 01 08 ff 00 87 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 c6 ff 05 ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb saa7133[0]: i2c eeprom 60: 35 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] problems with Terratec Cinergy 1200 DVB-C MK3 after mainboard switch
Matthias Müller schrieb: Ok, I cleaned the cards one more and atm there's only 1 card in the system. Blew out all dust (the motherboard arrived brand new yesterday, so probably not necessary), still the same probs. After heavy IO the card dies. I plugged one of the cards back in the old motherboard and installed a backup vdr, no probs at all with that card. Everything else on the new mainboard works like a charm, so I doubt the board is broken. Still looking for any other hints, After testing it with a dvb-c ff card and having the same probs, I tracked it down further and it's triggered by fast switching of the cpu frequency. After disabling the ondemand governor everything works as expected. So linux-media/linux-dvb are definitely the wrong lists for that kind of prob. Thanks, Matthias -- 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
Fixing HVR-1700 - broken in tree -process ?
Hi, would anyone be kind enough to tell me what the process of reporting problem and fixing the problem is? The HVR-1700 DVB-T works fine in a standard released kernel. However in the tree from http://linuxtv.org the DVB-T cannot find any channels. Thanks for any help -- 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
