Re: RFC: V4L - Support for video timings at the input/output interface
Hi Murali,
Thanks for your work on this!
See below for a few notes I made.
On Monday 14 September 2009 15:51:28 Karicheri, Muralidharan wrote:
> RFC: V4L - Support for video timings at the input/output interface
>
> Thanks to Hans Verkuil for his initial proposal and feedbacks to help write
> this RFC.
>
> Version : 1.0
>
> Background
> ---
>
> Currently v4l2 specification supports capturing video frames from TV signals
> using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband TV signals
> (V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output side, the
> signals could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR), baseband TV signal
> (V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA overlay
> (V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card and
> then use chromakeying to replace part of the picture with the video.
> V4L2_OUTPUT_TYPE_ANALOG & V4L2_INPUT_TYPE_CAMERA are for analog interfaces
> that includes composite, S-Video and VGA (for output only). Note that even
> though VGA is a supported output, we don't have anyway to set the standard or
> timing on the output. Standard ids are only defined for TVs using
> v4l2_std_id and a set of bit masks defined for analog TV standards.
>
> Today we have a wide variety of different interfaces available to
> transmit/receive video or graphics content between source device and
> destination device. Following are some of the interfaces used in addition to
> the ones described in the v4l2 specification.
>
> Component analog input/output interface - ED/HD video
> DVI - Digital only, ANALOG only, DVI integrated that support Digital and
> Analog; Dual Link - Where second data link is used for higher
> bandwidth
> SDI - Serial digital interface standardized by SMPTE
> HDMI - HD video and Audio
> DisplayPort - digital audio/video interconnect by VESA
>
> V4L2 specification currently defined NTSC/PAL/SECAM (all variants) standards
> for describing the timing of the signal transmitted over these interfaces.
> Even though the specification defined ANALOG output type for VGA, there are
> no ways to set the timings used for output to VGA or LCD display monitors.
> Some of the proprietary implementations used existing standards IOCTL,
> VIDIOC_S_STD, to set these timings over these interfaces.
> For example, TI has Video Processing Back End (VPBE) on various media SOCs
> (Eg, DM6446, DM355 etc) that can output signal for Analog TV and VGA
> interfaces (using Digital LCD port) and support timing for displaying SD and
> HD videos (1080i, 1080p and 720p) as well as over VGA interface to a CRT or
> LCD display monitor. So we need to enhance the v4l2 specification to allow
> applications to set these timings in the capture or output devices. This RFC
> proposes to add new IOCTLs for setting/getting timings over the different
> interfaces described above and freeze the the use of existing standards
> IOCTL and standards IDs for analog TVs only.
>
> Timings
> ---
>
> The timing at the analog or digital interface that are not covered by the
> v4l2_std_id can be defined using a set of preset timings that are used by the
> hardware where these timings are predefined or by a set of timing values
> which can be configured at the hardware to generate the signal expected at
> the interface. The former will be used for hardware like TVP7002/THS8200
> which specifies preset timing required for output HD video such 1080i50/60,
> 720p50/60 etc. The latter can be used for hardware that require configuration
> of frame timing such as front porch, hsync length, vsync length, pixel clock
> etc. For example the earlier mentioned TI SOCs has a Digital LCD port that
> can be configured to output different timing values expected by LCD Display
> monitors.
>
> Preset timings (defined by VESA, SMPTE or BT.656/BT.1120 or others) can be
> defined by the following structure:-
>
> struct v4l2_dv_preset {
> __u32 preset;
> __u32 reserved[4];
> };
>
> Where preset is one of the following values:-
>
> #define V4L2_DV_CUSTOM0x
> #define V4L2_DV_480I59_94 0x0001
> #define V4L2_DV_480I600x0002
> #define V4L2_DV_480P23_9760x0003
> #define V4L2_DV_480P240x0004
> #define V4L2_DV_480P29_97 0x0005
> #define V4L2_DV_480P300x0006
> #define V4L2_DV_576I500x0007
> #define V4L2_DV_576P250x0008
> #define V4L2_DV_576P500x0009
> #define V4L2_DV_720P23_9760x000A
> #define V4L2_DV_720P240x000B
> #define V4L2_DV_720P250x000C
> #define V4L2_DV_720P29_97 0x000C
> #define V4L2_DV_720P300x000D
> #define V4L2_DV_720P500x000E
> #define V4L2_DV_720P59_94 0x000F
> #define V4L2_DV_720P600x0010
> #define V4L2_DV_1080I50
Re: tuner, code for discuss
On Tuesday 15 September 2009 06:18:55 Michael Krufky wrote: > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov wrote: > > On Mon, 14 Sep 2009 08:55:22 -0400 > > Michael Krufky wrote: > > > >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov > >> wrote: > >> > Hi All > >> > > >> > This is my next patch. > >> > > >> > Changes: > >> > 1. By default charge pump is ON > >> > 2. For radio mode charge pump set to OFF > >> > 3. Set correct AGC value in radio mode > >> > 4. Add control gain of AGC. > >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for > >> > read/write gain of AGC. 6. Add some code for control gain from > >> > saa7134 part. By default this control is OFF 7. When TV card can > >> > manipulate this control, enable it. > >> > > >> > Main changes is control value of AGC TOP in .initdata = > >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq > >> > of TV. > >> > > >> > I don't understand how to correct call new function for read/write > >> > value of AGC TOP. > >> > > >> > What you think about it?? > >> > > >> > >> [patch snipped] > >> > >> > > >> > > >> > With my best regards, Dmitry. > >> > >> Dmitry, > >> > >> The direct usage of .initdata and .sleepdata is probably unnecessary > >> here -- If you trace how the tuner-simple driver works, you'll find > >> that simply having these fields defined will cause these bytes to be > >> written at the appropriate moment. > >> > >> However, for the actual sake of setting this gain value, I'm not sure > >> that initdata / sleep data is the right place for it either. (I know > >> that I recommended something like this at first, but at the time I > >> didn't realize that there is a range of six acceptable values for this > >> field) > >> > >> What I would still like to understand is: Who will be changing this > >> value? I see that you've added a control to the saa7134 driver -- is > >> this to be manipulated from userspace? > > > > Yes > > > >> Under what conditions will somebody want to change this value? > > > > for SECAM with strong signal we have wide white crap on the screen. > > Need reduce value of AGC TOP. > > > > For weak signal need increase value of AGC TOP > > Ajust value of AGC TOP can get more better image quality. > > > >> How will users know that they need to alter this gain value? > > > > By default use value from .initdata > > v4l2-ctl can modify this value or via some plugins for TV wach programm. > > > > End-user programm for watch TV IMHO now is very poor. > > > > With my best regards, Dmitry. > > > > I have to admit that I am not familiar enough with SECAM myself to see > this kind of trouble. For NTSC and PAL, tvtime is a great application > -- the only shortcoming that bothers me about tvtime is lack of audio > support. One must rely on a separate mechanism to hear audio, whether > it's a patch cable from the tv tuner to the sound board, or a separate > application decoding DMA audio. ...but that is not what this email > thread is about. > > As far as simple tuning and analog television viewing goes, tvtime > rocks. Is it really that difficult for SECAM users? > > In summary, you are telling us that we need to add userspace controls > to handle gain control, for tuning SECAM. I am going to have to ask > for help on this topic from those cc'd on this email. (Adding Hans > Verkuil, as I value his opinion for controls and dealing with video > standards in high regard) > > Personally, I don't quite understand why we would need to add such > controls NOW, while we've supported this video standard for years > already. I am not arguing against this in any way, but I dont feel > like I'm qualified to accept this addition without hearing the > opinions of others first. > > Can somebody help to shed some light? It's the first time I've heard about SECAM and AGC-TOP problems. I do know that the TOP value is standard-dependent, although the datasheets recommend different SECAM-L values only. So I can imagine that in some cases you would like to adjust the TOP value a bit. The problem is that end-users will have no idea what to do with a control like that. It falls into the category of 'advanced controls' that might be nice to add but is only for very advanced users or applications. The proposed media controller actually gives you a way of implementing that as tuner-specific controls that do not show up in the regular /dev/videoX control list. I have no problems adding an AGC-TOP control as a tuner-specific control, but adding it as a generic control is a bad idea IMHO. 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: Audio drop on saa7134
hermann pitton wrote: Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth: hermann pitton wrote: Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann OK, I'll try running with audio_debug=1. Could you clarify what you mean by "The kernel audio detection thread must have been started without success or id find the right thing again"? An audio drop can be initiated at any point in the recording. A weak signal is a good guess, but I've never noticed a correlation with video quality. You said audio sometimes recovers, than the kernel thread did detect it again, else failed on the pilots. I didn't know about audio_ddep -- what does it do? I'm not seeing it in modinfo. Oh, are you sure? My mistake -- I'm running 2.6.19 and it's there. It would be fantastic to get this problem solved -- we've had to record everything in parallel to avoid loss, and still very occasionally lose sound. It could also be something else, but that is the point to start. It stops the kernel audio detection thread and tells him to believe that only the norm given by insmod should be assumed. It is some hex in saa7134-audio, don't know it off hand for NTSC. Wait, i'll look it up. 0x40. Thank you! I'll try turning off the audio detection thread first, and then run debug. options saa7134 card=95,95,95,95 tuner=39,39,39,39 audio_ddep=0x40,0x40,0x40,0x40 # audio_debug=9,9,9,9 It's a production system so I may need to wait until the weekend. Cheers, Dave -- 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: Audio drop on saa7134
Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth: > hermann pitton wrote: > > Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: > > > >> > >> We've been using saa7135 cards for several years with relatively few > >> incidents, but they occasionally drop audio. > >> I've been unable to find any pattern in the audio drops, so I haven't > >> reported it -- I have no way to reproduce the error, but it happens > >> regularly, affecting between 3 and 5% of recordings. Audio will > >> sometimes drop in the middle of a recording and then resume, or else > >> work fine on the next recording. > >> > > > > Hi Dave, > > > > hmm, losing audio on three to five percent of the recordings is a lot! > > > > When we started to talk to each other, we had only saa7134 PAL/SECAM > > devices over here. > > > > That has changed a lot, but still no System-M here. > > > > The kernel thread detecting audio on saa7133/35/31e behaves different > > from the one on saa7134. > > > > But if you let it run with audio_debug=1, you should have something in > > the logs when losing the audio. The kernel audio detection thread must > > have been started without success or id find the right thing again. I > > would assume caused by a weaker signal in between. > > > > Do you know about the insmod option audio_ddep? > > > > It is pretty hidden and I almost must look it up myself in the code. > > > > Cheers, > > Hermann > > > > > OK, I'll try running with audio_debug=1. Could you clarify what you mean > by "The kernel audio detection thread must have been started without > success or id find the right thing again"? An audio drop can be > initiated at any point in the recording. A weak signal is a good guess, > but I've never noticed a correlation with video quality. You said audio sometimes recovers, than the kernel thread did detect it again, else failed on the pilots. > I didn't know about audio_ddep -- what does it do? I'm not seeing it in > modinfo. Oh, are you sure? depends: videobuf-core,videobuf-dma-sg,ir-common,i2c-core,videodev,tveeprom,v4l2-common vermagic: 2.6.30.1 SMP preempt mod_unload parm: disable_ir:disable infrared remote support (int) parm: ir_debug:enable debug messages [IR] (int) parm: pinnacle_remote:Specify Pinnacle PCTV remote: 0=coloured, 1=grey (defaults to 0) (int) parm: ir_rc5_remote_gap:int parm: ir_rc5_key_timeout:int parm: repeat_delay:delay before key repeat started (int) parm: repeat_period:repeat period between keypresses when key is down (int) parm: disable_other_ir:disable full codes of alternative remotes from other manufacturers (int) parm: video_debug:enable debug messages [video] (int) parm: gbuffers:number of capture buffers, range 2-32 (int) parm: noninterlaced:capture non interlaced video (int) parm: secam:force SECAM variant, either DK,L or Lc (string) parm: vbi_debug:enable debug messages [vbi] (int) parm: vbibufs:number of vbi buffers, range 2-32 (int) parm: audio_debug:enable debug messages [tv audio] (int) parm: audio_ddep:audio ddep overwrite (int) ^ parm: audio_clock_override:int parm: audio_clock_tweak:Audio clock tick fine tuning for cards with audio crystal that's slightly off (range [-1024 .. 1024]) (int) parm: ts_debug:enable debug messages [ts] (int) parm: tsbufs:number of ts buffers for read/write IO, range 2-32 (int) parm: ts_nr_packets:size of a ts buffers (in ts packets) (int) parm: i2c_debug:enable debug messages [i2c] (int) parm: i2c_scan:scan i2c bus at insmod time (int) parm: irq_debug:enable debug messages [IRQ handler] (int) parm: core_debug:enable debug messages [core] (int) parm: gpio_tracking:enable debug messages [gpio] (int) parm: alsa:enable/disable ALSA DMA sound [dmasound] (int) parm: latency:pci latency timer (int) parm: no_overlay:allow override overlay default (0 disables, 1 enables) [some VIA/SIS chipsets are known to have problem with overlay] (int) parm: video_nr:video device number (array of int) parm: vbi_nr:vbi device number (array of int) parm: radio_nr:radio device number (array of int) parm: tuner:tuner type (array of int) parm: card:card type (array of int) > It would be fantastic to get this problem solved -- we've had to record > everything in parallel to avoid loss, and still very occasionally lose > sound. It could also be something else, but that is the point to start. It stops the kernel audio detection thread and tells him to believe that only the norm given by insmod should be assumed. It is some hex in saa7134-audio, don't know it off hand for NTSC. Wait, i'll look it up. 0x40. Good Luck,
Re: tuner, code for discuss
Hi, Am Dienstag, den 15.09.2009, 00:55 -0400 schrieb Michael Krufky: > On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton > wrote: > > > > Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky: > >> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov > >> wrote: > >> > On Mon, 14 Sep 2009 08:55:22 -0400 > >> > Michael Krufky wrote: > >> > > >> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov > >> >> wrote: > >> >> > Hi All > >> >> > > >> >> > This is my next patch. > >> >> > > >> >> > Changes: > >> >> > 1. By default charge pump is ON > >> >> > 2. For radio mode charge pump set to OFF > >> >> > 3. Set correct AGC value in radio mode > >> >> > 4. Add control gain of AGC. > >> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for > >> >> > read/write gain of AGC. 6. Add some code for control gain from > >> >> > saa7134 part. By default this control is OFF 7. When TV card can > >> >> > manipulate this control, enable it. > >> >> > > >> >> > Main changes is control value of AGC TOP in .initdata = > >> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq > >> >> > of TV. > >> >> > > >> >> > I don't understand how to correct call new function for read/write > >> >> > value of AGC TOP. > >> >> > > >> >> > What you think about it?? > >> >> > > >> >> > >> >> [patch snipped] > >> >> > >> >> > > >> >> > > >> >> > With my best regards, Dmitry. > >> >> > >> >> Dmitry, > >> >> > >> >> The direct usage of .initdata and .sleepdata is probably unnecessary > >> >> here -- If you trace how the tuner-simple driver works, you'll find > >> >> that simply having these fields defined will cause these bytes to be > >> >> written at the appropriate moment. > >> >> > >> >> However, for the actual sake of setting this gain value, I'm not sure > >> >> that initdata / sleep data is the right place for it either. (I know > >> >> that I recommended something like this at first, but at the time I > >> >> didn't realize that there is a range of six acceptable values for this > >> >> field) > >> >> > >> >> What I would still like to understand is: Who will be changing this > >> >> value? I see that you've added a control to the saa7134 driver -- is > >> >> this to be manipulated from userspace? > >> > > >> > Yes > >> > > >> >> Under what conditions will somebody want to change this value? > >> > > >> > for SECAM with strong signal we have wide white crap on the screen. > >> > Need reduce value of AGC TOP. > >> > > >> > For weak signal need increase value of AGC TOP > >> > Ajust value of AGC TOP can get more better image quality. > >> > > >> >> How will users know that they need to alter this gain value? > >> > > >> > By default use value from .initdata > >> > v4l2-ctl can modify this value or via some plugins for TV wach programm. > >> > > >> > End-user programm for watch TV IMHO now is very poor. > >> > > >> > With my best regards, Dmitry. > >> > > >> > >> I have to admit that I am not familiar enough with SECAM myself to see > >> this kind of trouble. For NTSC and PAL, tvtime is a great application > >> -- the only shortcoming that bothers me about tvtime is lack of audio > >> support. One must rely on a separate mechanism to hear audio, whether > >> it's a patch cable from the tv tuner to the sound board, or a separate > >> application decoding DMA audio. ...but that is not what this email > >> thread is about. > >> > >> As far as simple tuning and analog television viewing goes, tvtime > >> rocks. Is it really that difficult for SECAM users? > >> > >> In summary, you are telling us that we need to add userspace controls > >> to handle gain control, for tuning SECAM. I am going to have to ask > >> for help on this topic from those cc'd on this email. (Adding Hans > >> Verkuil, as I value his opinion for controls and dealing with video > >> standards in high regard) > >> > >> Personally, I don't quite understand why we would need to add such > >> controls NOW, while we've supported this video standard for years > >> already. I am not arguing against this in any way, but I dont feel > >> like I'm qualified to accept this addition without hearing the > >> opinions of others first. > >> > >> Can somebody help to shed some light? > >> > >> Cheers, > >> > >> Mike > > > > Mike, > > > > i did discuss this with Dmitri a lot on the list previously. > > > > I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in > > China, to convince him not to do that for the original Philips tuners. > > > > Andy was also pretty active on it, thanks for your help. > > > > However, it is for now only about that TCL MK3, using different filters > > than the original Philips stuff, and their labs have clear results, that > > they can improve SECAM-DK this way for their users. > > Thanks for the comment, Hermann. > > Do you think there is any way that we can automate this without having > to expose an additional user control? > > If you believe that it's necessary, I am fine with adding this, b
Audio drop on saa7134
hermann pitton wrote: Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann OK, I'll try running with audio_debug=1. Could you clarify what you mean by "The kernel audio detection thread must have been started without success or id find the right thing again"? An audio drop can be initiated at any point in the recording. A weak signal is a good guess, but I've never noticed a correlation with video quality. I didn't know about audio_ddep -- what does it do? I'm not seeing it in modinfo. It would be fantastic to get this problem solved -- we've had to record everything in parallel to avoid loss, and still very occasionally lose sound. Cheers, Dave -- 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: cx88: 2 channels on each of 2 cards
Thanks Hermann, hermann pitton wrote: starting point here is, that neither of the now older chips like bt878, saa713x or cx88xx can do two external inputs at the same time on one chip at once. Else, they totally depend on software switching between those external inputs. Ok, I will attempt to correct the implementation in ZoneMinder to allow this. But as I understand it, one channel on each of two cards should work, correct? I'm currently accessing each of /dev/video0 and /dev/video1 this way (single channel on each), and the card accessed second gives no video. I've got the same results with both xawtv and ZoneMinder. Regards Adam Swift -- 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: Reliable work-horse capture device?
Mauro Carvalho Chehab wrote: Em Mon, 14 Sep 2009 21:02:52 -0700 David Liontooth escreveu: As for the ventilation issue for USB devices, that may not be a serious obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable components, we could strip the plastic casing and mount the unit next to a fan inside the case. Yes, this may work. Don't forget that, if you use USB devices, you'll probably need one separate USB buses per each device, due to USB limits in terms of the maximum number of isoc packets per second. If you don't require high quality, you could try to use a format that requires less than 16 bits per pixel or 320x240 pixels, in order to have more than one device per bus. Thanks for pointing this out. I would be happy to use bttv, but I can't find cards. I also need to grab audio off the PCI bus, which only some bttv cards support. We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. saa7134 has a thread to detect audio audio stereo mode. Maybe there is a bug somewhere there. Interesting idea -- anything I can do to debug? Our fallback is ivtv. I was hoping to use USB so that we could get blades instead of 3U cases; it's also getting hard to find good motherboards with four PCI slots. The current best relation in terms of slots is the new cx25821. It has 8 simultaneous inputs at 60 fps per each PCIe board. If you don't need a tuner, this design could be very interesting. The driver was written by Conexant, and it is not yet present on any distribution (I just committed it today - at staging - since it needs some cleanups to match kernel CodingStyle). Wow, that's great to get support for this powerful device. We do need tuners, though -- we're capturing straight from RF television cable. Otherwise a beautiful product, even with h264 compression, which is what we need. Cheers, Dave -- 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: tuner, code for discuss
On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton wrote: > > Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky: >> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov wrote: >> > On Mon, 14 Sep 2009 08:55:22 -0400 >> > Michael Krufky wrote: >> > >> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov >> >> wrote: >> >> > Hi All >> >> > >> >> > This is my next patch. >> >> > >> >> > Changes: >> >> > 1. By default charge pump is ON >> >> > 2. For radio mode charge pump set to OFF >> >> > 3. Set correct AGC value in radio mode >> >> > 4. Add control gain of AGC. >> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for >> >> > read/write gain of AGC. 6. Add some code for control gain from >> >> > saa7134 part. By default this control is OFF 7. When TV card can >> >> > manipulate this control, enable it. >> >> > >> >> > Main changes is control value of AGC TOP in .initdata = >> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq >> >> > of TV. >> >> > >> >> > I don't understand how to correct call new function for read/write >> >> > value of AGC TOP. >> >> > >> >> > What you think about it?? >> >> > >> >> >> >> [patch snipped] >> >> >> >> > >> >> > >> >> > With my best regards, Dmitry. >> >> >> >> Dmitry, >> >> >> >> The direct usage of .initdata and .sleepdata is probably unnecessary >> >> here -- If you trace how the tuner-simple driver works, you'll find >> >> that simply having these fields defined will cause these bytes to be >> >> written at the appropriate moment. >> >> >> >> However, for the actual sake of setting this gain value, I'm not sure >> >> that initdata / sleep data is the right place for it either. (I know >> >> that I recommended something like this at first, but at the time I >> >> didn't realize that there is a range of six acceptable values for this >> >> field) >> >> >> >> What I would still like to understand is: Who will be changing this >> >> value? I see that you've added a control to the saa7134 driver -- is >> >> this to be manipulated from userspace? >> > >> > Yes >> > >> >> Under what conditions will somebody want to change this value? >> > >> > for SECAM with strong signal we have wide white crap on the screen. >> > Need reduce value of AGC TOP. >> > >> > For weak signal need increase value of AGC TOP >> > Ajust value of AGC TOP can get more better image quality. >> > >> >> How will users know that they need to alter this gain value? >> > >> > By default use value from .initdata >> > v4l2-ctl can modify this value or via some plugins for TV wach programm. >> > >> > End-user programm for watch TV IMHO now is very poor. >> > >> > With my best regards, Dmitry. >> > >> >> I have to admit that I am not familiar enough with SECAM myself to see >> this kind of trouble. For NTSC and PAL, tvtime is a great application >> -- the only shortcoming that bothers me about tvtime is lack of audio >> support. One must rely on a separate mechanism to hear audio, whether >> it's a patch cable from the tv tuner to the sound board, or a separate >> application decoding DMA audio. ...but that is not what this email >> thread is about. >> >> As far as simple tuning and analog television viewing goes, tvtime >> rocks. Is it really that difficult for SECAM users? >> >> In summary, you are telling us that we need to add userspace controls >> to handle gain control, for tuning SECAM. I am going to have to ask >> for help on this topic from those cc'd on this email. (Adding Hans >> Verkuil, as I value his opinion for controls and dealing with video >> standards in high regard) >> >> Personally, I don't quite understand why we would need to add such >> controls NOW, while we've supported this video standard for years >> already. I am not arguing against this in any way, but I dont feel >> like I'm qualified to accept this addition without hearing the >> opinions of others first. >> >> Can somebody help to shed some light? >> >> Cheers, >> >> Mike > > Mike, > > i did discuss this with Dmitri a lot on the list previously. > > I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in > China, to convince him not to do that for the original Philips tuners. > > Andy was also pretty active on it, thanks for your help. > > However, it is for now only about that TCL MK3, using different filters > than the original Philips stuff, and their labs have clear results, that > they can improve SECAM-DK this way for their users. Thanks for the comment, Hermann. Do you think there is any way that we can automate this without having to expose an additional user control? If you believe that it's necessary, I am fine with adding this, but I will need Mauro to agree on it as well -- that's why I'm asking for some argument points. Some questions that he might ask -- why do we need this in the saa7134 driver but not the other drivers? Is this specific to this TCL MK3 only? Could doing this help to improve SECAM support for users of other tuners? Cheers,
Re: tuner, code for discuss
Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky: > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov wrote: > > On Mon, 14 Sep 2009 08:55:22 -0400 > > Michael Krufky wrote: > > > >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov > >> wrote: > >> > Hi All > >> > > >> > This is my next patch. > >> > > >> > Changes: > >> > 1. By default charge pump is ON > >> > 2. For radio mode charge pump set to OFF > >> > 3. Set correct AGC value in radio mode > >> > 4. Add control gain of AGC. > >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for > >> > read/write gain of AGC. 6. Add some code for control gain from > >> > saa7134 part. By default this control is OFF 7. When TV card can > >> > manipulate this control, enable it. > >> > > >> > Main changes is control value of AGC TOP in .initdata = > >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq > >> > of TV. > >> > > >> > I don't understand how to correct call new function for read/write > >> > value of AGC TOP. > >> > > >> > What you think about it?? > >> > > >> > >> [patch snipped] > >> > >> > > >> > > >> > With my best regards, Dmitry. > >> > >> Dmitry, > >> > >> The direct usage of .initdata and .sleepdata is probably unnecessary > >> here -- If you trace how the tuner-simple driver works, you'll find > >> that simply having these fields defined will cause these bytes to be > >> written at the appropriate moment. > >> > >> However, for the actual sake of setting this gain value, I'm not sure > >> that initdata / sleep data is the right place for it either. (I know > >> that I recommended something like this at first, but at the time I > >> didn't realize that there is a range of six acceptable values for this > >> field) > >> > >> What I would still like to understand is: Who will be changing this > >> value? I see that you've added a control to the saa7134 driver -- is > >> this to be manipulated from userspace? > > > > Yes > > > >> Under what conditions will somebody want to change this value? > > > > for SECAM with strong signal we have wide white crap on the screen. > > Need reduce value of AGC TOP. > > > > For weak signal need increase value of AGC TOP > > Ajust value of AGC TOP can get more better image quality. > > > >> How will users know that they need to alter this gain value? > > > > By default use value from .initdata > > v4l2-ctl can modify this value or via some plugins for TV wach programm. > > > > End-user programm for watch TV IMHO now is very poor. > > > > With my best regards, Dmitry. > > > > I have to admit that I am not familiar enough with SECAM myself to see > this kind of trouble. For NTSC and PAL, tvtime is a great application > -- the only shortcoming that bothers me about tvtime is lack of audio > support. One must rely on a separate mechanism to hear audio, whether > it's a patch cable from the tv tuner to the sound board, or a separate > application decoding DMA audio. ...but that is not what this email > thread is about. > > As far as simple tuning and analog television viewing goes, tvtime > rocks. Is it really that difficult for SECAM users? > > In summary, you are telling us that we need to add userspace controls > to handle gain control, for tuning SECAM. I am going to have to ask > for help on this topic from those cc'd on this email. (Adding Hans > Verkuil, as I value his opinion for controls and dealing with video > standards in high regard) > > Personally, I don't quite understand why we would need to add such > controls NOW, while we've supported this video standard for years > already. I am not arguing against this in any way, but I dont feel > like I'm qualified to accept this addition without hearing the > opinions of others first. > > Can somebody help to shed some light? > > Cheers, > > Mike Mike, i did discuss this with Dmitri a lot on the list previously. I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in China, to convince him not to do that for the original Philips tuners. Andy was also pretty active on it, thanks for your help. However, it is for now only about that TCL MK3, using different filters than the original Philips stuff, and their labs have clear results, that they can improve SECAM-DK this way for their users. 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: Reliable work-horse capture device?
Em Mon, 14 Sep 2009 21:02:52 -0700 David Liontooth escreveu: > As for the ventilation issue for USB devices, that may not be a serious > obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable > components, we could strip the plastic casing and mount the unit next to > a fan inside the case. Yes, this may work. Don't forget that, if you use USB devices, you'll probably need one separate USB buses per each device, due to USB limits in terms of the maximum number of isoc packets per second. If you don't require high quality, you could try to use a format that requires less than 16 bits per pixel or 320x240 pixels, in order to have more than one device per bus. > I would be happy to use bttv, but I can't find cards. I also need to > grab audio off the PCI bus, which only some bttv cards support. > > We've been using saa7135 cards for several years with relatively few > incidents, but they occasionally drop audio. > I've been unable to find any pattern in the audio drops, so I haven't > reported it -- I have no way to reproduce the error, but it happens > regularly, affecting between 3 and 5% of recordings. Audio will > sometimes drop in the middle of a recording and then resume, or else > work fine on the next recording. saa7134 has a thread to detect audio audio stereo mode. Maybe there is a bug somewhere there. > Our fallback is ivtv. I was hoping to use USB so that we could get > blades instead of 3U cases; it's also getting hard to find good > motherboards with four PCI slots. The current best relation in terms of slots is the new cx25821. It has 8 simultaneous inputs at 60 fps per each PCIe board. If you don't need a tuner, this design could be very interesting. The driver was written by Conexant, and it is not yet present on any distribution (I just committed it today - at staging - since it needs some cleanups to match kernel CodingStyle). 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: Reliable work-horse capture device?
Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: > Mauro Carvalho Chehab wrote: > > Hi David, > > > > Em Mon, 14 Sep 2009 19:41:13 -0700 > > David Liontooth escreveu: > > > > > >> We're setting up NTSC cable television capture devices in a handfull of > >> remote locations, using four devices to capture around fifty hours a day > >> on each location. Capture is scripted and will be ongoing for several > >> years. We want to minimize the need for human intervention. > >> > >> I'm looking for advice on which capture device to use. My main > >> candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of > >> the supported USB devices. > >> > >> Are there USB devices that are sufficiently reliable to hold up under > >> continuous capture for years? Are the drivers robust? > >> > >> I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just > >> now adding it to em28xx. Do any other USB device chipsets have raw > >> closed captioning support? > >> > >> I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, > >> but I need analog support. > >> > >> Appreciate any advice. > >> > > > > If you look for stability, the most important item is to choose a good > > stable > > server distribution, like RHEL5. You'll be better serviced than using a > > desktop > > distro with some new (not so stable) kernel and tools. > > > > In terms of stability, the PCI devices are generally more reliable, and, > > among > > all drivers, bttv is the winner, since it is the older driver, so, in > > thesis, > > more bugs were solved on it. That's the reason why several surveillance > > systems > > are still today based on bttv. If you need a newer hardware, then you may > > choose > > saa7134, cx88 or ivtv devices. > > > > I don't recommend using an USB hardware for such hard usage: it will > > probably > > have a shorter life (since it is not as ventilated as a PCI device on a > > server cabinet), and you might experience troubles after long plays. In > > terms > > of USB with analog support, em28xx driver is the more stable, and we > > recently > > fixed some bugs on it, related to memory consumption along the time (it > > used to > > forget to free memory, resulting on crashes, after several stream > > start/stop's). > > > > There's a tool at v4l2-apps/test made to stress a video driver, made by > > Douglas. I suggest that you should run it with the board you'll choose to be > > sure that you won't have memory garbage along driver usage. > > > > Cheers, > > Mauro > > > Thank you, Mauro! I much appreciate the advice. > > I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos > goes to Devin Heitmueller for great work on this. > > As for the ventilation issue for USB devices, that may not be a serious > obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable > components, we could strip the plastic casing and mount the unit next to > a fan inside the case. > > Memory leaks would be a serious problem on the other hand; thank you for > pointing to the stress test. > > I would be happy to use bttv, but I can't find cards. I also need to > grab audio off the PCI bus, which only some bttv cards support. > > We've been using saa7135 cards for several years with relatively few > incidents, but they occasionally drop audio. > I've been unable to find any pattern in the audio drops, so I haven't > reported it -- I have no way to reproduce the error, but it happens > regularly, affecting between 3 and 5% of recordings. Audio will > sometimes drop in the middle of a recording and then resume, or else > work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann > Our fallback is ivtv. I was hoping to use USB so that we could get > blades instead of 3U cases; it's also getting hard to find good > motherboards with four PCI slots. > > Cheers, > Dave > -- 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: tuner, code for discuss
On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov wrote: > On Mon, 14 Sep 2009 08:55:22 -0400 > Michael Krufky wrote: > >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov >> wrote: >> > Hi All >> > >> > This is my next patch. >> > >> > Changes: >> > 1. By default charge pump is ON >> > 2. For radio mode charge pump set to OFF >> > 3. Set correct AGC value in radio mode >> > 4. Add control gain of AGC. >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for >> > read/write gain of AGC. 6. Add some code for control gain from >> > saa7134 part. By default this control is OFF 7. When TV card can >> > manipulate this control, enable it. >> > >> > Main changes is control value of AGC TOP in .initdata = >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq >> > of TV. >> > >> > I don't understand how to correct call new function for read/write >> > value of AGC TOP. >> > >> > What you think about it?? >> > >> >> [patch snipped] >> >> > >> > >> > With my best regards, Dmitry. >> >> Dmitry, >> >> The direct usage of .initdata and .sleepdata is probably unnecessary >> here -- If you trace how the tuner-simple driver works, you'll find >> that simply having these fields defined will cause these bytes to be >> written at the appropriate moment. >> >> However, for the actual sake of setting this gain value, I'm not sure >> that initdata / sleep data is the right place for it either. (I know >> that I recommended something like this at first, but at the time I >> didn't realize that there is a range of six acceptable values for this >> field) >> >> What I would still like to understand is: Who will be changing this >> value? I see that you've added a control to the saa7134 driver -- is >> this to be manipulated from userspace? > > Yes > >> Under what conditions will somebody want to change this value? > > for SECAM with strong signal we have wide white crap on the screen. > Need reduce value of AGC TOP. > > For weak signal need increase value of AGC TOP > Ajust value of AGC TOP can get more better image quality. > >> How will users know that they need to alter this gain value? > > By default use value from .initdata > v4l2-ctl can modify this value or via some plugins for TV wach programm. > > End-user programm for watch TV IMHO now is very poor. > > With my best regards, Dmitry. > I have to admit that I am not familiar enough with SECAM myself to see this kind of trouble. For NTSC and PAL, tvtime is a great application -- the only shortcoming that bothers me about tvtime is lack of audio support. One must rely on a separate mechanism to hear audio, whether it's a patch cable from the tv tuner to the sound board, or a separate application decoding DMA audio. ...but that is not what this email thread is about. As far as simple tuning and analog television viewing goes, tvtime rocks. Is it really that difficult for SECAM users? In summary, you are telling us that we need to add userspace controls to handle gain control, for tuning SECAM. I am going to have to ask for help on this topic from those cc'd on this email. (Adding Hans Verkuil, as I value his opinion for controls and dealing with video standards in high regard) Personally, I don't quite understand why we would need to add such controls NOW, while we've supported this video standard for years already. I am not arguing against this in any way, but I dont feel like I'm qualified to accept this addition without hearing the opinions of others first. Can somebody help to shed some light? Cheers, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
saa7134 and soft SPI bus
Hi All. Our new TV card has MPEG-2 encoder NEC µPD61151. This encoder hasn't I2C bus, only SPI. Can you point me how to make software SPI bus via GPIO of the saa7134. Better way for do it. With my best regards, Dmitry. -- 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: tuner, code for discuss
On Mon, 14 Sep 2009 08:55:22 -0400 Michael Krufky wrote: > On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov > wrote: > > Hi All > > > > This is my next patch. > > > > Changes: > > 1. By default charge pump is ON > > 2. For radio mode charge pump set to OFF > > 3. Set correct AGC value in radio mode > > 4. Add control gain of AGC. > > 5. New function simple_get_tv_gain and simple_set_tv_gain for > > read/write gain of AGC. 6. Add some code for control gain from > > saa7134 part. By default this control is OFF 7. When TV card can > > manipulate this control, enable it. > > > > Main changes is control value of AGC TOP in .initdata = > > tua603x_agc112 array. Use this value for set AGC TOP after set freq > > of TV. > > > > I don't understand how to correct call new function for read/write > > value of AGC TOP. > > > > What you think about it?? > > > > [patch snipped] > > > > > > > With my best regards, Dmitry. > > Dmitry, > > The direct usage of .initdata and .sleepdata is probably unnecessary > here -- If you trace how the tuner-simple driver works, you'll find > that simply having these fields defined will cause these bytes to be > written at the appropriate moment. > > However, for the actual sake of setting this gain value, I'm not sure > that initdata / sleep data is the right place for it either. (I know > that I recommended something like this at first, but at the time I > didn't realize that there is a range of six acceptable values for this > field) > > What I would still like to understand is: Who will be changing this > value? I see that you've added a control to the saa7134 driver -- is > this to be manipulated from userspace? Yes > Under what conditions will somebody want to change this value? for SECAM with strong signal we have wide white crap on the screen. Need reduce value of AGC TOP. For weak signal need increase value of AGC TOP Ajust value of AGC TOP can get more better image quality. > How will users know that they need to alter this gain value? By default use value from .initdata v4l2-ctl can modify this value or via some plugins for TV wach programm. End-user programm for watch TV IMHO now is very poor. With my best regards, Dmitry. -- 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: Reliable work-horse capture device?
Mauro Carvalho Chehab wrote: Hi David, Em Mon, 14 Sep 2009 19:41:13 -0700 David Liontooth escreveu: We're setting up NTSC cable television capture devices in a handfull of remote locations, using four devices to capture around fifty hours a day on each location. Capture is scripted and will be ongoing for several years. We want to minimize the need for human intervention. I'm looking for advice on which capture device to use. My main candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of the supported USB devices. Are there USB devices that are sufficiently reliable to hold up under continuous capture for years? Are the drivers robust? I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just now adding it to em28xx. Do any other USB device chipsets have raw closed captioning support? I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, but I need analog support. Appreciate any advice. If you look for stability, the most important item is to choose a good stable server distribution, like RHEL5. You'll be better serviced than using a desktop distro with some new (not so stable) kernel and tools. In terms of stability, the PCI devices are generally more reliable, and, among all drivers, bttv is the winner, since it is the older driver, so, in thesis, more bugs were solved on it. That's the reason why several surveillance systems are still today based on bttv. If you need a newer hardware, then you may choose saa7134, cx88 or ivtv devices. I don't recommend using an USB hardware for such hard usage: it will probably have a shorter life (since it is not as ventilated as a PCI device on a server cabinet), and you might experience troubles after long plays. In terms of USB with analog support, em28xx driver is the more stable, and we recently fixed some bugs on it, related to memory consumption along the time (it used to forget to free memory, resulting on crashes, after several stream start/stop's). There's a tool at v4l2-apps/test made to stress a video driver, made by Douglas. I suggest that you should run it with the board you'll choose to be sure that you won't have memory garbage along driver usage. Cheers, Mauro Thank you, Mauro! I much appreciate the advice. I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos goes to Devin Heitmueller for great work on this. As for the ventilation issue for USB devices, that may not be a serious obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable components, we could strip the plastic casing and mount the unit next to a fan inside the case. Memory leaks would be a serious problem on the other hand; thank you for pointing to the stress test. I would be happy to use bttv, but I can't find cards. I also need to grab audio off the PCI bus, which only some bttv cards support. We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Our fallback is ivtv. I was hoping to use USB so that we could get blades instead of 3U cases; it's also getting hard to find good motherboards with four PCI slots. Cheers, Dave -- 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/em28xx-vbi-codingstyle/
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/em28xx-vbi-codingstyle/ for the codingstyle fixes for my em28xx VBI support: em28xx: remove text editor tags from em28xx-vbi.c em28xx: fix codingstyle issues in em28xx-video.c em28xx: fix codingstyle issues introduced with VBI support 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: Reliable work-horse capture device?
Hi David, Em Mon, 14 Sep 2009 19:41:13 -0700 David Liontooth escreveu: > > We're setting up NTSC cable television capture devices in a handfull of > remote locations, using four devices to capture around fifty hours a day > on each location. Capture is scripted and will be ongoing for several > years. We want to minimize the need for human intervention. > > I'm looking for advice on which capture device to use. My main > candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of > the supported USB devices. > > Are there USB devices that are sufficiently reliable to hold up under > continuous capture for years? Are the drivers robust? > > I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just > now adding it to em28xx. Do any other USB device chipsets have raw > closed captioning support? > > I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, > but I need analog support. > > Appreciate any advice. If you look for stability, the most important item is to choose a good stable server distribution, like RHEL5. You'll be better serviced than using a desktop distro with some new (not so stable) kernel and tools. In terms of stability, the PCI devices are generally more reliable, and, among all drivers, bttv is the winner, since it is the older driver, so, in thesis, more bugs were solved on it. That's the reason why several surveillance systems are still today based on bttv. If you need a newer hardware, then you may choose saa7134, cx88 or ivtv devices. I don't recommend using an USB hardware for such hard usage: it will probably have a shorter life (since it is not as ventilated as a PCI device on a server cabinet), and you might experience troubles after long plays. In terms of USB with analog support, em28xx driver is the more stable, and we recently fixed some bugs on it, related to memory consumption along the time (it used to forget to free memory, resulting on crashes, after several stream start/stop's). There's a tool at v4l2-apps/test made to stress a video driver, made by Douglas. I suggest that you should run it with the board you'll choose to be sure that you won't have memory garbage along driver usage. 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
Reliable work-horse capture device?
We're setting up NTSC cable television capture devices in a handfull of remote locations, using four devices to capture around fifty hours a day on each location. Capture is scripted and will be ongoing for several years. We want to minimize the need for human intervention. I'm looking for advice on which capture device to use. My main candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of the supported USB devices. Are there USB devices that are sufficiently reliable to hold up under continuous capture for years? Are the drivers robust? I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just now adding it to em28xx. Do any other USB device chipsets have raw closed captioning support? I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, but I need analog support. Appreciate any advice. Dave -- 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
[GIT PATCHES for 2.6.32] V4L/DVB updates
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the first set of patches for 2.6.32. During this cycle, we avoided to make lots of changes at core, in order to have the system more stable, since there were lots of internal API changes merged during 2.6.31 window. In summary, this series have: - New tuner/frontend driver for ce5039/zl10039; - New webcam driver: jeilinj; - radio si4713 were broken into a common part and an usb part, to allow its usage with some different devices; - IR standardization: use a more uniform mapping for IR keys along different video boards; - dvb-usb: allow dynamic IR key table replacement; - As usual, lots of cleanups, new board additions, driver improvements and fixes. Cheers, Mauro. --- Documentation/video4linux/CARDLIST.cx23885 |2 + Documentation/video4linux/CARDLIST.cx88 |1 + Documentation/video4linux/CARDLIST.em28xx|5 +- Documentation/video4linux/CARDLIST.saa7134 |4 + Documentation/video4linux/CARDLIST.tuner |1 + Documentation/video4linux/CQcam.txt |4 +- Documentation/video4linux/gspca.txt |6 + Documentation/video4linux/si4713.txt | 176 + drivers/media/common/ir-functions.c | 15 +- drivers/media/common/ir-keymaps.c| 5022 -- drivers/media/common/tuners/tda18271-fe.c| 20 +- drivers/media/common/tuners/tda18271-priv.h | 20 +- drivers/media/common/tuners/tda18271.h |3 + drivers/media/common/tuners/tuner-simple.c |6 + drivers/media/common/tuners/tuner-types.c| 25 + drivers/media/dvb/Kconfig| 13 + drivers/media/dvb/b2c2/flexcop-fe-tuner.c| 218 +- drivers/media/dvb/bt8xx/dst.c|2 +- drivers/media/dvb/dm1105/dm1105.c| 150 +- drivers/media/dvb/dvb-core/dmxdev.c | 231 +- drivers/media/dvb/dvb-core/dmxdev.h |9 +- drivers/media/dvb/dvb-core/dvb_demux.c |8 +- drivers/media/dvb/dvb-core/dvb_frontend.c| 35 +- drivers/media/dvb/dvb-core/dvbdev.h |5 + drivers/media/dvb/dvb-usb/Kconfig|6 +- drivers/media/dvb/dvb-usb/a800.c | 68 +- drivers/media/dvb/dvb-usb/af9005-remote.c| 76 +- drivers/media/dvb/dvb-usb/af9015.c | 20 +- drivers/media/dvb/dvb-usb/af9015.h | 460 +- drivers/media/dvb/dvb-usb/anysee.c | 92 +- drivers/media/dvb/dvb-usb/cinergyT2-core.c | 74 +- drivers/media/dvb/dvb-usb/cinergyT2-fe.c |1 + drivers/media/dvb/dvb-usb/cxusb.c| 260 +- drivers/media/dvb/dvb-usb/dib0700_devices.c | 387 +- drivers/media/dvb/dvb-usb/dibusb-common.c| 244 +- drivers/media/dvb/dvb-usb/dibusb-mc.c| 10 +- drivers/media/dvb/dvb-usb/digitv.c | 114 +- drivers/media/dvb/dvb-usb/dtt200u.c | 36 +- drivers/media/dvb/dvb-usb/dvb-usb-i2c.c |2 +- drivers/media/dvb/dvb-usb/dvb-usb-ids.h |6 + drivers/media/dvb/dvb-usb/dvb-usb-remote.c | 73 +- drivers/media/dvb/dvb-usb/dvb-usb.h | 17 +- drivers/media/dvb/dvb-usb/dw2102.c | 403 ++- drivers/media/dvb/dvb-usb/m920x.c| 68 +- drivers/media/dvb/dvb-usb/nova-t-usb2.c | 97 +- drivers/media/dvb/dvb-usb/opera1.c | 55 +- drivers/media/dvb/dvb-usb/vp702x.c |6 +- drivers/media/dvb/dvb-usb/vp7045.c | 102 +- drivers/media/dvb/firewire/firedtv-avc.c | 143 +- drivers/media/dvb/frontends/Kconfig |7 + drivers/media/dvb/frontends/Makefile |1 + drivers/media/dvb/frontends/cx22700.c|2 +- drivers/media/dvb/frontends/cx24113.c|6 +- drivers/media/dvb/frontends/cx24123.c|2 +- drivers/media/dvb/frontends/dib0070.c|2 +- drivers/media/dvb/frontends/dib7000p.c |2 +- drivers/media/dvb/frontends/dvb-pll.c| 75 + drivers/media/dvb/frontends/dvb-pll.h|4 + drivers/media/dvb/frontends/lgs8gxx.c| 484 ++- drivers/media/dvb/frontends/lgs8gxx.h| 11 +- drivers/media/dvb/frontends/lgs8gxx_priv.h | 12 +- drivers/media/dvb/frontends/mt312.c |7 +- drivers/media/dvb/frontends/stb6100.c|4 +- drivers/media/dvb/frontends/stv0900_core.c |8 +- drivers/media/dvb/frontends/stv0900_sw.c |2 +- drivers/media/dvb/frontends/stv6110.c| 48 +- drivers/media/dvb/frontends/stv6110.h|2 +- drivers/media/dvb/frontends/tda10021.c |2 +- drivers/media/dvb/frontends/tda8261.c|4 +- drivers/media/dvb/fronte
saa7134 - radio broken for v4l1 apps - was - Re: Problems with Pinnacle 310i (saa7134) and recent kernels
Hi, Am Montag, den 14.09.2009, 08:24 +0200 schrieb Hans Verkuil: > On Monday 14 September 2009 00:42:16 hermann pitton wrote: > > Hi, > > > > Am Sonntag, den 13.09.2009, 12:02 + schrieb Avl Jawrowski: > > > Hi, > > > > > > hermann pitton arcor.de> writes: > > > [snip] > > > > > > The only other issue I'm aware of is that radio is broken since guessed > > > > 8 weeks on my tuners, only realized when testing on enabling external > > > > active antenna voltage for DVB-T on a/some 310i. > > > > > > > > Might be anything, hm, hopefully I should not have caused it ;) > > > > > > The radio works for me, even if there's much noise (I don't usually use > > > it). > > > I'm using the internal audio cable. > > > > The radio is broken for all tuners, you must be on older stuff. > > > > I finally found the time to do the mercurial bisect today. > > > > It is broken since Hans' changeset 12429 on seventh August. > > What are the symptoms? What application do you use to test the radio? > I don't immediately see why that changeset would break radio support as > it only affects VIDIOC_G_STD and VIDIOC_G_PARM. > > Regards, > > Hans Hans, it are indeed only the v4l1 apps like radio, qtradio, gnomeradio and fm from fmtools. Avl is right, mplayer does still work and also kradio. So the trouble happens in the v4l1 compat layer. Symptoms are, that you just have loud static noise and tuning has not any effect. Also no signal and/or stereo detection. "fm" gives now "ioctl VIDIOCGTUNER: Invalid argument". qtradio Using v4l Video4Linux detected 87 - 108 SIGNAL = 0 SIGNAL = 0 VIDIOCGAUDIO: Ungültiger Dateideskriptor VIDIOCSAUDIO: Ungültiger Dateideskriptor VIDIOCGAUDIO: Ungültiger Dateideskriptor VIDIOCSAUDIO: Ungültiger Dateideskriptor Tested on old style simple tuners, some tda9887 stuff and tda8275a/tda8290/saa7131e, on both x86 and x86_64, with some 2.6.29 and some 2.6.30. 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: [Bugme-new] [Bug 14174] New: floppy drive not usable more than one time after reboot - kernel panic with active DVB
Em Mon, 14 Sep 2009 15:13:40 -0700 Andrew Morton escreveu: > Dunno about the floppy problem but this photo you took: > https://bugzillafiles.novell.org/attachment.cgi?id=318005 > shows a good solid oops in dvb_dmx_memcopy(). I suspect that this is a bug caused by the lack of a memory barrier, already corrected by dda06a8e4610757def753ee3a541a0b1a1feb36b. -- 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: Problems with Pinnacle 310i (saa7134) and recent kernels
Hi, Am Montag, den 14.09.2009, 13:32 + schrieb Avl Jawrowski: > Hi, > > hermann pitton arcor.de> writes: > > > no, in this case I meant mplayer should work for you too. > > You need to have DVB support enabled and a channels.conf file in > > ~/.mplayer. > > It's compiled with --enable-dvbhead, and the channels.conf is made by w_scan, > but I tried even with a made by scan one. mplayer works on all my cards including the 310i for DVB-T and DVB-S since years. Guess you miss something or have a broken checkout. > > We might collect pictures of the cards and remotes as well. > > To identify those card with an additional LNA circuitry is likely not > > easy hardware wise, since the tuner shielding is soldered with 16 pins, > > many close to lines. Maybe we can identify those boards by the card > > revision printed on them. Don't know how to auto detect them. > > I will post some photos. Best is to add them to the wiki, else upload somewhere else or post off list. > > > In the matter of the IR, the modules seems to be loaded: > > > > > > tda1004x 13048 1 > > > saa7134_dvb20772 0 > > > videobuf_dvb5644 1 saa7134_dvb > > > ir_kbd_i2c 5500 0 > > > tda827x 8880 2 > > > tuner 16960 1 > > > saa7134 138436 1 saa7134_dvb > > > ir_common 41828 2 ir_kbd_i2c,saa7134 > > > videobuf_dma_sg 9876 2 saa7134_dvb,saa7134 > > > videobuf_core 13596 3 videobuf_dvb,saa7134,videobuf_dma_sg > > > tveeprom 10488 1 saa7134 > > > > > > But I can't find anything in /proc/bus/input/devices. > > > > We might have more than the two supported remotes on such cards. > > After all that would not make me wonder anymore and the windows driver > > presents some more. Do you have that silver remote with colored buttons. > > There must be a device at 0x47 detected to support it. > > Yes that is: http://www.hwp.ru/Tvtuners/Pinnaclehybridpro.pci > /Pinnaclepctvhybridpropci-1sm.jpg Remote and IR sensor look the same like mine on the 310i, but they still might have changed something and you are by far not the first reporting the remote not working on newer devices. BTW, mine seems not to work on vista with the Pinnacle media software. > > You might have to load ir-kbd-i2c at first or reload saa7134-alsa and > > saa7134-dvb, which includes saa7134. > > I've unloaded all modules, then loaded first ir-kbd-i2c and next saa7134-dvb, > but I can't see any difference. > Loading saa7134 with ir_debug=1 and i2c_debug=1 I can see some of these > errors: > > saa7133[0]: i2c xfer: < 8e ERROR: NO_DEVICE Here is the problem. The supported cards do have the i2c chip at 0x47 or 0x8e in 8bit notation. Needs closer investigation. > saa7133[0]: i2c xfer: < e2 ERROR: NO_DEVICE > saa7133[0]: i2c xfer: < 5a ERROR: NO_DEVICE > > > > > The only other issue I'm aware of is that radio is broken since guessed > > > > 8 weeks on my tuners, only realized when testing on enabling external > > > > active antenna voltage for DVB-T on a/some 310i. > > > > > > > > Might be anything, hm, hopefully I should not have caused it ;) > > > > > > The radio works for me, even if there's much noise (I don't usually use > > > it). > > > I'm using the internal audio cable. > > > > The radio is broken for all tuners, you must be on older stuff. > > Using 2.6.31 and mplayer it really works for me. Ah, thanks. Should have thought about it. Most radio apps are still v4l1. Mplayer indeed works, tested with saa7134-alsa, as does "kradio", just installed it again, both are v4l2. > > I finally found the time to do the mercurial bisect today. > > > > It is broken since Hans' changeset 12429 on seventh August. So only all the v4l1 apps are broken. 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: [Bugme-new] [Bug 14174] New: floppy drive not usable more than one time after reboot - kernel panic with active DVB
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sun, 13 Sep 2009 15:08:21 GMT bugzilla-dae...@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=14174 > >Summary: floppy drive not usable more than one time after > reboot - kernel panic with active DVB >Product: IO/Storage >Version: 2.5 > Kernel Version: 2.6.27.29-0.1-vanilla x86_64 SMP > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: io_ot...@kernel-bugs.osdl.org > ReportedBy: alexander.koe...@koenig-a.de > Regression: No > > > This bug report is afollow-up of my report already posted in the OPENSuse > bugzilla at https://bugzilla.novell.com/show_bug.cgi?id=421732 > You can find detailed information of my hardware and software configuration > there. > > Short System description: > - CPU: AMD Phenom X4 9550 4x2.2GHz (95W) 65nm Quad Core > - Memory: 4GB - 2x2048MB DDR2-800 CL5, Dual Channel 2x1024MB > - Motherboard: GIGABYTE GA-MA770-DS3 > - Graphics NVidia GeForce 7300 GS, 256MB, TV-Out, DVI, PCIe > - Floppy: 1.44MB > - 1. hard disk:500GB Seagate 7200 RPM SATA II > - 2. hard disk:500GB Seagate 7200 RPM SATA II > - DVD-ROM: Optiarc DDU 1615 16x/48x, IDE > - DVD-RW: NEC AD-7200, IDE > - SCSI-Controller: Adaptec 2940 SCSI adapter,SCSI ID: 7 > - DVB controller: Technotrend/Hauppauge DVB card rev2.1 > > Symptoms: > The first command to the floppy drive after re-boot seems to work, all > subsequent access to the floppy drive - with the same disk or with any other - > fail (floppy LED is on, floppy drive moves, but no positive result). See log > of > a terminal session below: > > alexa...@asterix:~> mdir > Volume in drive A has no label > Volume Serial Number is 2828-50E1 > Directory for A:/ > > autoexec bat 1142 1998-05-15 20:01 autoexec.bat > setramd bat 881 1998-05-15 20:01 setramd.bat > findramd exe 6855 1998-05-15 20:01 findramd.exe > aspi4dos sys 14386 1998-05-15 20:01 aspi4dos.sys > aspicd sys 29620 1998-05-15 20:01 aspicd.sys > aspi2dos sys 35330 1998-05-15 20:01 aspi2dos.sys > aspi8u2 sys 40792 1998-05-15 20:01 aspi8u2.sys > extract exe 93242 1998-05-15 20:01 extract.exe > drvspace bin 69079 1998-05-15 20:01 drvspace.bin > himemsys 33447 1998-05-15 20:01 himem.sys > ebd cab276324 1998-05-15 20:01 ebd.cab > country sys 30742 1998-05-15 20:01 country.sys > mode com 29815 1998-05-15 20:01 mode.com > keyb com 20023 1998-05-15 20:01 keyb.com > ebd sys 0 2000-01-08 10:09 ebd.sys > io sys222390 1998-05-15 20:01 io.sys > config sys 860 2003-11-16 0:26 config.sys > readme txt 16216 1998-05-15 20:01 readme.txt > ramdrive sys 12823 1998-05-15 20:01 ramdrive.sys > btcdrom sys 21971 1998-05-15 20:01 btcdrom.sys > btdosm sys 30955 1998-05-15 20:01 btdosm.sys > aspi8dos sys 37564 1998-05-15 20:01 aspi8dos.sys > flashpt sys 64425 1998-05-15 20:01 flashpt.sys > fdiskexe 64956 1998-05-15 20:01 fdisk.exe > command com 96360 1998-05-15 20:01 command.com > oakcdrom sys 41302 1998-05-15 20:01 oakcdrom.sys > display sys 17191 1998-05-15 20:01 display.sys > ega cpi 58870 1998-05-15 20:01 ega.cpi > keyboard sys 34566 1998-05-15 20:01 keyboard.sys > msdossys 9 2000-01-08 10:09 msdos.sys > toshv224 sys 13720 2003-11-16 0:24 toshv224.sys >31 files 1 415 856 bytes > 33 792 bytes free > > alexa...@asterix:~> mdir > init A: non DOS media > Cannot initialize 'A:' > alexa...@asterix:~> mdir > init A: non DOS media > Cannot initialize 'A:' > alexa...@asterix:~> mount /media/floppy > mount: blockorientiertes Ger__t /dev/fd0 ist schreibgesch__tzt, wird > eingeh__ngt > im Nur-Lese-Modus > mount: konnte Dateisystemtyp nicht feststellen, und es wurde keiner angegeben > ---> floppy removed from drive <--- > alexa...@asterix:~> mount /media/floppy > mount: /dev/fd0 ist kein g__ltiges blockorientiertes Ger__t > ---> inserted another floppy into the drive <--- > alexa...@asterix:~> mount /media/floppy > mount: blockorientiertes Ger__t /dev/fd0 ist schreibgesch__tzt, wird > eingeh__ngt > im Nur-Lese-Modus > mount: konnte Dateisystemtyp nicht feststellen, und es wurde keiner angegeben > ---> removed floppy from drive <--- > alexa...@asterix:~> mdir > Can't open /dev/fd0: No such device or address > Cannot initialize 'A:' > ---> inserted floppy into drive <--- > alexa...@asterix:~> mdir > init A: non DOS media > Cannot initialize 'A:' > alexa...@asterix:~> mdir > init A: non DOS media > Can
Re: V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
On Mon, Sep 14, 2009 at 11:50:50PM +0200, Jiri Slaby wrote:
> A potential problem here is rather that it may wait longer due to
> returning 1 jiffie. It's then timeout * 1000 * 1. On 250HZ system it
> makes a difference of multiple of 4. Don't think it's a real issue in
> those drivers at all, but it's worth fixing. Care to post a patch?
*sigh*. :) OK, last thing to be done this day.
Generated via precise copy&paste of the change between drivers
(which is a flashing warning that they likely contain too much c&p anyway),
plus:
for file in sn9c102/sn9c102_core.c et61x251/et61x251_core.c
zc0301/zc0301_core.c; do diff -upN
linux-2.6.31/drivers/media/video/"$file"
linux-2.6.31.patched/drivers/media/video/"$file" >>
/tmp/v4l2_drivers.diff; done
Disclaimer: FULLY UNTESTED, make sure to guard your hen house, use as dog food.
ChangeLog:
Correct dangerous and inefficient msecs_to_jiffies() calculation in some V4L2
drivers
Signed-off-by: Andreas Mohr
--- linux-2.6.31/drivers/media/video/sn9c102/sn9c102_core.c 2009-09-10
00:13:59.0 +0200
+++ linux-2.6.31.patched/drivers/media/video/sn9c102/sn9c102_core.c
2009-09-14 23:58:27.0 +0200
@@ -1954,8 +1954,10 @@ sn9c102_read(struct file* filp, char __u
(!list_empty(&cam->outqueue)) ||
(cam->state & DEV_DISCONNECTED) ||
(cam->state & DEV_MISCONFIGURED),
- cam->module_param.frame_timeout *
- 1000 * msecs_to_jiffies(1) );
+ msecs_to_jiffies(
+ cam->module_param.frame_timeout * 1000
+ )
+ );
if (timeout < 0) {
mutex_unlock(&cam->fileop_mutex);
return timeout;
--- linux-2.6.31/drivers/media/video/et61x251/et61x251_core.c 2009-09-10
00:13:59.0 +0200
+++ linux-2.6.31.patched/drivers/media/video/et61x251/et61x251_core.c
2009-09-14 23:58:54.0 +0200
@@ -1379,8 +1379,10 @@ et61x251_read(struct file* filp, char __
(!list_empty(&cam->outqueue)) ||
(cam->state & DEV_DISCONNECTED) ||
(cam->state & DEV_MISCONFIGURED),
- cam->module_param.frame_timeout *
- 1000 * msecs_to_jiffies(1) );
+ msecs_to_jiffies(
+ cam->module_param.frame_timeout * 1000
+ )
+ );
if (timeout < 0) {
mutex_unlock(&cam->fileop_mutex);
return timeout;
--- linux-2.6.31/drivers/media/video/zc0301/zc0301_core.c 2009-09-10
00:13:59.0 +0200
+++ linux-2.6.31.patched/drivers/media/video/zc0301/zc0301_core.c
2009-09-15 00:00:14.0 +0200
@@ -819,8 +819,10 @@ zc0301_read(struct file* filp, char __us
(!list_empty(&cam->outqueue)) ||
(cam->state & DEV_DISCONNECTED) ||
(cam->state & DEV_MISCONFIGURED),
- cam->module_param.frame_timeout *
- 1000 * msecs_to_jiffies(1) );
+ msecs_to_jiffies(
+ cam->module_param.frame_timeout * 1000
+ )
+ );
if (timeout < 0) {
mutex_unlock(&cam->fileop_mutex);
return timeout;
--
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: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 sensor
Dne Po 14. září 2009 23:21:33 Guennadi Liakhovetski napsal(a): > On Mon, 14 Sep 2009, Marek Vasut wrote: > > Dne Po 14. září 2009 22:30:41 Guennadi Liakhovetski napsal(a): > > > On Mon, 14 Sep 2009, Marek Vasut wrote: > > > > Dne Po 14. září 2009 21:29:26 Guennadi Liakhovetski napsal(a): > > > > > From: Marek Vasut > > > > > > > > > > Signed-off-by: Marek Vasut > > > > > Signed-off-by: Guennadi Liakhovetski > > > > > --- > > > > > > > > > > Marek, please confirm, that this version is ok. I'll push it > > > > > upstream for 2.6.32 then. > > > > > > > > No, it's not OK. You removed the RGB part. Either enclose those parts > > > > into ifdef OV9640_RGB_BUGGY or preserve it in some other way. Someone > > > > will certainly want to re-add RGB parts later and will have to figure > > > > it out all over again. > > > > > > Ok, make a proposal, how you would like to see it. But - I do not want > > > commented out code, including "#ifdef MACRO_THAT_DOESNT_GET_DEFINED." I > > > think, I described it in sufficient detail, so that re-adding that code > > > should not take longer than 10 minutes for anyone sufficiently familiar > > > with the code. Referencing another driver also has an advantage, that > > > if we switch to imagebus or any other API, you don't get stale > > > commented out code, but you look up updated code in a functional > > > driver. But I am open to your ideas / but no commented out code, > > > please. > > > > The RGB is broken only in a way where it swaps colours, the color matrix > > coeficients and register configurations are OK (which is what other > > people who will want to add it will need to figure out again from scratch > > if you remove the code). > > Excuse me, have you looked at my patch? Have you compared it to yours? I > only removed your RGB code entries from the list of supported formats, I > haven't removed any implementation details, thus effectively just > disabling it. Just briefly skimmed over it. Ok then, that diff seems fine. I assume the imagebus will fix the rgb issues anyway. > > > I dont want this merged before this is solved in some way where those > > values are preserved. > > Sure, let's have it fixed and submit it in time for 2.6.33. > > 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: V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
On 09/14/2009 11:39 PM, Andreas Mohr wrote: > On Mon, Sep 14, 2009 at 11:34:40PM +0200, Jiri Slaby wrote: >> On 09/14/2009 11:07 PM, Andreas Mohr wrote: >>> msecs_to_jiffies(1) is quite a bit too boldly assuming >>> that all of the msecs_to_jiffies(x) implementation branches >>> always round up. >> >> They do, don't they? > > I'd hope so, but a slight risk remains, you never know, > especially with 4+ or so variants... A potential problem here is rather that it may wait longer due to returning 1 jiffie. It's then timeout * 1000 * 1. On 250HZ system it makes a difference of multiple of 4. Don't think it's a real issue in those drivers at all, but it's worth fixing. Care to post a patch? -- 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: V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
On Mon, 14 Sep 2009, Andreas Mohr wrote: > cam->module_param.frame_timeout * > 1000 * msecs_to_jiffies(1) ); > multiple times each. > What they should do instead is > frame_timeout * msecs_to_jiffies(1000), I'd think. > msecs_to_jiffies(1) is quite a bit too boldly assuming > that all of the msecs_to_jiffies(x) implementation branches > always round up. It might also wait far longer than desired. On a 100 Hz kernel a jiffie is 10 ms. 1000 * msecs_to_jiffies(1) will wait 10 seconds instead of 1. But, I believe there is an issue with msecs_to_jiffies(x) overflowing for very high values of x. I'm not sure where that point is though. -- 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: V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
Hi, On Mon, Sep 14, 2009 at 11:34:40PM +0200, Jiri Slaby wrote: > On 09/14/2009 11:07 PM, Andreas Mohr wrote: > > ./drivers/media/video/zc0301/zc0301_core.c > > do > > cam->module_param.frame_timeout * > > 1000 * msecs_to_jiffies(1) ); > > multiple times each. > > What they should do instead is > > frame_timeout * msecs_to_jiffies(1000), I'd think. > > In fact, msecs_to_jiffies(frame_timeout * 1000) makes much more sense. Heh, right, even a bit better ;) > > msecs_to_jiffies(1) is quite a bit too boldly assuming > > that all of the msecs_to_jiffies(x) implementation branches > > always round up. > > They do, don't they? I'd hope so, but a slight risk remains, you never know, especially with 4+ or so variants... Andreas Mohr -- 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: V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
On 09/14/2009 11:07 PM, Andreas Mohr wrote: > ./drivers/media/video/zc0301/zc0301_core.c > do > cam->module_param.frame_timeout * > 1000 * msecs_to_jiffies(1) ); > multiple times each. > What they should do instead is > frame_timeout * msecs_to_jiffies(1000), I'd think. In fact, msecs_to_jiffies(frame_timeout * 1000) makes much more sense. > msecs_to_jiffies(1) is quite a bit too boldly assuming > that all of the msecs_to_jiffies(x) implementation branches > always round up. They do, don't they? -- 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: Terratec T USB XXS 0ccd:00ab device
Just for the record На Sunday 13 September 2009 14:56:56 Emanoil Kotsev написа: > Hello, I've just subscribed this list. I'm normally using knode to read > news, but somehow I can not pull the groups etc from the vger server. > > I also tried to post to linux-dvb mailing list, but found out that it moved > here. If you think I need to know something explicitly about participating > to the list, please let me know. Something is completely wrong with this "linux-dvb" list. I subscriubed there before and people are posting - I'm getting the mails. > > The issue I'm facing is that my old TV card (HVR900) stopped working, so I > googled around and decided to buy Terratec T USB XXS, reading it was > supported in dvb_usb_dib0700 > > However after installing the card (usb-stick) it was not recognized (my one > has product id 0x00ab and not 0x0078), so I googled again and found a hint > to change the device id in dvb_usb_ids.h which was working for other > Terratec card. It seems there are two device ids covering the same card model http://linux.terratec.de/tv_en.html > > I pulled the latest v4l-dvb code and did it (perhaps I could have done it > in the kernel 2.6.31), compiled, installed and it started working. no dvb_usb_dib0700 is not part of the mainstream kernel yet > > However I can not handle udev to get the remote control links created > correctly. Can someone help me with it? How can I provide useful output to > developers to solve the issues with ir? I read and saw that ir control keys > are coded in the driver, so if the ir part of the 0x00ab card is different, > how can I get a useful information that can be coded for this card? Who is > doing the work at linux-dvb? http://www.linuxtv.org/wiki/index.php/Template:Making-it-work:dvb-usb-dib0700 helped solve the issues however you don't get this page listed in google under top ten (at least on my pc) > > I read there are other people, returning the cards to the seller, because > it's not working/supported by linux, which does not seem to be really true. This is really stupid idea to give up something that easily. > > Luckilly I have a bit kernel experience and good C knowledge and could do > testing if somebody can have a look at the issues - the code is completely > new to me so that I prefer to be an alpha tester for the device. > The offer still holds - someebody should change the code to make it work regards -- pub 1024D/648C084C 2008-06-06 Emanoil Kotsev Primary key fingerprint: 002C AF99 232A 5A44 EF9E 6D7D 0D65 4160 648C 084C -- 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: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 sensor
On Mon, 14 Sep 2009, Marek Vasut wrote: > Dne Po 14. září 2009 22:30:41 Guennadi Liakhovetski napsal(a): > > On Mon, 14 Sep 2009, Marek Vasut wrote: > > > Dne Po 14. září 2009 21:29:26 Guennadi Liakhovetski napsal(a): > > > > From: Marek Vasut > > > > > > > > Signed-off-by: Marek Vasut > > > > Signed-off-by: Guennadi Liakhovetski > > > > --- > > > > > > > > Marek, please confirm, that this version is ok. I'll push it upstream > > > > for 2.6.32 then. > > > > > > No, it's not OK. You removed the RGB part. Either enclose those parts > > > into ifdef OV9640_RGB_BUGGY or preserve it in some other way. Someone > > > will certainly want to re-add RGB parts later and will have to figure it > > > out all over again. > > > > Ok, make a proposal, how you would like to see it. But - I do not want > > commented out code, including "#ifdef MACRO_THAT_DOESNT_GET_DEFINED." I > > think, I described it in sufficient detail, so that re-adding that code > > should not take longer than 10 minutes for anyone sufficiently familiar > > with the code. Referencing another driver also has an advantage, that if > > we switch to imagebus or any other API, you don't get stale commented out > > code, but you look up updated code in a functional driver. But I am open > > to your ideas / but no commented out code, please. > > The RGB is broken only in a way where it swaps colours, the color matrix > coeficients and register configurations are OK (which is what other people > who > will want to add it will need to figure out again from scratch if you remove > the > code). Excuse me, have you looked at my patch? Have you compared it to yours? I only removed your RGB code entries from the list of supported formats, I haven't removed any implementation details, thus effectively just disabling it. > I dont want this merged before this is solved in some way where those values > are > preserved. Sure, let's have it fixed and submit it in time for 2.6.33. 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: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 sensor
Dne Po 14. září 2009 22:30:41 Guennadi Liakhovetski napsal(a): > On Mon, 14 Sep 2009, Marek Vasut wrote: > > Dne Po 14. září 2009 21:29:26 Guennadi Liakhovetski napsal(a): > > > From: Marek Vasut > > > > > > Signed-off-by: Marek Vasut > > > Signed-off-by: Guennadi Liakhovetski > > > --- > > > > > > Marek, please confirm, that this version is ok. I'll push it upstream > > > for 2.6.32 then. > > > > No, it's not OK. You removed the RGB part. Either enclose those parts > > into ifdef OV9640_RGB_BUGGY or preserve it in some other way. Someone > > will certainly want to re-add RGB parts later and will have to figure it > > out all over again. > > Ok, make a proposal, how you would like to see it. But - I do not want > commented out code, including "#ifdef MACRO_THAT_DOESNT_GET_DEFINED." I > think, I described it in sufficient detail, so that re-adding that code > should not take longer than 10 minutes for anyone sufficiently familiar > with the code. Referencing another driver also has an advantage, that if > we switch to imagebus or any other API, you don't get stale commented out > code, but you look up updated code in a functional driver. But I am open > to your ideas / but no commented out code, please. The RGB is broken only in a way where it swaps colours, the color matrix coeficients and register configurations are OK (which is what other people who will want to add it will need to figure out again from scratch if you remove the code). I dont want this merged before this is solved in some way where those values are preserved. > > 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: [ANOUNCE] Staging trees at V4L/DVB trees
Em Mon, 14 Sep 2009 23:58:33 +0530 "Hiremath, Vaibhav" escreveu: > > -Original Message- > > From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] > > Sent: Monday, September 14, 2009 11:42 PM > > To: Hiremath, Vaibhav > > Cc: linux-media@vger.kernel.org > > Subject: Re: [ANOUNCE] Staging trees at V4L/DVB trees > > > > Em Mon, 14 Sep 2009 22:51:44 +0530 > > "Hiremath, Vaibhav" escreveu: > > > > > > -Original Message- > > > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > > > ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab > > > > Sent: Monday, September 14, 2009 5:39 AM > > > > To: linux-media@vger.kernel.org > > > > Subject: [ANOUNCE] Staging trees at V4L/DVB trees > > > > > > > > Probably some of you already noticed that we're creating some > > > > staging trees at > > > > V4L/DVB trees. > > > > > > > > There are currently 2 staging trees: > > > > > > > > 1) /linux/drivers/staging - With drivers that aren't ready yet > > for > > > > merge, needing > > > > help for being finished. > > > > > > > [Hiremath, Vaibhav] Hi Mauro, > > > > > > As you know I am also working on OMAP3 V4L2 display driver and > > posted initial patches (Posted by myself and Hardik Shah) to the > > community which went through couple of review cycles. Since it was > > having dependency on DSS2 library being developed by and at Nokia > > (Tomi) we decided to wait for it to be accepted. > > > > > > Now DSS2 has already being submitted to the community and will > > make his way to mainline soon. > > > > > > Do you want me to submit the OMAP3 DSS driver for staging tree, > > this would be really good candidate for this. I will make sure that > > it stays updated and tested till DSS2 gets accepted. > > > > > > Please let me know your inputs, if you feel it should be done then > > I will submit patch tomorrow as soon as I get into office. > > > > Hmm... if it has dependency with another tree, this may be a problem > > since my > > intention is to merge the three drivers we have currently at kernel > > drivers/staging (in fact two of them, since go7007 is already > > there), but, if > > they compile fine, even without DSS2 library (is it a kernel > > library?), then, > > that's fine for staging. > > > > > [Hiremath, Vaibhav] Yes, this is kernel level library which sits underneath > driver, V4L2 and Fbdev and provides seamless DSS hardware access to above > drivers. They won't compile without it. > > V4L2 Fbdev >| | > -- > | | > DSS2 VRFB > | | > OMAP3 DSS HW VRFB HW engine > > But should it be ok if I put dependency in Kconfig itself? The file won't get > compiled. I understand we won't gain anything with this, this is just another > tree to hold, and this is one of the main reason I stopped pushing this > patch. > The patch is submit worthy and cater most of the requirements, but due to > some dependencies it has blocked till now. Well, what would be the gain on having it there upstream without being capable of compiling? I would prefer if you add it at some -hg tree and ask me to pull after having the DSS2 library at upstream or at linux-next. 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
V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
Hi all, ./drivers/media/video/sn9c102/sn9c102_core.c , ./drivers/media/video/et61x251/et61x251_core.c and ./drivers/media/video/zc0301/zc0301_core.c do cam->module_param.frame_timeout * 1000 * msecs_to_jiffies(1) ); multiple times each. What they should do instead is frame_timeout * msecs_to_jiffies(1000), I'd think. msecs_to_jiffies(1) is quite a bit too boldly assuming that all of the msecs_to_jiffies(x) implementation branches always round up. Not to mention that the current implementation needs one additional multiplication operation as opposed to constant-aggregating it into the msecs_to_jiffies() argument and thus nicely evaporating it into nirvana. HTH, Andreas Mohr -- 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: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 sensor
On Mon, Sep 14, 2009 at 4:30 PM, Guennadi Liakhovetski wrote: > On Mon, 14 Sep 2009, Marek Vasut wrote: > >> Dne Po 14. září 2009 21:29:26 Guennadi Liakhovetski napsal(a): >> > From: Marek Vasut >> > >> > Signed-off-by: Marek Vasut >> > Signed-off-by: Guennadi Liakhovetski >> > --- >> > >> > Marek, please confirm, that this version is ok. I'll push it upstream for >> > 2.6.32 then. >> >> No, it's not OK. You removed the RGB part. Either enclose those parts into >> ifdef >> OV9640_RGB_BUGGY or preserve it in some other way. Someone will certainly >> want >> to re-add RGB parts later and will have to figure it out all over again. > > Ok, make a proposal, how you would like to see it. But - I do not want > commented out code, including "#ifdef MACRO_THAT_DOESNT_GET_DEFINED." I > think, I described it in sufficient detail, so that re-adding that code > should not take longer than 10 minutes for anyone sufficiently familiar > with the code. Referencing another driver also has an advantage, that if > we switch to imagebus or any other API, you don't get stale commented out > code, but you look up updated code in a functional driver. But I am open > to your ideas / but no commented out code, please. > I don't know much about this driver, but here's my $0.02. Since the RGB code has known issues and this is a new driver, it is probably best to submit it without the code for RGB support. As is, even without direct support from the driver, users can retrieve RGB data from the camera using libv4l. Your argument is therefore more or less mute. If someone were to want to add RGB support to the driver, I'm sure they'd prefer to have a clean and functional driver to work with rather than wading through a bunch of dead/broken code. Regards, David Ellingsworth -- 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: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 sensor
On Mon, 14 Sep 2009, Marek Vasut wrote: > Dne Po 14. září 2009 21:29:26 Guennadi Liakhovetski napsal(a): > > From: Marek Vasut > > > > Signed-off-by: Marek Vasut > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > Marek, please confirm, that this version is ok. I'll push it upstream for > > 2.6.32 then. > > No, it's not OK. You removed the RGB part. Either enclose those parts into > ifdef > OV9640_RGB_BUGGY or preserve it in some other way. Someone will certainly > want > to re-add RGB parts later and will have to figure it out all over again. Ok, make a proposal, how you would like to see it. But - I do not want commented out code, including "#ifdef MACRO_THAT_DOESNT_GET_DEFINED." I think, I described it in sufficient detail, so that re-adding that code should not take longer than 10 minutes for anyone sufficiently familiar with the code. Referencing another driver also has an advantage, that if we switch to imagebus or any other API, you don't get stale commented out code, but you look up updated code in a functional driver. But I am open to your ideas / but no commented out code, please. 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: parameter for module gspca_sn9c20x
On Mon, Sep 14, 2009 at 12:20 PM, Alan Jenkins wrote: > [CC linux-media] The linux-modules list is for the program "modprobe" > etc, not the actual kernel drivers. > > On 9/14/09, baeck...@gmx.net wrote: >> I have a built-in webcam in my laptop: 0c45:624f Microdia PC Camera >> (SN9C201) >> >> Till today I used the driver from [groups.google.de] to make it work. >> But now I found the driver in the 2.6.31 kernel: >> >> gspca_sn9c20x >> >> Unfortunately I have to flip the image vertically so it is displayed right, >> otherwise it is upside- >> down. >> >> With the google-groups-driver I had to use the parameter vflip=1 to flip the >> image. But with the >> kernel module gspca_sn9c20x this is not working: >> >> # modprobe gspca_sn9c20x vflip=1 >> FATAL: Error inserting gspca_sn9c20x >> (/lib/modules/2.6.31/kernel/drivers/media/video/gspca/gspca_sn9c20x.ko): >> Unknown symbol in module, >> or unknown parameter (see dmesg) >> >> Does anyone know how to flip the image? You might want to take a look at libv4l. Several cameras, like yours are known to have the sensor mounted upside down. Kernel drivers typically do not correct for this since it's impossible for the driver to know if the sensor is upside down or not on all supported devices. >From what I recall, libv4l does a couple of checks to determine if the sensor is upside down or not and corrects the image if necessary. It might also provide additional controls that allow you to flip the image even if it's not a sensor that's known to be mounted upside down. libv4l is compatible with all v4l2 applications simply by pre-loading the library for the application using LDPRELOAD. Regards, David Ellingsworth -- 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://udev.netup.ru/hg/v4l-dvb-commits
Em Mon, 14 Sep 2009 16:29:58 +0400
"aos...@netup.ru" escreveu:
> Hello,
>
> Fixed. Try again please.
>
>
> # HG changeset patch
> # User Abylay Ospan
> # Date 1252176678 -14400
> # Node ID 2f1119c624ebafde8332fb7a0c8a9315e50e9d51
> # Parent 2b49813f84822a1c0d88875ac590a455d93e9225
> Fix gpio mutex in NetUP Dual DVB-S2 CI card.
>
> From: Abylay Ospan
>
> The card uses the same cx23885 gpio lines for two adapters.
> In case of there is several cards in system we must implement
> gpio mutex per cx23885 chip.
>
> Signed-off-by: Abylay Ospan
>
> --- a/linux/drivers/media/video/cx23885/cimax2.c Thu Sep 03 09:06:34
> 2009 -0300
> +++ b/linux/drivers/media/video/cx23885/cimax2.c Sat Sep 05 22:51:18
> 2009 +0400
> @@ -75,7 +75,6 @@
> void *priv;
> };
>
> -struct mutex gpio_mutex;/* Two CiMax's uses same GPIO lines */
>
> int netup_read_i2c(struct i2c_adapter *i2c_adap, u8 addr, u8 reg,
> u8 *buf, int len)
> @@ -183,10 +182,11 @@
> if (ret != 0)
> return ret;
>
> - mutex_lock(&gpio_mutex);
> + mutex_lock(&dev->gpio_lock);
>
> /* write addr */
> cx_write(MC417_OEN, NETUP_EN_ALL);
> + udelay(2000);
udelay is not nice to the processor, since it won't handle any other task while
waiting. In general, it is better to use usleep().
> cx_write(MC417_RWD, NETUP_CTRL_OFF |
> NETUP_ADLO | (0xff & addr));
> cx_clear(MC417_RWD, NETUP_ADLO);
> @@ -194,9 +194,10 @@
> NETUP_ADHI | (0xff & (addr >> 8)));
> cx_clear(MC417_RWD, NETUP_ADHI);
>
> - if (read) /* data in */
> + if (read) { /* data in */
> cx_write(MC417_OEN, NETUP_EN_ALL | NETUP_DATA);
> - else /* data out */
> + udelay(2000);
Same issue here.
> + } else /* data out */
> cx_write(MC417_RWD, NETUP_CTRL_OFF | data);
>
> /* choose chip */
> @@ -206,7 +207,7 @@
> cx_clear(MC417_RWD, (read) ? NETUP_RD : NETUP_WR);
> mem = netup_ci_get_mem(dev);
>
> - mutex_unlock(&gpio_mutex);
> + mutex_unlock(&dev->gpio_lock);
>
> if (!read)
> if (mem < 0)
> @@ -411,7 +412,6 @@
> switch (port->nr) {
> case 1:
> state->ci_i2c_addr = 0x40;
> - mutex_init(&gpio_mutex);
> break;
> case 2:
> state->ci_i2c_addr = 0x41;
> --- a/linux/drivers/media/video/cx23885/cx23885-core.cThu Sep 03
> 09:06:34 2009 -0300
> +++ b/linux/drivers/media/video/cx23885/cx23885-core.cSat Sep 05
> 22:51:18 2009 +0400
> @@ -759,6 +759,7 @@
> int i;
>
> mutex_init(&dev->lock);
> + mutex_init(&dev->gpio_lock);
>
> atomic_inc(&dev->refcount);
>
> --- a/linux/drivers/media/video/cx23885/cx23885.h Thu Sep 03 09:06:34
> 2009 -0300
> +++ b/linux/drivers/media/video/cx23885/cx23885.h Sat Sep 05 22:51:18
> 2009 +0400
> @@ -326,6 +326,7 @@
>
> intnr;
> struct mutex lock;
> + struct mutex gpio_lock;
>
> /* board details */
> unsigned int board;
>
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: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 sensor
Dne Po 14. září 2009 21:29:26 Guennadi Liakhovetski napsal(a):
> From: Marek Vasut
>
> Signed-off-by: Marek Vasut
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> Marek, please confirm, that this version is ok. I'll push it upstream for
> 2.6.32 then.
No, it's not OK. You removed the RGB part. Either enclose those parts into
ifdef
OV9640_RGB_BUGGY or preserve it in some other way. Someone will certainly want
to re-add RGB parts later and will have to figure it out all over again.
>
> drivers/media/video/Kconfig |6 +
> drivers/media/video/Makefile|1 +
> drivers/media/video/ov9640.c| 805
> +++ drivers/media/video/ov9640.h|
> 209 ++
> include/media/v4l2-chip-ident.h |1 +
> 5 files changed, 1022 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/ov9640.c
> create mode 100644 drivers/media/video/ov9640.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 14a1b61..498a223 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -843,6 +843,12 @@ config SOC_CAMERA_OV772X
> help
> This is a ov772x camera driver
>
> +config SOC_CAMERA_OV9640
> + tristate "ov9640 camera support"
> + depends on SOC_CAMERA && I2C
> + help
> + This is a ov9640 camera driver
> +
> config MX1_VIDEO
> bool
>
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 00fb23e..541e7f3 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111)+= mt9m111.o
> obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o
> obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o
> obj-$(CONFIG_SOC_CAMERA_OV772X) += ov772x.o
> +obj-$(CONFIG_SOC_CAMERA_OV9640) += ov9640.o
> obj-$(CONFIG_SOC_CAMERA_TW9910) += tw9910.o
>
> # And now the v4l2 drivers:
> diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c
> new file mode 100644
> index 000..f7826b9
> --- /dev/null
> +++ b/drivers/media/video/ov9640.c
> @@ -0,0 +1,805 @@
> +/*
> + * OmniVision OV96xx Camera Driver
> + *
> + * Copyright (C) 2009 Marek Vasut
> + *
> + * Based on ov772x camera driver:
> + *
> + * Copyright (C) 2008 Renesas Solutions Corp.
> + * Kuninori Morimoto
> + *
> + * Based on ov7670 and soc_camera_platform driver,
> + *
> + * Copyright 2006-7 Jonathan Corbet
> + * Copyright (C) 2008 Magnus Damm
> + * Copyright (C) 2008, Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ov9640.h"
> +
> +/* default register setup */
> +static const struct ov9640_reg ov9640_regs_dflt[] = {
> + { OV9640_COM5, OV9640_COM5_SYSCLK | OV9640_COM5_LONGEXP },
> + { OV9640_COM6, OV9640_COM6_OPT_BLC | OV9640_COM6_ADBLC_BIAS |
> + OV9640_COM6_FMT_RST | OV9640_COM6_ADBLC_OPTEN },
> + { OV9640_PSHFT, OV9640_PSHFT_VAL(0x01) },
> + { OV9640_ACOM, OV9640_ACOM_2X_ANALOG | OV9640_ACOM_RSVD },
> + { OV9640_TSLB, OV9640_TSLB_YUYV_UYVY },
> + { OV9640_COM16, OV9640_COM16_RB_AVG },
> +
> + /* Gamma curve P */
> + { 0x6c, 0x40 }, { 0x6d, 0x30 }, { 0x6e, 0x4b }, { 0x6f, 0x60 },
> + { 0x70, 0x70 }, { 0x71, 0x70 }, { 0x72, 0x70 }, { 0x73, 0x70 },
> + { 0x74, 0x60 }, { 0x75, 0x60 }, { 0x76, 0x50 }, { 0x77, 0x48 },
> + { 0x78, 0x3a }, { 0x79, 0x2e }, { 0x7a, 0x28 }, { 0x7b, 0x22 },
> +
> + /* Gamma curve T */
> + { 0x7c, 0x04 }, { 0x7d, 0x07 }, { 0x7e, 0x10 }, { 0x7f, 0x28 },
> + { 0x80, 0x36 }, { 0x81, 0x44 }, { 0x82, 0x52 }, { 0x83, 0x60 },
> + { 0x84, 0x6c }, { 0x85, 0x78 }, { 0x86, 0x8c }, { 0x87, 0x9e },
> + { 0x88, 0xbb }, { 0x89, 0xd2 }, { 0x8a, 0xe6 },
> +};
> +
> +/* Configurations
> + * NOTE: for YUV, alter the following registers:
> + * COM12 |= OV9640_COM12_YUV_AVG
> + *
> + *for RGB, alter the following registers:
> + * COM7 |= OV9640_COM7_RGB
> + * COM13 |= OV9640_COM13_RGB_AVG
> + * COM15 |= proper RGB color encoding mode
> + */
> +static const struct ov9640_reg ov9640_regs_qqcif[] = {
> + { OV9640_CLKRC, OV9640_CLKRC_DPLL_EN | OV9640_CLKRC_DIV(0x0f) },
> + { OV9640_COM1, OV9640_COM1_QQFMT | OV9640_COM1_HREF_2SKIP },
> + { OV9640_COM4, OV9640_COM4_QQ_VP | OV9640_COM4_RSVD },
> + { OV9640_COM7, OV9640_COM7_QCIF },
> + { OV9640_COM12, OV9640_COM12_RSVD },
> + { OV9640_COM13, OV9640_COM13_GAMMA_RAW | OV9640_COM13_MATRIX_EN },
> + { OV9640_COM15, OV9640_COM15_OR_10F0 },
> +};
> +
> +static const struct ov9640_reg ov9640_regs_qqvga[] = {
> + { OV9640_CLKRC, OV9640_CLKRC_DPLL_
V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 sensor
From: Marek Vasut
Signed-off-by: Marek Vasut
Signed-off-by: Guennadi Liakhovetski
---
Marek, please confirm, that this version is ok. I'll push it upstream for
2.6.32 then.
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile|1 +
drivers/media/video/ov9640.c| 805 +++
drivers/media/video/ov9640.h| 209 ++
include/media/v4l2-chip-ident.h |1 +
5 files changed, 1022 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov9640.c
create mode 100644 drivers/media/video/ov9640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 14a1b61..498a223 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -843,6 +843,12 @@ config SOC_CAMERA_OV772X
help
This is a ov772x camera driver
+config SOC_CAMERA_OV9640
+ tristate "ov9640 camera support"
+ depends on SOC_CAMERA && I2C
+ help
+ This is a ov9640 camera driver
+
config MX1_VIDEO
bool
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 00fb23e..541e7f3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o
obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o
obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o
obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
+obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o
obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
# And now the v4l2 drivers:
diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c
new file mode 100644
index 000..f7826b9
--- /dev/null
+++ b/drivers/media/video/ov9640.c
@@ -0,0 +1,805 @@
+/*
+ * OmniVision OV96xx Camera Driver
+ *
+ * Copyright (C) 2009 Marek Vasut
+ *
+ * Based on ov772x camera driver:
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto
+ *
+ * Based on ov7670 and soc_camera_platform driver,
+ *
+ * Copyright 2006-7 Jonathan Corbet
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ov9640.h"
+
+/* default register setup */
+static const struct ov9640_reg ov9640_regs_dflt[] = {
+ { OV9640_COM5, OV9640_COM5_SYSCLK | OV9640_COM5_LONGEXP },
+ { OV9640_COM6, OV9640_COM6_OPT_BLC | OV9640_COM6_ADBLC_BIAS |
+ OV9640_COM6_FMT_RST | OV9640_COM6_ADBLC_OPTEN },
+ { OV9640_PSHFT, OV9640_PSHFT_VAL(0x01) },
+ { OV9640_ACOM, OV9640_ACOM_2X_ANALOG | OV9640_ACOM_RSVD },
+ { OV9640_TSLB, OV9640_TSLB_YUYV_UYVY },
+ { OV9640_COM16, OV9640_COM16_RB_AVG },
+
+ /* Gamma curve P */
+ { 0x6c, 0x40 }, { 0x6d, 0x30 }, { 0x6e, 0x4b }, { 0x6f, 0x60 },
+ { 0x70, 0x70 }, { 0x71, 0x70 }, { 0x72, 0x70 }, { 0x73, 0x70 },
+ { 0x74, 0x60 }, { 0x75, 0x60 }, { 0x76, 0x50 }, { 0x77, 0x48 },
+ { 0x78, 0x3a }, { 0x79, 0x2e }, { 0x7a, 0x28 }, { 0x7b, 0x22 },
+
+ /* Gamma curve T */
+ { 0x7c, 0x04 }, { 0x7d, 0x07 }, { 0x7e, 0x10 }, { 0x7f, 0x28 },
+ { 0x80, 0x36 }, { 0x81, 0x44 }, { 0x82, 0x52 }, { 0x83, 0x60 },
+ { 0x84, 0x6c }, { 0x85, 0x78 }, { 0x86, 0x8c }, { 0x87, 0x9e },
+ { 0x88, 0xbb }, { 0x89, 0xd2 }, { 0x8a, 0xe6 },
+};
+
+/* Configurations
+ * NOTE: for YUV, alter the following registers:
+ * COM12 |= OV9640_COM12_YUV_AVG
+ *
+ * for RGB, alter the following registers:
+ * COM7 |= OV9640_COM7_RGB
+ * COM13 |= OV9640_COM13_RGB_AVG
+ * COM15 |= proper RGB color encoding mode
+ */
+static const struct ov9640_reg ov9640_regs_qqcif[] = {
+ { OV9640_CLKRC, OV9640_CLKRC_DPLL_EN | OV9640_CLKRC_DIV(0x0f) },
+ { OV9640_COM1, OV9640_COM1_QQFMT | OV9640_COM1_HREF_2SKIP },
+ { OV9640_COM4, OV9640_COM4_QQ_VP | OV9640_COM4_RSVD },
+ { OV9640_COM7, OV9640_COM7_QCIF },
+ { OV9640_COM12, OV9640_COM12_RSVD },
+ { OV9640_COM13, OV9640_COM13_GAMMA_RAW | OV9640_COM13_MATRIX_EN },
+ { OV9640_COM15, OV9640_COM15_OR_10F0 },
+};
+
+static const struct ov9640_reg ov9640_regs_qqvga[] = {
+ { OV9640_CLKRC, OV9640_CLKRC_DPLL_EN | OV9640_CLKRC_DIV(0x07) },
+ { OV9640_COM1, OV9640_COM1_QQFMT | OV9640_COM1_HREF_2SKIP },
+ { OV9640_COM4, OV9640_COM4_QQ_VP | OV9640_COM4_RSVD },
+ { OV9640_COM7, OV9640_COM7_QVGA },
+ { OV9640_COM12, OV9640_COM12_RSVD },
+ { OV9640_COM13, OV9640_COM13_GAMMA_RAW | OV9640_COM13_MATRIX_EN },
+ { OV9640_COM15, OV9640_COM15_OR_10F0 },
+};
+
+static const struct ov9640_reg ov9640_regs_qcif[] = {
+ { OV9640_CLKRC, OV9640_CLKR
test
just a test. -- 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/RFT 0/14] radio-mr800 patch series
Hello David, On Sun, Sep 13, 2009 at 7:22 AM, David Ellingsworth wrote: > What follow is a series of patches to clean up the radio-mr800 driver. I > do _not_ have access to this device so these patches need to be tested. > These patches should apply to Mauro's git tree and against the 2.6.31 > release kernel. The patches in this series are as follows: > > 01. radio-mr800: implement proper locking > 02. radio-mr800: simplify video_device allocation > 03. radio-mr800: simplify error paths in usb probe callback > 04. radio-mr800: remove an unnecessary local variable > 05. radio-mr800: simplify access to amradio_device > 06. radio-mr800: simplify locking in ioctl callbacks > 07. radio-mr800: remove device-removed indicator > 08. radio-mr800: fix potential use after free > 09. radio-mr800: remove device initialization from open/close > 10. radio-mr800: ensure the radio is initialized to a consistent state > 11. radio-mr800: fix behavior of set_radio function > 12. radio-mr800: preserve radio state during suspend/resume > 13. radio-mr800: simplify device warnings > 14. radio-mr800: set radio frequency only upon success > > The first 7 in this series are the same as those submitted in my last series > and will not be resent. The remaining 7 patches in this series will be sent > separately for review. > > Regards, > > David Ellingsworth Thank you for work at radio-mr800. I'll check and test your patches as soon as possible, it probably takes 2-3 days. -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ANOUNCE] Staging trees at V4L/DVB trees
> -Original Message- > From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] > Sent: Monday, September 14, 2009 11:42 PM > To: Hiremath, Vaibhav > Cc: linux-media@vger.kernel.org > Subject: Re: [ANOUNCE] Staging trees at V4L/DVB trees > > Em Mon, 14 Sep 2009 22:51:44 +0530 > "Hiremath, Vaibhav" escreveu: > > > > -Original Message- > > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > > ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab > > > Sent: Monday, September 14, 2009 5:39 AM > > > To: linux-media@vger.kernel.org > > > Subject: [ANOUNCE] Staging trees at V4L/DVB trees > > > > > > Probably some of you already noticed that we're creating some > > > staging trees at > > > V4L/DVB trees. > > > > > > There are currently 2 staging trees: > > > > > > 1) /linux/drivers/staging - With drivers that aren't ready yet > for > > > merge, needing > > > help for being finished. > > > > > [Hiremath, Vaibhav] Hi Mauro, > > > > As you know I am also working on OMAP3 V4L2 display driver and > posted initial patches (Posted by myself and Hardik Shah) to the > community which went through couple of review cycles. Since it was > having dependency on DSS2 library being developed by and at Nokia > (Tomi) we decided to wait for it to be accepted. > > > > Now DSS2 has already being submitted to the community and will > make his way to mainline soon. > > > > Do you want me to submit the OMAP3 DSS driver for staging tree, > this would be really good candidate for this. I will make sure that > it stays updated and tested till DSS2 gets accepted. > > > > Please let me know your inputs, if you feel it should be done then > I will submit patch tomorrow as soon as I get into office. > > Hmm... if it has dependency with another tree, this may be a problem > since my > intention is to merge the three drivers we have currently at kernel > drivers/staging (in fact two of them, since go7007 is already > there), but, if > they compile fine, even without DSS2 library (is it a kernel > library?), then, > that's fine for staging. > > [Hiremath, Vaibhav] Yes, this is kernel level library which sits underneath driver, V4L2 and Fbdev and provides seamless DSS hardware access to above drivers. They won't compile without it. V4L2 Fbdev | | -- | | DSS2 VRFB | | OMAP3 DSS HW VRFB HW engine But should it be ok if I put dependency in Kconfig itself? The file won't get compiled. I understand we won't gain anything with this, this is just another tree to hold, and this is one of the main reason I stopped pushing this patch. The patch is submit worthy and cater most of the requirements, but due to some dependencies it has blocked till now. Thanks, Vaibhav > > 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
[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:Mon Sep 14 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12849:71dec186cdae gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: ERRORS linux-2.6.24.7-armv5: ERRORS linux-2.6.25.11-armv5: ERRORS linux-2.6.26-armv5: ERRORS linux-2.6.27-armv5: ERRORS linux-2.6.28-armv5: ERRORS linux-2.6.29.1-armv5: ERRORS linux-2.6.30-armv5: ERRORS linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: OK linux-2.6.28-armv5-omap2: ERRORS linux-2.6.29.1-armv5-omap2: ERRORS linux-2.6.30-armv5-omap2: ERRORS linux-2.6.31-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: ERRORS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: ERRORS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: ERRORS linux-2.6.27-x86_64: ERRORS linux-2.6.28-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30-x86_64: ERRORS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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: [ANOUNCE] Staging trees at V4L/DVB trees
Em Mon, 14 Sep 2009 22:51:44 +0530 "Hiremath, Vaibhav" escreveu: > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab > > Sent: Monday, September 14, 2009 5:39 AM > > To: linux-media@vger.kernel.org > > Subject: [ANOUNCE] Staging trees at V4L/DVB trees > > > > Probably some of you already noticed that we're creating some > > staging trees at > > V4L/DVB trees. > > > > There are currently 2 staging trees: > > > > 1) /linux/drivers/staging - With drivers that aren't ready yet for > > merge, needing > > help for being finished. > > > [Hiremath, Vaibhav] Hi Mauro, > > As you know I am also working on OMAP3 V4L2 display driver and posted initial > patches (Posted by myself and Hardik Shah) to the community which went > through couple of review cycles. Since it was having dependency on DSS2 > library being developed by and at Nokia (Tomi) we decided to wait for it to > be accepted. > > Now DSS2 has already being submitted to the community and will make his way > to mainline soon. > > Do you want me to submit the OMAP3 DSS driver for staging tree, this would be > really good candidate for this. I will make sure that it stays updated and > tested till DSS2 gets accepted. > > Please let me know your inputs, if you feel it should be done then I will > submit patch tomorrow as soon as I get into office. Hmm... if it has dependency with another tree, this may be a problem since my intention is to merge the three drivers we have currently at kernel drivers/staging (in fact two of them, since go7007 is already there), but, if they compile fine, even without DSS2 library (is it a kernel library?), then, that's fine for staging. 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: Compile error when I get to snd-go7007.c
Em Mon, 14 Sep 2009 12:31:28 -0500 "Peter J. Olson" escreveu: > Well, I made it a little farther... I think. I updated v4l-dvb: "hg > pull" then updated "hg update" > > I then ran "make allmodconfig" > > This is my output: > make -C /home/mythbox/Firmware/v4l-dvb/v4l allmodconfig > make[1]: Entering directory `/home/mythbox/Firmware/v4l-dvb/v4l' > ./scripts/make_kconfig.pl /lib/modules/2.6.28-15-generic/build > /lib/modules/2.6.28-15-generic/build 1 > Preparing to compile for kernel version 2.6.28 > > ***WARNING:*** You do not have the full kernel sources installed. > This does not prevent you from building the v4l-dvb tree if you have the > kernel headers, but the full kernel source may be required in order to use > make menuconfig / xconfig / qconfig. > > If you are experiencing problems building the v4l-dvb tree, please try > building against a vanilla kernel before reporting a bug. > > Vanilla kernels are available at http://kernel.org. > On most distros, this will compile a newly downloaded kernel: > > cp /boot/config-`uname -r` /.config > cd > make all modules_install install > > Please see your distro's web site for instructions to build a new kernel. > > VIDEO_VPSS_SYSTEM: Requires at least kernel 2.6.31 > VIDEO_VPFE_CAPTURE: Requires at least kernel 2.6.31 > VIDEO_DM6446_CCDC: Requires at least kernel 2.6.31 > VIDEO_DM355_CCDC: Requires at least kernel 2.6.31 > VIDEO_PXA27x: Requires at least kernel 2.6.29 > VIDEO_CX25821: Requires at least kernel 2.6.31 > VIDEO_CX25821_ALSA: Requires at least kernel 2.6.31 > Created default (all yes) .config file > ./scripts/fix_kconfig.pl > make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l' > > Then I made it here: > > CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-core.o > CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-sg.o > CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.o > /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.c: In function > 'videobuf_dma_contig_user_get': > /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.c:164: error: > implicit declaration of function 'follow_pfn' > make[3]: *** [/home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.o] Error > 1 > make[2]: *** [_module_/home/mythbox/Firmware/v4l-dvb/v4l] Error 2 > make[2]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic' > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l' > make: *** [all] Error 2 > > Its kinda annoying that a year ago this was super easy... > > I dont really want to bump up to 2.6.31 seeing it just came out a few days > ago. Ok, this is the usual backport issues we have every time we need to backport patches upstream. This should be solved soon, but currently my priority is to merge the pending patches at the tree. Up to then, you may do a: make menuconfig and select only the drivers you need, or just revert the latest changepatch to videobuf-dma-config. 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: Compile error when I get to snd-go7007.c
Well, I made it a little farther... I think. I updated v4l-dvb: "hg pull" then updated "hg update" I then ran "make allmodconfig" This is my output: make -C /home/mythbox/Firmware/v4l-dvb/v4l allmodconfig make[1]: Entering directory `/home/mythbox/Firmware/v4l-dvb/v4l' ./scripts/make_kconfig.pl /lib/modules/2.6.28-15-generic/build /lib/modules/2.6.28-15-generic/build 1 Preparing to compile for kernel version 2.6.28 ***WARNING:*** You do not have the full kernel sources installed. This does not prevent you from building the v4l-dvb tree if you have the kernel headers, but the full kernel source may be required in order to use make menuconfig / xconfig / qconfig. If you are experiencing problems building the v4l-dvb tree, please try building against a vanilla kernel before reporting a bug. Vanilla kernels are available at http://kernel.org. On most distros, this will compile a newly downloaded kernel: cp /boot/config-`uname -r` /.config cd make all modules_install install Please see your distro's web site for instructions to build a new kernel. VIDEO_VPSS_SYSTEM: Requires at least kernel 2.6.31 VIDEO_VPFE_CAPTURE: Requires at least kernel 2.6.31 VIDEO_DM6446_CCDC: Requires at least kernel 2.6.31 VIDEO_DM355_CCDC: Requires at least kernel 2.6.31 VIDEO_PXA27x: Requires at least kernel 2.6.29 VIDEO_CX25821: Requires at least kernel 2.6.31 VIDEO_CX25821_ALSA: Requires at least kernel 2.6.31 Created default (all yes) .config file ./scripts/fix_kconfig.pl make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l' Then I made it here: CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-core.o CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-sg.o CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.o /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.c: In function 'videobuf_dma_contig_user_get': /home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.c:164: error: implicit declaration of function 'follow_pfn' make[3]: *** [/home/mythbox/Firmware/v4l-dvb/v4l/videobuf-dma-contig.o] Error 1 make[2]: *** [_module_/home/mythbox/Firmware/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l' make: *** [all] Error 2 Its kinda annoying that a year ago this was super easy... I dont really want to bump up to 2.6.31 seeing it just came out a few days ago. Thanks, Peter On Mon, Sep 14, 2009 at 11:32 AM, Mauro Carvalho Chehab wrote: > Em Mon, 14 Sep 2009 10:18:42 -0500 > "Peter J. Olson" escreveu: > >> Hey all, >> >> I have a Mythbuntu 8.10 system w/ a pctv 800i (pci card) and a pctv hd >> stick (800e). Had both running just fine for about 8 months... then >> the stick stopped working. Or rather, it works but wont pick up a >> signal. >> >> I decided I would update my system a little and figure out what broke >> my 800e. I updated my kernel and went to recompile v4l-dvb and got >> this error: >> >> CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.o >> >> /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.c: In function >> 'go7007_snd_init': >> >> /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.c:251: error: implicit >> declaration of function 'snd_card_create' >> >> make[3]: *** [/home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.o] Error 1 >> >> make[2]: *** [_module_/home/mythbox/Firmware/v4l-dvb/v4l] Error 2 >> >> make[2]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic' >> >> make[1]: *** [default] Error 2 >> >> make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l' >> >> make: *** [all] Error 2 >> >> I was using the old copy of v4l I had so I thought it might have been >> the new kernel fighting w/ the old v4l. So I updated v4l (did a pull >> via hg)... same error. >> >> I dinked w/ it for a long time and finally gave up and upgraded to >> 9.0.4. Same error, now neither of my cards will work (brutal!) My >> 800i is acting like the 800e was. I can see the card in mythbackend >> setup but always gets no signal in mythtv. >> >> I dont even know what the snd-go7007 would go with... I dont even have >> that type of hardware (i dont think). >> >> Anyone have any ideas? > > Probably, it is incompatible with your kernel version. Just update and do a > "make allmodconfig". Then, try to compile again. I've disabled by the default > the compilation of the staging drivers. >> >> Thanks, >> Peter >> -- >> 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 > > > > > 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: [ANOUNCE] Staging trees at V4L/DVB trees
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab > Sent: Monday, September 14, 2009 5:39 AM > To: linux-media@vger.kernel.org > Subject: [ANOUNCE] Staging trees at V4L/DVB trees > > Probably some of you already noticed that we're creating some > staging trees at > V4L/DVB trees. > > There are currently 2 staging trees: > > 1) /linux/drivers/staging - With drivers that aren't ready yet for > merge, needing > help for being finished. > [Hiremath, Vaibhav] Hi Mauro, As you know I am also working on OMAP3 V4L2 display driver and posted initial patches (Posted by myself and Hardik Shah) to the community which went through couple of review cycles. Since it was having dependency on DSS2 library being developed by and at Nokia (Tomi) we decided to wait for it to be accepted. Now DSS2 has already being submitted to the community and will make his way to mainline soon. Do you want me to submit the OMAP3 DSS driver for staging tree, this would be really good candidate for this. I will make sure that it stays updated and tested till DSS2 gets accepted. Please let me know your inputs, if you feel it should be done then I will submit patch tomorrow as soon as I get into office. Thanks, Vaibhav > There are currently two drivers there: > go7007 driver - Used on some designs with a Micronas encoder. > cx25821 driver - Driver for Conexant cx25821 chips. > > The go7007 driver were written a long time ago and requires not only > CodingStyle fixes but also porting to some new API's and to V4L2 > framework. > This driver is already at kernel upstream, under /drivers/staging. > > The cx25821 driver is a new driver written this year for some very > powerful > PCIe chips, capable of up to 10 simultaneous video input/outputs. > The driver > needs several CodingStyle fixes, and has duplicated code for each > input/output. > > I intend to add tm6000 driver there later this week, if time permits > to port it > to the new i2c interface. > > The policy to accept new drivers code at staging tree is less rigid > than > at /drivers/media: the kernel driver for an unsupported hardware > shouldn't > depend on any userspace library other than libv4l and dvb-apps and > the code > should compile fine with the latest kernel, and the developer(s) > should be > working on fixing it for upstream inclusion. Drivers with bugs, > CodingStyle > errors, deprecated API usage, etc can be accepted. Also, drivers > there not > maintained for some time can be removed. > > 2) /staging-specs - This contains the latest V4L and DVB API specs, > in DocBook > XML 4.1.2. This is the same DocBook version used in kernel. > > It basically contains an effort to finally merge the API's at kernel > DocBook > directory. > > Currently, this is _not_ the official API, and the document still > needs review > and cleanups. > > My intention is to add the first tree upstream, under > drivers/staging for > kernel 2.6.32. As those drivers are new, if we can get them on a > good shape > during 2.6.32 rc cycle, it could be possible to move them to > drivers/media for > 2.6.32. All depends on how they'll evolute. > > If time is enough and we have the DocBook tree in good shape on the > next two > weeks, I intend to add it also to 2.6.32. > > Feel free to contribute to both trees. > > Have Fun! > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for Zolid Hybrid PCI card
On Wed, Sep 9, 2009 at 11:08 AM, Michael Krufky wrote: > On Wed, Sep 9, 2009 at 10:01 AM, wrote: >> On Tue, Sep 08, 2009 at 05:57:12PM -0400, Michael Krufky wrote: >>> >>> Henk, >>> >>> Why do you expect a 8295? If your board uses the SAA7131, then we >>> would expect an 8290 IF demod. >>> >>> Ah, I just checked the history of this email thread -- I must have >>> read one of your previous emails too quickly. :-) Perhaps there is a >>> typo in the document that you read -- tda8290 is correct. >>> >> Just to come back to this point, >> >> Well zolid has a SAA7131E, if you look at the datasheet (botom of page 15) >> http://www.nxp.com/acrobat_download/datasheets/SAA7131E_3.pdf >> >> it says: >> "The SAA7131E is functionally compatible with the SAA7135 audio and video >> broadcast decoder device and the stand-alone low-IF device TDA8295." >> >> So thats why I asked. >> >> Regards, >> Henk >> > > FIX YOUR MAILER!! > > It's a pain to reply to your emails -- I have to insert your actual > email address each time :-( > > Anyway, I am under the impression that it's a typo in the datasheet. > It is actually a tda8290. Henk, Just FYI, I merged your patch to my saa7134 repository last week: http://www.kernellabs.com/hg/~mkrufky/saa7134 I thought that I had replied to you already but that message seems to have gotten dropped somewhere :-/ I intend to send a pull request to Mauro for this, in addition to some other pending patches after he merges what I have already pending. Thanks again for your work. Regards, Mike Krufky -- 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
how to get a registered adapter name
Hi list, I'd like to enumerate connected DVB devices from my softawre, based on DVB API V3. Thank to ioctl FE_GET_INFO, I'm able to get frontends name, but they are not "clear" enough for users. After a "quick look" in /var/log/messages I discovered that adapters name are much expressives: > ... > DVB: registering new adapter (ASUS My Cinema U3000 Mini DVBT Tuner) > DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... > ... So, I tried to figure out a way to get "ASUS My Cinema U3000 Mini DVBT Tuner" string from adapter, instead of "DiBcom 7000PC" from adapter's frontend... Unsuccefully so far. Any suggestions? Regards -- Benedict -- 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: I can't get all pixels values from my driver. plz help ;0(
Guilherme, In the future, please post to the new mailing list: linux-media@vger.kernel.org That said, your camera won't output a video format that it does not support. In other words, despite you specifically asking for a 160x120 pixel RGB image, you may infact get something else. The formats your camera supports may be obtained by using VIDIOC_ENUM_FMT. Once you've selected a format you should then use VIDIOC_ENUM_FRAMESIZES to determine the size of the frames supported by that format. To simplify things a little, you might want to consider using libv4l since will automatically convert the native format supported by your camera to the one required by your application. Regards, David Ellingsworth On Mon, Sep 14, 2009 at 1:50 AM, Guilherme Longo wrote: > > Hi all. > > After 3 weeks trying to solve my problem, I am about to give up and find > another solution instead of trying to fix this one. > I have changed few things in the capture.c example available for download at > http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/ and > the altered code can be seen here: http://pastebin.com/m7ef25480 > > So... what is the problem? > > Well, I have set the following configuration for capture: > > fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; > fmt.fmt.pix.width = 160; > fmt.fmt.pix.height = 120; > fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB32; > fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; > > All the process is implemented in a function called process_image(void * p) > where p is a void pointer to the buffer where the frames captures should be > stored. > > this is the function that reads the buffer: > > if (-1 == read (fd, buffers[0].start, buffers[0].length)) (length = 160x120 > -> 19200) > > then after, I call the process_image function: > process_image (buffers[0].start); > > What I need is read the buffer separation the R, G, B, A storing them in > unsigned char variables. > > It should have 19.200 pixel (160x120) but instead, look what i have got: > > [0]87 [0]110 [0]68 [0]134 > [1]202 [1]73 [1]119 [1]109 > [2]213 [2]36 [2]73 [2]33 > . > . > [1287]73 [1287]100 [1287]150 [1287]133 > [1288]69 [1288]133 [1288]4 [1288]0 > [1289]0 [1289]0 [1289]0 [1289]0 > [1290]0 [1290]0 [1290]0 [1290]0 > [1291]0 [1291]0 [1291]0 [1291]0 > . > [4799]0 [4799]0 [4799]0 [4799]0 > [0]80 [0]105 [0]145 [0]4 > [1]146 [1]18 [1]108 [1]182 > [2]68 [2]136 [2]137 [2]170 > > As you can see, I get only 1289 pixels with values and all the rest are 0; > When the function is called again, the same happens over and over. > > So... why am I getting only 1289 pixel with values when in fact it should be > 160x120 pixel corresponding to 1 frame? > I am begging help 'cause my arsenal's over.. I am really out of ideas! > > Thanks a lot! > > > > _ > Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. > > http://www.microsoft.com/windows/windowslive/products/photos.aspx-- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-requ...@redhat.com?subjectunsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list > -- 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] tda18271 add FM filter selction + minor fixes
On Mon, Sep 14, 2009 at 11:10 AM, wrote: > On Mon, Sep 14, 2009 at 08:33:46AM -0400, Michael Krufky wrote: >> On Sun, Sep 13, 2009 at 8:14 PM, wrote: >> > >> > This patch adds support for FM filter selection. The tda18271 has two rf >> > inputs RF_IN (45-864 MHz) and FM_IN (65-108 MHz). The code automatically >> > enables the antialiasing filter for radio reception and depending on the >> > FM input selected configures EB23 register. >> > >> > Additional fixes: >> > - Fixed the temerature comensation, see revision history of TDA18271HD_4 >> > ?spec. >> > - Minor cosmetic change in the tda18271_rf_band[] >> > - Fixed one value and removed a duplicate in tda18271_cid_target[] >> > >> > Signed-off-by: henk.vergo...@gmail.com >> > >> > >> >> Henk, >> >> Thank you for your patch. >> >> I have some other tda18271 patches pending merge currently, so it will >> be a few days before I'll be able to test and merge your patch. >> >> In the meanwhile, I'd request that this single patch be broken down >> into three separate patches, each with a description of the change and >> sign-off. I know that the patch you sent in is small, I just prefer >> to apply changes separately. >> > Thats fine, I will wait for the pull in v4l-dvb and then redo the patches: > - FM filter selection > - Errata temerature compensation > - Table fixes > > if thast ok. > >> Do you have FM radio working on the Zolid board after applying this? > > Unfortunately not yet, I get static noise with small 'ticks' at regular > intervals. It maybe the way I am testing. Currently I am using: > > mplayer radio://91.3/capture -nocache -rawaudio rate=32000 -radio \ > adevice=hw=1.0:arate=32000 > > to test. > > I will try to see if a can solder some pin headers on the card so I can > use audio bypass to the sound card. Henk, Don't wait for them to be merged to v4l-dvb -- Just work against the tda18271 development repository: http://kernellabs.com/hg/~mkrufky/tda18271 I maintain this driver, and I actually have some other fixes with respect to rf tracking filter calibration / compensation that I have yet to push. I'm asking you to resend your patches so that I'll queue them for the next tda18271 merge. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Compile error when I get to snd-go7007.c
Hey all, I have a Mythbuntu 8.10 system w/ a pctv 800i (pci card) and a pctv hd stick (800e). Had both running just fine for about 8 months... then the stick stopped working. Or rather, it works but wont pick up a signal. I decided I would update my system a little and figure out what broke my 800e. I updated my kernel and went to recompile v4l-dvb and got this error: CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.o /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.c: In function 'go7007_snd_init': /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.c:251: error: implicit declaration of function 'snd_card_create' make[3]: *** [/home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.o] Error 1 make[2]: *** [_module_/home/mythbox/Firmware/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l' make: *** [all] Error 2 I was using the old copy of v4l I had so I thought it might have been the new kernel fighting w/ the old v4l. So I updated v4l (did a pull via hg)... same error. I dinked w/ it for a long time and finally gave up and upgraded to 9.0.4. Same error, now neither of my cards will work (brutal!) My 800i is acting like the 800e was. I can see the card in mythbackend setup but always gets no signal in mythtv. I dont even know what the snd-go7007 would go with... I dont even have that type of hardware (i dont think). Anyone have any ideas? Thanks, Peter -- 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
Race in gspca main or missing lock in stv06xx subdriver?
Howdy folks,
I have my old quickcam express webcam working, with HDCS1000
sensor, 046d:840. It's clearly throwing away every other frame. What
seems to be happening is, while the last packet of the previous frame
is being analyzed by the subdriver, the first packet of the next frame
is assigned to the current frame buffer. By the time that packet is
analysed and sent back to the main driver, it's frame buffer has been
completely filled and marked as "DONE." The entire frame is then
marked for "DISCARD." This does _not_ happen with all cams using this
subdriver.
Here's a little patch, supplied only to help illustrate the problem,
that allows for the full, expected frame rate of the webcam. What it
does is wait until the very last moment to assign a frame buffer to any
packet, but the last. I also threw in a few printks so I can see where
failure takes place without wading through a swamp of debug output.
--- gspca/gspca.c.orig 2009-09-11 22:43:54.0 -0400
+++ gspca/gspca.c 2009-09-11 23:04:34.0 -0400
@@ -114,8 +114,10 @@ struct gspca_frame *gspca_get_i_frame(st
i = gspca_dev->fr_queue[i];
frame = &gspca_dev->frame[i];
if ((frame->v4l2_buf.flags & BUF_ALL_FLAGS)
- != V4L2_BUF_FLAG_QUEUED)
- return NULL;
+ != V4L2_BUF_FLAG_QUEUED){
+ printk(KERN_DEBUG "Shout NULL NULL NULL\n");
+ return frame;
+ }
return frame;
}
EXPORT_SYMBOL(gspca_get_i_frame);
@@ -146,6 +148,7 @@ static void fill_frame(struct gspca_dev
/* check the availability of the frame buffer */
frame = gspca_get_i_frame(gspca_dev);
if (!frame) {
+ printk(KERN_DEBUG "get_i_frame fails\n");
gspca_dev->last_packet_type = DISCARD_PACKET;
break;
}
@@ -268,9 +271,12 @@ struct gspca_frame *gspca_frame_add(stru
/* when start of a new frame, if the current frame buffer
* is not queued, discard the whole frame */
if (packet_type == FIRST_PACKET) {
+ i = gspca_dev->fr_i;
+ frame = &gspca_dev->frame[i];
if ((frame->v4l2_buf.flags & BUF_ALL_FLAGS)
!= V4L2_BUF_FLAG_QUEUED) {
gspca_dev->last_packet_type = DISCARD_PACKET;
+ printk(KERN_DEBUG "Frame marked for discard\n");
return frame;
}
frame->data_end = frame->data;
@@ -285,8 +291,11 @@ struct gspca_frame *gspca_frame_add(stru
/* append the packet to the frame buffer */
if (len > 0) {
+ i = gspca_dev->fr_i;
+ frame = &gspca_dev->frame[i];
if (frame->data_end - frame->data + len
> frame->v4l2_buf.length) {
+ printk(KERN_DEBUG "Frame overflow\n");
PDEBUG(D_ERR|D_PACK, "frame overflow %zd > %d",
frame->data_end - frame->data + len,
frame->v4l2_buf.length);
It works, at least until there is any disruption to the stream, such as
an exposure change, and then something gets out of sync and it starts
throwing out every other frame again. It shows that the driver
framework and USB bus is capable of handling the full frame rate.
I'll keep looking for an actual solution, but there is a lot I don't
understand. Any suggestions or ideas would be appreciated. Several
questions come to mind. Why bother assigning a frame buffer with
get_i_frame, before it's needed? What purpose has frame_wait, when
it's not called until the frame is completed and the buffer is marked
as "DONE." Why are there five, fr_i fr_q fr_o fr_queue index , buffer
indexing counters? I'm sure I don't understand all the different tasks
this driver has to handle and all the different hardware it has to deal
with. But I would be surprised if my cam is the only one this is
happening with.
Thanks,
- Jim
--
There are two kinds of people. The innocent and the living.
--
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] tda18271 add FM filter selction + minor fixes
On Mon, Sep 14, 2009 at 08:33:46AM -0400, Michael Krufky wrote: > On Sun, Sep 13, 2009 at 8:14 PM, wrote: > > > > This patch adds support for FM filter selection. The tda18271 has two rf > > inputs RF_IN (45-864 MHz) and FM_IN (65-108 MHz). The code automatically > > enables the antialiasing filter for radio reception and depending on the > > FM input selected configures EB23 register. > > > > Additional fixes: > > - Fixed the temerature comensation, see revision history of TDA18271HD_4 > > ?spec. > > - Minor cosmetic change in the tda18271_rf_band[] > > - Fixed one value and removed a duplicate in tda18271_cid_target[] > > > > Signed-off-by: henk.vergo...@gmail.com > > > > > > Henk, > > Thank you for your patch. > > I have some other tda18271 patches pending merge currently, so it will > be a few days before I'll be able to test and merge your patch. > > In the meanwhile, I'd request that this single patch be broken down > into three separate patches, each with a description of the change and > sign-off. I know that the patch you sent in is small, I just prefer > to apply changes separately. > Thats fine, I will wait for the pull in v4l-dvb and then redo the patches: - FM filter selection - Errata temerature compensation - Table fixes if thast ok. > Do you have FM radio working on the Zolid board after applying this? Unfortunately not yet, I get static noise with small 'ticks' at regular intervals. It maybe the way I am testing. Currently I am using: mplayer radio://91.3/capture -nocache -rawaudio rate=32000 -radio \ adevice=hw=1.0:arate=32000 to test. I will try to see if a can solder some pin headers on the card so I can use audio bypass to the sound card. Thanks, Henk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
Ok, you were faster than I:-) If you agree, I can just remove those two RGB formats myself, changing your comment to a TODO, and modify the comment next to msleep(150) (if you could tell me what value didn't work, that would be appreciated) and push it out. 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: Compile error when I get to snd-go7007.c
Em Mon, 14 Sep 2009 10:18:42 -0500 "Peter J. Olson" escreveu: > Hey all, > > I have a Mythbuntu 8.10 system w/ a pctv 800i (pci card) and a pctv hd > stick (800e). Had both running just fine for about 8 months... then > the stick stopped working. Or rather, it works but wont pick up a > signal. > > I decided I would update my system a little and figure out what broke > my 800e. I updated my kernel and went to recompile v4l-dvb and got > this error: > > CC [M] /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.o > > /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.c: In function > 'go7007_snd_init': > > /home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.c:251: error: implicit > declaration of function 'snd_card_create' > > make[3]: *** [/home/mythbox/Firmware/v4l-dvb/v4l/snd-go7007.o] Error 1 > > make[2]: *** [_module_/home/mythbox/Firmware/v4l-dvb/v4l] Error 2 > > make[2]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic' > > make[1]: *** [default] Error 2 > > make[1]: Leaving directory `/home/mythbox/Firmware/v4l-dvb/v4l' > > make: *** [all] Error 2 > > I was using the old copy of v4l I had so I thought it might have been > the new kernel fighting w/ the old v4l. So I updated v4l (did a pull > via hg)... same error. > > I dinked w/ it for a long time and finally gave up and upgraded to > 9.0.4. Same error, now neither of my cards will work (brutal!) My > 800i is acting like the 800e was. I can see the card in mythbackend > setup but always gets no signal in mythtv. > > I dont even know what the snd-go7007 would go with... I dont even have > that type of hardware (i dont think). > > Anyone have any ideas? Probably, it is incompatible with your kernel version. Just update and do a "make allmodconfig". Then, try to compile again. I've disabled by the default the compilation of the staging drivers. > > Thanks, > Peter > -- > 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 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: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
Dne Po 14. září 2009 16:45:50 Guennadi Liakhovetski napsal(a): > Ok, you were faster than I:-) If you agree, I can just remove those two > RGB formats myself, changing your comment to a TODO, We can #ifdef them so others dont have to re-add them by hand if they want to try fixing those. > and modify the > comment next to msleep(150) 140 didn't > (if you could tell me what value didn't work, > that would be appreciated) and push it out. > > Thanks > Guennadi Cheers > --- > 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: [PATCH] tda18271 add FM filter selction + minor fixes
On Mon, Sep 14, 2009 at 11:21:17AM -0400, Michael Krufky wrote: > Don't wait for them to be merged to v4l-dvb -- Just work against the > tda18271 development repository: > > http://kernellabs.com/hg/~mkrufky/tda18271 > > I maintain this driver, and I actually have some other fixes with > respect to rf tracking filter calibration / compensation that I have > yet to push. I'm asking you to resend your patches so that I'll queue > them for the next tda18271 merge. Done -- 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: parameter for module gspca_sn9c20x
[CC linux-media] The linux-modules list is for the program "modprobe" etc, not the actual kernel drivers. On 9/14/09, baeck...@gmx.net wrote: > I have a built-in webcam in my laptop: 0c45:624f Microdia PC Camera > (SN9C201) > > Till today I used the driver from [groups.google.de] to make it work. > But now I found the driver in the 2.6.31 kernel: > >gspca_sn9c20x > > Unfortunately I have to flip the image vertically so it is displayed right, > otherwise it is upside- > down. > > With the google-groups-driver I had to use the parameter vflip=1 to flip the > image. But with the > kernel module gspca_sn9c20x this is not working: > > # modprobe gspca_sn9c20x vflip=1 > FATAL: Error inserting gspca_sn9c20x > (/lib/modules/2.6.31/kernel/drivers/media/video/gspca/gspca_sn9c20x.ko): > Unknown symbol in module, > or unknown parameter (see dmesg) > > Does anyone know how to flip the image? All I can say is it doesn't appear to be a module parameter, because there aren't any module parameters in the mainline driver :-). Regards Alan -- 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: [ANOUNCE] Staging trees at V4L/DVB trees
Em Sun, 13 Sep 2009 21:08:41 -0300 Mauro Carvalho Chehab escreveu: > I intend to add tm6000 driver there later this week, if time permits to port > it > to the new i2c interface. Ok, I've send part 1 of the patches I have here for tm6000. It still doesn't compile with kernel 2.6.30 or upper, due to the I2C API changes. I have still some other patches here pending, that are waiting for some time for testing them. I also intend to fix its compilation during this week. > The policy to accept new drivers code at staging tree is less rigid than > at /drivers/media: the kernel driver for an unsupported hardware shouldn't > depend on any userspace library other than libv4l and dvb-apps and the code > should compile fine with the latest kernel, and the developer(s) should be > working on fixing it for upstream inclusion. Drivers with bugs, CodingStyle > errors, deprecated API usage, etc can be accepted. Also, drivers there not > maintained for some time can be removed. >From some breakage reports with go7007 with some kernels and due to tm6000, I've added an option at Kconfig: STAGING_BROKEN, to indicate the drivers that are known to not compile against the latest kernel. However, there's a bad effect with this: those broken patches can't be updated upstream, otherwise they'll break upstream compilations. So, while we might eventually accept a broken driver at staging, a fix for it should be done quickly, to avoid causing upstream merging issues 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: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
On Mon, 14 Sep 2009, Marek Vasut wrote:
[snip]
> > > +/* NOTE: The RGB555X format still has issues, so it's left out. */
> > > +static const struct soc_camera_data_format ov9640_fmt_lists[] = {
> > > +{
> > > + .name = "VYUY",
> > > + .fourcc = V4L2_PIX_FMT_VYUY,
> > > + .depth = 16,
> > > + .colorspace = V4L2_COLORSPACE_JPEG,
> > > +},
> > > +{
> > > + .name = "RGB565X",
> > > + .fourcc = V4L2_PIX_FMT_RGB565X,
> >
> > Hm, so, do we keep RGB565X here or do we add a BGR565? We'll anyway have
> > to do that when converting to imagebus, so, better do it right straight
> > away, to avoid having to modify user-space apps.
>
> I changed this, but the RGB can still possibly be broken (can be fixed
> later).
Well, no, sorry, I do not think it's a good idea to commit code, that we
believe does not work. Then, please, remove RGB codes and add a TODO comment.
> The yuv works fine (and with the register tweak I did it's even more standard-
> conformant).
Ok.
> > > +/* read a register */
> > > +static int ov9640_reg_read(struct i2c_client *client, u8 reg, u8 *val)
> > > +{
> > > + int ret;
> > > + u8 data = reg;
> > > + struct i2c_msg msg = {
> > > + .addr = client->addr,
> > > + .flags = 0,
> > > + .len= 1,
> > > + .buf= &data,
> > > + };
> > > +
> > > + ret = i2c_transfer(client->adapter, &msg, 1);
> >
> > Are there any advantages in using raw i2c operations over smbus calls? The
> > latter look much simpler, cf., e.g., mt9m001:
> >
> > static int reg_read(struct i2c_client *client, const u8 reg)
> > {
> > s32 data = i2c_smbus_read_word_data(client, reg);
> > return data < 0 ? data : swab16(data);
> > }
> >
> > static int reg_write(struct i2c_client *client, const u8 reg,
> > const u16 data)
> > {
> > return i2c_smbus_write_word_data(client, reg, swab16(data));
> > }
> >
> > Ok, going through smbus layer takes a bit of time, but that's just done
> > during configuration.
>
> Yes, the sensor doesnt work with SMBUS calls, that's why those are there. It
> took me a while to figure it out.
Ok, then we should remove the check for SMBUS in probing.
> > > +/* program default register values */
> > > +static int ov9640_prog_dflt(struct i2c_client *client)
> > > +{
> > > + int i, ret;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(ov9640_regs_dflt); i++) {
> > > + ret = ov9640_reg_write(client, ov9640_regs_dflt[i].reg,
> > > + ov9640_regs_dflt[i].val);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > + /* wait for the changes to actually happen */
> > > + mdelay(150);
> >
> > I still think that's a lot. Have you tried any lower values? I would try
> > 50ms, if that works, try 10ms...
>
> You are free to try, I'm not doing anything about this. It doesnt work with
> lower values, period.
So, you did try it? Ok, then at least add a comment specifying whichlargest
value didn't work for you.
> > > + /*
> > > + * We must have a parent by now. And it cannot be a wrong one.
> > > + * So this entire test is completely redundant.
> > > + */
> > > + if (!icd->dev.parent ||
> > > + to_soc_camera_host(icd->dev.parent)->nr != icd->iface) {
> > > + dev_err(&icd->dev, "Parent missing or invalid!\n");
> >
> > Please, see
> > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;
> > h=d680a88e84792f84310042919065c90c5eb87423
Please adjust your dev_{dbg,err,warn,info} calls according to that patch.
> > > +/*
> > > + * i2c_driver function
> > > + */
> > > +static int ov9640_probe(struct i2c_client *client,
> > > + const struct i2c_device_id *did)
> > > +{
> > > + struct ov9640_priv *priv;
> > > + struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> > > + struct soc_camera_device *icd = client->dev.platform_data;
> > > + struct soc_camera_link *icl;
> > > + int ret;
> > > +
> > > + if (!icd) {
> > > + dev_err(&client->dev, "Missing soc-camera data!\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + icl = to_soc_camera_link(icd);
> > > + if (!icl) {
> > > + dev_err(&client->dev, "Missing platform_data for driver\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
> >
> > You're not using smbus calls, so, don't need this check. Or switch to
> > using them:-)
And remove this.
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: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
Dne Po 14. září 2009 16:35:24 Marek Vasut napsal(a): > Dne Ne 13. září 2009 21:13:32 Guennadi Liakhovetski napsal(a): > > On Sun, 13 Sep 2009, Marek Vasut wrote: > > > Dne Pá 11. záÅà 2009 23:51:44 Guennadi Liakhovetski napsal(a): > > > > Ok, a couple more simple questions / remarks, In principle, there's > > > > just one principle objection - if we agree, that the correct format > > > > is BGR565 and RGB565X, then we should change that. There's no BGR565 > > > > format currently in the kernel, so, we'd have to add it (and the > > > > documentation for the mercurial tree). > > > > > > I dont think I understand you at all. > > > > Your patch used RGB565X, which is the same as RGB565 but with _bytes_ > > swapped, whereas earlier you confirmed, that it's not a byte-swapped > > RGB565 but rather R and B _colours_ are swapped: > > > > http://marc.info/?l=linux-arm-kernel&m=125220918005429&w=2 > > > > , i.e., it is a BGR565. Now it looks like you don't change anything in > > your RGB processing code, but you declare it as plain RGB555 and RGB565 > > codes. So, are these really the normal unswapped formats or am I missing > > something? And you replaced VYUY with UYVY while also modifying register > > configuration, so, I hope, this has settled now and your current > > configuration works properly with the unmodified pxa270 for you, right? > > > > Oh, damn, I see now, I put my signature above the patch, so, you didn't > > look below it, and there were a couple more comments there:-( Sorry! All > > of them should be pretty easy to fix, so, please have a look at them. > > > > > Inlined is a new version of the patch (I did some lookup through the > > > datasheet). I might not need the BGR formats for now. > > > > > > btw. weren't you planning to merge the ov96xx drivers into .31? I > > > havent seen any of them there. > > > > Which ov96xx drivers? Do you mean the ov9655 driver from Stefan > > Herbrechtsmeier? My doubt with the latter one was (and still is), that we > > already have two drivers in the mainline (gspca/sn9c20x.c and > > gspca/ov534.c) that seem to claim support for that chip, so, I wanted to > > see, if we could reuse them. There's also an ov7670 from Jonathan Cameron > > with the same issue. And for that merge we have to come closer to > > v4l2-subdev, which is happening just now. > > > > Thanks > > Guennadi > > --- > > Guennadi Liakhovetski, Ph.D. > > Freelance Open-Source Software Developer > > http://www.open-technology.de/ > > Here's a new patch ... YUV works, RGB might be still broken (but that can > be fixed later when imagebus arrives). Tab fixed... From: Marek Vasut Date: Sat, 22 Aug 2009 05:14:23 +0200 Subject: [PATCH] Add driver for OmniVision OV9640 sensor Signed-off-by: Marek Vasut --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile|1 + drivers/media/video/ov9640.c| 812 +++ drivers/media/video/ov9640.h| 209 ++ include/media/v4l2-chip-ident.h |1 + 5 files changed, 1029 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ov9640.c create mode 100644 drivers/media/video/ov9640.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 84b6fc1..fddd654 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -772,6 +772,12 @@ config SOC_CAMERA_OV772X help This is a ov772x camera driver +config SOC_CAMERA_OV9640 + tristate "ov9640 camera support" + depends on SOC_CAMERA && I2C + help + This is a ov9640 camera driver + config MX1_VIDEO bool diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 9f2e321..e18efd5 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o +obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o # And now the v4l2 drivers: diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c new file mode 100644 index 000..a651d2b --- /dev/null +++ b/drivers/media/video/ov9640.c @@ -0,0 +1,812 @@ +/* + * OmniVision OV96xx Camera Driver + * + * Copyright (C) 2009 Marek Vasut + * + * Based on ov772x camera driver: + * + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov7670 and soc_camera_platform driver, + * + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#
Re: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
Dne Ne 13. září 2009 21:13:32 Guennadi Liakhovetski napsal(a): > On Sun, 13 Sep 2009, Marek Vasut wrote: > > Dne Pá 11. záÅà 2009 23:51:44 Guennadi Liakhovetski napsal(a): > > > Ok, a couple more simple questions / remarks, In principle, there's > > > just one principle objection - if we agree, that the correct format is > > > BGR565 and RGB565X, then we should change that. There's no BGR565 > > > format currently in the kernel, so, we'd have to add it (and the > > > documentation for the mercurial tree). > > > > I dont think I understand you at all. > > Your patch used RGB565X, which is the same as RGB565 but with _bytes_ > swapped, whereas earlier you confirmed, that it's not a byte-swapped > RGB565 but rather R and B _colours_ are swapped: > > http://marc.info/?l=linux-arm-kernel&m=125220918005429&w=2 > > , i.e., it is a BGR565. Now it looks like you don't change anything in > your RGB processing code, but you declare it as plain RGB555 and RGB565 > codes. So, are these really the normal unswapped formats or am I missing > something? And you replaced VYUY with UYVY while also modifying register > configuration, so, I hope, this has settled now and your current > configuration works properly with the unmodified pxa270 for you, right? > > Oh, damn, I see now, I put my signature above the patch, so, you didn't > look below it, and there were a couple more comments there:-( Sorry! All > of them should be pretty easy to fix, so, please have a look at them. > > > Inlined is a new version of the patch (I did some lookup through the > > datasheet). I might not need the BGR formats for now. > > > > btw. weren't you planning to merge the ov96xx drivers into .31? I havent > > seen any of them there. > > Which ov96xx drivers? Do you mean the ov9655 driver from Stefan > Herbrechtsmeier? My doubt with the latter one was (and still is), that we > already have two drivers in the mainline (gspca/sn9c20x.c and > gspca/ov534.c) that seem to claim support for that chip, so, I wanted to > see, if we could reuse them. There's also an ov7670 from Jonathan Cameron > with the same issue. And for that merge we have to come closer to > v4l2-subdev, which is happening just now. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > Here's a new patch ... YUV works, RGB might be still broken (but that can be fixed later when imagebus arrives). From: Marek Vasut Date: Sat, 22 Aug 2009 05:14:23 +0200 Subject: [PATCH] Add driver for OmniVision OV9640 sensor Signed-off-by: Marek Vasut --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile|1 + drivers/media/video/ov9640.c| 812 +++ drivers/media/video/ov9640.h| 209 ++ include/media/v4l2-chip-ident.h |1 + 5 files changed, 1029 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ov9640.c create mode 100644 drivers/media/video/ov9640.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 84b6fc1..fddd654 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -772,6 +772,12 @@ config SOC_CAMERA_OV772X help This is a ov772x camera driver +config SOC_CAMERA_OV9640 + tristate "ov9640 camera support" + depends on SOC_CAMERA && I2C + help + This is a ov9640 camera driver + config MX1_VIDEO bool diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 9f2e321..e18efd5 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o +obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o # And now the v4l2 drivers: diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c new file mode 100644 index 000..a651d2b --- /dev/null +++ b/drivers/media/video/ov9640.c @@ -0,0 +1,812 @@ +/* + * OmniVision OV96xx Camera Driver + * + * Copyright (C) 2009 Marek Vasut + * + * Based on ov772x camera driver: + * + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov7670 and soc_camera_platform driver, + * + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "ov9640.h" + +/* default register setup */ +static const struct ov9640_reg ov9640_regs_dflt[]
Re: [PATCH] hdpvr: i2c fixups for fully functional IR support
On 09/14/2009 09:32 AM, Brandon Jenkins wrote: Driver build procedure used: Cloned http://hg.jannau.net/hdpvr Pulled http://linuxtv.org/hg/v4l-dvb/ Pulled http://linuxtv.org/hg/~awalls/v4l-dvb/ This should bring in all changes for HDPVR and CX18. What specifically would you like me to test? I can't reload the modules until the kids are done watching TV. :) Whatever it was you did last time that was triggering an oops... Things I did myself were hotplugging the hdpvr after everything else was already up, and booting with the hdpvr connected (which in my case, led to it being set up before any of the other cards). -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
Dne Pá 11. září 2009 23:51:44 Guennadi Liakhovetski napsal(a): > On Fri, 4 Sep 2009, Marek Vasut wrote: > > Dne Po 24. srpna 2009 20:06:29 Guennadi Liakhovetski napsal(a): > > > Hi Marek > > > > > > On Sat, 22 Aug 2009, Marek Vasut wrote: > > > > From 479aafc9a6540efec8a691a84aff166eb0218a72 Mon Sep 17 00:00:00 > > > > 2001 From: Marek Vasut > > > > Date: Sat, 22 Aug 2009 05:14:23 +0200 > > > > Subject: [PATCH 2/3] Add driver for OmniVision OV9640 sensor > > > > > > > > Signed-off-by: Marek Vasut > > > > > > Ok, I see, you rebased your patches on my soc-camera patch-stack, this > > > is good, thanks. But you missed a couple of my comments - you still > > > have a few static functions in the ov9640.c marked inline: > > > ov9640_set_crop() is not used at all, ov9640_set_bus_param() gets > > > assigned to a struct member, so, cannot be inline. ov9640_alter_regs() > > > is indeed only called at one location, but see Chapter 15 in > > > Documentation/CodingStyle. You left at least one multi-line comment > > > wrongly formatted. You left some broken printk format lines, etc. You > > > moved your header under drivers/... - that's good. But, please, address > > > all my comments that I provided in a private review, or explain why you > > > do not agree. Otherwise I feel like I wasted my time. Besides, your > > > mailer has wrapped lines. Please, read > > > Documentation/email-clients.txt on how to configure your email client > > > to send patches properly. In the worst case, you can inline your > > > patches while reviewing, and then attach them for a final submission. > > > This is, however, discouraged, because it makes review and test of your > > > intermediate patches with wrapped lines more difficult. Also, please > > > check your patches with scripts/checkpatch.pl. > > > > Fixed patch follows, my mailer is fixed as much as possible (working on > > getting git-email to work, but that's still to be done). Please consider > > applying, thanks. > > Ok, a couple more simple questions / remarks, In principle, there's just > one principle objection - if we agree, that the correct format is BGR565 > and RGB565X, then we should change that. There's no BGR565 format > currently in the kernel, so, we'd have to add it (and the documentation > for the mercurial tree). > > Thanks > Guennadi > > > Add driver for OmniVision OV9640 sensor > > > > Signed-off-by: Marek Vasut > > --- > > drivers/media/video/Kconfig |6 + > > drivers/media/video/Makefile|1 + > > drivers/media/video/ov9640.c| 811 > > +++ drivers/media/video/ov9640.h| > > 206 ++ > > include/media/v4l2-chip-ident.h |1 + > > 5 files changed, 1025 insertions(+), 0 deletions(-) > > create mode 100644 drivers/media/video/ov9640.c > > create mode 100644 drivers/media/video/ov9640.h > > > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > > index 84b6fc1..fddd654 100644 > > --- a/drivers/media/video/Kconfig > > +++ b/drivers/media/video/Kconfig > > @@ -772,6 +772,12 @@ config SOC_CAMERA_OV772X > > help > > This is a ov772x camera driver > > > > +config SOC_CAMERA_OV9640 > > + tristate "ov9640 camera support" > > + depends on SOC_CAMERA && I2C > > + help > > + This is a ov9640 camera driver > > + > > config MX1_VIDEO > > bool > > > > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > > index 9f2e321..e18efd5 100644 > > --- a/drivers/media/video/Makefile > > +++ b/drivers/media/video/Makefile > > @@ -76,6 +76,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o > > obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o > > obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o > > obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o > > +obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o > > obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o > > > > # And now the v4l2 drivers: > > diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c > > new file mode 100644 > > index 000..289e82d > > --- /dev/null > > +++ b/drivers/media/video/ov9640.c > > @@ -0,0 +1,811 @@ > > +/* > > + * OmniVision OV96xx Camera Driver > > + * > > + * Copyright (C) 2009 Marek Vasut > > + * > > + * Based on ov772x camera driver: > > + * > > + * Copyright (C) 2008 Renesas Solutions Corp. > > + * Kuninori Morimoto > > + * > > + * Based on ov7670 and soc_camera_platform driver, > > + * > > + * Copyright 2006-7 Jonathan Corbet > > + * Copyright (C) 2008 Magnus Damm > > + * Copyright (C) 2008, Guennadi Liakhovetski > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "ov9640.h" > > + > > +/* default regist
RE: RFC: bus and data format negotiation
>> > >> > Video timings >> > - >> > >> > Once the bus is configured and the data format is set it is finally >possible >> > to determine what resolutions and framerates are supported. Here we run >into >> > a problem, though. The current V4L2 API is not clear on how that should >be >> > done. >> > >> > We have three enumeration ioctls involved in this: either >VIDIOC_ENUMSTD to >> > enumerate the supported video standards for analog TV video encoders >and >> > decoders, and VIDIOC_ENUM_FRAMESIZES/FRAMEINTERVALS to enumerate native >> > sensor resolutions and framerates. Unfortunately the spec is not clear >whether >> > ENUM_FRAMESIZES/INTERVALS really refers to the sensor (or more general, >the >> > component that is the initial source of the video stream) or to the >sizes >> > and framerates that you can capture on the video node. >> > >> > What makes this worse is that there is an essential ioctl missing: you >need >> > to have the equivalent of VIDIOC_S_STD to setup a sensor to a specific >> > resolution/framerate. Right now VIDIOC_S_FMT is used for that, but that >is >> > really meant to take an input resolution and scale it up or down to the >> > desired resolution. It is not meant to setup a sensor (or video source >or sink >> > in general) to a particular resolution. >> > >> > To fix this we need to 1) specify that the framesize/interval >enumeration >> > relates to the video source and not to the output of a possible scaler, >and >> > 2) add support for setting up a sensor to a specific size/framerate. >Murali >> > Karicheri from TI is working on something similar. >> > >> > Using S_FMT to select a particular resolution never felt right, and now >I >> > realize why. Luckily I don't think any of the webcam drivers we have >currently >> > do any scaling, so using S_FMT will still work for those and >applications do >> > not need to be modified. >> > >> > To do the sensor setup in the new-style we can either introduce a new >ioctl >> > to specify the size and use VIDIOC_S_PARM (yuck!) to setup the >framerate, or >> > we use the new video timings ioctl that Murali is working on. >> >> As yet one more example for your collection: I have an configuration with >> a sensor, that has a DSP in it. The sensor itself can perform scaling, >the >> DSP has three (!) resizing algorithms, and the SoC can scale too... >> >> > Data format negotiation >> > --- >> > >> > Depending on the bus configuration a component supports a list of data >formats. >> > The next step is to somehow coordinate both sides of the bus to select >> > compatible data formats. In many cases you can just go through the >supported >> > data formats and find matches. But this is not true in general. A >generic >> > camera framework like soc-camera either needs an optional mapping table >that >> > is supplied by the board configuration, or it should be given a >callback >> > function that can be implemented at the board level to do the matching >for >> > soc-camera (and if no function is supplied it can fallback to a default >> > matching function). >> > >> > A simple example where matching would fail is if the sensor is sending >on >> > 8 pins and the SoC receives it on 12 pins (with the lowest 4 pins >pulled >> > down). So the data format from the sensor is some 8 bit Bayer format, >while >> > the SoC receives a 12 bit Bayer format. You can try all sorts of fancy >> > heuristics to solve such problems, but in my opinion that will never be >able >> > to fully solve this data format negotiation. In the end the board >designer >> > knows exactly how to match it up, and so it is best to place the >matching code >> > at the level where that information is actually available: the platform >code. >> >> A better example is the one, that I've already mentioned several times: >> the sensor can only send 10 bits, they are connected directly to an SoC, >> that can sample 8, 9, or 10 data lines, but it always samples least >> significant ones. So, in this configuration only 10-bit data would be >> functional. But there's also an i2c multiplexer in between, thatcan >switch >> D9..D2 sensor outputs to D7..D0 SoC inputs, thus letting it also support >> 8-bit data. >> >> So, in this case: >> >> 1. the sensor shall honestly say "I can only send 10-bit data." >> >> 2. the platform callback shall make this to "you can get 8- or 10-bit >data >> from the sensor." >> >> 3. when actually configuring that 8-bit format, the platform code shall >> operate the switch and further issue a call to the sensor to set up the >> 10-bit data format. > >Exactly. Using a callback is probably the most flexible way of doing this. > >> > This type of data format matching works well in simple situations (e.g. >a >> > sensor connected to a SoC), but when you have a network of components >all >> > talking to one another it becomes impossible to manage that in a driver. >> > >> > Using the media controller it should be possible to setup the data >format >>
RFC: V4L - Support for video timings at the input/output interface
RFC: V4L - Support for video timings at the input/output interface
Thanks to Hans Verkuil for his initial proposal and feedbacks to help write
this RFC.
Version : 1.0
Background
---
Currently v4l2 specification supports capturing video frames from TV signals
using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband TV signals
(V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output side, the signals
could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR), baseband TV signal
(V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA overlay
(V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card and
then use chromakeying to replace part of the picture with the video.
V4L2_OUTPUT_TYPE_ANALOG & V4L2_INPUT_TYPE_CAMERA are for analog interfaces that
includes composite, S-Video and VGA (for output only). Note that even though
VGA is a supported output, we don't have anyway to set the standard or timing
on the output. Standard ids are only defined for TVs using
v4l2_std_id and a set of bit masks defined for analog TV standards.
Today we have a wide variety of different interfaces available to
transmit/receive video or graphics content between source device and
destination device. Following are some of the interfaces used in addition to
the ones described in the v4l2 specification.
Component analog input/output interface - ED/HD video
DVI - Digital only, ANALOG only, DVI integrated that support Digital and
Analog; Dual Link - Where second data link is used for higher
bandwidth
SDI - Serial digital interface standardized by SMPTE
HDMI - HD video and Audio
DisplayPort - digital audio/video interconnect by VESA
V4L2 specification currently defined NTSC/PAL/SECAM (all variants) standards
for describing the timing of the signal transmitted over these interfaces. Even
though the specification defined ANALOG output type for VGA, there are no ways
to set the timings used for output to VGA or LCD display monitors. Some of the
proprietary implementations used existing standards IOCTL, VIDIOC_S_STD, to set
these timings over these interfaces.
For example, TI has Video Processing Back End (VPBE) on various media SOCs
(Eg, DM6446, DM355 etc) that can output signal for Analog TV and VGA interfaces
(using Digital LCD port) and support timing for displaying SD and HD videos
(1080i, 1080p and 720p) as well as over VGA interface to a CRT or LCD display
monitor. So we need to enhance the v4l2 specification to allow applications to
set these timings in the capture or output devices. This RFC proposes to add
new IOCTLs for setting/getting timings over the different interfaces described
above and freeze the the use of existing standards
IOCTL and standards IDs for analog TVs only.
Timings
---
The timing at the analog or digital interface that are not covered by the
v4l2_std_id can be defined using a set of preset timings that are used by the
hardware where these timings are predefined or by a set of timing values which
can be configured at the hardware to generate the signal expected at the
interface. The former will be used for hardware like TVP7002/THS8200 which
specifies preset timing required for output HD video such 1080i50/60, 720p50/60
etc. The latter can be used for hardware that require configuration of frame
timing such as front porch, hsync length, vsync length, pixel clock etc. For
example the earlier mentioned TI SOCs has a Digital LCD port that can be
configured to output different timing values expected by LCD Display monitors.
Preset timings (defined by VESA, SMPTE or BT.656/BT.1120 or others) can be
defined by the following structure:-
struct v4l2_dv_preset {
__u32 preset;
__u32 reserved[4];
};
Where preset is one of the following values:-
#define V4L2_DV_CUSTOM0x
#define V4L2_DV_480I59_94 0x0001
#define V4L2_DV_480I600x0002
#define V4L2_DV_480P23_9760x0003
#define V4L2_DV_480P240x0004
#define V4L2_DV_480P29_97 0x0005
#define V4L2_DV_480P300x0006
#define V4L2_DV_576I500x0007
#define V4L2_DV_576P250x0008
#define V4L2_DV_576P500x0009
#define V4L2_DV_720P23_9760x000A
#define V4L2_DV_720P240x000B
#define V4L2_DV_720P250x000C
#define V4L2_DV_720P29_97 0x000C
#define V4L2_DV_720P300x000D
#define V4L2_DV_720P500x000E
#define V4L2_DV_720P59_94 0x000F
#define V4L2_DV_720P600x0010
#define V4L2_DV_1080I50 0x0011
#define V4L2_DV_1080I59_940x0012
#define V4L2_DV_1080I60 0x0013
#define V4L2_DV_1080P23_976 0x0014
#define V4L2_DV_1080P24 0x0015
#define V4L2_DV_1080P25 0x0016
#define V4L2_DV_1080P29_970x0017
#define V4L2_DV_1080P30 0x0018
Re: Problems with Pinnacle 310i (saa7134) and recent kernels
Hi, hermann pitton arcor.de> writes: > no, in this case I meant mplayer should work for you too. > You need to have DVB support enabled and a channels.conf file in > ~/.mplayer. It's compiled with --enable-dvbhead, and the channels.conf is made by w_scan, but I tried even with a made by scan one. > We might collect pictures of the cards and remotes as well. > To identify those card with an additional LNA circuitry is likely not > easy hardware wise, since the tuner shielding is soldered with 16 pins, > many close to lines. Maybe we can identify those boards by the card > revision printed on them. Don't know how to auto detect them. I will post some photos. > > In the matter of the IR, the modules seems to be loaded: > > > > tda1004x 13048 1 > > saa7134_dvb20772 0 > > videobuf_dvb5644 1 saa7134_dvb > > ir_kbd_i2c 5500 0 > > tda827x 8880 2 > > tuner 16960 1 > > saa7134 138436 1 saa7134_dvb > > ir_common 41828 2 ir_kbd_i2c,saa7134 > > videobuf_dma_sg 9876 2 saa7134_dvb,saa7134 > > videobuf_core 13596 3 videobuf_dvb,saa7134,videobuf_dma_sg > > tveeprom 10488 1 saa7134 > > > > But I can't find anything in /proc/bus/input/devices. > > We might have more than the two supported remotes on such cards. > After all that would not make me wonder anymore and the windows driver > presents some more. Do you have that silver remote with colored buttons. > There must be a device at 0x47 detected to support it. Yes that is: http://www.hwp.ru/Tvtuners/Pinnaclehybridpro.pci /Pinnaclepctvhybridpropci-1sm.jpg > You might have to load ir-kbd-i2c at first or reload saa7134-alsa and > saa7134-dvb, which includes saa7134. I've unloaded all modules, then loaded first ir-kbd-i2c and next saa7134-dvb, but I can't see any difference. Loading saa7134 with ir_debug=1 and i2c_debug=1 I can see some of these errors: saa7133[0]: i2c xfer: < 8e ERROR: NO_DEVICE saa7133[0]: i2c xfer: < e2 ERROR: NO_DEVICE saa7133[0]: i2c xfer: < 5a ERROR: NO_DEVICE > > > The only other issue I'm aware of is that radio is broken since guessed > > > 8 weeks on my tuners, only realized when testing on enabling external > > > active antenna voltage for DVB-T on a/some 310i. > > > > > > Might be anything, hm, hopefully I should not have caused it ;) > > > > The radio works for me, even if there's much noise (I don't usually use it). > > I'm using the internal audio cable. > > The radio is broken for all tuners, you must be on older stuff. Using 2.6.31 and mplayer it really works for me. > I finally found the time to do the mercurial bisect today. > > It is broken since Hans' changeset 12429 on seventh August. > > Cheers, > Hermann Thank you! -- 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] hdpvr: i2c fixups for fully functional IR support
Driver build procedure used: Cloned http://hg.jannau.net/hdpvr Pulled http://linuxtv.org/hg/v4l-dvb/ Pulled http://linuxtv.org/hg/~awalls/v4l-dvb/ This should bring in all changes for HDPVR and CX18. What specifically would you like me to test? I can't reload the modules until the kids are done watching TV. :) Thanks, Brandon -- 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: tuner, code for discuss
On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov wrote: > Hi All > > This is my next patch. > > Changes: > 1. By default charge pump is ON > 2. For radio mode charge pump set to OFF > 3. Set correct AGC value in radio mode > 4. Add control gain of AGC. > 5. New function simple_get_tv_gain and simple_set_tv_gain for read/write gain > of AGC. > 6. Add some code for control gain from saa7134 part. By default this control > is OFF 7. When TV card can > manipulate this control, enable it. > > Main changes is control value of AGC TOP in .initdata = tua603x_agc112 array. > Use this value for set AGC TOP after set freq of TV. > > I don't understand how to correct call new function for read/write value of > AGC TOP. > > What you think about it?? > [patch snipped] > > > With my best regards, Dmitry. Dmitry, The direct usage of .initdata and .sleepdata is probably unnecessary here -- If you trace how the tuner-simple driver works, you'll find that simply having these fields defined will cause these bytes to be written at the appropriate moment. However, for the actual sake of setting this gain value, I'm not sure that initdata / sleep data is the right place for it either. (I know that I recommended something like this at first, but at the time I didn't realize that there is a range of six acceptable values for this field) What I would still like to understand is: Who will be changing this value? I see that you've added a control to the saa7134 driver -- is this to be manipulated from userspace? Under what conditions will somebody want to change this value? How will users know that they need to alter this gain value? Apologies for the late response. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tda18271 add FM filter selction + minor fixes
On Sun, Sep 13, 2009 at 8:14 PM, wrote: > > This patch adds support for FM filter selection. The tda18271 has two rf > inputs RF_IN (45-864 MHz) and FM_IN (65-108 MHz). The code automatically > enables the antialiasing filter for radio reception and depending on the > FM input selected configures EB23 register. > > Additional fixes: > - Fixed the temerature comensation, see revision history of TDA18271HD_4 > spec. > - Minor cosmetic change in the tda18271_rf_band[] > - Fixed one value and removed a duplicate in tda18271_cid_target[] > > Signed-off-by: henk.vergo...@gmail.com > > Henk, Thank you for your patch. I have some other tda18271 patches pending merge currently, so it will be a few days before I'll be able to test and merge your patch. In the meanwhile, I'd request that this single patch be broken down into three separate patches, each with a description of the change and sign-off. I know that the patch you sent in is small, I just prefer to apply changes separately. Do you have FM radio working on the Zolid board after applying this? Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Media controller: sysfs vs ioctl
Hi, In our experience, sysfs was useful for simple control mechanism such as enable/disable or displaying statistics or status. But we had received customer complaints that with this approach, these functionality will become unavailable when kernel is built without sysfs as part of size optimization. So if this is really true, I don't think sysfs is the right candidate for MC. Since sysfs is more string oriented, won't it increase the code size when it is used for parsing a lot of variable/value pair to setup device hw configuration ? Besides, most of the application that is written for TI video drivers are based on ioctl and it would make technical support a nightmare with a different API used for device configuration. Murali From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab [mche...@infradead.org] Sent: Sunday, September 13, 2009 7:31 PM To: wk Cc: Hans Verkuil; linux-media@vger.kernel.org Subject: Re: Media controller: sysfs vs ioctl Em Sun, 13 Sep 2009 17:54:11 +0200 wk escreveu: > Hans Verkuil schrieb: > > Hi all, > > > > I've started this as a new thread to prevent polluting the discussions of > > the > > media controller as a concept. > > > > First of all, I have no doubt that everything that you can do with an ioctl, > > you can also do with sysfs and vice versa. That's not the problem here. > > > > The problem is deciding which approach is the best. > > > > > > Is it really a good idea to create a dependency to some virtual file > system which may go away in future? > From time to time some of those seem to go away, for example devfs. > Is it really unavoidable to have something in sysfs, something which is > really not possible with ioctls? > And do you really want to depend on sysfs developers? First of all, both ioctl's and sysfs are part of vfs support. Second: where did you got the wrong information that sysfs would be deprecated? There's no plan to deprecate sysfs, and, since there are lots of kernel-userspace API's depending on sysfs, you can't just remove it. It is completely different from what we had with devfs, where just device names were created there, on a limited way (for example, no directories were allowed at devfs). Yet, before devfs removal, sysfs was added to implement the same features, providing even more functionality. Removing sysfs is as hard as removing ioctl or procfs support on kernel. You may change their internal implementation, but not the userspace API. Btw, if we'll seek for the last internal changes, among those three API's, the more recent internal changes were at fs API where ioctl support is. There, the Kernel big logs were removed. This required a review on all driver locks and changes on almost all v4l/dvb drivers. Also, wanting or not, sysfs is called on every kernel driver, so this dependency already exists. 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 -- 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 USB stream parameters
I don't know exactly why (the USB/HW background for that is not present in my brain), but at some point having less than 39480B for one (high-level) URB for the dib0700 resulted in never having any URB returning from the USB stack. I chose 4 of them because .. I don't remember. It seems even 1 is working. I vote for a single high-level URB. Besides the memory savings this is the only way I could get my nova-td stick working. (see this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html ) The patch runs flawlessly on my vdr system for months now. I remember someone telling me that this is due to something in the firmware. I need to wait for some people to be back from whereever they are to know exactly what's going on (that's why I haven't responded yet). I hope you can sort out the dib0700_streaming_ctrl problems... Soeren -- 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://udev.netup.ru/hg/v4l-dvb-commits
Hello, Fixed. Try again please. On Sunday 13 September 2009 17:44:34 Mauro Carvalho Chehab wrote: > Em Wed, 9 Sep 2009 19:21:12 +0300 > > "Igor M. Liplianin" escreveu: > > Mauro, > > > > Please pull from http://udev.netup.ru/hg/v4l-dvb-commits > > I can't reach the server. the connection dies at utm.netup.ru. > > traceroute -n udev.netup.ru > traceroute to udev.netup.ru (77.72.80.20), 30 hops max, 40 byte packets > 1 * * * > 2 * * * > 3 * * * > 4 201.0.87.225 70.096 ms 70.345 ms 77.659 ms > 5 201.0.5.69 125.153 ms 201.0.5.65 77.956 ms 201.0.5.69 125.311 ms > 6 201.63.253.110 85.516 ms 200.100.98.97 63.072 ms 200.100.98.173 > 63.234 ms 7 84.16.6.193 63.207 ms 84.16.9.109 70.806 ms 84.16.6.141 > 63.449 ms 8 213.140.36.13 173.869 ms 213.140.43.109 181.653 ms > 213.140.36.69 174.597 ms 9 84.16.13.53 213.031 ms 84.16.12.221 197.664 > ms 84.16.13.53 205.391 ms 10 213.140.55.90 228.586 ms 229.547 ms > 228.847 ms > 11 207.138.94.70 339.372 ms 347.711 ms 340.608 ms > 12 62.140.245.174 340.202 ms 332.198 ms 339.701 ms > 13 193.203.36.250 348.137 ms 347.738 ms 348.086 ms > 14 193.203.36.250 3140.511 ms !H 3037.629 ms !H 2998.439 ms !H > > > for the following changeset: > > > > 01/01: Fix gpio mutex in NetUP Dual DVB-S2 CI card. > > http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=2f1119c624eb > > > > > > cimax2.c | 12 ++-- > > cx23885-core.c |1 + > > cx23885.h |1 + > > 3 files changed, 8 insertions(+), 6 deletions(-) > > > > Thanks, > > Igor > > > > -- > > 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 > > 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 -- 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: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support, giving up.
So, if i understand correctly, i should change "in" to 0xBF to get the missing bit. ( and if it work, i will be able to use ir_codes_adstech_dvb_t_pci instead of rolling my own keymap ) Thanks. hermann pitton a écrit : Hi, Am Sonntag, den 13.09.2009, 23:59 +0200 schrieb Morvan Le Meut: just out of curiosity ( and because google showed me a new trick to try ), i tried to load the module with gpio_tracking=1. this gave me a new thing in dmesg : gpio: mode=0x000 in=0x07f out=0x000 [pre-init] Am i correct by thinkig that the in=0x07f part is the mask ? If it is that then i am a problem : i did specify it as 0xff. Did i miss something ? it does not cover the IR gpio settings, but what happens in the card entry at saa7134-cards.c. "mode" is the gpio mask defined there, if any. You have nothing set there. "in" is the actual configuration of the gpio pins. This can reflect changes made to them, for example from using an other cards entry previously, which can change some pins or changes in different modes on them, which are not yet reset. By default it shows the manufacturers gpio configuration. 0x7f can mean that the first seven pins (0-6) are used for the gpio remote. That would be your mask keycode then. "out" is what the driver writes to the gpios of that card. In this mode only pins are changed, which are high in the mask, this is called masked writes. In your case nothing happens. See my next mail for a simple example of changing the single gpio21 pin to 0 in Television mode. 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
