Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
Hi Laurent,
2010-12-15 오전 9:19, Laurent Pinchart 쓴 글:
> Hi,
>
> (CC'ing linux-media this time, please discard the previous mail)
>
> On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
>> Hi Laurent and Hans,
>>
>> I am working on V4L2 subdev for M5MOLS by Fujitsu.
>> and I wanna listen your comments about Auto Focus mode of my ideas.
>> the details is in the following link discussed at the past.
>> Although the situation(adding the more various functions at the M5MOLS
>> or any other MEGA camera sensor, I worked.)is changed,
>> so I wanna continue this threads for now.
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
>>
>> First of all, the at least two more mode of auto-focus exists in the
>> M5MOLS camera sensor. So, considering defined V4L2 controls and the
>> controls in the M5MOLS, I suggest like this:
>>
>> +enum v4l2_focus_auto_type {
>> +V4L2_FOCUS_AUTO_NORMAL = 0,
>> +V4L2_FOCUS_AUTO_MACRO = 1,
>> +V4L2_FOCUS_AUTO_POSITION = 2,
>> +};
>> +#define V4L2_CID_FOCUS_POSITION
>> (V4L2_CID_CAMERA_CLASS_BASE+13)
>>
>> -#define V4L2_CID_ZOOM_ABSOLUTE
>> (V4L2_CID_CAMERA_CLASS_BASE+13)
>> -#define V4L2_CID_ZOOM_RELATIVE
>> (V4L2_CID_CAMERA_CLASS_BASE+14)
>> +#define V4L2_CID_ZOOM_ABSOLUTE
>> (V4L2_CID_CAMERA_CLASS_BASE+14)
>> +#define V4L2_CID_ZOOM_RELATIVE
>> (V4L2_CID_CAMERA_CLASS_BASE+15)
>>
>>
>> The M5MOLS(or other recent camera sensor) can have at least 2 mode although
>> in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports
>> positioning focus mode, AKA. POSITION AF mode.
>>
>> The MACRO mode scan short range, and this mode can be used at the
>> circumstance in the short distance with object and camera lens. So, It has
>> fast lens movement, but the command FOCUSING dosen't works well at the
>> long distance object.
>>
>> On the other hand, NORMAL mode can this. As the words, It's general and
>> normal focus mode. The M5MOLS scan fully in the mode.
>>
>> In the Position AF mode, the position(expressed x,y) is given at the
>> M5MOLS, and then the M5MOLS focus this area. But, the time given the
>> position, is normally touch the lcd screen at the mobile device, in my
>> case. If the time is given from button, it's no big problem *when*. But,
>> in touch-lcd screen case, the position is read at the touch screen driver,
>> before command FOCUS to camera sensor. It's the why I add another
>> CID(V4L2_CID_FOCUS_POSITION).
>
> I'm pretty sure that some devices would require a rectangle instead of
> coordinates to define the focus point. Even a rectangle might not be enough.
> It would help if we could get feedback from camera designers here.
>
> Hans, should we add a new control type to pass coordinates/rectangles ? :-)
>
Very glad to be sure that.
As you know, the recent camera sensor embedded in mobile devices has evoluted
rapidly in a decade. It's not digital camera, but it operates like digital
camera. Actually, the camera sensor module with ISP in the recent mobile device
use the same one in the digital camera. And I can let you know this newer
control types, like in a uppper FOCUS case.(e.g.,iso, exposure, wb, wdr(wide
dynamic range), effects, the method to get jpeg bulk streams with sync, even
face detections.)
So, I'll make general patch or RFC patch about new control types which is
needed at
the the mobile device, based on M5MOLS and some sensors else, for generality.
(considering another ISP like a NEC, Samsung sensor modules. It is available
for me.)
After that, I'm glad with being reviewed it to Hans and Laurent.
(Actually, I don't know who is the maintainer of CID of camera. Let me know,
plz. :-) )
If Laurent and Hans agree with that, I'll prepare patch works.
Thanks for reading.
ps. I wanna know where the recent v4l2 control is described, as already told
at the previous my mail.
Regards,
HeungJun Kim
--
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: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
On Wednesday, December 15, 2010 01:19:43 Laurent Pinchart wrote:
> Hi,
>
> (CC'ing linux-media this time, please discard the previous mail)
>
> On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
> > Hi Laurent and Hans,
> >
> > I am working on V4L2 subdev for M5MOLS by Fujitsu.
> > and I wanna listen your comments about Auto Focus mode of my ideas.
> > the details is in the following link discussed at the past.
> > Although the situation(adding the more various functions at the M5MOLS
> > or any other MEGA camera sensor, I worked.)is changed,
> > so I wanna continue this threads for now.
> >
> > http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
> >
> > First of all, the at least two more mode of auto-focus exists in the
> > M5MOLS camera sensor. So, considering defined V4L2 controls and the
> > controls in the M5MOLS, I suggest like this:
> >
> > +enum v4l2_focus_auto_type {
> > + V4L2_FOCUS_AUTO_NORMAL = 0,
> > + V4L2_FOCUS_AUTO_MACRO = 1,
> > + V4L2_FOCUS_AUTO_POSITION = 2,
> > +};
> > +#define V4L2_CID_FOCUS_POSITION
> > (V4L2_CID_CAMERA_CLASS_BASE+13)
> >
> > -#define V4L2_CID_ZOOM_ABSOLUTE
> > (V4L2_CID_CAMERA_CLASS_BASE+13)
> > -#define V4L2_CID_ZOOM_RELATIVE
> > (V4L2_CID_CAMERA_CLASS_BASE+14)
> > +#define V4L2_CID_ZOOM_ABSOLUTE
> > (V4L2_CID_CAMERA_CLASS_BASE+14)
> > +#define V4L2_CID_ZOOM_RELATIVE
> > (V4L2_CID_CAMERA_CLASS_BASE+15)
> >
> >
> > The M5MOLS(or other recent camera sensor) can have at least 2 mode although
> > in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports
> > positioning focus mode, AKA. POSITION AF mode.
> >
> > The MACRO mode scan short range, and this mode can be used at the
> > circumstance in the short distance with object and camera lens. So, It has
> > fast lens movement, but the command FOCUSING dosen't works well at the
> > long distance object.
> >
> > On the other hand, NORMAL mode can this. As the words, It's general and
> > normal focus mode. The M5MOLS scan fully in the mode.
> >
> > In the Position AF mode, the position(expressed x,y) is given at the
> > M5MOLS, and then the M5MOLS focus this area. But, the time given the
> > position, is normally touch the lcd screen at the mobile device, in my
> > case. If the time is given from button, it's no big problem *when*. But,
> > in touch-lcd screen case, the position is read at the touch screen driver,
> > before command FOCUS to camera sensor. It's the why I add another
> > CID(V4L2_CID_FOCUS_POSITION).
>
> I'm pretty sure that some devices would require a rectangle instead of
> coordinates to define the focus point. Even a rectangle might not be enough.
> It would help if we could get feedback from camera designers here.
>
> Hans, should we add a new control type to pass coordinates/rectangles ? :-)
It's a bit tricky actually since QUERYCTRL can return only one set of min/max
values. For coordinates/rectangles we need two sets (horizontal and vertical).
And I think it is important to know the min/max values.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: Hauppauge HVR-2200 analog
Am 14.12.2010 um 20:51 schrieb Steven Toth: > On 12/14/10 12:23 PM, Julian Scheel wrote: >> Is there any reason, why the additional card-information found here: >> http://www.kernellabs.com/hg/~stoth/saa7164-dev/ >> is not yet in the kernel tree? > > On my todo list. Ok, fine. > I validate each board before I add its profile to the core tree. If certain > boards are missing then its because that board is considered experimental or > is > pending testing and merge. > > PAL encoder support is broken in the current tree and it currently getting my > love and attention. Point me at the specific boards you think are missing and > I'll also add these to my todo list, they'll likely get merged at the same > time. Actually this is the board I am testing with: http://www.kernellabs.com/hg/~stoth/saa7164-dev/rev/cf2d7530d676 Should it work with your testing tree or is the encoder part broken there as well? Julian-- 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] bttv: fix mutex use before init
On Tue, Dec 14, 2010 at 10:43 PM, Brandon Philips wrote: > On 21:56 Tue 14 Dec 2010, Torsten Kaiser wrote: >> On Tue, Dec 14, 2010 at 1:30 AM, Brandon Philips wrote: >> > On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote: >> >> * change &fh->cap.vb_lock in bttv_open() AND radio_open() to >> >> &btv->init.cap.vb_lock >> >> * add a mutex_init(&btv->init.cap.vb_lock) to the setup of init in >> >> bttv_probe() >> > >> > That seems like a reasonable suggestion. An openSUSE user submitted this >> > bug to our tracker too. Here is the patch I am having him test. >> > >> > Would you mind testing it? >> >> No. :-) >> >> Without this patch (==vanilla 2.6.37-rc5) I got 2 more OOPSe by >> restarting hal around 20 times. >> After applying this patch, I did not see a single OOPS after 100 restarts. >> So it looks like the fix is correct. > > Dave, Torsten- Great thanks for testing, can I get both you and Dave's > Tested-by then? Tested-by: Torsten Kaiser Thanks for providing this patch. Torsten -- 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: tm6000 and IR
Hi Stefan > Am 14.12.2010 04:23, schrieb Dmitri Belimov: > > Hi > > > > What about my last patch?? This is OK or bad? > > Our customers kick me every day with IR remotes. > > > > With my best regards, Dmitry. > I think, you use the second variant, Dmitry. > Why you doesn't use this key map - RCMAP_BEHOLD. No this remotes is different. RCMAP_BEHOLD has more buttons and some other scancodes. People from linux community who was made this keymap and function for reading data from IR decoder has error with scancode. Our true address of scancode is 0x86 0x6B They wrote 0x6B 0x86 Need fix some code of the saa7134-input and RCMAP_BEHOLD keytable. RCMAP_BEHOLD_WANDER same as RCMAP_BEHOLD_COLUMBUS but from IR decoder the saa7134 received only one byte of scancode. Need rework saa7134-input too for get address and restore full scancodes for extended NEC full scancodes. I'll make it after some time. > The power led we can change to a separate function, right. Ok > The nec initiation looks right and must adding code for tm5600/6000 (going > over message pipe). I haven't USB stick with tm5600/6000 for test. Need people with this TV cards. > rc5 need some code for tm6010 (for tm5600/6000 are the hack). I didn't touch this code because I haven't RC5 remotes and tm5600/6000 > And the logic for your remote control is unused for > the second variant, but ir->rc_type = rc_type are o.k.. I think your mean is wrong. Our IR remotes send extended NEC it is 4 bytes. We removed inverted 4 byte and now we have 3 bytes from remotes. I think we must have full RCMAP with this 3 bytes from remotes. And use this remotes with some different IR recievers like some TV cards and LIRC-hardware and other. No need different RCMAP for the same remotes to different IR recievers like now. If we use second variant I can't use RCMAP_BEHOLD because it has full 3 bytes scancodes. As you wrote. > Then the function call usb_set_interface in tm6000_video, can write > for example: > > stop_ir_pipe > usb_set_interface > start_ir_pipe Ok, I'll try. > I will adding vbi_buffer and device in the next, and isoc calculating > without video_buffer size. I try add radio. 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: Simple request : mini-pcie analog TV capture card
On Wed, Dec 15, 2010 at 6:33 AM, Markus Rechberger wrote: > Hi, > > On Wed, Dec 15, 2010 at 1:25 AM, Fernando Laudares Camargos > wrote: >> >> Hello List, >> >> I'm after a somehow quite simple information: I'm looking for a >> mini-pcie TV tuner/capture card. I simply need to plug my cable TV >> decoder to such a card to "watch" TV on Linux. I've got success with a >> Hauppauge 950Q USB stick and TV time but this is not a one-time >> project and we would need to replicate it in a somehow large scale, so >> a mini-pcie card would fit the hardware best. >> >> Does anybody know any mini-pcie model analog card that are still >> available on the market and that is compatible with this need ? >> >> I've looked at linuxtv.org lists but couldn't find one. >> >> Habey has a new model, based on the ATI Theater 750 HD chip, which is >> not supported. >> >> AVerMedia has some models too, but none seems to have analog mode >> working on Linux. >> >> Any suggestions would be kindly appreciated. >> > > We have MiniPCIe AnalogTV devices which are very well supported. > > Basically those devices are using the USB Pins of the MiniPCIe Bus. > All worldwide standards are supported, we have > ATSC/clearQAM/analogTV(NTSC)/VBI/FM-Radio/composite and s-video > are available through reserved pin routing. > A European version is also available. > > Tested applications > * http://tvtime.sourceforge.net tvtime > * http://www.videolan.org/vlc/ VLC > * http://www.mplayerhq.hu/design7/news.html Linux mplayer > * http://www.mythtv.org/ MythTV > * http://linux.bytesex.org/xawtv/ XawTV > * http://zapping.sourceforge.net/Zapping/index.html Zapping > * http://ekiga.org/ Ekiga VOIP (Channel 0: TV Channel 1: Composite > Channel 2: S-Video) > * http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome Motion detection > Software > > http://support.sundtek.com/index.php/topic,4.0.html Sent the wrong link, this one is for ATSC (the other one is the european version): http://support.sundtek.com/index.php/topic,87.0.html > http://sundtek.com/images/vivi.png (some virtual driver emulation for testing) > > Setup shouldn't take longer than a few seconds > > Best Regards, > Markus > -- 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: Simple request : mini-pcie analog TV capture card
Hi, On Wed, Dec 15, 2010 at 1:25 AM, Fernando Laudares Camargos wrote: > > Hello List, > > I'm after a somehow quite simple information: I'm looking for a > mini-pcie TV tuner/capture card. I simply need to plug my cable TV > decoder to such a card to "watch" TV on Linux. I've got success with a > Hauppauge 950Q USB stick and TV time but this is not a one-time > project and we would need to replicate it in a somehow large scale, so > a mini-pcie card would fit the hardware best. > > Does anybody know any mini-pcie model analog card that are still > available on the market and that is compatible with this need ? > > I've looked at linuxtv.org lists but couldn't find one. > > Habey has a new model, based on the ATI Theater 750 HD chip, which is > not supported. > > AVerMedia has some models too, but none seems to have analog mode > working on Linux. > > Any suggestions would be kindly appreciated. > We have MiniPCIe AnalogTV devices which are very well supported. Basically those devices are using the USB Pins of the MiniPCIe Bus. All worldwide standards are supported, we have ATSC/clearQAM/analogTV(NTSC)/VBI/FM-Radio/composite and s-video are available through reserved pin routing. A European version is also available. Tested applications * http://tvtime.sourceforge.net tvtime * http://www.videolan.org/vlc/ VLC * http://www.mplayerhq.hu/design7/news.html Linux mplayer * http://www.mythtv.org/ MythTV * http://linux.bytesex.org/xawtv/ XawTV * http://zapping.sourceforge.net/Zapping/index.html Zapping * http://ekiga.org/ Ekiga VOIP (Channel 0: TV Channel 1: Composite Channel 2: S-Video) * http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome Motion detection Software http://support.sundtek.com/index.php/topic,4.0.html http://sundtek.com/images/vivi.png (some virtual driver emulation for testing) Setup shouldn't take longer than a few seconds Best Regards, Markus -- 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
Leadtek DTV2000DS - no channel lock
Hi all. I have 2 Leadtek DTV2000DS PCI tuners in my mythtv pc. This is a AF9015 + AF9013 + NXP TDA18211 based PCI card. The tuner is detected as TDA18271. (see http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards#Leadtek) My issue is that I can't lock onto any channel. My PC is: MB: Asus M4A87TD-USB3 AM3 CPU: AMD Athlon II X2 250 3 GHz RAM: Kingston 2 Gb single PC10666 (1333 MHz) PSU: Zalman ZM500-HP 500 W Storage: 2x WD 1Tb Caviar Blue 7200 RPM SATAII OS disc: Kingston 64 Gb SSD SNV425-S2 GPU: 512Mb Winfast NVidia 8400GS Remote: Hauppauge MCE remote I am running Mythbuntu 10.04, updated to the 2.6.32-26-generic kernel. MythTV is currently at version 0.24. w_scan shows that channels exist, but cannot lock on to them. It fails with either "no signal" or " __tune_to_transponder:1733: ERROR: FE_READ_STATUS failed: 121 Remote I/O error" Scanning in Mythtv 0.24 shows a signal strength of ~65-70% and gives me approx. 28 channels (Melbourne, Australia), but I can't lock on to any to watch them. http://linuxtv.org/wiki/index.php/Leadtek_WinFast_DTV2000DS#Making_it_work_in_Ubuntu has some recent updates dealing with different sample freqs and i2c fixes. As far as I know, I've applied them all. The output of uname, dmesg and w_scan is given below. I've inspected the output of compiling the V4L drivers (http://linuxtv.org/hg/v4l-dvb/rev/abd3aac6644e) and I can't see any error messages. I did a make clean before compiling. Are there any suggestions on what I can do from here? Some other questions: * What does the " __tune_to_transponder:1733: ERROR: FE_READ_STATUS failed: 121 Remote I/O error" error mean? * Are there any suggestions on cleaning before making? ie, how to do it? I just ran "$make clean" * Any other logs to inspect? (I've seen /var/log/messages and syslog mentioned elsewhere) * Blow everything away and start again? (I'm 95% sure I still have the V4L drivers I originally downloaded in late September, when I put this together) ( I don't really want to have to do this, but will if I have to...) * Try a newer kernel? dmesg does warn that the driver has been backported to an older kernel. Thanks Matthew ** $uname -a Linux matthew-desktop 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24 09:00:03 UTC 2010 i686 GNU/Linux ** $dmesg (after a cold start; grepped for dvb, af901 and tda18271) [3.851105] WARNING: You're using an experimental version of the DVB stack. As the driver [3.851107] is backported to an older kernel, it doesn't offer enough quality for [3.851108] its usage in production. [3.851109] Use it with care. [4.495703] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in cold state, will try to load a firmware [4.495709] usb 4-1: firmware: requesting dvb-usb-af9015.fw [4.505186] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [4.588950] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in warm state. [4.588994] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [4.589344] DVB: registering new adapter (Leadtek WinFast DTV2000DS) [4.623460] af9013: firmware version:5.1.0 [4.628354] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [4.644423] tda18271 0-00c0: creating new instance [4.650848] TDA18271HD/C2 detected @ 0-00c0 [4.937877] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [4.938338] DVB: registering new adapter (Leadtek WinFast DTV2000DS) [5.660964] af9013: found a 'Afatech AF9013 DVB-T' in warm state. [5.663592] af9013: firmware version:5.1.0 [5.674971] DVB: registering adapter 1 frontend 0 (Afatech AF9013 DVB-T)... [5.675104] tda18271 1-00c0: creating new instance [5.680074] TDA18271HD/C2 detected @ 1-00c0 [5.992172] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:14.4/:02:06.2/usb4/4-1/input/input5 [5.992215] dvb-usb: schedule remote query interval to 150 msecs. [5.992218] dvb-usb: Leadtek WinFast DTV2000DS successfully initialized and connected. [6.562561] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in cold state, will try to load a firmware [6.562565] usb 5-1: firmware: requesting dvb-usb-af9015.fw [6.563871] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [6.636225] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in warm state. [6.636273] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [6.636725] DVB: registering new adapter (Leadtek WinFast DTV2000DS) [6.639709] af9013: firmware version:5.1.0 [6.644592] DVB: registering adapter 2 frontend 0 (Afatech AF9013 DVB-T)... [6.644730] tda18271 2-00c0: creating new instance [6.651093] TDA18271HD/C2 detected @ 2-00c0 [6.961757] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [
Re: [PATCH] bttv: fix mutex use before init
On Wed, Dec 15, 2010 at 5:43 AM, Brandon Philips wrote: > On 21:56 Tue 14 Dec 2010, Torsten Kaiser wrote: >> On Tue, Dec 14, 2010 at 1:30 AM, Brandon Philips wrote: >> > On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote: >> >> * change &fh->cap.vb_lock in bttv_open() AND radio_open() to >> >> &btv->init.cap.vb_lock >> >> * add a mutex_init(&btv->init.cap.vb_lock) to the setup of init in >> >> bttv_probe() >> > >> > That seems like a reasonable suggestion. An openSUSE user submitted this >> > bug to our tracker too. Here is the patch I am having him test. >> > >> > Would you mind testing it? >> >> No. :-) >> >> Without this patch (==vanilla 2.6.37-rc5) I got 2 more OOPSe by >> restarting hal around 20 times. >> After applying this patch, I did not see a single OOPS after 100 restarts. >> So it looks like the fix is correct. > > Dave, Torsten- Great thanks for testing, can I get both you and Dave's > Tested-by then? Feel free to add my tested-by line for this, Thanks > > Mauro- can you please pick up this patch? > > Cheers, > > Brandon > -- Regards 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
[PATCH v2] [media] s5p-fimc: fix the value of YUV422 1-plane formats
Some color formats are mismatched in s5p-fimc driver.
CICICTRL[1:0], order422_out, should be set 2b'00 not 2b'11
to use V4L2_PIX_FMT_YUYV. Because in V4L2 standard V4L2_PIX_FMT_YUYV means
"start + 0: Y'00 Cb00 Y'01 Cr00 Y'02 Cb01 Y'03 Cr01". According to datasheet
2b'00 is right value for V4L2_PIX_FMT_YUYV.
-
bit |MSBLSB
-
00 | Cr1Y3Cb1Y2Cr0Y1Cb0Y0
-
01 | Cb1Y3Cr1Y2Cb0Y1Cr0Y0
-
10 | Y3Cr1Y2Cb1Y1Cr0Y0Cb0
-
11 | Y3Cb1Y2Cr1Y1Cb0Y0Cr0
-
V4L2_PIX_FMT_YVYU, V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_VYUY are also mismatched
with datasheet. MSCTRL[17:16], order2p_in, is also mismatched
in V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YVYU.
Signed-off-by: Hyunwoong Kim
Reviewed-by: Jonghun han
---
Changes since V1:
=
- make corrections directly in function fimc_set_yuv_order
commented by Sylwester Nawrocki.
- remove S5P_FIMC_IN_* and S5P_FIMC_OUT_* definitions from fimc-core.h
drivers/media/video/s5p-fimc/fimc-core.c | 16
drivers/media/video/s5p-fimc/fimc-core.h | 12
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 7f56987..71e1536 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -448,34 +448,34 @@ static void fimc_set_yuv_order(struct fimc_ctx *ctx)
/* Set order for 1 plane input formats. */
switch (ctx->s_frame.fmt->color) {
case S5P_FIMC_YCRYCB422:
- ctx->in_order_1p = S5P_FIMC_IN_YCRYCB;
+ ctx->in_order_1p = S5P_MSCTRL_ORDER422_YCRYCB;
break;
case S5P_FIMC_CBYCRY422:
- ctx->in_order_1p = S5P_FIMC_IN_CBYCRY;
+ ctx->in_order_1p = S5P_MSCTRL_ORDER422_CBYCRY;
break;
case S5P_FIMC_CRYCBY422:
- ctx->in_order_1p = S5P_FIMC_IN_CRYCBY;
+ ctx->in_order_1p = S5P_MSCTRL_ORDER422_CRYCBY;
break;
case S5P_FIMC_YCBYCR422:
default:
- ctx->in_order_1p = S5P_FIMC_IN_YCBYCR;
+ ctx->in_order_1p = S5P_MSCTRL_ORDER422_YCBYCR;
break;
}
dbg("ctx->in_order_1p= %d", ctx->in_order_1p);
switch (ctx->d_frame.fmt->color) {
case S5P_FIMC_YCRYCB422:
- ctx->out_order_1p = S5P_FIMC_OUT_YCRYCB;
+ ctx->out_order_1p = S5P_CIOCTRL_ORDER422_YCRYCB;
break;
case S5P_FIMC_CBYCRY422:
- ctx->out_order_1p = S5P_FIMC_OUT_CBYCRY;
+ ctx->out_order_1p = S5P_CIOCTRL_ORDER422_CBYCRY;
break;
case S5P_FIMC_CRYCBY422:
- ctx->out_order_1p = S5P_FIMC_OUT_CRYCBY;
+ ctx->out_order_1p = S5P_CIOCTRL_ORDER422_YCBYCR;
break;
case S5P_FIMC_YCBYCR422:
default:
- ctx->out_order_1p = S5P_FIMC_OUT_YCBYCR;
+ ctx->out_order_1p = S5P_CIOCTRL_ORDER422_CRYCBY;
break;
}
dbg("ctx->out_order_1p= %d", ctx->out_order_1p);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 4efc1a1..92cca62 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -95,18 +95,6 @@ enum fimc_color_fmt {
#define fimc_fmt_is_rgb(x) ((x) & 0x10)
-/* Y/Cb/Cr components order at DMA output for 1 plane YCbCr 4:2:2 formats. */
-#defineS5P_FIMC_OUT_CRYCBY S5P_CIOCTRL_ORDER422_YCBYCR
-#defineS5P_FIMC_OUT_CBYCRY S5P_CIOCTRL_ORDER422_CBYCRY
-#defineS5P_FIMC_OUT_YCRYCB S5P_CIOCTRL_ORDER422_YCRYCB
-#defineS5P_FIMC_OUT_YCBYCR S5P_CIOCTRL_ORDER422_CRYCBY
-
-/* Input Y/Cb/Cr components order for 1 plane YCbCr 4:2:2 color formats. */
-#defineS5P_FIMC_IN_CRYCBY S5P_MSCTRL_ORDER422_CRYCBY
-#defineS5P_FIMC_IN_CBYCRY S5P_MSCTRL_ORDER422_CBYCRY
-#defineS5P_FIMC_IN_YCRYCB S5P_MSCTRL_ORDER422_YCRYCB
-#defineS5P_FIMC_IN_YCBYCR S5P_MSCTRL_ORDER422_YCBYCR
-
/* Cb/Cr chrominance components order for 2 plane Y/CbCr 4:2:2 formats. */
#defineS5P_FIMC_LSB_CRCB S5P_CIOCTRL_ORDER422_2P_LSB_CRCB
--
1.6.2.5
--
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] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors
Hi Martin, Thanks for the patch. On Tuesday 14 December 2010 15:43:43 Martin Hostettler wrote: > Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in > syncronous interface. > > The data width is configured in the parallel interface part of the isp > platform data, defaulting to 10bit as before this commit. When i 8bit mode > don't apply DC substraction of 64 per default as this would remove 1/4 of > the sensor range. > > When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel) mode > set the CDCC to output 8bit per pixel instead of 16bit. > > Signed-off-by: Martin Hostettler I got a similar patch for 12bit support. I'll try to push a new version of the ISP driver with that patch included in the next few days (it needs to go through internal review first), could you then rebase your patch on top of it ? The core infrastructure will be set up, you will just have to add 8-bit support. -- Regards, Laurent Pinchart -- 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
Simple request : mini-pcie analog TV capture card
Hello List, I'm after a somehow quite simple information: I'm looking for a mini-pcie TV tuner/capture card. I simply need to plug my cable TV decoder to such a card to "watch" TV on Linux. I've got success with a Hauppauge 950Q USB stick and TV time but this is not a one-time project and we would need to replicate it in a somehow large scale, so a mini-pcie card would fit the hardware best. Does anybody know any mini-pcie model analog card that are still available on the market and that is compatible with this need ? I've looked at linuxtv.org lists but couldn't find one. Habey has a new model, based on the ATI Theater 750 HD chip, which is not supported. AVerMedia has some models too, but none seems to have analog mode working on Linux. Any suggestions would be kindly appreciated. Regards, -- 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: Simple request : mini-pcie analog TV capture card
Fernando, You should send questions to linux-media@vger.kernel.org as the video4linux list is mostly dead. The Yuan MPC718 is supported by the cx18 driver, but it is mini-pci (not mini-pcie) and has hardware mpeg2 encoding, which may be overkill for your needs. Regards, Andy Fernando Laudares Camargos wrote: >Hello List, > >I'm after a somehow quite simple information: I'm looking for a >mini-pcie TV tuner/capture card. I simply need to plug my cable TV >decoder to such a card to "watch" TV on Linux. I've got success with a >Hauppauge 950Q USB stick and TV time but this is not a one-time >project and we would need to replicate it in a somehow large scale, so >a mini-pcie card would fit the hardware best. > >Does anybody know any mini-pcie model analog card that are still >available on the market and that is compatible with this need ? > >I've looked at linuxtv.org lists but couldn't find one. > >Habey has a new model, based on the ATI Theater 750 HD chip, which is >not supported. > >AVerMedia has some models too, but none seems to have analog mode >working on Linux. > >Any suggestions would be kindly appreciated. > >Regards, > >Fernando > >-- >video4linux-list mailing list >Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe >https://www.redhat.com/mailman/listinfo/video4linux-list
Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
Hi,
(CC'ing linux-media this time, please discard the previous mail)
On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
> Hi Laurent and Hans,
>
> I am working on V4L2 subdev for M5MOLS by Fujitsu.
> and I wanna listen your comments about Auto Focus mode of my ideas.
> the details is in the following link discussed at the past.
> Although the situation(adding the more various functions at the M5MOLS
> or any other MEGA camera sensor, I worked.)is changed,
> so I wanna continue this threads for now.
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
>
> First of all, the at least two more mode of auto-focus exists in the
> M5MOLS camera sensor. So, considering defined V4L2 controls and the
> controls in the M5MOLS, I suggest like this:
>
> +enum v4l2_focus_auto_type {
> + V4L2_FOCUS_AUTO_NORMAL = 0,
> + V4L2_FOCUS_AUTO_MACRO = 1,
> + V4L2_FOCUS_AUTO_POSITION = 2,
> +};
> +#define V4L2_CID_FOCUS_POSITION
> (V4L2_CID_CAMERA_CLASS_BASE+13)
>
> -#define V4L2_CID_ZOOM_ABSOLUTE
> (V4L2_CID_CAMERA_CLASS_BASE+13)
> -#define V4L2_CID_ZOOM_RELATIVE
> (V4L2_CID_CAMERA_CLASS_BASE+14)
> +#define V4L2_CID_ZOOM_ABSOLUTE
> (V4L2_CID_CAMERA_CLASS_BASE+14)
> +#define V4L2_CID_ZOOM_RELATIVE
> (V4L2_CID_CAMERA_CLASS_BASE+15)
>
>
> The M5MOLS(or other recent camera sensor) can have at least 2 mode although
> in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports
> positioning focus mode, AKA. POSITION AF mode.
>
> The MACRO mode scan short range, and this mode can be used at the
> circumstance in the short distance with object and camera lens. So, It has
> fast lens movement, but the command FOCUSING dosen't works well at the
> long distance object.
>
> On the other hand, NORMAL mode can this. As the words, It's general and
> normal focus mode. The M5MOLS scan fully in the mode.
>
> In the Position AF mode, the position(expressed x,y) is given at the
> M5MOLS, and then the M5MOLS focus this area. But, the time given the
> position, is normally touch the lcd screen at the mobile device, in my
> case. If the time is given from button, it's no big problem *when*. But,
> in touch-lcd screen case, the position is read at the touch screen driver,
> before command FOCUS to camera sensor. It's the why I add another
> CID(V4L2_CID_FOCUS_POSITION).
I'm pretty sure that some devices would require a rectangle instead of
coordinates to define the focus point. Even a rectangle might not be enough.
It would help if we could get feedback from camera designers here.
Hans, should we add a new control type to pass coordinates/rectangles ? :-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 08/10] mm: cma: Contiguous Memory Allocator added
On Tue, 14 Dec 2010 11:23:15 +0100 Michal Nazarewicz wrote: > > Hmm, it seems __cm_alloc() and __cm_migrate() has no special codes for CMA. > > I'd like reuse this for my own contig page allocator. > > So, could you make these function be more generic (name) ? > > as > > __alloc_range(start, size, mirate_type); > > > > Then, what I have to do is only to add "search range" functions. > > Sure thing. I'll post it tomorrow or Friday. How about > alloc_contig_range() maybe? > That sounds great. Thank you. -Kame -- 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens, On Tuesday 14 December 2010 14:49:15 Clemens Ladisch wrote: > Laurent Pinchart wrote: > > On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: > >> > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > >> >> * Entity types > >> >> > >> >> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a > >> >> node in a graph, which does not distinguish it from other entity > >> >> types because all entities are part of the topology graph. I chose > >> >> "device" as this type describes entities that are visible as some > >> >> device node to other software. > >> > > >> > What this type describes is a device node. Both NODE and DEVICE can be > >> > confusing in my opinion, but DEVICE_NODE is a bit long. > >> > >> What about DEVNODE? I think that would be a good alternative. > > > > Fine with me. Clemens, any opinion on that ? > > Fine with me too. OK I'll use that name. > > > >> TYPE_EXT describes entities that represent some interface to the > > > >> external world, TYPE_INT those that are internal to the entire > > > >> device. (I'm not sure if that distinction is very useful, but > > > >> TYPE_SUBDEV seems to be an even more meaningless name.) > > > > > > > > SUBDEV comes from the V4L2 world, and I agree that it might not be a > > > > very good name. > > > > > > SUBDEV refers to a specific type of driver. Within the v4l world it is > > > well defined. So I prefer to keep this. Perhaps some additional > > > comments or documentation can be added to clarify this. > > > > Should this be clarified by using V4L2_SUBDEV instead then ? > > If the "SUBDEV" concept doesn't exist outside V4L, that would indeed be > better. > > I don't want to rename things that come out of existing frameworks; this > naming discussion makes sense only for those entity (sub)types that can > be shared between them. Are there any, besides jacks? Some entities like TV tuners play a dual audio/video role. I'm not sure how to handle them, I lack experience in that field. > > What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? > > The entity types representing ALSA devices are already named "ALSA". I was talking about the INT_* types. They're ALSA-specific, but have no ALSA in the type name. -- Regards, Laurent Pinchart -- 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] bttv: fix mutex use before init
On 22:13 Tue 14 Dec 2010, Torsten Kaiser wrote: > On Tue, Dec 14, 2010 at 9:56 PM, Torsten Kaiser > wrote: > > Using the card also still works, but I think I found out what was > > causing sporadic shutdown problems with 37-rc kernels: When I try to > > exit tvtime it gets stuck in an uninterruptible D state and can't be > > killed. And that seems to mess up the shutdown. > > > > But this happens independent with or without your patch and looks like > > different problem. > > > > SysRQ+W provided this stack trace, maybe someone seens an obvious bug...: > > [ 274.772528] 8800dec69680 0086 81089d73 > > 8800729d05a0 > > [ 274.778599] 00011480 8800df923fd8 00011480 > > 8800df922000 > > [ 274.778599] 8800df923fd8 00011480 8800dec69680 > > 00011480 > > [ 274.778599] Call Trace: > > [ 274.778599] [] ? free_pcppages_bulk+0x343/0x3b0 > > [ 274.778599] [] ? __mutex_lock_slowpath+0xe1/0x160 > > [ 274.778599] [] ? mutex_lock+0x1a/0x40 > > [ 274.778599] [] ? free_btres_lock.clone.19+0x3f/0x100 > > [ 274.778599] [] ? bttv_release+0x1c1/0x1e0 > > [ 274.778599] [] ? v4l2_release+0x4a/0x70 > > [ 274.778599] [] ? fput+0xe1/0x250 > > [ 274.778599] [] ? filp_close+0x59/0x80 > > [ 274.778599] [] ? sys_close+0x8b/0xe0 > > [ 274.778599] [] ? system_call_fastpath+0x16/0x1b > > The calls to lock btv->lock in bttv_release() where added as part of > the BKL removal, but I do not understand enough to fix this. > Can this be dropped from bttv_release() completely, or would an > unlocked version of free_btres_lock() be better? I would create an unlocked version of free_btres_lock. Does that fix the issue? Cheers, 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: [PATCH] bttv: fix mutex use before init
On 21:56 Tue 14 Dec 2010, Torsten Kaiser wrote: > On Tue, Dec 14, 2010 at 1:30 AM, Brandon Philips wrote: > > On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote: > >> * change &fh->cap.vb_lock in bttv_open() AND radio_open() to > >> &btv->init.cap.vb_lock > >> * add a mutex_init(&btv->init.cap.vb_lock) to the setup of init in > >> bttv_probe() > > > > That seems like a reasonable suggestion. An openSUSE user submitted this > > bug to our tracker too. Here is the patch I am having him test. > > > > Would you mind testing it? > > No. :-) > > Without this patch (==vanilla 2.6.37-rc5) I got 2 more OOPSe by > restarting hal around 20 times. > After applying this patch, I did not see a single OOPS after 100 restarts. > So it looks like the fix is correct. Dave, Torsten- Great thanks for testing, can I get both you and Dave's Tested-by then? Mauro- can you please pick up this patch? Cheers, 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: [PATCH] bttv: fix mutex use before init
On Tue, Dec 14, 2010 at 9:56 PM, Torsten Kaiser wrote: > Using the card also still works, but I think I found out what was > causing sporadic shutdown problems with 37-rc kernels: When I try to > exit tvtime it gets stuck in an uninterruptible D state and can't be > killed. And that seems to mess up the shutdown. > > But this happens independent with or without your patch and looks like > different problem. > > SysRQ+W provided this stack trace, maybe someone seens an obvious bug...: > [ 274.772528] 8800dec69680 0086 81089d73 > 8800729d05a0 > [ 274.778599] 00011480 8800df923fd8 00011480 > 8800df922000 > [ 274.778599] 8800df923fd8 00011480 8800dec69680 > 00011480 > [ 274.778599] Call Trace: > [ 274.778599] [] ? free_pcppages_bulk+0x343/0x3b0 > [ 274.778599] [] ? __mutex_lock_slowpath+0xe1/0x160 > [ 274.778599] [] ? mutex_lock+0x1a/0x40 > [ 274.778599] [] ? free_btres_lock.clone.19+0x3f/0x100 > [ 274.778599] [] ? bttv_release+0x1c1/0x1e0 > [ 274.778599] [] ? v4l2_release+0x4a/0x70 > [ 274.778599] [] ? fput+0xe1/0x250 > [ 274.778599] [] ? filp_close+0x59/0x80 > [ 274.778599] [] ? sys_close+0x8b/0xe0 > [ 274.778599] [] ? system_call_fastpath+0x16/0x1b Hmm:bttv_release() does mutex_lock(&btv->lock), then calls into free_btres_lock(...) that also first does mutex_lock(&btv->lock); The calls to lock btv->lock in bttv_release() where added as part of the BKL removal, but I do not understand enough to fix this. Can this be dropped from bttv_release() completely, or would an unlocked version of free_btres_lock() be better? Torsten -- 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] bttv: fix mutex use before init
On Tue, Dec 14, 2010 at 1:30 AM, Brandon Philips wrote:
> On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote:
>> * change &fh->cap.vb_lock in bttv_open() AND radio_open() to
>> &btv->init.cap.vb_lock
>> * add a mutex_init(&btv->init.cap.vb_lock) to the setup of init in
>> bttv_probe()
>
> That seems like a reasonable suggestion. An openSUSE user submitted this
> bug to our tracker too. Here is the patch I am having him test.
>
> Would you mind testing it?
No. :-)
Without this patch (==vanilla 2.6.37-rc5) I got 2 more OOPSe by
restarting hal around 20 times.
After applying this patch, I did not see a single OOPS after 100 restarts.
So it looks like the fix is correct.
Using the card also still works, but I think I found out what was
causing sporadic shutdown problems with 37-rc kernels: When I try to
exit tvtime it gets stuck in an uninterruptible D state and can't be
killed. And that seems to mess up the shutdown.
But this happens independent with or without your patch and looks like
different problem.
SysRQ+W provided this stack trace, maybe someone seens an obvious bug...:
[ 274.772528] 8800dec69680 0086 81089d73
8800729d05a0
[ 274.778599] 00011480 8800df923fd8 00011480
8800df922000
[ 274.778599] 8800df923fd8 00011480 8800dec69680
00011480
[ 274.778599] Call Trace:
[ 274.778599] [] ? free_pcppages_bulk+0x343/0x3b0
[ 274.778599] [] ? __mutex_lock_slowpath+0xe1/0x160
[ 274.778599] [] ? mutex_lock+0x1a/0x40
[ 274.778599] [] ? free_btres_lock.clone.19+0x3f/0x100
[ 274.778599] [] ? bttv_release+0x1c1/0x1e0
[ 274.778599] [] ? v4l2_release+0x4a/0x70
[ 274.778599] [] ? fput+0xe1/0x250
[ 274.778599] [] ? filp_close+0x59/0x80
[ 274.778599] [] ? sys_close+0x8b/0xe0
[ 274.778599] [] ? system_call_fastpath+0x16/0x1b
> From 456dc0ce36db523c4c0c8a269f4eec43a72de1dc Mon Sep 17 00:00:00 2001
> From: Brandon Philips
> Date: Mon, 13 Dec 2010 16:21:55 -0800
> Subject: [PATCH] bttv: fix locking for btv->init
>
> Fix locking for the btv->init by using btv->init.cap.vb_lock and in the
> process fix uninitialized deref introduced in c37db91fd0d.
>
> Signed-off-by: Brandon Philips
> ---
> drivers/media/video/bt8xx/bttv-driver.c | 24 +---
> 1 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/video/bt8xx/bttv-driver.c
> b/drivers/media/video/bt8xx/bttv-driver.c
> index a529619..e656424 100644
> --- a/drivers/media/video/bt8xx/bttv-driver.c
> +++ b/drivers/media/video/bt8xx/bttv-driver.c
> @@ -2391,16 +2391,11 @@ static int setup_window_lock(struct bttv_fh *fh,
> struct bttv *btv,
> fh->ov.field = win->field;
> fh->ov.setup_ok = 1;
>
> - /*
> - * FIXME: btv is protected by btv->lock mutex, while btv->init
> - * is protected by fh->cap.vb_lock. This seems to open the
> - * possibility for some race situations. Maybe the better would
> - * be to unify those locks or to use another way to store the
> - * init values that will be consumed by videobuf callbacks
> - */
> + mutex_lock(&btv->init.cap.vb_lock);
> btv->init.ov.w.width = win->w.width;
> btv->init.ov.w.height = win->w.height;
> btv->init.ov.field = win->field;
> + mutex_unlock(&btv->init.cap.vb_lock);
>
> /* update overlay if needed */
> retval = 0;
> @@ -2620,9 +2615,11 @@ static int bttv_s_fmt_vid_cap(struct file *file, void
> *priv,
> fh->cap.last = V4L2_FIELD_NONE;
> fh->width = f->fmt.pix.width;
> fh->height = f->fmt.pix.height;
> + mutex_lock(&btv->init.cap.vb_lock);
> btv->init.fmt = fmt;
> btv->init.width = f->fmt.pix.width;
> btv->init.height = f->fmt.pix.height;
> + mutex_unlock(&btv->init.cap.vb_lock);
> mutex_unlock(&fh->cap.vb_lock);
>
> return 0;
> @@ -2855,6 +2852,7 @@ static int bttv_s_fbuf(struct file *file, void *f,
>
> retval = 0;
> fh->ovfmt = fmt;
> + mutex_lock(&btv->init.cap.vb_lock);
> btv->init.ovfmt = fmt;
> if (fb->flags & V4L2_FBUF_FLAG_OVERLAY) {
> fh->ov.w.left = 0;
> @@ -2876,6 +2874,7 @@ static int bttv_s_fbuf(struct file *file, void *f,
> retval = bttv_switch_overlay(btv, fh, new);
> }
> }
> + mutex_unlock(&btv->init.cap.vb_lock);
> mutex_unlock(&fh->cap.vb_lock);
> return retval;
> }
> @@ -3141,6 +3140,7 @@ static int bttv_s_crop(struct file *file, void *f,
> struct v4l2_crop *crop)
> fh->do_crop = 1;
>
> mutex_lock(&fh->cap.vb_lock);
> + mutex_lock(&btv->init.cap.vb_lock);
>
> if (fh->width < c.min_scaled_width) {
> fh->width = c.min_scaled_width;
> @@ -3158,6 +3158,7 @@ static int bttv_s_crop(struct file *file, void *f,
> struct v4l2_crop *crop)
>
Re: [PATCH 3/6] [media] gspca core: Fix regressions gspca breaking devices with audio
On Tue, Dec 14, 2010 at 9:08 PM, Jean-Francois Moine wrote: > On Tue, 14 Dec 2010 20:52:43 +0200 > Anca Emanuel wrote: > >> How can I disable the noise from camera ? >> There is no physical microphone in it. >> ( mute do not work ) > [snip] >> [ 139.848996] usb 8-1: usb_probe_device >> [ 139.849003] usb 8-1: configuration #1 chosen from 1 choice >> [ 139.851825] usb 8-1: adding 8-1:1.0 (config #1, interface 0) >> [ 139.851932] usb 8-1: adding 8-1:1.1 (config #1, interface 1) >> [ 139.851992] usb 8-1: adding 8-1:1.2 (config #1, interface 2) >> [ 139.898020] gspca: v2.11.0 registered >> [ 139.904357] ov519 8-1:1.0: usb_probe_interface >> [ 139.904362] ov519 8-1:1.0: usb_probe_interface - got id > > This is an old version. May you get the last one from my web page? > (actual 2.11.15) The same biz ... [ 74.272034] usb 8-1: new full speed USB device using uhci_hcd and address 2 [ 74.404016] usb 8-1: ep0 maxpacket = 8 [ 74.440242] usb 8-1: skipped 3 descriptors after interface [ 74.440245] usb 8-1: skipped 2 descriptors after interface [ 74.440248] usb 8-1: skipped 1 descriptor after endpoint [ 74.445234] usb 8-1: default language 0x0409 [ 74.464241] usb 8-1: udev 2, busnum 8, minor = 897 [ 74.464244] usb 8-1: New USB device found, idVendor=05a9, idProduct=4519 [ 74.464247] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 74.464250] usb 8-1: Product: USB Camera [ 74.464252] usb 8-1: Manufacturer: OmniVision Technologies, Inc. [ 74.464365] usb 8-1: usb_probe_device [ 74.464369] usb 8-1: configuration #1 chosen from 1 choice [ 74.467255] usb 8-1: adding 8-1:1.0 (config #1, interface 0) [ 74.467326] usb 8-1: adding 8-1:1.1 (config #1, interface 1) [ 74.467356] usb 8-1: adding 8-1:1.2 (config #1, interface 2) [ 74.467409] hub 8-0:1.0: state 7 ports 2 chg evt 0002 [ 74.508926] gspca: v2.11.0 registered [ 74.515078] ov519 8-1:1.0: usb_probe_interface [ 74.515083] ov519 8-1:1.0: usb_probe_interface - got id [ 74.515088] gspca-2.11.5: probing 05a9:4519 [ 74.700355] ov519-2.11.5: I2C synced in 0 attempt(s) [ 74.700358] ov519-2.11.5: starting OV7xx0 configuration [ 74.712360] ov519-2.11.5: Sensor is a OV7660 [ 76.070091] input: ov519 as /devices/pci:00/:00:1d.3/usb8/8-1/input/input5 [ 76.070213] gspca-2.11.5: video0 created [ 76.070224] ov519 8-1:1.1: usb_probe_interface [ 76.070227] ov519 8-1:1.1: usb_probe_interface - got id [ 76.070239] ov519 8-1:1.2: usb_probe_interface [ 76.070241] ov519 8-1:1.2: usb_probe_interface - got id [ 76.070262] usbcore: registered new interface driver ov519 [ 76.178628] snd-usb-audio 8-1:1.1: usb_probe_interface [ 76.178635] snd-usb-audio 8-1:1.1: usb_probe_interface - got id [ 76.185357] usbcore: registered new interface driver snd-usb-audio [ 76.279093] uhci_hcd :00:1d.3: reserve dev 2 ep82-ISO, period 1, phase 0, 40 us [ 76.804108] hub 2-0:1.0: hub_suspend [ 76.804117] usb usb2: bus auto-suspend [ 76.804121] ehci_hcd :00:1d.7: suspend root hub [ 81.286524] uhci_hcd :00:1d.3: release dev 2 ep82-ISO, period 1, phase 0, 40 us -- 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: Hauppauge HVR-2200 analog
On 12/14/10 12:23 PM, Julian Scheel wrote: > Is there any reason, why the additional card-information found here: > http://www.kernellabs.com/hg/~stoth/saa7164-dev/ > is not yet in the kernel tree? On my todo list. I validate each board before I add its profile to the core tree. If certain boards are missing then its because that board is considered experimental or is pending testing and merge. PAL encoder support is broken in the current tree and it currently getting my love and attention. Point me at the specific boards you think are missing and I'll also add these to my todo list, they'll likely get merged at the same time. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] gspca - sonixj: Better handling of the bridge registers 0x01 and 0x17 (bug fix)
The initial values of the registers 0x01 and 0x17 are taken from the sensor
table at capture start and updated according to the flag PDN_INV.
Their values are updated at each step of the capture initialization and
memorized for reuse in capture stop.
This patch also fixed automatically some bad hardcoded values of these
registers.
Signed-off-by: Jean-François Moine
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index a75f7ec..901ca81 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -63,6 +63,8 @@ struct sd {
#define QUALITY_DEF 80
u8 jpegqual;/* webcam quality */
+ u8 reg01;
+ u8 reg17;
u8 reg18;
u8 flags;
@@ -2306,8 +2308,8 @@ static int sd_start(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
+ u8 reg01, reg17;
u8 reg0102[2];
- u8 reg1, reg17;
const u8 *sn9c1xx;
const u8 (*init)[8];
const u8 *reg9a;
@@ -2341,10 +2343,13 @@ static int sd_start(struct gspca_dev *gspca_dev)
/* sensor clock already enabled in sd_init */
/* reg_w1(gspca_dev, 0xf1, 0x00); */
- reg_w1(gspca_dev, 0x01, sn9c1xx[1]);
+ reg01 = sn9c1xx[1];
+ if (sd->flags & PDN_INV)
+ reg01 ^= S_PDN_INV; /* power down inverted */
+ reg_w1(gspca_dev, 0x01, reg01);
/* configure gpio */
- reg0102[0] = sn9c1xx[1];
+ reg0102[0] = reg01;
reg0102[1] = sn9c1xx[2];
if (gspca_dev->audio)
reg0102[1] |= 0x04; /* keep the audio connection */
@@ -2370,95 +2375,49 @@ static int sd_start(struct gspca_dev *gspca_dev)
reg_w(gspca_dev, 0x03, &sn9c1xx[3], 0x0f);
+ reg17 = sn9c1xx[0x17];
switch (sd->sensor) {
- case SENSOR_ADCM1700:
- reg_w1(gspca_dev, 0x01, 0x43);
- reg_w1(gspca_dev, 0x17, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- reg_w1(gspca_dev, 0x01, 0x42);
- break;
case SENSOR_GC0307:
- msleep(50);
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x22);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- msleep(50);
- break;
- case SENSOR_MI0360B:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x60);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_MT9V111:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x61);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
+ msleep(50); /*fixme: is it useful? */
break;
case SENSOR_OM6802:
msleep(10);
reg_w1(gspca_dev, 0x02, 0x73);
- reg_w1(gspca_dev, 0x17, 0x60);
+ reg17 |= SEN_CLK_EN;
+ reg_w1(gspca_dev, 0x17, reg17);
reg_w1(gspca_dev, 0x01, 0x22);
msleep(100);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x17, 0x64);
- reg_w1(gspca_dev, 0x17, 0x64);
- reg_w1(gspca_dev, 0x01, 0x42);
+ reg01 = SCL_SEL_OD | S_PDN_INV;
+ reg17 &= MCK_SIZE_MASK;
+ reg17 |= 0x04; /* clock / 4 */
+ break;
+ }
+ reg01 |= SYS_SEL_48M;
+ reg_w1(gspca_dev, 0x01, reg01);
+ reg17 |= SEN_CLK_EN;
+ reg_w1(gspca_dev, 0x17, reg17);
+ reg01 &= ~S_PWR_DN; /* sensor power on */
+ reg_w1(gspca_dev, 0x01, reg01);
+ reg01 &= ~SYS_SEL_48M;
+ reg_w1(gspca_dev, 0x01, reg01);
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ hv7131r_probe(gspca_dev); /*fixme: is it useful? */
+ break;
+ case SENSOR_OM6802:
msleep(10);
- reg_w1(gspca_dev, 0x01, 0x42);
+ reg_w1(gspca_dev, 0x01, reg01);
i2c_w8(gspca_dev, om6802_init0[0]);
i2c_w8(gspca_dev, om6802_init0[1]);
msleep(15);
reg_w1(gspca_dev, 0x02, 0x71);
msleep(150);
break;
- case SENSOR_OV7630:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0xe2);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_OV7648:
- reg_w1(gspca_dev, 0x01, 0x63);
- reg_w1(gspca_dev, 0x17, 0x20);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- break;
- case SENSOR_PO1030:
- case SENSOR_
[PATCH 6/6] gspca - sonixj: Better handling of the bridge registers 0x01 and 0x17
The initial values of the registers 0x01 and 0x17 are taken from the sensor
table at capture start and updated according to the flag PDN_INV.
Their values are updated at each step of the capture initialization and
memorized for reuse in capture stop.
This patch also fixed automatically some bad hardcoded values of these
registers.
Signed-off-by: Jean-François Moine
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index a75f7ec..901ca81 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -63,6 +63,8 @@ struct sd {
#define QUALITY_DEF 80
u8 jpegqual;/* webcam quality */
+ u8 reg01;
+ u8 reg17;
u8 reg18;
u8 flags;
@@ -2306,8 +2308,8 @@ static int sd_start(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
+ u8 reg01, reg17;
u8 reg0102[2];
- u8 reg1, reg17;
const u8 *sn9c1xx;
const u8 (*init)[8];
const u8 *reg9a;
@@ -2341,10 +2343,13 @@ static int sd_start(struct gspca_dev *gspca_dev)
/* sensor clock already enabled in sd_init */
/* reg_w1(gspca_dev, 0xf1, 0x00); */
- reg_w1(gspca_dev, 0x01, sn9c1xx[1]);
+ reg01 = sn9c1xx[1];
+ if (sd->flags & PDN_INV)
+ reg01 ^= S_PDN_INV; /* power down inverted */
+ reg_w1(gspca_dev, 0x01, reg01);
/* configure gpio */
- reg0102[0] = sn9c1xx[1];
+ reg0102[0] = reg01;
reg0102[1] = sn9c1xx[2];
if (gspca_dev->audio)
reg0102[1] |= 0x04; /* keep the audio connection */
@@ -2370,95 +2375,49 @@ static int sd_start(struct gspca_dev *gspca_dev)
reg_w(gspca_dev, 0x03, &sn9c1xx[3], 0x0f);
+ reg17 = sn9c1xx[0x17];
switch (sd->sensor) {
- case SENSOR_ADCM1700:
- reg_w1(gspca_dev, 0x01, 0x43);
- reg_w1(gspca_dev, 0x17, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- reg_w1(gspca_dev, 0x01, 0x42);
- break;
case SENSOR_GC0307:
- msleep(50);
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x22);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- msleep(50);
- break;
- case SENSOR_MI0360B:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x60);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_MT9V111:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x61);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
+ msleep(50); /*fixme: is it useful? */
break;
case SENSOR_OM6802:
msleep(10);
reg_w1(gspca_dev, 0x02, 0x73);
- reg_w1(gspca_dev, 0x17, 0x60);
+ reg17 |= SEN_CLK_EN;
+ reg_w1(gspca_dev, 0x17, reg17);
reg_w1(gspca_dev, 0x01, 0x22);
msleep(100);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x17, 0x64);
- reg_w1(gspca_dev, 0x17, 0x64);
- reg_w1(gspca_dev, 0x01, 0x42);
+ reg01 = SCL_SEL_OD | S_PDN_INV;
+ reg17 &= MCK_SIZE_MASK;
+ reg17 |= 0x04; /* clock / 4 */
+ break;
+ }
+ reg01 |= SYS_SEL_48M;
+ reg_w1(gspca_dev, 0x01, reg01);
+ reg17 |= SEN_CLK_EN;
+ reg_w1(gspca_dev, 0x17, reg17);
+ reg01 &= ~S_PWR_DN; /* sensor power on */
+ reg_w1(gspca_dev, 0x01, reg01);
+ reg01 &= ~SYS_SEL_48M;
+ reg_w1(gspca_dev, 0x01, reg01);
+
+ switch (sd->sensor) {
+ case SENSOR_HV7131R:
+ hv7131r_probe(gspca_dev); /*fixme: is it useful? */
+ break;
+ case SENSOR_OM6802:
msleep(10);
- reg_w1(gspca_dev, 0x01, 0x42);
+ reg_w1(gspca_dev, 0x01, reg01);
i2c_w8(gspca_dev, om6802_init0[0]);
i2c_w8(gspca_dev, om6802_init0[1]);
msleep(15);
reg_w1(gspca_dev, 0x02, 0x71);
msleep(150);
break;
- case SENSOR_OV7630:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0xe2);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_OV7648:
- reg_w1(gspca_dev, 0x01, 0x63);
- reg_w1(gspca_dev, 0x17, 0x20);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- break;
- case SENSOR_PO1030:
- case SENSOR_
[PATCH 5/6] gspca - sonixj: Add the bit definitions of the bridge reg 0x01 and 0x17
Signed-off-by: Jean-François Moine
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index 5deff24..a75f7ec 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -100,6 +100,19 @@ enum sensors {
/* device flags */
#define PDN_INV1 /* inverse pin S_PWR_DN / sn_xxx tables
*/
+/* sn9c1xx definitions */
+/* register 0x01 */
+#define S_PWR_DN 0x01/* sensor power down */
+#define S_PDN_INV 0x02/* inverse pin S_PWR_DN */
+#define V_TX_EN0x04/* video transfer enable */
+#define LED0x08/* output to pin LED */
+#define SCL_SEL_OD 0x20/* open-drain mode */
+#define SYS_SEL_48M0x40/* system clock 0: 24MHz, 1: 48MHz */
+/* register 0x17 */
+#define MCK_SIZE_MASK 0x1f/* sensor master clock */
+#define SEN_CLK_EN 0x20/* enable sensor clock */
+#define DEF_EN 0x80/* defect pixel by 0: soft, 1: hard */
+
/* V4L2 controls supported by the driver */
static void setbrightness(struct gspca_dev *gspca_dev);
static void setcontrast(struct gspca_dev *gspca_dev);
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] gspca - sonixj: Set the flag for some devices
The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
value as other webcams with the same sensor. For now, only two webcams have
been so detected: the Microsoft's VX1000 and VX3000.
Signed-off-by: Jean-François Moine
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index ed7349b..5deff24 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -97,6 +97,9 @@ enum sensors {
SENSOR_SP80708,
};
+/* device flags */
+#define PDN_INV1 /* inverse pin S_PWR_DN / sn_xxx tables
*/
+
/* V4L2 controls supported by the driver */
static void setbrightness(struct gspca_dev *gspca_dev);
static void setcontrast(struct gspca_dev *gspca_dev);
@@ -2959,8 +2962,8 @@ static const __devinitdata struct usb_device_id
device_table[] = {
{USB_DEVICE(0x0458, 0x7025), BS(SN9C120, MI0360)},
{USB_DEVICE(0x0458, 0x702e), BS(SN9C120, OV7660)},
#endif
- {USB_DEVICE(0x045e, 0x00f5), BS(SN9C105, OV7660)},
- {USB_DEVICE(0x045e, 0x00f7), BS(SN9C105, OV7660)},
+ {USB_DEVICE(0x045e, 0x00f5), BSF(SN9C105, OV7660, PDN_INV)},
+ {USB_DEVICE(0x045e, 0x00f7), BSF(SN9C105, OV7660, PDN_INV)},
{USB_DEVICE(0x0471, 0x0327), BS(SN9C105, MI0360)},
{USB_DEVICE(0x0471, 0x0328), BS(SN9C105, MI0360)},
{USB_DEVICE(0x0471, 0x0330), BS(SN9C105, MI0360)},
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] gspca - sonixj: Add a flag in the driver_info table
Signed-off-by: Jean-François Moine
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index 5978676..ed7349b 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -64,6 +64,7 @@ struct sd {
u8 jpegqual;/* webcam quality */
u8 reg18;
+ u8 flags;
s8 ag_cnt;
#define AG_CNT_START 13
@@ -1763,7 +1764,8 @@ static int sd_config(struct gspca_dev *gspca_dev,
struct cam *cam;
sd->bridge = id->driver_info >> 16;
- sd->sensor = id->driver_info;
+ sd->sensor = id->driver_info >> 8;
+ sd->flags = id->driver_info;
cam = &gspca_dev->cam;
if (sd->sensor == SENSOR_ADCM1700) {
@@ -2947,7 +2949,11 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
#define BS(bridge, sensor) \
.driver_info = (BRIDGE_ ## bridge << 16) \
- | SENSOR_ ## sensor
+ | (SENSOR_ ## sensor << 8)
+#define BSF(bridge, sensor, flags) \
+ .driver_info = (BRIDGE_ ## bridge << 16) \
+ | (SENSOR_ ## sensor << 8) \
+ | (flags)
static const __devinitdata struct usb_device_id device_table[] = {
#if !defined CONFIG_USB_SN9C102 && !defined CONFIG_USB_SN9C102_MODULE
{USB_DEVICE(0x0458, 0x7025), BS(SN9C120, MI0360)},
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] gspca - sonixj: Fix a bad probe exchange
Signed-off-by: Jean-François Moine
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index 4660cbe..5978676 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -1794,7 +1794,7 @@ static int sd_init(struct gspca_dev *gspca_dev)
/* setup a selector by bridge */
reg_w1(gspca_dev, 0xf1, 0x01);
reg_r(gspca_dev, 0x00, 1);
- reg_w1(gspca_dev, 0xf1, gspca_dev->usb_buf[0]);
+ reg_w1(gspca_dev, 0xf1, 0x00);
reg_r(gspca_dev, 0x00, 1); /* get sonix chip id */
regF1 = gspca_dev->usb_buf[0];
if (gspca_dev->usb_err < 0)
@@ -2289,10 +2289,10 @@ static int sd_start(struct gspca_dev *gspca_dev)
struct sd *sd = (struct sd *) gspca_dev;
int i;
u8 reg0102[2];
- const u8 *reg9a;
u8 reg1, reg17;
const u8 *sn9c1xx;
const u8 (*init)[8];
+ const u8 *reg9a;
int mode;
static const u8 reg9a_def[] =
{0x00, 0x40, 0x20, 0x00, 0x00, 0x00};
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] gspca - sonixj: Move bridge init to sd start
Signed-off-by: Jean-François Moine
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index 2229847..4660cbe 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -1755,141 +1755,6 @@ static void po2030n_probe(struct gspca_dev *gspca_dev)
}
}
-static void bridge_init(struct gspca_dev *gspca_dev,
- const u8 *sn9c1xx)
-{
- struct sd *sd = (struct sd *) gspca_dev;
- u8 reg0102[2];
- const u8 *reg9a;
- static const u8 reg9a_def[] =
- {0x00, 0x40, 0x20, 0x00, 0x00, 0x00};
- static const u8 reg9a_spec[] =
- {0x00, 0x40, 0x38, 0x30, 0x00, 0x20};
- static const u8 regd4[] = {0x60, 0x00, 0x00};
-
- /* sensor clock already enabled in sd_init */
- /* reg_w1(gspca_dev, 0xf1, 0x00); */
- reg_w1(gspca_dev, 0x01, sn9c1xx[1]);
-
- /* configure gpio */
- reg0102[0] = sn9c1xx[1];
- reg0102[1] = sn9c1xx[2];
- if (gspca_dev->audio)
- reg0102[1] |= 0x04; /* keep the audio connection */
- reg_w(gspca_dev, 0x01, reg0102, 2);
- reg_w(gspca_dev, 0x08, &sn9c1xx[8], 2);
- reg_w(gspca_dev, 0x17, &sn9c1xx[0x17], 5);
- switch (sd->sensor) {
- case SENSOR_GC0307:
- case SENSOR_OV7660:
- case SENSOR_PO1030:
- case SENSOR_PO2030N:
- case SENSOR_SOI768:
- case SENSOR_SP80708:
- reg9a = reg9a_spec;
- break;
- default:
- reg9a = reg9a_def;
- break;
- }
- reg_w(gspca_dev, 0x9a, reg9a, 6);
-
- reg_w(gspca_dev, 0xd4, regd4, sizeof regd4);
-
- reg_w(gspca_dev, 0x03, &sn9c1xx[3], 0x0f);
-
- switch (sd->sensor) {
- case SENSOR_ADCM1700:
- reg_w1(gspca_dev, 0x01, 0x43);
- reg_w1(gspca_dev, 0x17, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- reg_w1(gspca_dev, 0x01, 0x42);
- break;
- case SENSOR_GC0307:
- msleep(50);
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x22);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- msleep(50);
- break;
- case SENSOR_MI0360B:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x60);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_MT9V111:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x61);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_OM6802:
- msleep(10);
- reg_w1(gspca_dev, 0x02, 0x73);
- reg_w1(gspca_dev, 0x17, 0x60);
- reg_w1(gspca_dev, 0x01, 0x22);
- msleep(100);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x17, 0x64);
- reg_w1(gspca_dev, 0x17, 0x64);
- reg_w1(gspca_dev, 0x01, 0x42);
- msleep(10);
- reg_w1(gspca_dev, 0x01, 0x42);
- i2c_w8(gspca_dev, om6802_init0[0]);
- i2c_w8(gspca_dev, om6802_init0[1]);
- msleep(15);
- reg_w1(gspca_dev, 0x02, 0x71);
- msleep(150);
- break;
- case SENSOR_OV7630:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0xe2);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_OV7648:
- reg_w1(gspca_dev, 0x01, 0x63);
- reg_w1(gspca_dev, 0x17, 0x20);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- break;
- case SENSOR_PO1030:
- case SENSOR_SOI768:
- reg_w1(gspca_dev, 0x01, 0x61);
- reg_w1(gspca_dev, 0x17, 0x20);
- reg_w1(gspca_dev, 0x01, 0x60);
- reg_w1(gspca_dev, 0x01, 0x40);
- break;
- case SENSOR_PO2030N:
- case SENSOR_OV7660:
- reg_w1(gspca_dev, 0x01, 0x63);
- reg_w1(gspca_dev, 0x17, 0x20);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- break;
- case SENSOR_SP80708:
- reg_w1(gspca_dev, 0x01, 0x63);
- reg_w1(gspca_dev, 0x17, 0x20);
- reg_w1(gspca_dev, 0x01, 0x62);
- reg_w1(gspca_dev, 0x01, 0x42);
- msleep(100);
- reg_w1(gspca_dev, 0x02, 0x62);
- break;
- default:
-/* case SENSOR_HV7131R: */
-/* case SENSOR_MI0360: */
-/* case SENSOR_MO4000: */
- reg_w1(gspca_dev, 0x01, 0x
[PATCH 0/6] gspca sonixj better handling of reg 01 and 17
Here is a new version following Mauro's remarks and with some fixes. Jean-François Moine (6): gspca - sonixj: Move bridge init to sd start gspca - sonixj: Fix a bad probe exchange gspca - sonixj: Add a flag in the driver_info table gspca - sonixj: Set the flag for some devices gspca - sonixj: Add the bit definitions of the bridge reg 0x01 and 0x17 gspca - sonixj: Better handling of the bridge registers 0x01 and 0x17 drivers/media/video/gspca/sonixj.c | 416 1 files changed, 184 insertions(+), 232 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] [media] gspca core: Fix regressions gspca breaking devices with audio
On Tue, 14 Dec 2010 20:52:43 +0200 Anca Emanuel wrote: > How can I disable the noise from camera ? > There is no physical microphone in it. > ( mute do not work ) [snip] > [ 139.848996] usb 8-1: usb_probe_device > [ 139.849003] usb 8-1: configuration #1 chosen from 1 choice > [ 139.851825] usb 8-1: adding 8-1:1.0 (config #1, interface 0) > [ 139.851932] usb 8-1: adding 8-1:1.1 (config #1, interface 1) > [ 139.851992] usb 8-1: adding 8-1:1.2 (config #1, interface 2) > [ 139.898020] gspca: v2.11.0 registered > [ 139.904357] ov519 8-1:1.0: usb_probe_interface > [ 139.904362] ov519 8-1:1.0: usb_probe_interface - got id This is an old version. May you get the last one from my web page? (actual 2.11.15) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] [media] gspca core: Fix regressions gspca breaking devices with audio
On Fri, Dec 10, 2010 at 12:51 PM, Jean-Francois Moine wrote: > On Thu, 9 Dec 2010 18:42:36 -0200 > Mauro Carvalho Chehab wrote: > >> Changeset 35680ba broke several devices: >> - Sony Playstation Eye (1415:2000); >> - Gigaware model 25-234 (0c45:628f); >> - Logitech Messenger Plus (046d:08f6). >> >> Probably more devices were broken by this change. >> >> What happens is that several devices don't need to save some bandwidth >> for audio. >> >> Also, as pointed by Hans de Goede , the logic >> that implements the bandwidth reservation for audio is broken, since >> it will reduce the alt number twice, on devices with audio. >> >> So, let's just revert the broken logic, and think on a better solution >> for usb 1.1 devices with audio that can't use the maximum packetsize. > > Acked-by: Jean-Francois Moine > > -- > Ken ar c'hentañ | ** Breizh ha Linux atav! ** > Jef | http://moinejf.free.fr/ > -- > 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 can I disable the noise from camera ? There is no physical microphone in it. ( mute do not work ) [ 139.656021] usb 8-1: new full speed USB device using uhci_hcd and address 2 [ 139.788024] usb 8-1: ep0 maxpacket = 8 [ 139.824840] usb 8-1: skipped 3 descriptors after interface [ 139.824846] usb 8-1: skipped 2 descriptors after interface [ 139.824851] usb 8-1: skipped 1 descriptor after endpoint [ 139.829822] usb 8-1: default language 0x0409 [ 139.848810] usb 8-1: udev 2, busnum 8, minor = 897 [ 139.848816] usb 8-1: New USB device found, idVendor=05a9, idProduct=4519 [ 139.848821] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 139.848826] usb 8-1: Product: USB Camera [ 139.848830] usb 8-1: Manufacturer: OmniVision Technologies, Inc. [ 139.848996] usb 8-1: usb_probe_device [ 139.849003] usb 8-1: configuration #1 chosen from 1 choice [ 139.851825] usb 8-1: adding 8-1:1.0 (config #1, interface 0) [ 139.851932] usb 8-1: adding 8-1:1.1 (config #1, interface 1) [ 139.851992] usb 8-1: adding 8-1:1.2 (config #1, interface 2) [ 139.898020] gspca: v2.11.0 registered [ 139.904357] ov519 8-1:1.0: usb_probe_interface [ 139.904362] ov519 8-1:1.0: usb_probe_interface - got id [ 139.904367] gspca: probing 05a9:4519 [ 140.088677] ov519: I2C synced in 0 attempt(s) [ 140.088683] ov519: starting OV7xx0 configuration [ 140.100673] ov519: Sensor is a OV7660 [ 141.530010] input: ov519 as /devices/pci:00/:00:1d.3/usb8/8-1/input/input5 [ 141.530188] gspca: video0 created [ 141.530205] ov519 8-1:1.1: usb_probe_interface [ 141.530210] ov519 8-1:1.1: usb_probe_interface - got id [ 141.530227] ov519 8-1:1.2: usb_probe_interface [ 141.530231] ov519 8-1:1.2: usb_probe_interface - got id [ 141.530267] usbcore: registered new interface driver ov519 [ 141.643983] snd-usb-audio 8-1:1.1: usb_probe_interface [ 141.643990] snd-usb-audio 8-1:1.1: usb_probe_interface - got id [ 141.651156] usbcore: registered new interface driver snd-usb-audio [ 141.758522] uhci_hcd :00:1d.3: reserve dev 2 ep82-ISO, period 1, phase 0, 40 us -- 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: Hauppauge HVR-2200 analog
Am 14.12.2010 18:23, schrieb Julian Scheel: Am 07.12.2010 14:01, schrieb Andy Walls: It appears to be in the media_tree.git repository on the staging/for_v2.6.37-rc1 branch: http://git.linuxtv.org/media_tree.git?a=tree;f=drivers/media/video/saa7164;h=0acaa4ada45ae6881bfbb19447ae9db43f06ef9b;hb=staging/for_v2.6.37-rc1 saa7164-cards.c appears to have analog entries added for HVR-2200's and saa7164-encoder.c has a number of V4L ioctl()'s for MPEG streams. Is there any reason, why the additional card-information found here: http://www.kernellabs.com/hg/~stoth/saa7164-dev/ is not yet in the kernel tree? Actually after manually adding this changeset into linux-26.37-rc5 tree the card is detected and dmesg says: [3.653289] saa7164 driver loaded [3.653340] saa7164 :02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [3.654909] CORE saa7164[0]: subsystem: 0070:8940, board: Hauppauge WinTV-HVR2200 [card=9,autodetected] [3.654914] saa7164[0]/0: found at :02:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xfb00 [3.654919] saa7164 :02:00.0: setting latency timer to 64 [3.813647] saa7164_downloadfirmware() no first image [3.814781] saa7164_downloadfirmware() Waiting for firmware upload (NXP7164-2010-03-10.1.fw) [3.839841] saa7164_downloadfirmware() firmware read 4019072 bytes. [3.839843] saa7164_downloadfirmware() firmware loaded. [3.839844] Firmware file header part 1: [3.839846] .FirmwareSize = 0x0 [3.839847] .BSLSize = 0x0 [3.839848] .Reserved = 0x3d538 [3.839849] .Version = 0x3 [3.839850] saa7164_downloadfirmware() SecBootLoader.FileSize = 4019072 [3.839856] saa7164_downloadfirmware() FirmwareSize = 0x1fd6 [3.839857] saa7164_downloadfirmware() BSLSize = 0x0 [3.839858] saa7164_downloadfirmware() Reserved = 0x0 [3.839860] saa7164_downloadfirmware() Version = 0x1661c00 [ 10.693325] saa7164_downloadimage() Image downloaded, booting... [ 10.797316] saa7164_downloadimage() Image booted successfully. [ 10.797332] starting firmware download(2) [ 13.425188] saa7164_downloadimage() Image downloaded, booting... [ 15.089109] saa7164_downloadimage() Image booted successfully. [ 15.089128] firmware download complete. [ 15.129700] tveeprom 1-: Hauppauge model 89619, rev D3F2, serial# 7259796 [ 15.129703] tveeprom 1-: MAC address is 00:0d:fe:6e:c6:94 [ 15.129704] tveeprom 1-: tuner model is NXP 18271C2_716x (idx 152, type 4) [ 15.129707] tveeprom 1-: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) [ 15.129709] tveeprom 1-: audio processor is SAA7164 (idx 43) [ 15.129710] tveeprom 1-: decoder processor is SAA7164 (idx 40) [ 15.129711] tveeprom 1-: has radio [ 15.129712] saa7164[0]: Hauppauge eeprom: model=89619 [ 15.189491] tda18271 2-0060: creating new instance [ 15.194156] TDA18271HD/C2 detected @ 2-0060 [ 15.446842] DVB: registering new adapter (saa7164) [ 15.446845] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [ 15.477568] tda18271 3-0060: creating new instance [ 15.482514] TDA18271HD/C2 detected @ 3-0060 [ 15.733973] tda18271: performing RF tracking filter calibration [ 18.082962] tda18271: RF tracking filter calibration complete [ 18.083552] DVB: registering new adapter (saa7164) [ 18.083554] DVB: registering adapter 1 frontend 0 (NXP TDA10048HN DVB-T)... dvb-devices are registered, but no video-devices. Any thoughts? -- 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: WARNINGS
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:Tue Dec 14 19:00:06 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: Hauppauge USB Live 2
$ git log --oneline --no-merges 4270c3ca.. drivers/media/video/cx231xx f5db33f [media] cx231xx: stray unlock on error path Using that commit directly looks better. I still see the UsbInterface::sendCommand failures, but the driver seems to finish the initialization and looks for the firmware. So it seems something between -rc2 and -rc5 in mainline made it regress ... Uhm, no. Looks like the difference is actually the .config The stripped-down kernel with the driver compiled in statically for a quick test works fine, whereas the fedora-derived configuration doesn't. /me continues burning cpu cycles with kernel builds ;) cheers, Gerd -- 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: Hauppauge HVR-2200 analog
Am 07.12.2010 14:01, schrieb Andy Walls: On Tue, 2010-12-07 at 12:04 +0100, Julian Scheel wrote: Hi, is there any progress on adding analog support to the HVR-2200? It seems support for the used chipsets in general is already in the kernel? It appears to be in the media_tree.git repository on the staging/for_v2.6.37-rc1 branch: http://git.linuxtv.org/media_tree.git?a=tree;f=drivers/media/video/saa7164;h=0acaa4ada45ae6881bfbb19447ae9db43f06ef9b;hb=staging/for_v2.6.37-rc1 saa7164-cards.c appears to have analog entries added for HVR-2200's and saa7164-encoder.c has a number of V4L ioctl()'s for MPEG streams. Is there any reason, why the additional card-information found here: http://www.kernellabs.com/hg/~stoth/saa7164-dev/ is not yet in the kernel tree? -- 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: Hauppauge USB Live 2
On 12/14/10 15:05, Mauro Carvalho Chehab wrote: Hi Devin, Em 14-12-2010 08:06, Devin Heitmueller escreveu: On Tue, Dec 14, 2010 at 4:57 AM, Gerd Hoffmann wrote: Hi folks, Got a "Hauppauge USB Live 2" after google found me that there is a linux driver for it. Unfortunaly linux doesn't manage to initialize the device. I've connected the device to a Thinkpad T60. It runs a 2.6.37-rc5 kernel with the linuxtv/staging/for_v2.6.38 branch merged in. Kernel log and lsusb output are attached. Ideas anyone? Looks like a regression got introduced since I submitted the original support for the device. Mauro? No idea what happened. The driver is working here with the devices I have. Unfortunately, I don't have any USB Live 2 here for testing. Based on the logs, maybe the driver is directing the I2C commands to the wrong bus. The better would be to bisect the kernel and see what patch broke it. The support for USB live2 were added on changeset 4270c3ca. There aren't many changes on it (45 changes), so, bisecting it shouldn't be hard: $ git log --oneline --no-merges 4270c3ca.. drivers/media/video/cx231xx f5db33f [media] cx231xx: stray unlock on error path Using that commit directly looks better. I still see the UsbInterface::sendCommand failures, but the driver seems to finish the initialization and looks for the firmware. So it seems something between -rc2 and -rc5 in mainline made it regress ... cheers, Gerd -- 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: tm6000 and IR
Am 14.12.2010 04:23, schrieb Dmitri Belimov: Hi What about my last patch?? This is OK or bad? Our customers kick me every day with IR remotes. With my best regards, Dmitry. I think, you use the second variant, Dmitry. Why you doesn't use this key map - RCMAP_BEHOLD. The power led we can change to a separate function, right. The nec initiation looks right and must adding code for tm5600/6000 (going over message pipe). rc5 need some code for tm6010 (for tm5600/6000 are the hack). And the logic for your remote control is unused for the second variant, but ir->rc_type = rc_type are o.k.. Then the function call usb_set_interface in tm6000_video, can write for example: stop_ir_pipe usb_set_interface start_ir_pipe I will adding vbi_buffer and device in the next, and isoc calculating without video_buffer size. Stefan Ringel -- 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Laurent Pinchart wrote: > On Tuesday 14 December 2010 14:31:55 Clemens Ladisch wrote: > > Laurent Pinchart wrote: > > > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > > >> EXT_SPEAKER also includes headphones; there might be made a case for > > >> having those as a separate subtype. > > > > > > Shouldn't headphones be represented by an EXT_JACK_ANALOG ? > > > > Headphone jacks are jacks; there are also USB headphones. > > So EXT_SPEAKER are speakers not connected through a jack (USB, internal > analog, ...) ? Yes. When there is jack, the driver often does not know what is connected. > > >> EXT_BROADCAST represents devices like TV tuners, satellite receivers, > > >> cable tuners, or radios. > > > > > > There's clearly an overlap with V4L here. > > > > These come from the USB audio spec. Video devices are indeed likely to > > be more detailed than just a single audio source. :) > > Does EXT_BROADCAST represent the TV tuner (or satellite receiver, cable tuner, > radio tuner, ...) itself, or the connection between the tuner and the rest of > the device ? Most TV tuner are currently handled by V4L2 and would thus turn > up as V4L2 subdevs (I'm not sure if that's what we want in the long term, but > it's at least the current situation). >From the point of view of an audio device, this would be just some audio source, much like a connector. We don't need this if there is some better V4L entitity that the USB audio entity can be mapped to. Regards, Clemens -- 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Hans, On Tuesday 14 December 2010 15:51:08 Hans Verkuil wrote: > > Laurent Pinchart wrote: > >> On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > >>> TYPE_EXT describes entities that represent some interface to the > >>> external world, TYPE_INT those that are internal to the entire device. > >>> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems > >>> to be an even more meaningless name.) > >> > >> SUBDEV comes from the V4L2 world, and I agree that it might not be a > >> very good > >> name. > >> > >> I'm not sure I would split entities in internal/external categories. I > >> would > >> create a category for connectors though. > > > > I'm not disagreeing, but what is actually the distinction between types > > and subtypes? ;-) > > The type tells what the behavior is of an entity. E.g., type DEVNODE > represents device node(s) in userspace, V4L2_SUBDEV represents a v4l2 > sub-device, etc. The subtype tells whether a V4L2_SUBDEV is a sensor or a > receiver or whatever. Nice to know, but it doesn't change the way > sub-devices work. > > In the case of connectors you would create a CONNECTOR type and have a > bunch of subtypes for all the variations of connectors. > > That said, I'm not sure whether the distinction is useful for DEVNODEs. > You do need to know the subtype in order to interpret the union correctly. > > Laurent, does the MC code test against the DEVNODE type? I.e., does the MC > code ignore the subtype of a DEVNODE, or does it always use it? The MC code uses the DEVNODE type, ignoring the subtype, for power management. When a device node is opened all entities in the chain need to be powered up. -- Regards, Laurent Pinchart -- 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
> Laurent Pinchart wrote: >> On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: >>> TYPE_EXT describes entities that represent some interface to the >>> external world, TYPE_INT those that are internal to the entire device. >>> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems >>> to be an even more meaningless name.) >> >> SUBDEV comes from the V4L2 world, and I agree that it might not be a >> very good >> name. >> >> I'm not sure I would split entities in internal/external categories. I >> would >> create a category for connectors though. > > I'm not disagreeing, but what is actually the distinction between types > and subtypes? ;-) The type tells what the behavior is of an entity. E.g., type DEVNODE represents device node(s) in userspace, V4L2_SUBDEV represents a v4l2 sub-device, etc. The subtype tells whether a V4L2_SUBDEV is a sensor or a receiver or whatever. Nice to know, but it doesn't change the way sub-devices work. In the case of connectors you would create a CONNECTOR type and have a bunch of subtypes for all the variations of connectors. That said, I'm not sure whether the distinction is useful for DEVNODEs. You do need to know the subtype in order to interpret the union correctly. Laurent, does the MC code test against the DEVNODE type? I.e., does the MC code ignore the subtype of a DEVNODE, or does it always use it? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens, Laurent, Hans & others! Clemens Ladisch wrote: > I wrote: >> I'll see if I can draw up the ALSA-specific media stuff over the weekend. > > Sorry, wrong weekend. > > Anyway, below are some remarks and a patch. > > > * Entity types > > TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a node > in a graph, which does not distinguish it from other entity types > because all entities are part of the topology graph. I chose "device" > as this type describes entities that are visible as some device node to > other software. > > TYPE_EXT describes entities that represent some interface to the > external world, TYPE_INT those that are internal to the entire device. > (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems > to be an even more meaningless name.) > > > ALSA mixer controls are not directly represented; a better fit for the > architecture of actual devices is that one or more mixer controls can be > associated with an entity. (This can be done with a field of the mixer > control.) > > > * Entity properties > > There needs to be a mechanism to associate meta-information (properties) > with entities. This information should be optional and extensible, but, > when being handled inside the kernel, doesn't need to be more than > a read-only blob. I think that something like ALSA's TLV format (used > for mixer controls) can be used here. (I'm not mentioning the X-word > here, except to note that the "M" stands for "markup".) > > > * Entity subtypes > > EXT_JACK_ANALOG represents any analog audio and/or video connector. > Properties for audio jacks would be jack type (TRS/RCA), color code, > line level, position, etc. > > EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/ > TOSLINK), ADAT, TDIF, or MADI. > > EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio > spec. (I doubt that any devices with this entitiy will ever exist.) > > EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI > controller. (Instrument entities are typically audio sources and MIDI > sources and sinks, but can also be audio sinks.) > > EXT_SPEAKER also includes headphones; there might be made a case for > having those as a separate subtype. > > EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can > also write to that device, so "player" might not be an ideal name. > > EXT_BROADCAST represents devices like TV tuners, satellite receivers, > cable tuners, or radios. > > INT_SYNTHESIZER converts MIDI to audio. > > INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt > to describe the characteristics of consumer-grade devices :-) , but > represents an internal noise source for level calibration or measurements. > > INT_CONTROLS may have multiple independent controls (this is USB's > Feature Unit); INT_EFFECT may have multiple controls that affect one > single algorithm. > > INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology > information has only stereo links. This naming already has been commented, but what do you think: should the type explicitly tell what kind of interface, if any, is exported to user space? Only MEDIA_ENTITY_NODE_* types do this currently, and MEDIA_ENTITY_TYPE_SUBDEV_* to some extent, but the way is not consistent at the moment. MEDIA_ENTITY_NODE_* range has lost of different interfaces whereas MEDIA_ENTITY_TYPE_SUBDEV_* are basically offering v4l2_subdev and beyond that, suggesting what kind of controls might be found from the nodes. I would expect that the interfaces offered by the character devices would be somewhat standardised in the end like v4l2_subdev user space interface. The types above are mostly describing the role of an entity, which might be interesting as well. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l: OMAP3 ISP CCDC: Add support for 8bit greyscale sensors
Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
syncronous interface.
The data width is configured in the parallel interface part of the isp platform
data, defaulting to 10bit as before this commit. When i 8bit mode don't apply
DC substraction of 64 per default as this would remove 1/4 of the sensor range.
When using V4L2_MBUS_FMT_Y8_1X8 (or possibly another 8bit per pixel) mode
set the CDCC to output 8bit per pixel instead of 16bit.
Signed-off-by: Martin Hostettler
---
drivers/media/video/isp/isp.h |2 ++
drivers/media/video/isp/ispccdc.c | 21 -
drivers/media/video/isp/ispvideo.c |7 +++
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/isp/isp.h b/drivers/media/video/isp/isp.h
index edc029c..76c09ed 100644
--- a/drivers/media/video/isp/isp.h
+++ b/drivers/media/video/isp/isp.h
@@ -132,11 +132,13 @@ struct isp_reg {
* ISPCTRL_PAR_BRIDGE_DISABLE - Disable
* ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
* ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
+ * @datsz: Width of the data-bus in bits (8, 10, 11, 12, 13) or 0 for default
(10bit)
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
+ unsigned int data_bus_width;
};
/**
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index be4581e..bff217a 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -45,6 +45,7 @@ static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_SRGGB10_1X10,
V4L2_MBUS_FMT_SBGGR10_1X10,
V4L2_MBUS_FMT_SGBRG10_1X10,
+ V4L2_MBUS_FMT_Y8_1X8,
};
/*
@@ -1069,6 +1070,10 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
isp_configure_bridge(isp, ccdc->input, pdata);
ispccdc_config_sync_if(ccdc, &ccdc->syncif);
+ /* CCDC_PAD_SINK */
+ format = &ccdc->formats[CCDC_PAD_SINK];
+ isp_video_mbus_to_pix(&ccdc->video_out, format, &pix);
+
syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Use the raw, unprocessed data when writing to memory. The H3A and
@@ -1086,10 +1091,14 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
else
syn_mode &= ~ISPCCDC_SYN_MODE_SDR2RSZ;
- isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
+ /* Use PACK8 mode for 1byte per pixel formats */
+ if (pix.bytesperline < format->width * 2)
+ syn_mode |= ISPCCDC_SYN_MODE_PACK8;
+ else
+ syn_mode &= ~ISPCCDC_SYN_MODE_PACK8;
- /* CCDC_PAD_SINK */
- format = &ccdc->formats[CCDC_PAD_SINK];
+
+ isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Mosaic filter */
switch (format->code) {
@@ -1128,7 +1137,6 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
<< ISPCCDC_VERT_LINES_NLV_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
- isp_video_mbus_to_pix(&ccdc->video_out, format, &pix);
ispccdc_config_outlineoffset(ccdc, pix.bytesperline, 0, 0);
/* CCDC_PAD_SOURCE_VP */
@@ -2164,6 +2172,9 @@ int isp_ccdc_init(struct isp_device *isp)
ccdc->syncif.ccdc_mastermode = 0;
ccdc->syncif.datapol = 0;
ccdc->syncif.datsz = 10;
+ if (isp->pdata->subdevs->interface == ISP_INTERFACE_PARALLEL
+ && isp->pdata->subdevs->bus.parallel.data_bus_width != 0)
+ ccdc->syncif.datsz =
isp->pdata->subdevs->bus.parallel.data_bus_width;
ccdc->syncif.fldmode = 0;
ccdc->syncif.fldout = 0;
ccdc->syncif.fldpol = 0;
@@ -2172,7 +2183,7 @@ int isp_ccdc_init(struct isp_device *isp)
ccdc->syncif.vdpol = 0;
ccdc->clamp.oblen = 0;
- ccdc->clamp.dcsubval = 64;
+ ccdc->clamp.dcsubval = (ccdc->syncif.datsz == 8) ? 0 : 64;
ccdc->vpcfg.pixelclk = 0;
diff --git a/drivers/media/video/isp/ispvideo.c
b/drivers/media/video/isp/ispvideo.c
index 64068ff..35e8c72 100644
--- a/drivers/media/video/isp/ispvideo.c
+++ b/drivers/media/video/isp/ispvideo.c
@@ -228,6 +228,10 @@ void isp_video_mbus_to_pix(const struct isp_video *video,
pix->pixelformat = V4L2_PIX_FMT_YUYV;
pix->bytesperline = pix->width * 2;
break;
+ case V4L2_MBUS_FMT_Y8_1X8:
+ pix->pixelformat = V4L2_PIX_FMT_GREY;
+ pix->bytesperline = pix->width;
+ break;
case V4L2_MBUS_FMT_UYVY8_1X16:
default:
pix->pixelformat = V4L2_PIX_FMT_UYVY;
@@ -261,6 +265,9 @@ void isp_video_pix_to_mbus(const struct v4l2_pix_format
*pix,
case V4L2_PIX_FMT_YUYV:
mbus->code = V4L2_MBUS_FMT_YUYV8_1X16;
break;
+ case V4L2_PIX_FMT_GREY:
+
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens, On Tuesday 14 December 2010 14:31:55 Clemens Ladisch wrote: > Laurent Pinchart wrote: > > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > >> TYPE_EXT describes entities that represent some interface to the > >> external world, TYPE_INT those that are internal to the entire device. > >> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems > >> to be an even more meaningless name.) > > > > SUBDEV comes from the V4L2 world, and I agree that it might not be a very > > good name. > > > > I'm not sure I would split entities in internal/external categories. I > > would create a category for connectors though. > > I'm not disagreeing, but what is actually the distinction between types > and subtypes? ;-) The type is currently used to distinguish between entities that stream media data from/to memory and other entities. They need to be handled differently in the kernel for power management purposes for instance. I'm not sure if we should create new types, or just remove the type/subtype distinction and add a flag somewhere. > >> * Entity properties > >> > >> There needs to be a mechanism to associate meta-information (properties) > >> with entities. This information should be optional and extensible, but, > >> when being handled inside the kernel, doesn't need to be more than > >> a read-only blob. I think that something like ALSA's TLV format (used > >> for mixer controls) can be used here. (I'm not mentioning the X-word > >> here, except to note that the "M" stands for "markup".) > > > > I've been thinking of adding a new ioctl for that. It's something we need > > to draft. The UVC driver will need it, and I'm pretty sure other V4L2 > > drivers would find it useful as well. > > I'm imagining a "read-the-properties" ioctl that just returns the > entity's blob. Martin Rubli has already proposed something similar a while ago on the linux- media mailing list. His proposal didn't use TLV though. > >> EXT_SPEAKER also includes headphones; there might be made a case for > >> having those as a separate subtype. > > > > Shouldn't headphones be represented by an EXT_JACK_ANALOG ? > > Headphone jacks are jacks; there are also USB headphones. So EXT_SPEAKER are speakers not connected through a jack (USB, internal analog, ...) ? > >> EXT_BROADCAST represents devices like TV tuners, satellite receivers, > >> cable tuners, or radios. > > > > There's clearly an overlap with V4L here. > > These come from the USB audio spec. Video devices are indeed likely to > be more detailed than just a single audio source. :) Does EXT_BROADCAST represent the TV tuner (or satellite receiver, cable tuner, radio tuner, ...) itself, or the connection between the tuner and the rest of the device ? Most TV tuner are currently handled by V4L2 and would thus turn up as V4L2 subdevs (I'm not sure if that's what we want in the long term, but it's at least the current situation). > >> INT_CONTROLS may have multiple independent controls (this is USB's > >> Feature Unit); INT_EFFECT may have multiple controls that affect one > >> single algorithm. > > > > I'd describe this as a feature unit/processing unit then. > > I was aiming for more descriptive names, but I agree that the original > names might be more useful. > > > Should we have an AUDIO category ? > > Probably not, because there are combined audio/video jacks, any maybe > other entities. > >> * Entity specifications > >> > >> While TYPE_DEVICE entities can be identified by their device node, other > >> entities typcially have just a numeric ID. > > > > In V4L2 sub-devices have (or rather will have once the media controller > > patches will be integrated) device nodes as well, so exposing that > > information is required. > > USB and HDA entities already have numeric IDs. Right. Same for USB Video Class. We could let drivers set the entity ID, and have the core fill it if the value is 0. Non-zero values would have to be checked for uniqueness though. Hans, a comment on that ? > >> For that, it would be useful to make do without separate identification > >> and let the driver choose the entity ID. > > > > How would drivers do that ? What if you have two instances of the same > > chip (a video sensor, audio mixer, ...) on the same board ? > > Then those would get different IDs; USB descriptors always describe the > entire device. -- Regards, Laurent Pinchart -- 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: Hauppauge USB Live 2
Hi Devin, Em 14-12-2010 08:06, Devin Heitmueller escreveu: > On Tue, Dec 14, 2010 at 4:57 AM, Gerd Hoffmann wrote: >> Hi folks, >> >> Got a "Hauppauge USB Live 2" after google found me that there is a linux >> driver for it. Unfortunaly linux doesn't manage to initialize the device. >> >> I've connected the device to a Thinkpad T60. It runs a 2.6.37-rc5 kernel >> with the linuxtv/staging/for_v2.6.38 branch merged in. >> >> Kernel log and lsusb output are attached. >> >> Ideas anyone? > > Looks like a regression got introduced since I submitted the original > support for the device. > > Mauro? No idea what happened. The driver is working here with the devices I have. Unfortunately, I don't have any USB Live 2 here for testing. Based on the logs, maybe the driver is directing the I2C commands to the wrong bus. The better would be to bisect the kernel and see what patch broke it. The support for USB live2 were added on changeset 4270c3ca. There aren't many changes on it (45 changes), so, bisecting it shouldn't be hard: $ git log --oneline --no-merges 4270c3ca.. drivers/media/video/cx231xx f5db33f [media] cx231xx: stray unlock on error path 9a1f8b3 [media] v4l: Remove module_name argument to the v4l2_i2c_new_subdev* functions 80bab1f [media] rc: Properly name the rc_map struct e58462f [media] rc: Rename remote controller type to rc_type instead of ir_type 9489b78 [media] cx231xx: Properly name rc_map name 6054b77 [media] rc: rename the remaining things to rc_core b8da8d2 [media] cx231xx-417: Remove unnecessary casts of void ptr returning alloc function return values c3e1500 [media] cx231xx: Fix i2c support at cx231xx-input 1639cc0 [media] ir-core: make struct rc_dev the primary interface 0d71fa1 [media] ir-core: more cleanups of ir-functions.c 0edf2e5 [media] v4l: kill the BKL e31e62a [media] cx231xx: Add IR support for Pixelview Hybrid SBTVD 0d1220a [media] cx231xx: Add a driver for I2C-based IR 2d1b6c2 [media] mb86a20s: add support for serial streams 9bb63ec [media] cx231xx: use callback to set agc on PixelView e97fc39 [media] add digital support for PV SBTVD hybrid 4938aef [media] Add analog support for Pixelvied Hybrid SBTVD 1532a07 [media] v4l: Remove hardcoded module names passed to v4l2_i2c_new_subdev* b838396 [media] cx231xx: fix double lock typo 4372584 [media] cx231xx: Fix compilation breakage if DVB is not selected 44ed895 [media] cx231xx: Remove IR support from the driver 10e4ebb [media] cx231xx: Only register USB interface 1 9439943 [media] v4l-dvb: using vmalloc needs vmalloc.h in cx231xx-417.c 643800d [media] cx231xx: use core-assisted lock 0f86158 [media] cx231xx: Colibri carrier offset was wrong for PAL/M 1001f90 [media] cx231xx: remove some unused functions 82c3cca [media] cx231xx: declare static functions as such bae94dc [media] cx231xx-417: Fix a gcc warning 955e6ed [media] CodingStyle cleanup at s5h1432 and cx231xx 61b04cb [media] cx231xx-audio: fix some locking issues 78bb6df [media] cx231xx: Only change gpio direction when needed a6f6fb9 [media] cx231xx: better handle the master port enable command 1a4aa92 [media] cx231xx: properly use the right tuner i2c address 24c80b6 [media] cx231xx: properly implement URB control messages log 92fbb811 [media] cx231xx: fix Kconfig dependencies 62c78c9 [media] cx231xx: remove a printk warning at -avcore and at -417 6af8cc0 [media] cx231xx: Fix vblank/vactive line counts for PAL/SECAM 222c435 [media] cx231xx: properly set active line count for PAL/SECAM 2ded0fe [media] cx231xx: whitespace cleanup b6cd9c4 [media] cx231xx: remove board specific check for Colibri configuration 8aed3f4 [media] cx231xx: Make the DIF configuration based on the tuner not the board id b522591 [media] cx231xx: remove i2c ir stubs 2b43db3 [media] cx231xx: move printk() line related to 417 initialization 9f51259 [media] cx231xx: fixup video grabber board profile 8880621 [media] cx231xx: make output mode configurable via the board profile 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
At Tue, 14 Dec 2010 14:31:55 +0100, Clemens Ladisch wrote: > > > Should we have an AUDIO category ? > > Probably not, because there are combined audio/video jacks, any maybe > other entities. Yes, nowadays HDMI / DP are pretty common, for example. Takashi -- 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Laurent Pinchart wrote: > On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: >> > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: >> >> * Entity types >> >> >> >> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a node >> >> in a graph, which does not distinguish it from other entity types >> >> because all entities are part of the topology graph. I chose "device" >> >> as this type describes entities that are visible as some device node to >> >> other software. >> > >> > What this type describes is a device node. Both NODE and DEVICE can be >> > confusing in my opinion, but DEVICE_NODE is a bit long. >> >> What about DEVNODE? I think that would be a good alternative. > > Fine with me. Clemens, any opinion on that ? Fine with me too. > > >> TYPE_EXT describes entities that represent some interface to the > > >> external world, TYPE_INT those that are internal to the entire device. > > >> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems > > >> to be an even more meaningless name.) > > > > > > SUBDEV comes from the V4L2 world, and I agree that it might not be a very > > > good name. > > > > SUBDEV refers to a specific type of driver. Within the v4l world it is > > well defined. So I prefer to keep this. Perhaps some additional comments > > or documentation can be added to clarify this. > > Should this be clarified by using V4L2_SUBDEV instead then ? If the "SUBDEV" concept doesn't exist outside V4L, that would indeed be better. I don't want to rename things that come out of existing frameworks; this naming discussion makes sense only for those entity (sub)types that can be shared between them. Are there any, besides jacks? > What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? The entity types representing ALSA devices are already named "ALSA". Regards, Clemens -- 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 several saa7134 cards
Em 13-12-2010 11:45, Artem Bokhan escreveu: > I use several (from three to five) saa7134-based cards on single PC. > Currently I'm trying to migrate from 2.6.22 to 2.6.32 (ubuntu lts). > > I've got problems which I did not have with 2.6.22 kernel: > > 1. Depending on configuration load average holds 1 or 2 when saa7134 module > is loaded. The reason is kernel process "events/". > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND >16 root 20 0 000 S3 0.0 9:36.89 events/1 >15 root 20 0 000 D3 0.0 9:35.81 events/0 Probably, it is IR polling. You may disable IR via modprobe parameter: $ modinfo saa7134|grep ir parm: disable_ir:disable infrared remote support (int) Not sure if this parameter is on .32 kernel of if it were added on a newer one. > 2. Sound and video are not synced when recording with mencoder. I think that there are some parameters at mencoder to adjust the sync between video and audio (-delay?). Basically, it needs to delay either audio or video, in order to sync. The delay time is empiric, as the audio API doesn't provide any way to pass audio timestamps, currently. > > > The same problem with 2.6.36 kernel except "events" process have different > name (can't remember exact name, sorry) > -- > 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: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Laurent Pinchart wrote: > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: >> TYPE_EXT describes entities that represent some interface to the >> external world, TYPE_INT those that are internal to the entire device. >> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems >> to be an even more meaningless name.) > > SUBDEV comes from the V4L2 world, and I agree that it might not be a very > good > name. > > I'm not sure I would split entities in internal/external categories. I would > create a category for connectors though. I'm not disagreeing, but what is actually the distinction between types and subtypes? ;-) >> * Entity properties >> >> There needs to be a mechanism to associate meta-information (properties) >> with entities. This information should be optional and extensible, but, >> when being handled inside the kernel, doesn't need to be more than >> a read-only blob. I think that something like ALSA's TLV format (used >> for mixer controls) can be used here. (I'm not mentioning the X-word >> here, except to note that the "M" stands for "markup".) > > I've been thinking of adding a new ioctl for that. It's something we need to > draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers > would find it useful as well. I'm imagining a "read-the-properties" ioctl that just returns the entity's blob. >> EXT_SPEAKER also includes headphones; there might be made a case for >> having those as a separate subtype. > > Shouldn't headphones be represented by an EXT_JACK_ANALOG ? Headphone jacks are jacks; there are also USB headphones. >> EXT_BROADCAST represents devices like TV tuners, satellite receivers, >> cable tuners, or radios. > > There's clearly an overlap with V4L here. These come from the USB audio spec. Video devices are indeed likely to be more detailed than just a single audio source. :) >> INT_CONTROLS may have multiple independent controls (this is USB's >> Feature Unit); INT_EFFECT may have multiple controls that affect one >> single algorithm. > > I'd describe this as a feature unit/processing unit then. I was aiming for more descriptive names, but I agree that the original names might be more useful. > Should we have an AUDIO category ? Probably not, because there are combined audio/video jacks, any maybe other entities. >> * Entity specifications >> >> While TYPE_DEVICE entities can be identified by their device node, other >> entities typcially have just a numeric ID. > > In V4L2 sub-devices have (or rather will have once the media controller > patches will be integrated) device nodes as well, so exposing that information > is required. USB and HDA entities already have numeric IDs. >> For that, it would be useful to make do without separate identification and >> let the driver choose the entity ID. > > How would drivers do that ? What if you have two instances of the same chip > (a video sensor, audio mixer, ...) on the same board ? Then those would get different IDs; USB descriptors always describe the entire device. Regards, Clemens -- 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
Terratec Cinergy HT MKII has a VHF problem.
>>> I think I found a bug in the "Terratec Cinergy HT PCI MKII." The card basically works, but the DVB stations in the VHF band have a problem. I can watch them (with xine or me-TV) or scan them only after a reboot, because if I change to a UHF station and then I re-tune to the previous VHF station, it doesn't work anymore. Here what happens with scandvb: [ja...@athlon650 ~]$ cat rai T 17750 7MHz 3/4 NONE QAM64 8k 1/32 NONE [ja...@athlon650 ~]$ cat med T 69800 8MHz 2/3 NONE QAM64 8k 1/32 NONE [ja...@athlon650 ~]$ scandvb rai scanning rai using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 17750 1 3 9 3 1 0 0 >>> tune to: 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 0x 0x0d49: pmt_pid 0x0102 RAI -- Rai 1 (running) 0x 0x0d4a: pmt_pid 0x0101 RAI -- Rai 2 (running) 0x 0x0d4b: pmt_pid 0x0100 RAI -- Rai 3 TGR Veneto (running) 0x 0x0d53: pmt_pid 0x0118 RAI -- Rai News (running) 0x 0x0d4c: pmt_pid 0x0103 Rai -- Rai Radio1 (running) 0x 0x0d4d: pmt_pid 0x0104 Rai -- Rai Radio2 (running) 0x 0x0d4e: pmt_pid 0x0105 Rai -- Rai Radio3 (running) Network Name 'Rai' >>> tune to: 16:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE __tune_to_transponder:1483: ERROR: Setting frontend parameters failed: 22 Invalid argument >>> tune to: 16:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE __tune_to_transponder:1483: ERROR: Setting frontend parameters failed: 22 Invalid argument dumping lists (7 services) Rai 1:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:512:650:3401 Rai 2:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:513:651:3402 Rai 3 TGR Veneto:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:514:652:3403 Rai News:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:520:690:3411 Rai Radio1:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:653:3404 Rai Radio2:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:654:3405 Rai Radio3:17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:655:3406 Done. [ja...@athlon650 ~]$ scandvb med scanning med using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 69800 0 2 9 3 1 0 0 >>> tune to: 69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 0x 0x0001: pmt_pid 0x0065 (null) -- Servizio OTA (running) 0x 0x03ec: pmt_pid 0x0101 (null) -- Servizio4 (running) 0x 0x03ed: pmt_pid 0x0105 (null) -- Servizio5 (running) 0x 0x03ee: pmt_pid 0x0106 (null) -- Servizio6 (running) 0x 0x03ef: pmt_pid 0x0107 (null) -- Servizio7 (running) 0x 0x03f0: pmt_pid 0x0108 (null) -- Servizio8 (running) 0x 0x03f1: pmt_pid 0x0109 (null) -- Servizio9 (running) 0x 0x03f2: pmt_pid 0x010a (null) -- Servizio10 (running) 0x 0x03f3: pmt_pid 0x010b (null) -- Servizio11 (running) 0x 0x03f4: pmt_pid 0x010c (null) -- Servizio12 (running) 0x 0x0fa4: pmt_pid 0x00cc Mediaset -- Rete4 (running) 0x 0x0fa5: pmt_pid 0x00cd Mediaset -- Canale5 (running) 0x 0x0fa6: pmt_pid 0x00ce Mediaset -- Italia1 (running) 0x 0x0fab: pmt_pid 0x00d3 Mediaset -- Mediaset Extra (running) 0x 0x0fad: pmt_pid 0x00d5 Mediaset -- La 5 (running) Network Name 'Mediaset4' dumping lists (15 services) Servizio OTA:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:1 Servizio4:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:1004 Servizio5:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:1005 Servizio6:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:1006 Servizio7:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:1007 Servizio8:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:1008 Servizio9:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4: QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:1009 Servizio10:69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Hans, On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: > > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > >> * Entity types > >> > >> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a node > >> in a graph, which does not distinguish it from other entity types > >> because all entities are part of the topology graph. I chose "device" > >> as this type describes entities that are visible as some device node to > >> other software. > > > > What this type describes is a device node. Both NODE and DEVICE can be > > confusing in my opinion, but DEVICE_NODE is a bit long. > > What about DEVNODE? I think that would be a good alternative. Fine with me. Clemens, any opinion on that ? > >> TYPE_EXT describes entities that represent some interface to the > >> external world, TYPE_INT those that are internal to the entire device. > >> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems > >> to be an even more meaningless name.) > > > > SUBDEV comes from the V4L2 world, and I agree that it might not be a very > > good name. > > SUBDEV refers to a specific type of driver. Within the v4l world it is > well defined. So I prefer to keep this. Perhaps some additional comments > or documentation can be added to clarify this. Should this be clarified by using V4L2_SUBDEV instead then ? What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? > > I'm not sure I would split entities in internal/external categories. I > > would create a category for connectors though. > > I agree. It was always the plan to eventually add connectors, but v4l > didn't really need it (it already has an API to enumerate connectors). > > >> ALSA mixer controls are not directly represented; a better fit for the > >> architecture of actual devices is that one or more mixer controls can be > >> associated with an entity. (This can be done with a field of the mixer > >> control.) > > > > Agreed. > > > >> * Entity properties > >> > >> There needs to be a mechanism to associate meta-information (properties) > >> with entities. This information should be optional and extensible, but, > >> when being handled inside the kernel, doesn't need to be more than > >> a read-only blob. I think that something like ALSA's TLV format (used > >> for mixer controls) can be used here. (I'm not mentioning the X-word > >> here, except to note that the "M" stands for "markup".) > > > > I've been thinking of adding a new ioctl for that. It's something we need > > to draft. The UVC driver will need it, and I'm pretty sure other V4L2 > > drivers would find it useful as well. > > > >> * Entity subtypes > >> > >> EXT_JACK_ANALOG represents any analog audio and/or video connector. > >> Properties for audio jacks would be jack type (TRS/RCA), color code, > >> line level, position, etc. > >> > >> EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/ > >> TOSLINK), ADAT, TDIF, or MADI. > >> > >> EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio > >> spec. (I doubt that any devices with this entitiy will ever exist.) > >> > >> EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI > >> controller. (Instrument entities are typically audio sources and MIDI > >> sources and sinks, but can also be audio sinks.) > >> > >> EXT_SPEAKER also includes headphones; there might be made a case for > >> having those as a separate subtype. > > > > Shouldn't headphones be represented by an EXT_JACK_ANALOG ? > > > >> EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can > >> also write to that device, so "player" might not be an ideal name. > >> > >> EXT_BROADCAST represents devices like TV tuners, satellite receivers, > >> cable tuners, or radios. > > I don't think it is right to talk about 'represents devices'. I'd rephrase > it to 'connects to devices'. > > > There's clearly an overlap with V4L here. Hopefully someone from the > > linux-media list can comment on this. > > I don't think this will be a problem. Initially we probably won't be > enumerating connectors for V4L since it already has its own API for that. My understanding is that EXT_BROADCAST really represents the TV tuners, ..., not the connector they connect to. Some (all ?) of them are definitely V4L2 subdevs. > >> INT_SYNTHESIZER converts MIDI to audio. > >> > >> INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt > >> to describe the characteristics of consumer-grade devices :-) , but > >> represents an internal noise source for level calibration or > >> measurements. > >> > >> INT_CONTROLS may have multiple independent controls (this is USB's > >> Feature Unit); INT_EFFECT may have multiple controls that affect one > >> single algorithm. > > > > I'd describe this as a feature unit/processing unit then. > > > >> INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology > >> information has only stereo links. > > > >
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
> Hi Clemens, > > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: >> I wrote: >> > I'll see if I can draw up the ALSA-specific media stuff over the >> weekend. >> >> Sorry, wrong weekend. >> >> Anyway, below are some remarks and a patch. > > Thank you. Please see my comments inline. > >> * Entity types >> >> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a node >> in a graph, which does not distinguish it from other entity types >> because all entities are part of the topology graph. I chose "device" >> as this type describes entities that are visible as some device node to >> other software. > > What this type describes is a device node. Both NODE and DEVICE can be > confusing in my opinion, but DEVICE_NODE is a bit long. What about DEVNODE? I think that would be a good alternative. >> TYPE_EXT describes entities that represent some interface to the >> external world, TYPE_INT those that are internal to the entire device. >> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems >> to be an even more meaningless name.) > > SUBDEV comes from the V4L2 world, and I agree that it might not be a very > good > name. SUBDEV refers to a specific type of driver. Within the v4l world it is well defined. So I prefer to keep this. Perhaps some additional comments or documentation can be added to clarify this. > I'm not sure I would split entities in internal/external categories. I > would > create a category for connectors though. I agree. It was always the plan to eventually add connectors, but v4l didn't really need it (it already has an API to enumerate connectors). >> ALSA mixer controls are not directly represented; a better fit for the >> architecture of actual devices is that one or more mixer controls can be >> associated with an entity. (This can be done with a field of the mixer >> control.) > > Agreed. > >> * Entity properties >> >> There needs to be a mechanism to associate meta-information (properties) >> with entities. This information should be optional and extensible, but, >> when being handled inside the kernel, doesn't need to be more than >> a read-only blob. I think that something like ALSA's TLV format (used >> for mixer controls) can be used here. (I'm not mentioning the X-word >> here, except to note that the "M" stands for "markup".) > > I've been thinking of adding a new ioctl for that. It's something we need > to > draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers > would find it useful as well. > >> * Entity subtypes >> >> EXT_JACK_ANALOG represents any analog audio and/or video connector. >> Properties for audio jacks would be jack type (TRS/RCA), color code, >> line level, position, etc. >> >> EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/ >> TOSLINK), ADAT, TDIF, or MADI. >> >> EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio >> spec. (I doubt that any devices with this entitiy will ever exist.) >> >> EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI >> controller. (Instrument entities are typically audio sources and MIDI >> sources and sinks, but can also be audio sinks.) >> >> EXT_SPEAKER also includes headphones; there might be made a case for >> having those as a separate subtype. > > Shouldn't headphones be represented by an EXT_JACK_ANALOG ? > >> EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can >> also write to that device, so "player" might not be an ideal name. >> >> EXT_BROADCAST represents devices like TV tuners, satellite receivers, >> cable tuners, or radios. I don't think it is right to talk about 'represents devices'. I'd rephrase it to 'connects to devices'. > There's clearly an overlap with V4L here. Hopefully someone from the > linux- > media list can comment on this. I don't think this will be a problem. Initially we probably won't be enumerating connectors for V4L since it already has its own API for that. >> INT_SYNTHESIZER converts MIDI to audio. >> >> INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt >> to describe the characteristics of consumer-grade devices :-) , but >> represents an internal noise source for level calibration or >> measurements. >> >> INT_CONTROLS may have multiple independent controls (this is USB's >> Feature Unit); INT_EFFECT may have multiple controls that affect one >> single algorithm. > > I'd describe this as a feature unit/processing unit then. > >> INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology >> information has only stereo links. > > Some of those INT entities could also be implemented in dedicated chips, > so I > really think the EXT/INT split doesn't make too much sense. Should we have > an > AUDIO category ? > >> * Entity specifications >> >> While TYPE_DEVICE entities can be identified by their device node, other >> entities typcially have just a numeric ID. > > In V4L2 sub-devices have (or rather will have once
Re: [patch v2] [media] bttv: take correct lock in bttv_open()
Em 14-12-2010 08:36, Dan Carpenter escreveu: > On Mon, Dec 13, 2010 at 01:42:49AM +0300, Sergej Pupykin wrote: >> mutex_lock(&btv->lock); >> *fh = btv->init; >> mutex_unlock(&btv->lock); >> >> Probably it is overkill and may be incorrect, but it starts working. >> > > Mauro would be the one to know for sure. > >> Also I found another issue: tvtime hangs on exit in D-state, so it >> looks like there is a problem near bttv_release function or >> something like this. > > Speaking of other bugs in this driver, I submitted a another fix > that hasn't been merged yet. I've attached it. Don't know if it's > related at all to the other bug you noticed but it can't hurt. I'm preparing one machine in order to test bttv and try to fix the locking issues. Hopefully, I'll have something today. 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] bttv: fix mutex use before init
On Mon, Dec 13, 2010 at 04:30:24PM -0800, Brandon Philips wrote:
> On 17:13 Sun 12 Dec 2010, Torsten Kaiser wrote:
> > * change &fh->cap.vb_lock in bttv_open() AND radio_open() to
> > &btv->init.cap.vb_lock
> > * add a mutex_init(&btv->init.cap.vb_lock) to the setup of init in
> > bttv_probe()
>
> That seems like a reasonable suggestion. An openSUSE user submitted this
> bug to our tracker too. Here is the patch I am having him test.
>
> Would you mind testing it?
>
> From 456dc0ce36db523c4c0c8a269f4eec43a72de1dc Mon Sep 17 00:00:00 2001
> From: Brandon Philips
> Date: Mon, 13 Dec 2010 16:21:55 -0800
> Subject: [PATCH] bttv: fix locking for btv->init
>
> Fix locking for the btv->init by using btv->init.cap.vb_lock and in the
> process fix uninitialized deref introduced in c37db91fd0d.
Tested this patch, seems fine. But there's still possible deadlock, kernel
hangs with lockdep warning, I think maybe it is another issue.
Could some v4l2 guys who have deep understand about bttv driver have a look at
this issue?
[ 322.172772] bttv: driver version 0.9.18 loaded
[ 322.172781] bttv: using 8 buffers with 2080k (520 pages) each for capture
[ 322.173300] bttv: Bt8xx card found (0).
[ 322.174510] bttv :03:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 322.174560] bttv0: Bt878 (rev 17) at :03:01.0, irq: 17, latency: 64,
mmio: 0xd0001000
[ 322.174679] bttv0: detected: Leadtek WinFast TV 2000 [card=34], PCI
subsystem ID is 107d:6606
[ 322.174687] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP
[card=34,autodetected]
[ 322.175062] bttv0: gpio: en=, out= in=003fbfff [init]
[ 322.178792] bttv0: tuner type=5
[ 322.254454] bttv0: audio absent, no audio device found!
[ 322.289946] tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw])
[ 322.290944] tuner-simple 1-0061: creating new instance
[ 322.290953] tuner-simple 1-0061: type set to 5 (Philips PAL_BG (FI1216 and
compatibles))
[ 322.295830] bttv0: registered device video0
[ 322.300020] bttv0: registered device vbi0
[ 322.303216] bttv0: registered device radio0
[ 322.303636] bttv0: PLL: 28636363 => 35468950 .. ok
[ 322.334635] Registered IR keymap rc-winfast
[ 322.341201] input: bttv IR (card=34) as
/devices/pci:00/:00:1e.0/:03:01.0/rc/rc0/input4
[ 322.357025] rc0: bttv IR (card=34) as
/devices/pci:00/:00:1e.0/:03:01.0/rc/rc0
[ 382.342433] bttv0: PLL can sleep, using XTAL (28636363).
[ 382.816353] irq event stamp: 1078776
[ 382.816363] hardirqs last enabled at (1078775): []
debug_check_no_locks_freed+0x102/0x113
[ 382.816381]
[ 382.816384] ===
[ 382.816389] [ INFO: possible circular locking dependency detected ]
[ 382.816394] 2.6.37-rc5-00062-g6313e3c-dirty #114
[ 382.816398] ---
[ 382.816403] kdetv/2109 is trying to acquire lock:
[ 382.816408] (&mm->mmap_sem){++}, at: [] might_fault+0x47/0x81
[ 382.816422]
[ 382.816424] but task is already holding lock:
[ 382.816427] (&q->vb_lock){+.+.+.}, at: []
videobuf_queue_lock+0x10/0x12 [videobuf_core]
[ 382.816442]
[ 382.816444] which lock already depends on the new lock.
[ 382.816446]
[ 382.816449]
[ 382.816450] the existing dependency chain (in reverse order) is:
[ 382.816455]
[ 382.816456] -> #1 (&q->vb_lock){+.+.+.}:
[ 382.816463][] lock_acquire+0xa1/0xc4
[ 382.816472][] __mutex_lock_common+0x35/0x2dc
[ 382.816482][] mutex_lock_nested+0x30/0x38
[ 382.816489][] videobuf_queue_lock+0x10/0x12 [videobuf_core]
[ 382.816499][] videobuf_mmap_mapper+0x69/0xc0
[videobuf_core]
[ 382.816509][] bttv_mmap+0x66/0x6d [bttv]
[ 382.816522][] v4l2_mmap+0x5a/0x73
[ 382.816532][] mmap_region+0x24c/0x400
[ 382.816540][] do_mmap_pgoff+0x22f/0x27f
[ 382.816547][] sys_mmap_pgoff+0xdd/0x119
[ 382.816560][] syscall_call+0x7/0xb
[ 382.816569]
[ 382.816571] -> #0 (&mm->mmap_sem){++}:
[ 382.816577][] __lock_acquire+0x9d7/0xc86
[ 382.816585][] lock_acquire+0xa1/0xc4
[ 382.816592][] might_fault+0x64/0x81
[ 382.816599][] copy_to_user+0x2c/0xfe
[ 382.816608][] videobuf_read_stream+0x17f/0x24c
[videobuf_core]
[ 382.816619][] bttv_read+0xcf/0xe9 [bttv]
[ 382.816633][] v4l2_read+0x63/0x7f
[ 382.816640][] vfs_read+0x81/0xdb
[ 382.816649][] sys_read+0x3b/0x60
[ 382.816655][] syscall_call+0x7/0xb
[ 382.816663]
[ 382.816665] other info that might help us debug this:
[ 382.816667]
[ 382.816671] 1 lock held by kdetv/2109:
[ 382.816675] #0: (&q->vb_lock){+.+.+.}, at: []
videobuf_queue_lock+0x10/0x12 [videobuf_core]
[ 382.816688]
[ 382.816690] stack backtrace:
[ 382.816695] Pid: 2109, comm: kdetv Not tainted
2.6.37-rc5-00062-g6313e3c-dirty #114
[ 382.816700] Call Trace:
[ 382.816639] hardirqs last disabled at (1078776): []
common_interr
Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Clemens,
On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote:
> I wrote:
> > I'll see if I can draw up the ALSA-specific media stuff over the weekend.
>
> Sorry, wrong weekend.
>
> Anyway, below are some remarks and a patch.
Thank you. Please see my comments inline.
> * Entity types
>
> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a node
> in a graph, which does not distinguish it from other entity types
> because all entities are part of the topology graph. I chose "device"
> as this type describes entities that are visible as some device node to
> other software.
What this type describes is a device node. Both NODE and DEVICE can be
confusing in my opinion, but DEVICE_NODE is a bit long.
> TYPE_EXT describes entities that represent some interface to the
> external world, TYPE_INT those that are internal to the entire device.
> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems
> to be an even more meaningless name.)
SUBDEV comes from the V4L2 world, and I agree that it might not be a very good
name.
I'm not sure I would split entities in internal/external categories. I would
create a category for connectors though.
> ALSA mixer controls are not directly represented; a better fit for the
> architecture of actual devices is that one or more mixer controls can be
> associated with an entity. (This can be done with a field of the mixer
> control.)
Agreed.
> * Entity properties
>
> There needs to be a mechanism to associate meta-information (properties)
> with entities. This information should be optional and extensible, but,
> when being handled inside the kernel, doesn't need to be more than
> a read-only blob. I think that something like ALSA's TLV format (used
> for mixer controls) can be used here. (I'm not mentioning the X-word
> here, except to note that the "M" stands for "markup".)
I've been thinking of adding a new ioctl for that. It's something we need to
draft. The UVC driver will need it, and I'm pretty sure other V4L2 drivers
would find it useful as well.
> * Entity subtypes
>
> EXT_JACK_ANALOG represents any analog audio and/or video connector.
> Properties for audio jacks would be jack type (TRS/RCA), color code,
> line level, position, etc.
>
> EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/
> TOSLINK), ADAT, TDIF, or MADI.
>
> EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio
> spec. (I doubt that any devices with this entitiy will ever exist.)
>
> EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI
> controller. (Instrument entities are typically audio sources and MIDI
> sources and sinks, but can also be audio sinks.)
>
> EXT_SPEAKER also includes headphones; there might be made a case for
> having those as a separate subtype.
Shouldn't headphones be represented by an EXT_JACK_ANALOG ?
> EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can
> also write to that device, so "player" might not be an ideal name.
>
> EXT_BROADCAST represents devices like TV tuners, satellite receivers,
> cable tuners, or radios.
There's clearly an overlap with V4L here. Hopefully someone from the linux-
media list can comment on this.
> INT_SYNTHESIZER converts MIDI to audio.
>
> INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt
> to describe the characteristics of consumer-grade devices :-) , but
> represents an internal noise source for level calibration or measurements.
>
> INT_CONTROLS may have multiple independent controls (this is USB's
> Feature Unit); INT_EFFECT may have multiple controls that affect one
> single algorithm.
I'd describe this as a feature unit/processing unit then.
> INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology
> information has only stereo links.
Some of those INT entities could also be implemented in dedicated chips, so I
really think the EXT/INT split doesn't make too much sense. Should we have an
AUDIO category ?
> * Entity specifications
>
> While TYPE_DEVICE entities can be identified by their device node, other
> entities typcially have just a numeric ID.
In V4L2 sub-devices have (or rather will have once the media controller
patches will be integrated) device nodes as well, so exposing that information
is required.
> For that, it would be useful to make do without separate identification and
> let the driver choose the entity ID.
How would drivers do that ? What if you have two instances of the same chip (a
video sensor, audio mixer, ...) on the same board ?
> Signed-off-by: Clemens Ladisch
>
> --- linux/include/linux/media.h
> +++ linux/include/linux/media.h
> @@ -46,16 +46,36 @@ struct media_device_info {
> #define MEDIA_ENTITY_TYPE_MASK 0x00ff
> #define MEDIA_ENTITY_SUBTYPE_MASK0x
>
> -#define MEDIA_ENTITY_TYPE_NODE (1 <<
> MEDIA_ENTITY_TYPE_SHIFT)
> -#define MEDIA_ENTITY_TYPE_
Fwd: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
I miss linux-media email addres.
So, I added it.
Thanks.
-
Hi Laurent and Hans,
I am working on V4L2 subdev for M5MOLS by Fujitsu.
and I wanna listen your comments about Auto Focus mode of my ideas.
the details is in the following link discussed at the past.
Although the situation(adding the more various functions at the M5MOLS
or any other MEGA camera sensor, I worked.)is changed,
so I wanna continue this threads for now.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
First of all, the at least two more mode of auto-focus exists in the
M5MOLS camera sensor. So, considering defined V4L2 controls and the controls
in the M5MOLS, I suggest like this:
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_POSITION = 2,
+};
+#define V4L2_CID_FOCUS_POSITION
(V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+15)
The M5MOLS(or other recent camera sensor) can have at least 2 mode although in
any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports positioning focus
mode, AKA. POSITION AF mode.
The MACRO mode scan short range, and this mode can be used at the circumstance
in the short distance with object and camera lens. So, It has fast lens
movement,
but the command FOCUSING dosen't works well at the long distance object.
On the other hand, NORMAL mode can this. As the words, It's general and normal
focus
mode. The M5MOLS scan fully in the mode.
In the Position AF mode, the position(expressed x,y) is given at the M5MOLS,
and then the M5MOLS focus this area. But, the time given the position, is
normally touch the lcd screen at the mobile device, in my case. If the time is
given from button, it's no big problem *when*. But, in touch-lcd screen case,
the position is read at the touch screen driver,
before command FOCUS to camera sensor. It's the why I add another
CID(V4L2_CID_FOCUS_POSITION).
So, how do you think about this?
Thanks to read my ideas, and I wait for your answer.
Regrads,
HeungJun Kim
PS. can you let me know where the recent v4l2 controls is described or
specificated??
I found this -
http://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#camera-controls,
but It seems a little old, I think.
--
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: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ?
Hi Laurent Pinchart, Thanks you for reply. It makes sense. Best regards, Jonghun Han > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > Sent: Tuesday, December 14, 2010 8:00 PM > To: Jonghun Han > Cc: linux-media@vger.kernel.org; 'Hans Verkuil'; mche...@redhat.com > Subject: Re: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in > V4L2_MEMORY_USERPTR case ? > > Hi Jonghun, > > On Tuesday 14 December 2010 11:51:17 Jonghun Han wrote: > > Hi, > > > > Any comment for this ? > > > > In my opinion v4l2 spec is not accurate in this topic. > > Because VIDIOC_REQBUFS describes count is only used in > V4L2_MEMORY_MMAP as > > below. > > __u32 count The number of buffers requested or granted. This field is > > only used when memory is set to V4L2_MEMORY_MMAP. > > > > But there is no comment in QBUF and DQBUF part about index. > > So I am confused. If an index isn't needed, how to driver handle it ? > > The spec should be fixed. VIDIOC_REQBUFS needs to be called for USERPTR as > well, and the buffer count is definitely used. > > > On Saturday, December 11, 2010 2:10 PM Jonghun Han wrote: > > > > > > I wonder that a index should be passed on the fly with the VIDIOC_QBUF > > > ioctl in V4L2_MEMORY_USERPTR case. > > > If it isn't needed, should driver return virtual address gotten from > > > application on the fly with the VIDIOC_DQBUF ioctl ? > > VIDIOC_DQBUF is supposed to fill the v4l2_buffer structure with the index and > the userspace virtual address (among other information). If it doesn't, it's a > driver bug. > > -- > Regards, > > Laurent Pinchart > -- > 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: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ?
Hi Jonghun, On Tuesday 14 December 2010 11:51:17 Jonghun Han wrote: > Hi, > > Any comment for this ? > > In my opinion v4l2 spec is not accurate in this topic. > Because VIDIOC_REQBUFS describes count is only used in V4L2_MEMORY_MMAP as > below. > __u32 count The number of buffers requested or granted. This field is > only used when memory is set to V4L2_MEMORY_MMAP. > > But there is no comment in QBUF and DQBUF part about index. > So I am confused. If an index isn't needed, how to driver handle it ? The spec should be fixed. VIDIOC_REQBUFS needs to be called for USERPTR as well, and the buffer count is definitely used. > On Saturday, December 11, 2010 2:10 PM Jonghun Han wrote: > > > > I wonder that a index should be passed on the fly with the VIDIOC_QBUF > > ioctl in V4L2_MEMORY_USERPTR case. > > If it isn't needed, should driver return virtual address gotten from > > application on the fly with the VIDIOC_DQBUF ioctl ? VIDIOC_DQBUF is supposed to fill the v4l2_buffer structure with the index and the userspace virtual address (among other information). If it doesn't, it's a driver bug. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.37] uvcvideo: BKL removal
Hi Mauro, Please don't forget this pull request for 2.6.37. On Monday 29 November 2010 11:15:10 Laurent Pinchart wrote: > Hi Mauro, > > The following changes since commit > c796e203229c8c08250f9d372ae4e10c466b1787: > > [media] kconfig: add an option to determine a menu's visibility > (2010-11-22 10:37:56 -0200) > > are available in the git repository at: > git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable > > They complete the BKL removal from the uvcvideo driver. Feedback received > from Hans during review has been integrated. > > Laurent Pinchart (5): > uvcvideo: Lock controls mutex when querying menus > uvcvideo: Move mutex lock/unlock inside uvc_free_buffers > uvcvideo: Move mmap() handler to uvc_queue.c > uvcvideo: Lock stream mutex when accessing format-related information > uvcvideo: Convert to unlocked_ioctl > > drivers/media/video/uvc/uvc_ctrl.c | 48 +- > drivers/media/video/uvc/uvc_queue.c | 133 +- > drivers/media/video/uvc/uvc_v4l2.c | 185 > +++--- drivers/media/video/uvc/uvc_video.c | > 3 - > drivers/media/video/uvc/uvcvideo.h | 10 ++- > 5 files changed, 222 insertions(+), 157 deletions(-) -- Regards, Laurent Pinchart -- 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: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ?
Hi, Any comment for this ? In my opinion v4l2 spec is not accurate in this topic. Because VIDIOC_REQBUFS describes count is only used in V4L2_MEMORY_MMAP as below. __u32 count The number of buffers requested or granted. This field is only used when memory is set to V4L2_MEMORY_MMAP. But there is no comment in QBUF and DQBUF part about index. So I am confused. If an index isn't needed, how to driver handle it ? Best regards, Jonghun Han, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Jonghun Han > Sent: Saturday, December 11, 2010 2:10 PM > To: linux-media@vger.kernel.org > Subject: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in > V4L2_MEMORY_USERPTR case ? > > Hi, > > I wonder that a index should be passed on the fly with the VIDIOC_QBUF > ioctl in V4L2_MEMORY_USERPTR case. > If it isn't needed, should driver return virtual address gotten from > application on the fly with the VIDIOC_DQBUF ioctl ? > > Best regards, > Jonghun Han, > -- > 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: Request for linux drivers for IDS uEye USB cameras -- we will ship you the hardware and you can keep it
Hi all, while the email to got delivered to prj...@linuxdriverproject.org & linux-ker...@vger.kernel.org the attachment made the linux-media list eat this mail. Resending verbatim without attachment. Richard On Wed, Dec 8, 2010 at 13:16, Richard Hartmann wrote: > Hi all, > > as Hans de Goede does not have enough free time to go after this, he > asked me to poke the V4L list. As this also concerns Linux in general, > I am sending to the Linux Driver Project as well. [0] says to mail > prjmgr@ for new projects so I am doing that. Finally, I wasn't sure if > mailing LKML would reach people who might reasonably be interested in > this offer yet miss it due to not reading the other two lists. I am > still unsure but decided to default to the save option especially as > one additional email to LKML is a drop in an insanely-sized bucket, > anyway. > > > We have two USB cameras by IDS Imaging [1], the uEye XS [2] and the > uEye LE [3] which require a proprietary blob [4] to run under Linux. > There is an user-space API of questionable usefulness. We would prefer > native V4L support which actually works over said Linux "solution". > > > The USB IDs are: > > Bus 002 Device 007: ID 1409:1645 # uEye U|164xLE-C > Bus 002 Device 002: ID 1409:1008 # uEye U|1008XS-C (seems to be a > Sony package meant for phones with IDS stuff around it) > > The full output lsusb -v can be found at > http://paste.debian.net/100555/ - the first entry is my mouse :p > > > The text on chips on the LE is: > > CY22150FZ > XC > 1007 A 02 > 609214 > > 2400P > ED4Ca > > 464WP > K018 > > Output from usbmon [5] is attached. It's only 344 kiB in size so I > decided to attach it for everyone's convenience. In case any list > filters out attachments, just poke me and I'll send them your way. > > > More stuff: > > * We will ship the cameras we bought to you. Preferably to a location > where shipping costs are not insane; Europe preferred. You keep the > cameras; they are yours. > * You try and get pictures out of the cams. We don't need HD or > anything. Our use case is criminal investigation so pics don't need to > be print perfect. > * The XS has auto focus and can somewhat dynamically adapt to > different lighting situations. Ideally, this should work. > * Hans will advise us on who of the volunteers, if any, are best > suited for this. I don't know the V4L community; he does. If we get > volunteers via the Linux Driver Project, I don't know how people are > selected, but I am happy to go with whatever they propose. > * While we know that no guarantees of any kind can be made, we > obviously prefer fast results over slower ones. If someone has gobs of > time available and is looking for a end-of-year project, that is a > huge plus :p That being said, we don't expect miracles. > * As the cameras were not cheap, we would appreciate, but do not > require, a short mention in the initial commit message[s]. > > As an aside, if anyone can point us to any small (around thumb size or > smaller) cameras, both with really wide angle and narrow angle, that > connect via USB, FireWire, or Ethernet and are well-supported under > Linux... we are all ears. The pictures will need to be fed into > zoneminder, other than that, we don't really care how we get the pics > as long as it's reliable and supported for the longer term. One would > assume that dozens of webcams would fit the bill, but most of the ones > I could find have been EOLed for ages. > > > Thanks, > Richard > > [0] http://www.linuxdriverproject.org/foswiki/bin/view/Main/MailingLists > [1] http://www.ids-imaging.com/ > [2] http://www.ids-imaging.com/frontend/products.php?cam_id=125 > [3] http://www.ids-imaging.com/frontend/products.php?cam_id=48 > [4] http://www.ueyesetup.de/frontend/files/uEyeupdater/Setup_e.htm > [5] http://people.redhat.com/zaitcev/linux/usbmon-6.tar.gz > -- Richard -- 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 v2] [media] bttv: take correct lock in bttv_open()
On Mon, Dec 13, 2010 at 01:42:49AM +0300, Sergej Pupykin wrote:
> mutex_lock(&btv->lock);
> *fh = btv->init;
> mutex_unlock(&btv->lock);
>
> Probably it is overkill and may be incorrect, but it starts working.
>
Mauro would be the one to know for sure.
> Also I found another issue: tvtime hangs on exit in D-state, so it
> looks like there is a problem near bttv_release function or
> something like this.
Speaking of other bugs in this driver, I submitted a another fix
that hasn't been merged yet. I've attached it. Don't know if it's
related at all to the other bug you noticed but it can't hurt.
regards,
dan carpenter
>From erro...@gmail.com Thu Nov 18 07:19:15 2010
Date: Thu, 18 Nov 2010 06:55:59 +0300
From: Dan Carpenter
To: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org, kernel-janit...@vger.kernel.org
Subject: [patch] [media] bt8xx: missing unlock in bttv_overlay()
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8
Status: RO
There is a missing unlock here. This was introduced as part of BKL
removal in c37db91fd0d4 "V4L/DVB: bttv: fix driver lock and remove
explicit calls to BKL"
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c
index 3da6e80..aca755c 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -2779,16 +2779,14 @@ static int bttv_overlay(struct file *file, void *f, unsigned int on)
mutex_lock(&fh->cap.vb_lock);
/* verify args */
if (unlikely(!btv->fbuf.base)) {
- mutex_unlock(&fh->cap.vb_lock);
- return -EINVAL;
- }
- if (unlikely(!fh->ov.setup_ok)) {
+ retval = -EINVAL;
+ } else if (unlikely(!fh->ov.setup_ok)) {
dprintk("bttv%d: overlay: !setup_ok\n", btv->c.nr);
retval = -EINVAL;
}
+ mutex_unlock(&fh->cap.vb_lock);
if (retval)
return retval;
- mutex_unlock(&fh->cap.vb_lock);
}
if (!check_alloc_btres_lock(btv, fh, RESOURCE_OVERLAY))
Re: [PATCHv7 08/10] mm: cma: Contiguous Memory Allocator added
> On Mon, 13 Dec 2010 12:26:49 +0100
> Michal Nazarewicz wrote:
>> +/* Initialise CMA */
>> +
>> +static struct cma_grabbed {
>> +unsigned long start;
>> +unsigned long size;
>> +} cma_grabbed[8] __initdata;
>> +static unsigned cma_grabbed_count __initdata;
>> +
>> +int cma_init(unsigned long start, unsigned long size)
>> +{
>> +pr_debug("%s(%p+%p)\n", __func__, (void *)start, (void *)size);
>> +
>> +if (!size)
>> +return -EINVAL;
>> +if ((start | size) & ((MAX_ORDER_NR_PAGES << PAGE_SHIFT) - 1))
>> +return -EINVAL;
>> +if (start + size < start)
>> +return -EOVERFLOW;
>> +
>> +if (cma_grabbed_count == ARRAY_SIZE(cma_grabbed))
>> +return -ENOSPC;
>> +
>> +cma_grabbed[cma_grabbed_count].start = start;
>> +cma_grabbed[cma_grabbed_count].size = size;
>> +++cma_grabbed_count;
>> +return 0;
>> +}
>> +
KAMEZAWA Hiroyuki writes:
> Is it guaranteed that there are no memory holes, or zone overlap
> in the range ? I think correctness of the range must be checked.
I keep thinking about it myself. The idea is that you get memory range
reserved using memblock (or some such) thus it should not contain any
memory holes. I'm not entirely sure about spanning different zones.
I'll add the checking code.
>> +#define MIGRATION_RETRY 5
>> +static int __cm_migrate(unsigned long start, unsigned long end)
>> +{
[...]
>> +}
>> +
>> +static int __cm_alloc(unsigned long start, unsigned long size)
>> +{
>> +unsigned long end, _start, _end;
>> +int ret;
>> +
[...]
>> +
>> +start = phys_to_pfn(start);
>> +end = start + (size >> PAGE_SHIFT);
>> +
>> +pr_debug("\tisolate range(%lx, %lx)\n",
>> + pfn_to_maxpage(start), pfn_to_maxpage_up(end));
>> +ret = __start_isolate_page_range(pfn_to_maxpage(start),
>> + pfn_to_maxpage_up(end), MIGRATE_CMA);
>> +if (ret)
>> +goto done;
>> +
>> +pr_debug("\tmigrate range(%lx, %lx)\n", start, end);
>> +ret = __cm_migrate(start, end);
>> +if (ret)
>> +goto done;
>> +
[...]
>> +
>> +pr_debug("\tfinding buddy\n");
>> +ret = 0;
>> +while (!PageBuddy(pfn_to_page(start & (~0UL << ret
>> +if (WARN_ON(++ret >= MAX_ORDER))
>> +return -EINVAL;
>> +
>> +_start = start & (~0UL << ret);
>> +pr_debug("\talloc freed(%lx, %lx)\n", _start, end);
>> +_end = alloc_contig_freed_pages(_start, end, 0);
>> +
>> +/* Free head and tail (if any) */
>> +pr_debug("\tfree contig(%lx, %lx)\n", _start, start);
>> +free_contig_pages(pfn_to_page(_start), start - _start);
>> +pr_debug("\tfree contig(%lx, %lx)\n", end, _end);
>> +free_contig_pages(pfn_to_page(end), _end - end);
>> +
>> +ret = 0;
>> +
>> +done:
>> +pr_debug("\tundo isolate range(%lx, %lx)\n",
>> + pfn_to_maxpage(start), pfn_to_maxpage_up(end));
>> +__undo_isolate_page_range(pfn_to_maxpage(start),
>> + pfn_to_maxpage_up(end), MIGRATE_CMA);
>> +
>> +pr_debug("ret = %d\n", ret);
>> +return ret;
>> +}
>> +
>> +static void __cm_free(unsigned long start, unsigned long size)
>> +{
>> +pr_debug("%s(%p+%p)\n", __func__, (void *)start, (void *)size);
>> +
>> +free_contig_pages(pfn_to_page(phys_to_pfn(start)),
>> + size >> PAGE_SHIFT);
>> +}
> Hmm, it seems __cm_alloc() and __cm_migrate() has no special codes for CMA.
> I'd like reuse this for my own contig page allocator.
> So, could you make these function be more generic (name) ?
> as
> __alloc_range(start, size, mirate_type);
>
> Then, what I have to do is only to add "search range" functions.
Sure thing. I'll post it tomorrow or Friday. How about
alloc_contig_range() maybe?
--
Pozdrawiam_ _
.o. | Wasal Jasnie Oswieconej Pani Informatyki o' \,=./ `o
..o | Michal "mina86" Nazarewicz (o o)
ooo +-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 06/10] mm: MIGRATE_CMA migration type added
> On Mon, 13 Dec 2010 12:26:47 +0100
> Michal Nazarewicz wrote:
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> @@ -35,13 +35,24 @@
>> */
>> #define PAGE_ALLOC_COSTLY_ORDER 3
>>
>> -#define MIGRATE_UNMOVABLE 0
>> -#define MIGRATE_RECLAIMABLE 1
>> -#define MIGRATE_MOVABLE 2
>> -#define MIGRATE_PCPTYPES 3 /* the number of types on the pcp lists */
>> -#define MIGRATE_RESERVE 3
>> -#define MIGRATE_ISOLATE 4 /* can't allocate from here */
>> -#define MIGRATE_TYPES 5
>> +enum {
>> +MIGRATE_UNMOVABLE,
>> +MIGRATE_RECLAIMABLE,
>> +MIGRATE_MOVABLE,
>> +MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
>> +MIGRATE_RESERVE = MIGRATE_PCPTYPES,
>> +MIGRATE_ISOLATE,/* can't allocate from here */
>> +#ifdef CONFIG_MIGRATE_CMA
>> +MIGRATE_CMA,/* only movable */
>> +#endif
>> +MIGRATE_TYPES
>> +};
>
KAMEZAWA Hiroyuki writes:
> I personaly would like to put MIGRATE_ISOLATE to be bottom of enum
> because it means _not_for_allocation.
Will change. I didn't want to change the value of MIGRATE_ISOLATE in
fear of breaking something but hopefully no one depends on
MIGRATE_ISOLATE's value.
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> @@ -824,11 +848,15 @@ struct page *__rmqueue_smallest(struct zone *zone,
>> unsigned int order,
>> * This array describes the order lists are fallen back to when
>> * the free lists for the desirable migrate type are depleted
>> */
>> -static int fallbacks[MIGRATE_TYPES][MIGRATE_TYPES-1] = {
>> +static int fallbacks[MIGRATE_TYPES][4] = {
>> [MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,
>> MIGRATE_RESERVE },
>> [MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE,
>> MIGRATE_RESERVE },
>> +#ifdef CONFIG_MIGRATE_CMA
>> +[MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,
>> MIGRATE_CMA, MIGRATE_RESERVE },
>> +#else
>> [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,
>> MIGRATE_RESERVE },
>> -[MIGRATE_RESERVE] = { MIGRATE_RESERVE, MIGRATE_RESERVE,
>> MIGRATE_RESERVE }, /* Never used */
>> +#endif
>> +[MIGRATE_RESERVE] = { MIGRATE_RESERVE }, /* Never used */
>> };
>>
>> /*
>> @@ -924,12 +952,12 @@ __rmqueue_fallback(struct zone *zone, int order, int
>> start_migratetype)
>> /* Find the largest possible block of pages in the other list */
>> for (current_order = MAX_ORDER-1; current_order >= order;
>> --current_order) {
>> -for (i = 0; i < MIGRATE_TYPES - 1; i++) {
>> +for (i = 0; i < ARRAY_SIZE(fallbacks[0]); i++) {
> Why fallbacks[0] ? and why do you need to change this ?
I've changed the dimensions of fallbacks matrix, in particular second
dimension from MIGRATE_TYPE - 1 to 4 so this place needed to be changed
as well. Now, I think changing to ARRAY_SIZE() is just the safest
option available. This is actually just a minor optimisation.
>> migratetype = fallbacks[start_migratetype][i];
>>
>> /* MIGRATE_RESERVE handled later if necessary */
>> if (migratetype == MIGRATE_RESERVE)
>> -continue;
>> +break;
>>
> Isn't this change enough for your purpose ?
This is mostly just an optimisation really. I'm not sure what you think
is my purpose here. ;) It does fix an this issue of some of the
fallback[*] arrays having MIGRATETYPE_UNMOVABLE at the end.
>> @@ -1042,7 +1083,12 @@ static int rmqueue_bulk(struct zone *zone, unsigned
>> int order,
>> list_add(&page->lru, list);
>> else
>> list_add_tail(&page->lru, list);
>> -set_page_private(page, migratetype);
>> +#ifdef CONFIG_MIGRATE_CMA
>> +if (is_pageblock_cma(page))
>> +set_page_private(page, MIGRATE_CMA);
>> +else
>> +#endif
>> +set_page_private(page, migratetype);
> Hmm, doesn't this meet your changes which makes MIGRATE_CMA >
> MIGRATE_PCPLIST ? And I think putting mixture of pages marked of
> MIGRATE_TYPE onto a pcplist is ugly.
You mean that pcplist page is on can disagree with page_private()?
I didn't think this was such a big deal honestly. Unless MIGRATE_CMA <
MIGRATE_PCPTYPES, a special case is needed either here or in
free_pcppages_bulk(), so I think this comes down to whether to make
MIGRATE_CAM < MIGRATE_PCPTYPES for which see below.
>> @@ -1181,9 +1227,16 @@ void free_hot_cold_page(struct page *page, int cold)
>> * offlined but treat RESERVE as movable pages so we can get those
>> * areas back if necessary. Otherwise, we may have to free
>> * excessively into the page allocator
>> + *
>> + * Still, do not change migration type of MIGRATE_CMA pages (if
>> + * they'd be recorded as MIGRATE_MOVABLE an unmovable page
Re: Hauppauge USB Live 2
On Tue, Dec 14, 2010 at 4:57 AM, Gerd Hoffmann wrote: > Hi folks, > > Got a "Hauppauge USB Live 2" after google found me that there is a linux > driver for it. Unfortunaly linux doesn't manage to initialize the device. > > I've connected the device to a Thinkpad T60. It runs a 2.6.37-rc5 kernel > with the linuxtv/staging/for_v2.6.38 branch merged in. > > Kernel log and lsusb output are attached. > > Ideas anyone? Looks like a regression got introduced since I submitted the original support for the device. Mauro? 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
Hauppauge USB Live 2
Hi folks, Got a "Hauppauge USB Live 2" after google found me that there is a linux driver for it. Unfortunaly linux doesn't manage to initialize the device. I've connected the device to a Thinkpad T60. It runs a 2.6.37-rc5 kernel with the linuxtv/staging/for_v2.6.38 branch merged in. Kernel log and lsusb output are attached. Ideas anyone? cheers, Gerd [ 231.994065] usb 1-2: new high speed USB device using ehci_hcd and address 5 [ 232.110991] usb 1-2: New USB device found, idVendor=2040, idProduct=c200 [ 232.110998] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 232.111023] usb 1-2: Product: Hauppauge Device [ 232.111029] usb 1-2: Manufacturer: Hauppauge [ 232.111033] usb 1-2: SerialNumber: 0013566174 [ 232.465523] IR NEC protocol handler initialized [ 232.489573] Linux video capture interface: v2.00 [ 232.499834] IR RC5(x) protocol handler initialized [ 232.518668] IR RC6 protocol handler initialized [ 232.541743] IR JVC protocol handler initialized [ 232.579260] IR Sony protocol handler initialized [ 232.614172] lirc_dev: IR Remote Control driver registered, major 250 [ 232.643778] IR LIRC bridge handler initialized [ 232.656779] cx231xx v4l2 driver loaded. [ 232.656844] cx231xx #0: New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 5 interfaces [ 232.656848] cx231xx #0: registering interface 1 [ 232.659017] cx231xx #0: can't change interface 3 alt no. to 3: Max. Pkt size = 0 [ 232.660130] cx231xx #0: can't change interface 4 alt no. to 1: Max. Pkt size = 0 [ 232.661252] cx231xx #0: Identified as Hauppauge USB Live 2 (card=9) [ 232.686363] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.686726] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.687166] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.687479] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.687853] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.688348] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.688727] cx231xx #0: UsbInterface::sendCommand, failed with status --32 [ 232.688731] cx231xx #0: cx231xx_dev_init: cx231xx_afe init super block - errCode [-32]! [ 232.688845] cx231xx #0: cx231xx_init_dev: cx231xx_i2c_register - errCode [-32]! [ 232.688859] cx231xx: probe of 1-2:1.1 failed with error -32 [ 232.688915] usbcore: registered new interface driver cx231xx Bus 001 Device 005: ID 2040:c200 Hauppauge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x2040 Hauppauge idProduct 0xc200 bcdDevice 40.01 iManufacturer 1 Hauppauge iProduct2 Hauppauge Device iSerial 3 0013566174 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 248 bNumInterfaces 6 bConfigurationValue 1 iConfiguration 4 Hauppauge Device bmAttributes 0x80 (Bus Powered) MaxPower 340mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 32 Hauppauge Device Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0e EP 14 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Interface Association: bLength 8 bDescriptorType11 bFirstInterface 1 bInterfaceCount 5 bFunctionClass255 Vendor Specific Class bFunctionSubClass 255 Vendor Specific Subclass bFunctionProtocol 255 Vendor Specific Protocol iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting
RE: [RFC][media] s5p-fimc : Need to modify for s5pv310
Hi Sylwester, Thanks for your reply. I almost agree with your opinion. On 12/13/2010 07:46 PM, Sylwester Nawrocki wrote: > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki > Sent: Monday, December 13, 2010 7:46 PM > To: sungchun.k...@samsung.com > Cc: linux-media@vger.kernel.org > Subject: Re: [RFC][media] s5p-fimc : Need to modify for s5pv310 > > > Hi Sungchun, > > On 12/10/2010 03:21 AM, Sungchun Kang wrote: > > > > > >> -Original Message- > >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >> ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki > >> Sent: Monday, December 06, 2010 6:46 PM > >> To: sungchun.k...@samsung.com > >> Cc: linux-media@vger.kernel.org > >> Subject: Re: [RFC][media] s5p-fimc : Need to modify for s5pv310 > >> > >> Hi Sungchun, > >> > >> thanks for your suggestions. > >> I am planning to improve output DMA handling in the fimc camera > >> capture driver, > >> what is done already is only a minimal adaptation to make driver > work > >> on > >> S5PV310 SoC. We don't even have a platform support (resource and > >> platform > >> device definitions) for f...@s5pv310 yet though. I think it needs > to > >> be done first. > >> > >> Your proposed scheme of presetting output DMA buffer adresses > before > >> streaming > >> is enabled and then using the CIFCNTSEQ register to mask out > buffers > >> passed > >> to user space looks reasonable to me. I could imagine adopting such > a > >> method > >> for buffer of V4L2_MEMORY_MMAP memory type. But do you think it is > >> going to > >> work for V4L2_MEMORY_USERPTR? There is no confidence that USERPTR > >> addresses > >> passed by applications in subsequent VIDIOC_QBUF calls will not be > >> changing, > >> right? > > > > Like V4L2_MEMORY_MMAP, it is possible to use V4L2_MEMORY_USERPTR for > memory type. > > Surely, in case of V4L2_MEMORY_USERPTR, output buffer SFR could be > changed. > > But, it is possible to adjust my concept too. > > When the VIDIOC_QBUF called, user can set m.userptr field to the > address of the buffer, > > length to its size, and index field. > > > > > > > > Output DMASFR index m.userptr > > CIFCNTSEQ[bit] > > CIOYSA1 0 0x4000 [0] - > > enable > > CIOYSA2 1 0x40001000 [1] - > > enable > > CIOYSA3 2 0x40002000 [2] - > > enable > > CIOYSA4 3 0x40003000 [3] - > > enable > > CIOYSA5 4 0x40004000 [4] - > > enable > > CIOYSA6 5 0x40005000 [5] - > > enable > > CIOYSA1 0 0x40006000 [0] - > > enable > (SFR value change for output buffer) > > > > Because it is possible to regard a index as output DMA SFR, there's > no need to use pending queue concept. > > I do not really see much gain in that approach, we still need to > obtain > physical address from video buffer, read the address from registers, > compare > both and then perform write if necessary. First of all, I wonder V4L2 standard as below. Index field of v4l2_buffer is used not only V4L2_MEMORY_MMAP but also V4L2_MEMORY_USERPTR of vb2_qbuf. But it is not described at V4L2 standard. What is right thing? And in V4L2_MEMORY_USERPTR case, you're right. But I doubt such case(change CIOYSAn's value)is existed. > The code would be different among various SoC revisions and it would > increase > interrupt service routine size. > I would see CIFCNTSEQ as a means of additional protection preventing > the DMA > engine from writing to a buffer which has been passed to user land. > CIFCNTSEQ is for maximum 32 buffer count to user. User can select buffer count easier. > Please note that if user does not queue the buffers in an ascending > buffer > index order, the buffers are going to be dequeued out of order. > Since we cannot change the order of processing the buffers in hardware, > we are only able to mask/unmask specific buffer in the DMA engine. > The processing sequence is always fixed and the buffers would be > dequeued > in an ascending video buffer index order. > However this kind of operation is possible with videobuf2. > > The modification for s5pv310 is rather straightforward. I am more > concerned > at the moment with the fact that in s5pv210 output frame index > register > seem to be changing in a non deterministic way when the CIOYSAn > address > registers are being updated in the interrupt handler. So it looks like > there is > no reliable status register in HW to determine which DMA buffer is > currently > being used. This causes trouble when streaming is stopped in the > camera capture > driver when user does not queue buffer on time, and then > the capturing need
Re: Translation Faults on OMAP ISP update
Hi Sergio, On Friday 03 December 2010 01:32:08 Aguirre, Sergio wrote: > On Thursday, December 02, 2010 11:34 AM Lane Brooks wrote: > > On 12/02/2010 07:35 AM, Laurent Pinchart wrote: > > [snip] > > > > > > Any ideas on the problem? Is there a way to force a reset to the CCDC > > > > so that it will become IDLE? > > > > > > Would you expect the ISP to recover gracefully if you removed the > > > OMAP3530 or the RAM from the board and plugged it back ? The same > > > applies to the sensor :-) > > > > > > Long story short, once started, the CCDC can't be stopped before the > > > end of the image. When you unplug the sensor the CCDC will wait forever > > > for the end of frame. When restarted it will resume working to the > > > previous, no longer mapped buffer, leading to IOMMU faults. > > > The CCDC, like most ISP blocks, can't be reset individually. You need > > > to reset the whole ISP to recover from this (blame whoever decided that > > > individual block resets were not useful). This was done before on > > > streamoff, but now that the ISP driver supports running multiple > > > pipelines in parallel we can't do it anymore. > > > > > > It might be possible to write a clean patch to reset the ISP when all > > > streams are stopped. In the meantime you can rmmod/modprobe the driver. > > > > Laurent, > > > > Thanks for the feedback. The behavior makes perfect sense now. I can > > take it from here. Given the user *can* unplug the sensor module in our > > hardware, I need to do something, as locking up the kernel is not > > acceptable. I will first look to see if an ISP reset on stream off > > works, as we can sacrifice multiple pipeline support (for now). > > Laurent, > > Just a question on this: > > Do we ever plan to support dynamic v4l2_subdevs > registration/unregistration? > > I guess we'll require to "notify" the media controller device, so we add > it, (or remove it) from the pipeline, and refresh the links. > > I think that is going to become an important requirement, as like Lane is > doing (unloading a module). > > It's very likely that we can interchange camera modules, like in the > Beagleboard xM, and we don't have a real reason to really not support > that. > > It would be very cool to be able to: > > 1. Plug Aptina 5MP camera sensor. > 2. Load the kernel module > 3. Use the camera > 4. Unload the kernel module > 5. Interchange the camera board for a VGA sensor > 6. Load the appropriate sensor driver. > > All that without needing to restart the board. > > Does that really sound _that_ crazy to everyone? :) Totally :-) One good reason not to support that is that the busses used by the sensors (I2C and CCDC parallel interface) are not hot-pluggable. You can't get connect/disconnect events, you can't discover devices dynamically, and connecting/disconnected a sensor while the system is powered on might damage both the sensor and the processor. Is that a good enough reason ? :-) -- Regards, Laurent Pinchart -- 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 1/8] v4l: add videobuf2 Video for Linux 2 driver framework
Hello,
On Tuesday, December 14, 2010 8:58 AM Hans Verkuil wrote:
> On Tuesday, December 14, 2010 08:14:32 Marek Szyprowski wrote:
> > Hello,
> >
> > On Saturday, December 11, 2010 5:55 PM Hans Verkuil wrote:
> >
> > Big thanks for the review! I will fix all these minor issues and resend
> > the patches soon. I hope we will manage to get videobuf2 merged soon! :)
> >
> > > Hi Marek,
> > >
> > > Here is my review. I wish I could ack it, but I found a few bugs that need
> > > fixing first. Also a bunch of small stuff that's trivial to fix.
> > >
> > > On Monday, December 06, 2010 11:52:38 Marek Szyprowski wrote:
> > > > From: Pawel Osciak
> > > >
> > > > Videobuf2 is a Video for Linux 2 API-compatible driver framework for
> > > > multimedia devices. It acts as an intermediate layer between userspace
> > > > applications and device drivers. It also provides low-level, modular
> > > > memory management functions for drivers.
> > > >
> > > > Videobuf2 eases driver development, reduces drivers' code size and aids
> > > > in
> > > > proper and consistent implementation of V4L2 API in drivers.
> > > >
> > > > Videobuf2 memory management backend is fully modular. This allows custom
> > > > memory management routines for devices and platforms with non-standard
> > > > memory management requirements to be plugged in, without changing the
> > > > high-level buffer management functions and API.
> > > >
> > > > The framework provides:
> > > > - implementations of streaming I/O V4L2 ioctls and file operations
> > > > - high-level video buffer, video queue and state management functions
> > > > - video buffer memory allocation and management
> > > >
> > > > Signed-off-by: Pawel Osciak
> > > > Signed-off-by: Marek Szyprowski
> > > > Signed-off-by: Kyungmin Park
> > > > CC: Pawel Osciak
> > > > ---
> >
> >
> >
> > > > +/**
> > > > + * __vb2_wait_for_done_vb() - wait for a buffer to become available
> > > > + * for dequeuing
> > > > + *
> > > > + * Will sleep if required for nonblocking == false.
> > > > + */
> > > > +static int __vb2_wait_for_done_vb(struct vb2_queue *q, int nonblocking)
> > > > +{
> > > > + /*
> > > > +* All operation on vb_done_list is performed under vb_done_lock
> > > > +* spinlock protection. However buffers may must be removed from
> > > > +* it and returned to userspace only while holding both driver's
> > > > +* lock and the vb_done_lock spinlock. Thus we can be sure that
> > > > as
> > > > +* long as we hold lock, the list will remain not empty if this
> > > > +* check succeeds.
> > > > +*/
> > > > +
> > > > + for (;;) {
> > > > + int ret;
> > > > +
> > > > + if (!q->streaming) {
> > > > + dprintk(1, "Streaming off, will not wait for
> > > > buffers\n");
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (!list_empty(&q->done_list)) {
> > > > + /*
> > > > +* Found a buffer that we were waiting for.
> > > > +*/
> > > > + break;
> > > > + } else if (nonblocking) {
> > >
> > > The 'else' keyword can be removed since the 'if' above always breaks.
> > >
> > > > + dprintk(1, "Nonblocking and no buffers to
> > > > dequeue, "
> > > > + "will
> > > > not wait\n");
> > > > + return -EAGAIN;
> > > > + }
> > > > +
> > > > + /*
> > > > +* We are streaming and blocking, wait for another
> > > > buffer to
> > > > +* become ready or for streamoff. Driver's lock is
> > > > released to
> > > > +* allow streamoff or qbuf to be called while waiting.
> > > > +*/
> > > > + call_qop(q, wait_prepare, q);
> > > > +
> > > > + /*
> > > > +* All locks has been released, it is safe to sleep now.
> > > > +*/
> > > > + dprintk(3, "Will sleep waiting for buffers\n");
> > > > + ret = wait_event_interruptible(q->done_wq,
> > > > + !list_empty(&q->done_list) ||
> > > > !q->streaming);
> > > > +
> > > > + /*
> > > > +* We need to reevaluate both conditions again after
> > > > reacquiring
> > > > +* the locks or return an error if it occured. In case
> > > > of error
> > > > +* we return -EINTR, because -ERESTARTSYS should not be
> > > > returned
> > > > +* to userspace.
> > > > +*/
> > > > + call_qop(q, wait_finish, q);
> > > > + if (ret)
> > > > + return -EINTR;
> > >
> > > No, this should be -ERESTARTSYS. This won't be returned to userspace,
> > > instead
> > > the kernel will handle
