Re: S2-3200 switching-timeouts on 2.6.38
On 03/21/2011 08:46 PM, Rico Tzschichholz wrote: Hello, I would like to know if there is any intention to include this patch soon? https://patchwork.kernel.org/patch/244201/ Currently using 2.6.38 results in switching-timeouts on my S2-3200 and this patch fixes this for good. So it would be nice to have it in 2.6.39. Thank you and best regards, Rico Tzschichholz Hello, I also have a Technotrend S2-3200. Bought it 4 years ago. Support for Linux seemed to be close at the time. I was a bit of a fool for thinking that. It's been on the shelf for most of the time. Anyway, I've applied that patch, and it turns the S2-3200 from being worth hardly more than a paperweight to a functional DVB-S card. I don't understand why this patch does not get included. Only DVB-S2 transponders don't consistently lock properly in kaffeine. I'll test what "scan" does tomorrow, see if it's a kaffeine-specific problem or not. But even just DVB-S working properly is a massive difference for this card. If it helps, I'll check the silicon version of my card tomorrow as well. Best regards, P. van Gaans -- 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: USB mini-summit at LinuxCon Vancouver
On Tuesday 09 August 2011, Hans de Goede wrote: > Hi, > > On 08/09/2011 10:31 PM, Adam Baker wrote: > > On Tuesday 09 August 2011, Hans de Goede wrote: > > > > It has also just occured to me that it might be possible to solve the > > issues we are facing just in the kernel. At the moment when the kernel > > performs a USBDEVFS_DISCONNECT it keeps the kernel driver locked out > > until userspace performs a USBDEVFS_CONNECT. If the kernel reattached > > the kernel driver when the device file was closed then, as gvfs doesn't > > keep the file open the biggest current issue would be solved instantly. > > If a mechanism could be found to prevent USBDEVFS_DISCONNECT from > > succeeding when the corresponding /dev/videox file was open then that > > would seem to be a reasonable solution. > > > > This has been discussed over and over and over again, playing clever > tricks with USBDEVFS_[DIS]CONNECT like adding a new USBDEVFS_TRYDISCONNECT > which the v4l2 driver could intercept won't cut it. We need some central > manager of the device doing multiplexing between the 2 functions, and you > can *not* assume that either side will be nice wrt closing file > descriptors. > > Examples: > 1) You are wrong wrt gvfs, it does keep the libgphoto2 context open all the > time, and through that the usbfs device nodes. It seems that that depends, on my system gvfs isn't actually automounting the camera after it detects it and the file is only open (according to lsof) when the device is actually mounted. As soon as you unmount it the device gets closed again. Because it does do a brief open, USBDEVFS_DISCONNECT then close at connection time it does still disable the kernel driver. > > 2) Lets say a user starts a photo managing app like f-spot, and that opens > the device through libgphoto2 on startup, then the user switches to another > virtual desktop and forgets all about having f-spot open. Notice that if > the user now tries to stream he will not get a busy error, but the app > trying to do the streaming will simply not see the camera at all (kernel > driver unbound /dev/video# node is gone). This does seem like a situation where your approach could potentially give a better user experience. I'm wondering slightly how you define busy though. For webcams the streamon and streamoff ioctls tell you if you are using mmap or userptr transfers but you don't know if when the user has finished if they just use read. For stillcam mode it is again hard to determine a busy condition other than being in the middle of transfering an individual picture. > > 3) Notice that little speaker icon in your panel on your average Linux > desktop, that keeps the mixer of the audio device open *all the time* it > is quite easy to imagine a similar applet for v4l2 device controls (see > for example gtk-v4l) doing the same. Or a user could simply start up a > v4l2 control panel app like gtk-v4l, qv4l2 or v4l2ucp, and leave it running > minimized ... > This again needs a usable concept of busy > 4) Some laptops have a Fn + F## key which enables / disables the builtin > webcam by turning its power on / off. Effectively plugging it into / out > of a usb port. We would like to have an on screen notification of this one > day like we have now for brightness and volume controls, based on udev > events. But the current dual mode cam stuff causes udev events for > a *new* video device being added / an existing one being removed > each time libgphoto2 releases / takes control of the camera. > Would such a system know what camera is supposed to be the internal one so it doesn't show the camera as turned on just because you plug in an external camera. If so then it won't turn on and off as an external camera changes modes. If not then showing on when any camera is usable and off when it isn't seems like sensible behaviour. > 5) More in general, more and more software is dynamically monitoring the > addition / removal of (usb) devices using udev, our current solution > suggests to this software the /dev/video device is being unplugged / > re-plugged all the time, not pretty. > > > All in all what we've today is a kludge, and if we want to provide > a "seamless" user experience we need to fix it. I think in summary I'm concerned about the possibility of perfect being the enemy of good enough. At the moment we've got a significant usability problem (a web search for gvfs-gphoto2-volume-monitor turns up mostly instructions on how to disable it). If we come up with a solution that whilst it would be perfect there isn't enough effort available to implement then that is worse than a solution that fixes most of the problem. This is an even greater concern when the technically superior solution has a higher long term maintenance overhead (as we no longer get Win32 and OSX users helping to maintain the stillcam drivers). I'm not sure if there is anything in this discussion that is relevant to the cameras in phones or tablets. T
Re: Structure of DiSEqC Command
On 08/08/2011 19:06, Nima Mohammadi wrote: > Hi folks, > I was reading the source code of various dvb related utilities and I > was wondering about forming up the message which instructs the DiSEqC > switch. But I found out that different programs produce the command > differently. > The confusing thing is that according to the DiSEqC specification > documents that I've read, the least significant bit (lsb) must > indicate the band (low/high), not the polarity (ver/hor), but as you > see it only applies to some of these programs: > > getstrean abd dvbstream: > int i = 4 * switch_pos + 2 * hiband + (voltage_18 ? 1 : 0); > > szap and mplayer: > (((sat_no * 4) & 0x0f) | (hi_lo ? 1 : 0) | (polv ? 0 : 2)); > > scan: > 4 * switch_pos + 2 * hiband + (voltage_18 ? 1 : 0) > > gstdvbsrc: > (((sat_no * 4) & 0x0f) | (tone == SEC_TONE_ON ? 1 : 0) | (voltage == > SEC_VOLTAGE_13 ? 0 : 2)); > > Hello I'm the upstream author of MuMuDVB (http://mumudvb.braice.net) The diseqc related code is here http://gitweb.braice.net/gitweb?p=mumudvb;a=blob;f=src/tune.c On the document http://www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/applic_info_LNB_switchers.pdf Page 7 (page 10 of the PDF) the band is the LSB and the table is organized in increasing binary data But in http://www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/update_recomm_for_implim.pdf page 33 (35 in the PDF) The LSB SEEMS to be the polarization, but it's still the band, the table is just organized in a strange way If you look deeply into the code of scan http://www.linuxtv.org/hg/dvb-apps/file/36a084aace47/util/scan/diseqc.c You'll see that the table is organized as in the second document and the code addresses the table for making the message but there is no mistake in the real data since it's f0,f2,f1 etc ... So the difference is if the diseqc data is wrote directly (as in MuMuDVB) or taken from a table organised as in the specification (as in scan) Hope it's clear and it helps Regards -- Brice A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting annoying in email? -- 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
It has "HDTV DVB-T USB2.0 MINI BOX" on it
[ 1736.936937] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, interface 0, class 0) [ 1736.941002] em28xx #0: chip ID is em2870 [ 1737.100772] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 70 28 c0 12 62 00 6a 22 00 00 [ 1737.100796] em28xx #0: i2c eeprom 10: 00 00 04 57 00 1d 00 00 00 00 00 00 00 00 00 00 [ 1737.100816] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 1e 00 00 [ 1737.100835] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 1737.100853] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.100872] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.100890] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 1737.100908] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 [ 1737.100927] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 1737.100945] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.100963] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.100982] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.101000] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.101018] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.101036] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.101054] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1737.101076] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xfdc15a89 [ 1737.101081] em28xx #0: EEPROM info: [ 1737.101084] em28xx #0: No audio on board. [ 1737.101088] em28xx #0: 500mA max power [ 1737.101094] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 1737.102519] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 1737.108771] em28xx #0: found i2c device @ 0x1e [???] [ 1737.144523] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 1737.151276] em28xx #0: found i2c device @ 0xc4 [tuner (analog)] [ 1737.162155] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 1737.162159] em28xx #0: You may try to use card= insmod option to workaround that. [ 1737.162161] em28xx #0: Please send an email with this log to: [ 1737.162163] em28xx #0: V4L Mailing List [ 1737.162165] em28xx #0: Board eeprom hash is 0xfdc15a89 [ 1737.162167] em28xx #0: Board i2c devicelist hash is 0xe62e628f [ 1737.162169] em28xx #0: Here is a list of valid choices for the card= insmod option: [ 1737.162172] em28xx #0: card=0 -> Unknown EM2800 video grabber [ 1737.162174] em28xx #0: card=1 -> Unknown EM2750/28xx video grabber [ 1737.162176] em28xx #0: card=2 -> Terratec Cinergy 250 USB [ 1737.162179] em28xx #0: card=3 -> Pinnacle PCTV USB 2 [ 1737.162181] em28xx #0: card=4 -> Hauppauge WinTV USB 2 [ 1737.162183] em28xx #0: card=5 -> MSI VOX USB 2.0 [ 1737.162185] em28xx #0: card=6 -> Terratec Cinergy 200 USB [ 1737.162187] em28xx #0: card=7 -> Leadtek Winfast USB II [ 1737.162189] em28xx #0: card=8 -> Kworld USB2800 [ 1737.162192] em28xx #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker [ 1737.162194] em28xx #0: card=10 -> Hauppauge WinTV HVR 900 [ 1737.162197] em28xx #0: card=11 -> Terratec Hybrid XS [ 1737.162199] em28xx #0: card=12 -> Kworld PVR TV 2800 RF [ 1737.162201] em28xx #0: card=13 -> Terratec Prodigy XS [ 1737.162203] em28xx #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 1737.162206] em28xx #0: card=15 -> V-Gear PocketTV [ 1737.162208] em28xx #0: card=16 -> Hauppauge WinTV HVR 950 [ 1737.162210] em28xx #0: card=17 -> Pinnacle PCTV HD Pro Stick [ 1737.162212] em28xx #0: card=18 -> Hauppauge WinTV HVR 900 (R2) [ 1737.162215] em28xx #0: card=19 -> EM2860/SAA711X Reference Design [ 1737.162217] em28xx #0: card=20 -> AMD ATI TV Wonder HD 600 [ 1737.162219] em28xx #0: card=21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder [ 1737.16] em28xx #0: card=22 -> EM2710/EM2750/EM2751 webcam grabber [ 1737.162224] em28xx #0: card=23 -> Huaqi DLCW-130 [ 1737.162226] em28xx #0: card=24 -> D-Link DUB-T210 TV Tuner [ 1737.162229] em28xx #0: card=25 -> Gadmei UTV310 [ 1737.162231] em28xx #0: card=26 -> Hercules Smart TV USB 2.0 [ 1737.162233] em28xx #0: card=27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) [ 1737.162235] em28xx #0: card=28 -> Leadtek Winfast USB II Deluxe [ 1737.162238] em28xx #0: card=29 -> [ 1737.162240] em28xx #0: card=30 -> Videology 20K14XUSB USB2.0 [ 1737.162242] em28xx #0: card=31 -> Usbgear VD204v9 [ 1737.162244] em28xx #0: card=32 -> Supercomp USB 2.0 TV [ 1737.162246] em28xx #0: card=33 -> [ 1737.162248] em28xx #0: card=34 -> Terratec Cinergy A Hybrid XS [ 1737.162250] em28xx #0: card=35 -> Typhoon DVD Mak
Re: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Mauro Carvalho Chehab wrote: > Em 10-08-2011 15:33, Theodore Kilgore escreveu: > > > Hans seems to have argued cogently for doing all of this in the kernel and > > for abandoning the usbfs-based drivers for these particular drivers for > > dual-mode cameras and, I would conjecture, for drivers for dual-mode > > hardware in general. Therefore, I anticipate that he won't like that very > > much. > > > > My position: > > > > I do not have preconceptions about how the problem gets handled, and at > > this point I remain agnostic and believe that all approaches ought to be > > carefully analysed. I can imagine, abstractly, that things like this > > could be handled by > > > > -- moving all basic functionality to the kernel, and fixing the > > relevant libgphoto2 drivers to look to the kernel instead of to libusb. > > (What Hans argues for, and I am not opposed if his arguments convince > > other concerned parties) > > Not looking on the amount of work to be done, I think that this would > give better results, IMO. Okay. I would guess that I am one of the guys who gets to do the work, though. > > > -- doing some kind of patch job to make current arrangement somehow to > > work better (this seems to be the position of Adam Baker; I do share > > the skepticism Hans has expressed about how well this could all be > > pasted together) > > Adam Baker's proposal of a locking between usbfs and the kernel driver seems > to be interesting, but, as he pointed, there are some side effects to > consider, > like suspend/resume, PM, etc. > > > -- doing something like the previous, but also figuring out how to bring > > udev rules into play, which would make it all work better (just tossing > > this one in, for laughs, but who knows someone might like it) > > I don't think this is a good alternative. I was trying to mention all alternatives. I should have also mentioned "leave things the way they are" but that is certainly out the window. > > > -- moving the kernel webcam drivers out of the kernel and doing with these > > cameras _everything_ including webcam function through libusb. I myself do > > not have the imagination to be able to figure out how this could be done > > without a rather humongous amount of work (for example, which streaming > > apps that are currently available would be able to live with this?) but > > unless I misunderstand what he was saying, Greg K-H seems to think that > > this would be the best thing to do. > > I also don't think that this a good alternative. As Hans V. pointed, one of > our long term targets is to create per-sensor I2C drivers that are independent > from the bridges. Also, moving it to userspace would require lots of work > with the duplication of V4L and gspca core into userspace for the devices > that would be moved, and may have some performance impacts. A good argument, though it probably does not affect the devices on my list one way or the other. > > > Which one of these possibile approaches gets adopted is a policy issue > > which I would consider is ultimately way above my pay grade. > > > > My main motivation for bringing up the issue was to get it to the front > > burner so that _something_ gets done. It is a matter which has been left > > alone for too long. Therefore, I am very glad that the matter is being > > addressed. > > > > Let me add to this that I have gotten permission for time off and for a > > expense money which might possibly cover my air fare. I hope to arrive in > > Vancouver by sometime on Monday and intend to attend the mini-summit. I > > suggest that we get all intersted parties together and figure out what is > > the best way to go. > > > > I hope everyone who is actively concerned can meet in Vancouver, and if > > all goes well then on Monday as well as Tuesday. I can hang around for > > another day or two after Tuesday, but I do not expect to register for > > LinuxCon or be involved in it. > > It will be great to have you there for those discussions. My take on this was that it seems to have become important for me to attend, which, frankly, I was not expecting. So thanks for the nice words. > > > When I leave Vancouver I will probably go > > to Seattle and spend a couple of days with my oldest son, the musician, > > before coming home on the next weekend. > > > > Theodore Kilgore > -- 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: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Greg KH wrote: > On Wed, Aug 10, 2011 at 01:33:25PM -0500, Theodore Kilgore wrote: > > -- moving the kernel webcam drivers out of the kernel and doing with these > > cameras _everything_ including webcam function through libusb. I myself do > > not have the imagination to be able to figure out how this could be done > > without a rather humongous amount of work (for example, which streaming > > apps that are currently available would be able to live with this?) but > > unless I misunderstand what he was saying, Greg K-H seems to think that > > this would be the best thing to do. > > No, I never said that. Or if I accidentally did, I do not think that is > the best thing to do at all, sorry for any confusion. OK. > > Which one of these possibile approaches gets adopted is a policy issue > > which I would consider is ultimately way above my pay grade. > > As no one is being paid here, there are no "pay grades", so don't worry > about that :) I meant this, of course, in a metaphorical sense. Cheers, Theodore Kilgore -- 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: USB mini-summit at LinuxCon Vancouver
Em 10-08-2011 15:33, Theodore Kilgore escreveu: > Hans seems to have argued cogently for doing all of this in the kernel and > for abandoning the usbfs-based drivers for these particular drivers for > dual-mode cameras and, I would conjecture, for drivers for dual-mode > hardware in general. Therefore, I anticipate that he won't like that very > much. > > My position: > > I do not have preconceptions about how the problem gets handled, and at > this point I remain agnostic and believe that all approaches ought to be > carefully analysed. I can imagine, abstractly, that things like this > could be handled by > > -- moving all basic functionality to the kernel, and fixing the > relevant libgphoto2 drivers to look to the kernel instead of to libusb. > (What Hans argues for, and I am not opposed if his arguments convince > other concerned parties) Not looking on the amount of work to be done, I think that this would give better results, IMO. > -- doing some kind of patch job to make current arrangement somehow to > work better (this seems to be the position of Adam Baker; I do share > the skepticism Hans has expressed about how well this could all be > pasted together) Adam Baker's proposal of a locking between usbfs and the kernel driver seems to be interesting, but, as he pointed, there are some side effects to consider, like suspend/resume, PM, etc. > -- doing something like the previous, but also figuring out how to bring > udev rules into play, which would make it all work better (just tossing > this one in, for laughs, but who knows someone might like it) I don't think this is a good alternative. > -- moving the kernel webcam drivers out of the kernel and doing with these > cameras _everything_ including webcam function through libusb. I myself do > not have the imagination to be able to figure out how this could be done > without a rather humongous amount of work (for example, which streaming > apps that are currently available would be able to live with this?) but > unless I misunderstand what he was saying, Greg K-H seems to think that > this would be the best thing to do. I also don't think that this a good alternative. As Hans V. pointed, one of our long term targets is to create per-sensor I2C drivers that are independent from the bridges. Also, moving it to userspace would require lots of work with the duplication of V4L and gspca core into userspace for the devices that would be moved, and may have some performance impacts. > Which one of these possibile approaches gets adopted is a policy issue > which I would consider is ultimately way above my pay grade. > > My main motivation for bringing up the issue was to get it to the front > burner so that _something_ gets done. It is a matter which has been left > alone for too long. Therefore, I am very glad that the matter is being > addressed. > > Let me add to this that I have gotten permission for time off and for a > expense money which might possibly cover my air fare. I hope to arrive in > Vancouver by sometime on Monday and intend to attend the mini-summit. I > suggest that we get all intersted parties together and figure out what is > the best way to go. > > I hope everyone who is actively concerned can meet in Vancouver, and if > all goes well then on Monday as well as Tuesday. I can hang around for > another day or two after Tuesday, but I do not expect to register for > LinuxCon or be involved in it. It will be great to have you there for those discussions. > When I leave Vancouver I will probably go > to Seattle and spend a couple of days with my oldest son, the musician, > before coming home on the next weekend. > > Theodore Kilgore -- 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: [cron job] v4l-dvb daily build: ERRORS
On Wednesday, August 10, 2011 21:27:35 Hans Verkuil wrote: > 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:Wed Aug 10 19:00:41 CEST 2011 > git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e > gcc version: i686-linux-gcc (GCC) 4.6.1 > host hardware:x86_64 > host os: 2.6.32.5 I've upgraded the cross linker/compiler used for these builds to binutils-2.21.1 and gcc-4.6.1. As a result there are now many warnings like this: v4l-dvb-git/drivers/media/radio/radio-si4713.c: In function 'radio_si4713_querycap': v4l-dvb-git/drivers/media/radio/radio-si4713.c:95:30: warning: variable 'rsdev' set but not used [-Wunused-but-set-variable] v4l-dvb-git/drivers/media/radio/si470x/radio-si470x-usb.c: In function 'si470x_int_in_callback': v4l-dvb-git/drivers/media/radio/si470x/radio-si470x-usb.c:398:16: warning: variable 'buf' set but not used [-Wunused-but-set-variable] v4l-dvb-git/drivers/media/common/tuners/mt20xx.c: In function 'mt2050_set_antenna': v4l-dvb-git/drivers/media/common/tuners/mt20xx.c:433:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] v4l-dvb-git/drivers/media/common/tuners/mt20xx.c: In function 'mt2050_init': v4l-dvb-git/drivers/media/common/tuners/mt20xx.c:577:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] Any volunteers to clean up these warnings? The compile builds for older kernels also show these warnings for internal kernel headers for any kernel < 2.6.35. I'll see if I can fix those myself. Regards, Hans > > 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: OK > linux-git-mips: WARNINGS > linux-git-powerpc64: WARNINGS > linux-git-x86_64: WARNINGS > linux-2.6.31.12-i686: WARNINGS > linux-2.6.32.6-i686: WARNINGS > linux-2.6.33-i686: WARNINGS > linux-2.6.34-i686: WARNINGS > linux-2.6.35.3-i686: WARNINGS > linux-2.6.36-i686: WARNINGS > linux-2.6.37-i686: WARNINGS > linux-2.6.38.2-i686: WARNINGS > linux-2.6.39.1-i686: WARNINGS > linux-3.0-i686: WARNINGS > linux-3.1-rc1-i686: WARNINGS > linux-2.6.31.12-x86_64: WARNINGS > linux-2.6.32.6-x86_64: WARNINGS > linux-2.6.33-x86_64: WARNINGS > linux-2.6.34-x86_64: WARNINGS > linux-2.6.35.3-x86_64: WARNINGS > linux-2.6.36-x86_64: WARNINGS > linux-2.6.37-x86_64: WARNINGS > linux-2.6.38.2-x86_64: WARNINGS > linux-2.6.39.1-x86_64: WARNINGS > linux-3.0-x86_64: WARNINGS > linux-3.1-rc1-x86_64: WARNINGS > spec-git: ERRORS > sparse: ERRORS > > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Wednesday.log > > Full logs are available here: > > http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 > > -- 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: USB mini-summit at LinuxCon Vancouver
On Wed, Aug 10, 2011 at 01:33:25PM -0500, Theodore Kilgore wrote: > -- moving the kernel webcam drivers out of the kernel and doing with these > cameras _everything_ including webcam function through libusb. I myself do > not have the imagination to be able to figure out how this could be done > without a rather humongous amount of work (for example, which streaming > apps that are currently available would be able to live with this?) but > unless I misunderstand what he was saying, Greg K-H seems to think that > this would be the best thing to do. No, I never said that. Or if I accidentally did, I do not think that is the best thing to do at all, sorry for any confusion. > Which one of these possibile approaches gets adopted is a policy issue > which I would consider is ultimately way above my pay grade. As no one is being paid here, there are no "pay grades", so don't worry about that :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Wednesday, August 10, 2011 20:33:25 Theodore Kilgore wrote: > > On Wed, 10 Aug 2011, Alan Stern wrote: > > > On Wed, 10 Aug 2011, Theodore Kilgore wrote: > > > > > > Okay, I didn't realize that the different cameras used different webcam > > > > drivers as well as different stillcam drivers. > > > > > > Oh, yes. They are Proprietary devices. And that means what it says. :-) > > > And all different from each other, too. > > > > > > > As far as I can see, there's nothing to stop anybody from adding the > > > > stillcam functionality into the webcam drivers right now. If some > > > > common code can be abstracted out into a shared source file, so much > > > > the better. > > > > > > > > That would solve the problem, right? > > > > > > I think everyone involved believes that it would solve the problem. > > > > > > The question has been all along whether or not there is any other way > > > which would work. Also the question of what, exactly, "belongs" in the > > > kernel and what does not. For, if something has been historically > > > supported in userspace (stillcam support, in this case) and has worked > > > well there, I would think it is kind of too bad to have to move said > > > support into the kernel just because the same hardware requires kernel > > > support for another functionality and the two sides clash. I mean, the > > > kernel is already big enough, no? But the logic that Hans has set forth > > > seems rather compelling. > > > > The alternative seems to be to define a device-sharing protocol for USB > > drivers. Kernel drivers would implement a new callback (asking them to > > give up control of the device), and usbfs would implement new ioctls by > > which a program could ask for and relinquish control of a device. The > > amount of rewriting needed would be relatively small. > > > > A few loose ends would remain, such as how to handle suspends, resumes, > > resets, and disconnects. Assuming usbfs is the only driver that will > > want to share a device in this way, we could handle them. > > > > Hans, what do you think? > > > > Alan Stern > > Alan, > > Hans seems to have argued cogently for doing all of this in the kernel and > for abandoning the usbfs-based drivers for these particular drivers for > dual-mode cameras and, I would conjecture, for drivers for dual-mode > hardware in general. Therefore, I anticipate that he won't like that very > much. > > My position: > > I do not have preconceptions about how the problem gets handled, and at > this point I remain agnostic and believe that all approaches ought to be > carefully analysed. I can imagine, abstractly, that things like this > could be handled by > > -- moving all basic functionality to the kernel, and fixing the > relevant libgphoto2 drivers to look to the kernel instead of to libusb. > (What Hans argues for, and I am not opposed if his arguments convince > other concerned parties) > > -- doing some kind of patch job to make current arrangement somehow to > work better (this seems to be the position of Adam Baker; I do share > the skepticism Hans has expressed about how well this could all be > pasted together) > > -- doing something like the previous, but also figuring out how to bring > udev rules into play, which would make it all work better (just tossing > this one in, for laughs, but who knows someone might like it) > > -- moving the kernel webcam drivers out of the kernel and doing with these > cameras _everything_ including webcam function through libusb. I myself do > not have the imagination to be able to figure out how this could be done > without a rather humongous amount of work (for example, which streaming > apps that are currently available would be able to live with this?) but > unless I misunderstand what he was saying, Greg K-H seems to think that > this would be the best thing to do. Webcam drivers can rely on i2c sensor drivers to handle the sensor. These sensor drivers can be used in other non-USB devices as well (particularly embedded SoC devices). Moving webcam drivers out of the kernel would likely mean that you end up with duplicate kernel and userspace sensor drivers. Not a good idea. In all fairness I have to say that most webcam drivers program the sensor directly instead of relying on an i2c driver. Often because they were reverse engineered. But I know of several that should really be split into a webcam driver and a separate i2c sensor driver. Video hardware tends to rely heavily on i2c devices hooked up to them. The big advantage of keeping everything in the kernel is that that makes i2c driver sharing between USB, PCI, SoC, etc. much easier. Video hardware also often has to toggle between different modes or functionalities (e.g. analog TV vs DVB, MPEG encoded video vs raw). Having all components in the kernel makes this a much easier job. I think the approach favored by Hans de Goede is the right one based on what I've read. Whatever s
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Aug 10 19:00:41 CEST 2011 git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e gcc version: i686-linux-gcc (GCC) 4.6.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: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Alan Stern wrote: > On Wed, 10 Aug 2011, Theodore Kilgore wrote: > > > > Okay, I didn't realize that the different cameras used different webcam > > > drivers as well as different stillcam drivers. > > > > Oh, yes. They are Proprietary devices. And that means what it says. :-) > > And all different from each other, too. > > > > > As far as I can see, there's nothing to stop anybody from adding the > > > stillcam functionality into the webcam drivers right now. If some > > > common code can be abstracted out into a shared source file, so much > > > the better. > > > > > > That would solve the problem, right? > > > > I think everyone involved believes that it would solve the problem. > > > > The question has been all along whether or not there is any other way > > which would work. Also the question of what, exactly, "belongs" in the > > kernel and what does not. For, if something has been historically > > supported in userspace (stillcam support, in this case) and has worked > > well there, I would think it is kind of too bad to have to move said > > support into the kernel just because the same hardware requires kernel > > support for another functionality and the two sides clash. I mean, the > > kernel is already big enough, no? But the logic that Hans has set forth > > seems rather compelling. > > The alternative seems to be to define a device-sharing protocol for USB > drivers. Kernel drivers would implement a new callback (asking them to > give up control of the device), and usbfs would implement new ioctls by > which a program could ask for and relinquish control of a device. The > amount of rewriting needed would be relatively small. > > A few loose ends would remain, such as how to handle suspends, resumes, > resets, and disconnects. Assuming usbfs is the only driver that will > want to share a device in this way, we could handle them. > > Hans, what do you think? > > Alan Stern Alan, Hans seems to have argued cogently for doing all of this in the kernel and for abandoning the usbfs-based drivers for these particular drivers for dual-mode cameras and, I would conjecture, for drivers for dual-mode hardware in general. Therefore, I anticipate that he won't like that very much. My position: I do not have preconceptions about how the problem gets handled, and at this point I remain agnostic and believe that all approaches ought to be carefully analysed. I can imagine, abstractly, that things like this could be handled by -- moving all basic functionality to the kernel, and fixing the relevant libgphoto2 drivers to look to the kernel instead of to libusb. (What Hans argues for, and I am not opposed if his arguments convince other concerned parties) -- doing some kind of patch job to make current arrangement somehow to work better (this seems to be the position of Adam Baker; I do share the skepticism Hans has expressed about how well this could all be pasted together) -- doing something like the previous, but also figuring out how to bring udev rules into play, which would make it all work better (just tossing this one in, for laughs, but who knows someone might like it) -- moving the kernel webcam drivers out of the kernel and doing with these cameras _everything_ including webcam function through libusb. I myself do not have the imagination to be able to figure out how this could be done without a rather humongous amount of work (for example, which streaming apps that are currently available would be able to live with this?) but unless I misunderstand what he was saying, Greg K-H seems to think that this would be the best thing to do. Which one of these possibile approaches gets adopted is a policy issue which I would consider is ultimately way above my pay grade. My main motivation for bringing up the issue was to get it to the front burner so that _something_ gets done. It is a matter which has been left alone for too long. Therefore, I am very glad that the matter is being addressed. Let me add to this that I have gotten permission for time off and for a expense money which might possibly cover my air fare. I hope to arrive in Vancouver by sometime on Monday and intend to attend the mini-summit. I suggest that we get all intersted parties together and figure out what is the best way to go. I hope everyone who is actively concerned can meet in Vancouver, and if all goes well then on Monday as well as Tuesday. I can hang around for another day or two after Tuesday, but I do not expect to register for LinuxCon or be involved in it. When I leave Vancouver I will probably go to Seattle and spend a couple of days with my oldest son, the musician, before coming home on the next weekend. Theodore Kilgore -- 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: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Theodore Kilgore wrote: > > Okay, I didn't realize that the different cameras used different webcam > > drivers as well as different stillcam drivers. > > Oh, yes. They are Proprietary devices. And that means what it says. :-) > And all different from each other, too. > > > As far as I can see, there's nothing to stop anybody from adding the > > stillcam functionality into the webcam drivers right now. If some > > common code can be abstracted out into a shared source file, so much > > the better. > > > > That would solve the problem, right? > > I think everyone involved believes that it would solve the problem. > > The question has been all along whether or not there is any other way > which would work. Also the question of what, exactly, "belongs" in the > kernel and what does not. For, if something has been historically > supported in userspace (stillcam support, in this case) and has worked > well there, I would think it is kind of too bad to have to move said > support into the kernel just because the same hardware requires kernel > support for another functionality and the two sides clash. I mean, the > kernel is already big enough, no? But the logic that Hans has set forth > seems rather compelling. The alternative seems to be to define a device-sharing protocol for USB drivers. Kernel drivers would implement a new callback (asking them to give up control of the device), and usbfs would implement new ioctls by which a program could ask for and relinquish control of a device. The amount of rewriting needed would be relatively small. A few loose ends would remain, such as how to handle suspends, resumes, resets, and disconnects. Assuming usbfs is the only driver that will want to share a device in this way, we could handle them. Hans, what do you think? Alan Stern -- 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: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Alan Stern wrote: > On Tue, 9 Aug 2011, Hans de Goede wrote: > > > Hi, > > > > On 08/09/2011 04:19 PM, Alan Stern wrote: > > > On Tue, 9 Aug 2011, Hans de Goede wrote: > > > According to Theodore, we have developed 5 drivers for them because the > > > stillcam modes in different devices use four different vendor-specific > > > drivers. > > > > Yes, but so the the webcam modes of the different devices, so for > > the 5 (not sure if that is the right number) dual-cam mode chipsets > > we support there will be 5 drivers, each supporting both the > > webcam and the access to pictures stored in memory of the chipset > > they support. So 5 chipsets -> 5 drivers each supporting 1 chipset, > > and both functions of the single logical device that chipset > > represents. > > > > > Does it really make sense to combine 5 drivers into one? > > > > Right, that is not the plan. The plan is to simply stop having 2 drivers > > for 1 logical (and physical) block. So we go from 10 drivers, 5 stillcam > > + 5 webcam, to just 5 drivers. We will also likely be able to share > > code between the code for the 2 functionalities for things like generic > > set / get register functions, initialization, etc. > > Okay, I didn't realize that the different cameras used different webcam > drivers as well as different stillcam drivers. Oh, yes. They are Proprietary devices. And that means what it says. :-) And all different from each other, too. > As far as I can see, there's nothing to stop anybody from adding the > stillcam functionality into the webcam drivers right now. If some > common code can be abstracted out into a shared source file, so much > the better. > > That would solve the problem, right? I think everyone involved believes that it would solve the problem. The question has been all along whether or not there is any other way which would work. Also the question of what, exactly, "belongs" in the kernel and what does not. For, if something has been historically supported in userspace (stillcam support, in this case) and has worked well there, I would think it is kind of too bad to have to move said support into the kernel just because the same hardware requires kernel support for another functionality and the two sides clash. I mean, the kernel is already big enough, no? But the logic that Hans has set forth seems rather compelling. Theodore Kilgore -- 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: USB mini-summit at LinuxCon Vancouver
On Tue, 9 Aug 2011, Hans de Goede wrote: > Hi, > > On 08/09/2011 04:19 PM, Alan Stern wrote: > > On Tue, 9 Aug 2011, Hans de Goede wrote: > > According to Theodore, we have developed 5 drivers for them because the > > stillcam modes in different devices use four different vendor-specific > > drivers. > > Yes, but so the the webcam modes of the different devices, so for > the 5 (not sure if that is the right number) dual-cam mode chipsets > we support there will be 5 drivers, each supporting both the > webcam and the access to pictures stored in memory of the chipset > they support. So 5 chipsets -> 5 drivers each supporting 1 chipset, > and both functions of the single logical device that chipset > represents. > > > Does it really make sense to combine 5 drivers into one? > > Right, that is not the plan. The plan is to simply stop having 2 drivers > for 1 logical (and physical) block. So we go from 10 drivers, 5 stillcam > + 5 webcam, to just 5 drivers. We will also likely be able to share > code between the code for the 2 functionalities for things like generic > set / get register functions, initialization, etc. Okay, I didn't realize that the different cameras used different webcam drivers as well as different stillcam drivers. As far as I can see, there's nothing to stop anybody from adding the stillcam functionality into the webcam drivers right now. If some common code can be abstracted out into a shared source file, so much the better. That would solve the problem, right? Alan Stern -- 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/2] omap3: ISP: Kernel crash when attempting suspend
From: Abhilash K V
This patch fixes the kernel crash introduced by the previous
patch:
omap3: ISP: Fix the failure of CCDC capture during
suspend/resume.
This null pointer exception happens when attempting suspend
while the ISP driver is not being used. The current patch
fixes this by deferring the code (as introduced in the
aforementioned patch) to handle buffer-starvation to get
called only if the ISP reference count is non-zero.
An additional safety check is also added to ensure that
buffer-starvation logic kicks in for an empty dmaqueue only
if the ISP pipeline is not in the stopped state.
Signed-off-by: Abhilash K V
Signed-off-by: Deepthy Ravi
---
drivers/media/video/omap3isp/isp.c | 12 ++--
drivers/media/video/omap3isp/ispvideo.c |4 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 6604fbd..6acdedc 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1573,6 +1573,9 @@ static int isp_pm_prepare(struct device *dev)
unsigned long flags;
WARN_ON(mutex_is_locked(&isp->isp_mutex));
+ if (isp->ref_count == 0)
+ return 0;
+
spin_lock_irqsave(&pipe->lock, flags);
pipe->state |= ISP_PIPELINE_PREPARE_SUSPEND;
spin_unlock_irqrestore(&pipe->lock, flags);
@@ -1581,9 +1584,6 @@ static int isp_pm_prepare(struct device *dev)
if (err < 0)
return err;
- if (isp->ref_count == 0)
- return 0;
-
reset = isp_suspend_modules(isp);
isp_disable_interrupts(isp);
isp_save_ctx(isp);
@@ -1613,13 +1613,13 @@ static int isp_pm_resume(struct device *dev)
struct isp_pipeline *pipe = to_isp_pipeline(&video->video.entity);
unsigned long flags;
+ if (isp->ref_count == 0)
+ return 0;
+
spin_lock_irqsave(&pipe->lock, flags);
pipe->state &= ~ISP_PIPELINE_PREPARE_SUSPEND;
spin_unlock_irqrestore(&pipe->lock, flags);
- if (isp->ref_count == 0)
- return 0;
-
return isp_enable_clocks(isp);
}
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index bf149a7..ffb339c 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -726,8 +726,10 @@ int isp_video_handle_buffer_starvation(struct isp_video
*video)
struct isp_video_queue *queue = video->queue;
struct isp_video_buffer *buf;
struct list_head *head = &video->dmaqueue;
+ struct isp_ccdc_device *ccdc = &video->isp->isp_ccdc;
- if (list_empty(&video->dmaqueue)) {
+ if (list_empty(&video->dmaqueue)
+ && ccdc->state != ISP_PIPELINE_STREAM_STOPPED) {
err = isp_video_deq_enq(queue);
} else if (head->next->next == head) {
/* only one buffer is left on dmaqueue */
--
1.7.0.4
--
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/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
From: Abhilash K V
While resuming from the "suspended to memory" state,
occasionally CCDC fails to get enabled and thus fails
to capture frames any more till the next suspend/resume
is issued.
This is a race condition which happens only when a CCDC
frame-completion ISR is pending even as ISP device's
isp_pm_prepare() is getting called and only one buffer
is left on the DMA queue.
The DMA queue buffers are thus depleted which results in
its underrun.So when ISP resumes there are no buffers on
the queue (as the application which can issue buffers is
yet to resume) to start video capture.
This fix addresses this issue by dequeuing and enqueing
the last buffer in isp_pm_prepare() after its DMA gets
completed. Thus,when ISP resumes it always finds atleast
one buffer on the DMA queue - this is true if application
uses only 3 buffers.
Reviewed-by: Vaibhav Hiremath
Signed-off-by: Abhilash K V
Signed-off-by: Deepthy Ravi
---
drivers/media/video/omap3isp/isp.c | 20 +++
drivers/media/video/omap3isp/isp.h |4 ++
drivers/media/video/omap3isp/ispvideo.c | 56 ++-
drivers/media/video/omap3isp/ispvideo.h |2 +
4 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 94b6ed8..6604fbd 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1566,8 +1566,20 @@ static int isp_pm_prepare(struct device *dev)
{
struct isp_device *isp = dev_get_drvdata(dev);
int reset;
+ int err = 0;
+ struct isp_ccdc_device *ccdc = &isp->isp_ccdc;
+ struct isp_video *video = &ccdc->video_out;
+ struct isp_pipeline *pipe = to_isp_pipeline(&video->video.entity);
+ unsigned long flags;
WARN_ON(mutex_is_locked(&isp->isp_mutex));
+ spin_lock_irqsave(&pipe->lock, flags);
+ pipe->state |= ISP_PIPELINE_PREPARE_SUSPEND;
+ spin_unlock_irqrestore(&pipe->lock, flags);
+
+ err = isp_video_handle_buffer_starvation(video);
+ if (err < 0)
+ return err;
if (isp->ref_count == 0)
return 0;
@@ -1596,6 +1608,14 @@ static int isp_pm_suspend(struct device *dev)
static int isp_pm_resume(struct device *dev)
{
struct isp_device *isp = dev_get_drvdata(dev);
+ struct isp_ccdc_device *ccdc = &isp->isp_ccdc;
+ struct isp_video *video = &ccdc->video_out;
+ struct isp_pipeline *pipe = to_isp_pipeline(&video->video.entity);
+ unsigned long flags;
+
+ spin_lock_irqsave(&pipe->lock, flags);
+ pipe->state &= ~ISP_PIPELINE_PREPARE_SUSPEND;
+ spin_unlock_irqrestore(&pipe->lock, flags);
if (isp->ref_count == 0)
return 0;
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 841870f..e391974 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -349,6 +349,10 @@ int omap3isp_register_entities(struct platform_device
*pdev,
struct v4l2_device *v4l2_dev);
void omap3isp_unregister_entities(struct platform_device *pdev);
+#ifdef CONFIG_PM
+int isp_video_handle_buffer_starvation(struct isp_video *video);
+#endif
+
/*
* isp_reg_readl - Read value of an OMAP3 ISP register
* @dev: Device pointer specific to the OMAP3 ISP.
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index 5833a0e..bf149a7 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -523,6 +523,26 @@ static int isp_video_buffer_prepare(struct
isp_video_buffer *buf)
return 0;
}
+#ifdef CONFIG_PM
+static int isp_video_deq_enq(struct isp_video_queue *queue)
+{
+ int err = 0;
+ struct v4l2_buffer vbuf;
+
+ vbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ /* blocking dequeue to ensure DMA is done */
+ err = omap3isp_video_queue_dqbuf(queue, &vbuf, 0);
+ if (err < 0)
+ return err;
+ else {
+ err = omap3isp_video_queue_qbuf(queue, &vbuf);
+ if (err < 0)
+ return err;
+ }
+ return err;
+}
+#endif
+
/*
* isp_video_buffer_queue - Add buffer to streaming queue
* @buf: Video buffer
@@ -546,7 +566,7 @@ static void isp_video_buffer_queue(struct isp_video_buffer
*buf)
empty = list_empty(&video->dmaqueue);
list_add_tail(&buffer->buffer.irqlist, &video->dmaqueue);
- if (empty) {
+ if (empty && !(pipe->state & ISP_PIPELINE_PREPARE_SUSPEND)) {
if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
state = ISP_PIPELINE_QUEUE_OUTPUT;
else
@@ -687,6 +707,40 @@ void omap3isp_video_resume(struct isp_video *video, int
continuous)
}
}
+#ifdef CONFIG_PM
+
+/*
+ * isp_video_handle_buffer_starvation - Handles the case when there are only 1
+ * or les
[PATCH 0/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
This patchset fixes the occasional failure of CCDC capture during suspend/resume. Cc: Vaibhav Hiremath Cc: Abhilash K V --- Abhilash K V (2): omap3: ISP: Fix the failure of CCDC capture during suspend/resume omap3: ISP: Kernel crash when attempting suspend drivers/media/video/omap3isp/isp.c | 22 +++- drivers/media/video/omap3isp/isp.h |4 ++ drivers/media/video/omap3isp/ispvideo.c | 58 ++- drivers/media/video/omap3isp/ispvideo.h |2 + 4 files changed, 84 insertions(+), 2 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: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Em 10-08-2011 05:41, Sylwester Nawrocki escreveu: Why not? I never saw an embedded hardware that allows physically changing the sensor. > > I understood Laurent's statement that you can have same ISP driver deployed on > multiple boards fitted with various sensors. Hence the multiple configurations > that cannot be known in advance, True, but such kind of dependence should solved either at config time or at probe time. It doesn't make any sense to show that a hardware is present, when it is not. This applies to both V4L or MC APIs (and also to sysfs). If V4L2 API is not enough, implementing it on libv4l won't solve, as userspace apps will use V4L2 API for requresting it. >>> >>> There are two kind of applications: specialised and generic. The generic >>> ones may rely on restrictive policies put in place by a libv4l plugin >>> whereas the specialised applications need to access the device's features >>> directly to get the most out of it. >> >> A submitted upstream driver should be capable of working with the existing >> tools/userspace. >> >> Currently, there isn't such libv4l plugins (or, at least, I failed to see a >> merged plugin there for N9, S5P, etc). Let's not upstream new drivers or >> remove >> functionalities from already existing drivers based on something that has >> yet >> to be developed. >> >> After having it there properly working and tested independently, we may >> consider >> patches removing V4L2 interfaces that were obsoleted in favor of using the >> libv4l >> implementation, of course using the Kernel way of deprecating interfaces. But >> doing it before having it, doesn't make any sense. >> >> Let's not put the the cart before the horse. > > That's a good point. My long term plan was to deprecate and remove duplicated > ioctls > at the driver _once_ support for regular V4L2 interface on top of MC/subdev > API > is added at the v4l2 libraries. But this will happen after I create an > initial.. > *cough* openmax IL for the driver. Which is not what the Tigers like best.. Ok. > > -- > Regards, > Sylwester -- 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
adp1653 usage
Hello, Sakari. I would like to understand how to use subdevice (like adp1653) in current v4l2 framework from user space. My understanding is following. Kernel has two drivers (simplified view): - camera device - flash device Kernel initializes a camera driver from a platform specific setup code. The camera driver loads the subdevice drivers. Later I could access the subdevice driver parts via IOCTL(s) on /dev/videoX device node. What I have missed. - if the subdevice creates device node /dev/v4l-subdevX, how the user space will know the X is corresponding to let say flash device? - if there is no v4l-subdevX device node, when and how the kernel runs ->open() and ->close() methods of v4l2_subdev_internal_ops? -- Andy Shevchenko Intel Finland Oy -- 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: [ANN] Meeting minutes of the Cambourne meeting
nitesh moundekar wrote: > Hi Sakari, Hi Nitesh, > So without touching these controls, drivers should be able to work with > default or internal settings calculated from frame rate and resolution. And > when application like DSLR wants more control it can access those controls. The current interface is provided from V4L2 subdevs, so the application using that can be expected to know something of the system already. It may be up to drivers to decide what do they implement and what they do not. We'll have to see how generic the new way of configuring the sensors is; my hope is that practically all raw bayer sensors (not the SoC ones!) could be configured this way. Lack of information from manufacturer could limit the ability to write such drivers for sensors, though. With such a system, an user space algorithm library (a plugin for libv4l) will be needed in any case to come up with a fully functional system useful for generic applications, and it may well be that this interface will be used from the plugins. Alternatively the old interface could be implemented using a wrapper library for all drivers providing the new sensor configuration interface. There would be a list of default modes, some of which could be more board dependent than others. 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] [media] vp7045: fix buffer setup
dvb_usb_device_init calls the frontend_attach method of this driver which
uses vp7045_usb_ob. In order to have a buffer ready in vp7045_usb_op, it has to
be allocated before that happens.
Luckily we can use the whole private data as the buffer as it gets separately
allocated on the heap via kzalloc in dvb_usb_device_init and is thus apt for
use via usb_control_msg.
This fixes a
BUG: unable to handle kernel paging request at 1e78
reported by Tino Keitel and diagnosed by Dan Carpenter.
References: https://bugzilla.kernel.org/show_bug.cgi?id=40062
Cc: v3.0.y
Tested-by: Tino Keitel
Signed-off-by: Florian Mickler
---
drivers/media/dvb/dvb-usb/vp7045.c | 26 --
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp7045.c
b/drivers/media/dvb/dvb-usb/vp7045.c
index 3db89e3..536c16c 100644
--- a/drivers/media/dvb/dvb-usb/vp7045.c
+++ b/drivers/media/dvb/dvb-usb/vp7045.c
@@ -224,26 +224,8 @@ static struct dvb_usb_device_properties vp7045_properties;
static int vp7045_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
- struct dvb_usb_device *d;
- int ret = dvb_usb_device_init(intf, &vp7045_properties,
- THIS_MODULE, &d, adapter_nr);
- if (ret)
- return ret;
-
- d->priv = kmalloc(20, GFP_KERNEL);
- if (!d->priv) {
- dvb_usb_device_exit(intf);
- return -ENOMEM;
- }
-
- return ret;
-}
-
-static void vp7045_usb_disconnect(struct usb_interface *intf)
-{
- struct dvb_usb_device *d = usb_get_intfdata(intf);
- kfree(d->priv);
- dvb_usb_device_exit(intf);
+ return dvb_usb_device_init(intf, &vp7045_properties,
+ THIS_MODULE, NULL, adapter_nr);
}
static struct usb_device_id vp7045_usb_table [] = {
@@ -258,7 +240,7 @@ MODULE_DEVICE_TABLE(usb, vp7045_usb_table);
static struct dvb_usb_device_properties vp7045_properties = {
.usb_ctrl = CYPRESS_FX2,
.firmware = "dvb-usb-vp7045-01.fw",
- .size_of_priv = sizeof(u8 *),
+ .size_of_priv = 20,
.num_adapters = 1,
.adapter = {
@@ -305,7 +287,7 @@ static struct dvb_usb_device_properties vp7045_properties =
{
static struct usb_driver vp7045_usb_driver = {
.name = "dvb_usb_vp7045",
.probe = vp7045_usb_probe,
- .disconnect = vp7045_usb_disconnect,
+ .disconnect = dvb_usb_device_exit,
.id_table = vp7045_usb_table,
};
--
1.7.6
--
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] media: vb2: add a check if queued userptr buffer is large enough
On Wednesday, August 10, 2011 11:08:20 Marek Szyprowski wrote:
> Hello,
>
> On Wednesday, August 10, 2011 10:46 AM Hans Verkuil wrote:
>
> > Just one comment:
> >
> > On Wednesday, August 10, 2011 10:21:28 Marek Szyprowski wrote:
> > > Videobuf2 accepted any userptr buffer without verifying if its size is
> > > large enough to store the video data from the driver. The driver reports
> > > the minimal size of video data once in queue_setup and expects that
> > > videobuf2 provides buffers that match these requirements. This patch
> > > adds the required check.
> > >
> > > Reported-by: Laurent Pinchart
> > > Signed-off-by: Marek Szyprowski
> > > Signed-off-by: Kyungmin Park
> > > CC: Pawel Osciak
> > > ---
> > > drivers/media/video/videobuf2-core.c | 41
> > +++--
> > > include/media/videobuf2-core.h |1 +
> > > 2 files changed, 25 insertions(+), 17 deletions(-)
> > >
> >
> >
> >
> > > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-
core.h
> > > index f87472a..496d6e5 100644
> > > --- a/include/media/videobuf2-core.h
> > > +++ b/include/media/videobuf2-core.h
> > > @@ -276,6 +276,7 @@ struct vb2_queue {
> > > wait_queue_head_t done_wq;
> > >
> > > void*alloc_ctx[VIDEO_MAX_PLANES];
> > > + unsigned long plane_sizes[VIDEO_MAX_PLANES];
> >
> > Why unsigned long when it is a u32 in struct v4l2_plane_pix_format?
> >
> > unsigned long is 64 bit on a 64-bit OS, so that seems wasteful to me.
>
> u32 type should be used in places where the exact size really matters,
> like strictly defined io structures passed to userspace or structures that
> are used for accessing hardware registers directly. For all other cases,
> like temporary storage of some values, the cpu native types should be used.
> Looks at the whole vb2 code - u32 type is not used in any single place.
You can also change unsigned long to unsigned int as that is always 32 bits.
I don't mind one way or another.
Regards,
Hans
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
--
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: [ANN] Meeting minutes of the Cambourne meeting
On Tuesday, August 09, 2011 06:36:19 pm nitesh moundekar wrote: > I am worried about direction v4l2 is taking. It looks against the basic > principle of driver i.e. hardware abstraction. There definitely should be an API which is hardware independent. However, the problem is that the hardware is so flexible that an hardware independent API needs to be necessarily enforce policies and possibly do complex image processing which is against the kernel philosophy and belongs to userspace. As I see it, it is necessary to provide more or less HW-dependent API to kernel V4L2. What we need is an userspace library abstracting that to simple HW-independent API. I think that libv4l is a very good way to do that, since it still provides the V4L2 interface but can do things in userspace. - Tuukka - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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] MAINTAINERS: add entries for s5p-mfc and s5p-tv drivers
Both driver has been merged to v3.1-rc1, so add its authors as maintainers. Signed-off-by: Marek Szyprowski Signed-off-by: Kamil Debski Signed-off-by: Tomasz Stanislawski Signed-off-by: Kyungmin Park --- MAINTAINERS | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 51d42fb..0618d9a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1084,6 +1084,24 @@ F: arch/arm/plat-s5p/dev-fimc* F: arch/arm/plat-samsung/include/plat/*fimc* F: drivers/media/video/s5p-fimc/ +ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT +M: Kyungmin Park +M: Kamil Debski +L: linux-arm-ker...@lists.infradead.org +L: linux-media@vger.kernel.org +S: Maintained +F: arch/arm/plat-s5p/dev-mfc.c +F: drivers/media/video/s5p-mfc/ + +ARM/SAMSUNG S5P SERIES TV SUBSYSTEM SUPPORT +M: Kyungmin Park +M: Tomasz Stanislawski +L: linux-arm-ker...@lists.infradead.org +L: linux-media@vger.kernel.org +S: Maintained +F: arch/arm/plat-s5p/dev-tv.c +F: drivers/media/video/s5p-tv/ + ARM/SHMOBILE ARM ARCHITECTURE M: Paul Mundt M: Magnus Damm -- 1.7.1.569.g6f426 -- 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] media: vb2: add a check if queued userptr buffer is large enough
Hello,
On Wednesday, August 10, 2011 10:46 AM Hans Verkuil wrote:
> Just one comment:
>
> On Wednesday, August 10, 2011 10:21:28 Marek Szyprowski wrote:
> > Videobuf2 accepted any userptr buffer without verifying if its size is
> > large enough to store the video data from the driver. The driver reports
> > the minimal size of video data once in queue_setup and expects that
> > videobuf2 provides buffers that match these requirements. This patch
> > adds the required check.
> >
> > Reported-by: Laurent Pinchart
> > Signed-off-by: Marek Szyprowski
> > Signed-off-by: Kyungmin Park
> > CC: Pawel Osciak
> > ---
> > drivers/media/video/videobuf2-core.c | 41
> +++--
> > include/media/videobuf2-core.h |1 +
> > 2 files changed, 25 insertions(+), 17 deletions(-)
> >
>
>
>
> > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> > index f87472a..496d6e5 100644
> > --- a/include/media/videobuf2-core.h
> > +++ b/include/media/videobuf2-core.h
> > @@ -276,6 +276,7 @@ struct vb2_queue {
> > wait_queue_head_t done_wq;
> >
> > void*alloc_ctx[VIDEO_MAX_PLANES];
> > + unsigned long plane_sizes[VIDEO_MAX_PLANES];
>
> Why unsigned long when it is a u32 in struct v4l2_plane_pix_format?
>
> unsigned long is 64 bit on a 64-bit OS, so that seems wasteful to me.
u32 type should be used in places where the exact size really matters,
like strictly defined io structures passed to userspace or structures that
are used for accessing hardware registers directly. For all other cases,
like temporary storage of some values, the cpu native types should be used.
Looks at the whole vb2 code - u32 type is not used in any single place.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
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] media: vb2: add a check if queued userptr buffer is large enough
Just one comment:
On Wednesday, August 10, 2011 10:21:28 Marek Szyprowski wrote:
> Videobuf2 accepted any userptr buffer without verifying if its size is
> large enough to store the video data from the driver. The driver reports
> the minimal size of video data once in queue_setup and expects that
> videobuf2 provides buffers that match these requirements. This patch
> adds the required check.
>
> Reported-by: Laurent Pinchart
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> CC: Pawel Osciak
> ---
> drivers/media/video/videobuf2-core.c | 41
+++--
> include/media/videobuf2-core.h |1 +
> 2 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index f87472a..496d6e5 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -276,6 +276,7 @@ struct vb2_queue {
> wait_queue_head_t done_wq;
>
> void*alloc_ctx[VIDEO_MAX_PLANES];
> + unsigned long plane_sizes[VIDEO_MAX_PLANES];
Why unsigned long when it is a u32 in struct v4l2_plane_pix_format?
unsigned long is 64 bit on a 64-bit OS, so that seems wasteful to me.
Regards,
Hans
>
> unsigned intstreaming:1;
>
> --
> 1.7.1.569.g6f426
>
> --
> 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: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
On 08/10/2011 02:22 AM, Mauro Carvalho Chehab wrote: > Em 09-08-2011 20:18, Sakari Ailus escreveu: >> Hi Mauro, >> >> On Tue, Aug 09, 2011 at 05:05:47PM -0300, Mauro Carvalho Chehab wrote: >>> Em 29-07-2011 05:36, Laurent Pinchart escreveu: Hi Mauro, On Friday 29 July 2011 06:02:54 Mauro Carvalho Chehab wrote: > Em 28-07-2011 19:57, Sylwester Nawrocki escreveu: >> On 07/28/2011 03:20 PM, Mauro Carvalho Chehab wrote: >>> Accumulating sub-dev controls at the video node is the right thing to >>> do. >>> >>> An MC-aware application will need to handle with that, but that doesn't >>> sound to be hard. All such application would need to do is to first >>> probe the subdev controls, and, when parsing the videodev controls, not >>> register controls with duplicated ID's, or to mark them with some >>> special attribute. >> >> IMHO it's not a big issue in general. Still, both subdev and the host >> device may support same control id. And then even though the control ids >> are same on the subdev and the host they could mean physically different >> controls (since when registering a subdev at the host driver the host's >> controls take precedence and doubling subdev controls are skipped). > > True, but, except for specific usecases, the host control is enough. Not for embedded devices. In many case the control won't even be implemented by the host. If your system has two sensors connected to the same host, they will both expose an exposure time control. Which one do you configure through the video node ? The two sensors will likely have different bounds for the same control, how do you report that ? >>> >>> If the device has two sensors that are mutually exclusive, they should be >>> mapped as two different inputs. The showed control should be the one used >>> by the currently active input. >> >> Video nodes should represent a dma engine rather than an image source. > > True. Image sources are represented, on V4L2, by inputs. > >> You >> could use the same hardware to process data from memory to memory while >> streaming video from a sensor to memory at the same time. This is a quite >> typical use in embedded systems. >> >> Usually boards where two sensors are connected to an isp the dependencies >> are not as straightforward as the sensors being fully independent or require >> exclusive access. Typically some of the hardware blocks are shared between >> the two and can be used by only one sensor at a time, so instead you may not >> get full functionality from both at the same time. And you need to be able >> to choose which one uses that hardware block. This is exactly what Media >> controller interface models perfectly. > > I see. > >> See FIMC Media controller graph AND Sylwester's explanation on it; a few >> links are actually missing from the grapg. >> >> http://www.spinics.net/lists/linux-media/msg35504.html> >> http://wstaw.org/m/2011/05/26/fimc_graph__.png> >> >> Cc Hans. >> >>> If the sensors aren't mutually exclusive, then two different video nodes >>> will >>> be shown in userspace. >>> Those controls are also quite useless for generic V4L2 applications, which will want auto-exposure anyway. This needs to be implemented in userspace in libv4l. >>> >>> Several webcams export exposure controls. Why shouldn't those controls be >>> exposed >>> to userspace anymore? >> >> This is not a webcam, > > I know, but the analogy is still valid. > >> it is a software controlled high end digital camera on >> a mobile device. The difference is that the functionality offered by the >> hardware is at much lower level compared to a webcam; the result is that >> more detailed control ia required but also much flexibility and performance >> is gained. > > I see. What I failed to see is why to remove control from userspace. If the > hardware is more powerful, I expect to see more controls exported, and not > removing the V4L2 functionality from the driver. > >>> Ok, if the hardware won't support 3A algorithm, libv4l will implement it, >>> eventually using an extra hardware-aware code to get the best performance >>> for that specific device, but this doesn't mean that the user should always >>> use it. >> >> Why not? What would be the alternative? > > User may want or need to disable the 3A algo and control some hardware > parameters > hardware directly, for example, to take an over-exposed picture, to create > some > neat effects, or to get some image whose exposure aperture/time is out of the > 3A range. > >>> Btw, the 3A algorithm is one of the things I don't like on my cell phone: >>> while >>> it works most of the time, sometimes I want to disable it and manually >>> adjust, >>> as it produces dark images, when there's a very bright light somewhere on >>> the >>> image background. Manually adjusting the exposure time and aperture is >>> somethi
[PATCH] media: vb2: dma-sg allocator: change scatterlist allocation method
From: Andrzej Pietrasiewicz
Scatter-gather lib provides a helper functions to allocate scatter list,
so there is no need to use vmalloc for it. sg_alloc_table() splits
allocation into page size chunks and links them together into a chain.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
CC: Pawel Osciak
---
drivers/media/video/videobuf2-dma-sg.c | 54 +++
1 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-sg.c
b/drivers/media/video/videobuf2-dma-sg.c
index 065f468..e1158f9 100644
--- a/drivers/media/video/videobuf2-dma-sg.c
+++ b/drivers/media/video/videobuf2-dma-sg.c
@@ -36,6 +36,8 @@ static void vb2_dma_sg_put(void *buf_priv);
static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size)
{
struct vb2_dma_sg_buf *buf;
+ struct sg_table sgt;
+ struct scatterlist *sl;
int i;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
@@ -48,23 +50,21 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size)
buf->sg_desc.size = size;
buf->sg_desc.num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
- buf->sg_desc.sglist = vzalloc(buf->sg_desc.num_pages *
- sizeof(*buf->sg_desc.sglist));
- if (!buf->sg_desc.sglist)
+ if (sg_alloc_table(&sgt, buf->sg_desc.num_pages, GFP_KERNEL))
goto fail_sglist_alloc;
- sg_init_table(buf->sg_desc.sglist, buf->sg_desc.num_pages);
+ buf->sg_desc.sglist = sgt.sgl;
buf->pages = kzalloc(buf->sg_desc.num_pages * sizeof(struct page *),
GFP_KERNEL);
if (!buf->pages)
goto fail_pages_array_alloc;
- for (i = 0; i < buf->sg_desc.num_pages; ++i) {
- buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
__GFP_NOWARN);
+ for_each_sg(buf->sg_desc.sglist, sl, buf->sg_desc.num_pages, i) {
+ buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
+ __GFP_NOWARN);
if (NULL == buf->pages[i])
goto fail_pages_alloc;
- sg_set_page(&buf->sg_desc.sglist[i],
- buf->pages[i], PAGE_SIZE, 0);
+ sg_set_page(sl, buf->pages[i], PAGE_SIZE, 0);
}
buf->handler.refcount = &buf->refcount;
@@ -89,7 +89,7 @@ fail_pages_alloc:
kfree(buf->pages);
fail_pages_array_alloc:
- vfree(buf->sg_desc.sglist);
+ sg_free_table(&sgt);
fail_sglist_alloc:
kfree(buf);
@@ -99,6 +99,7 @@ fail_sglist_alloc:
static void vb2_dma_sg_put(void *buf_priv)
{
struct vb2_dma_sg_buf *buf = buf_priv;
+ struct sg_table sgt;
int i = buf->sg_desc.num_pages;
if (atomic_dec_and_test(&buf->refcount)) {
@@ -106,7 +107,9 @@ static void vb2_dma_sg_put(void *buf_priv)
buf->sg_desc.num_pages);
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->sg_desc.num_pages);
- vfree(buf->sg_desc.sglist);
+ sgt.sgl = buf->sg_desc.sglist;
+ sgt.orig_nents = sgt.nents = i;
+ sg_free_table(&sgt);
while (--i >= 0)
__free_page(buf->pages[i]);
kfree(buf->pages);
@@ -118,6 +121,8 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
unsigned long size, int write)
{
struct vb2_dma_sg_buf *buf;
+ struct sg_table sgt;
+ struct scatterlist *sl;
unsigned long first, last;
int num_pages_from_user, i;
@@ -134,12 +139,9 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
last = ((vaddr + size - 1) & PAGE_MASK) >> PAGE_SHIFT;
buf->sg_desc.num_pages = last - first + 1;
- buf->sg_desc.sglist = vzalloc(
- buf->sg_desc.num_pages * sizeof(*buf->sg_desc.sglist));
- if (!buf->sg_desc.sglist)
+ if (sg_alloc_table(&sgt, buf->sg_desc.num_pages, GFP_KERNEL))
goto userptr_fail_sglist_alloc;
-
- sg_init_table(buf->sg_desc.sglist, buf->sg_desc.num_pages);
+ buf->sg_desc.sglist = sgt.sgl;
buf->pages = kzalloc(buf->sg_desc.num_pages * sizeof(struct page *),
GFP_KERNEL);
@@ -158,12 +160,12 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
if (num_pages_from_user != buf->sg_desc.num_pages)
goto userptr_fail_get_user_pages;
- sg_set_page(&buf->sg_desc.sglist[0], buf->pages[0],
- PAGE_SIZE - buf->offset, buf->offset);
+ sl = buf->sg_desc.sglist;
+ sg_set_page(sl, buf->pages[0], PAGE_SIZE - buf->offset, buf->offset);
size -= PAGE_SIZE - buf->offset;
for (i = 1; i < buf->sg_desc.num_pages; ++i) {
- sg
[PATCH] media: vb2: add a check if queued userptr buffer is large enough
Videobuf2 accepted any userptr buffer without verifying if its size is
large enough to store the video data from the driver. The driver reports
the minimal size of video data once in queue_setup and expects that
videobuf2 provides buffers that match these requirements. This patch
adds the required check.
Reported-by: Laurent Pinchart
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
CC: Pawel Osciak
---
drivers/media/video/videobuf2-core.c | 41 +++--
include/media/videobuf2-core.h |1 +
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 3015e60..c360627 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -43,8 +43,7 @@ module_param(debug, int, 0644);
/**
* __vb2_buf_mem_alloc() - allocate video memory for the given buffer
*/
-static int __vb2_buf_mem_alloc(struct vb2_buffer *vb,
- unsigned long *plane_sizes)
+static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb->vb2_queue;
void *mem_priv;
@@ -53,13 +52,13 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb,
/* Allocate memory for all planes in this buffer */
for (plane = 0; plane < vb->num_planes; ++plane) {
mem_priv = call_memop(q, plane, alloc, q->alloc_ctx[plane],
- plane_sizes[plane]);
+ q->plane_sizes[plane]);
if (IS_ERR_OR_NULL(mem_priv))
goto free;
/* Associate allocator private data with this plane */
vb->planes[plane].mem_priv = mem_priv;
- vb->v4l2_planes[plane].length = plane_sizes[plane];
+ vb->v4l2_planes[plane].length = q->plane_sizes[plane];
}
return 0;
@@ -141,8 +140,7 @@ static void __setup_offsets(struct vb2_queue *q)
* Returns the number of buffers successfully allocated.
*/
static int __vb2_queue_alloc(struct vb2_queue *q, enum v4l2_memory memory,
-unsigned int num_buffers, unsigned int num_planes,
-unsigned long plane_sizes[])
+unsigned int num_buffers, unsigned int num_planes)
{
unsigned int buffer;
struct vb2_buffer *vb;
@@ -169,7 +167,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
v4l2_memory memory,
/* Allocate video buffer memory for the MMAP type */
if (memory == V4L2_MEMORY_MMAP) {
- ret = __vb2_buf_mem_alloc(vb, plane_sizes);
+ ret = __vb2_buf_mem_alloc(vb);
if (ret) {
dprintk(1, "Failed allocating memory for "
"buffer %d\n", buffer);
@@ -454,7 +452,6 @@ static bool __buffers_in_use(struct vb2_queue *q)
int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
{
unsigned int num_buffers, num_planes;
- unsigned long plane_sizes[VIDEO_MAX_PLANES];
int ret = 0;
if (q->fileio) {
@@ -516,7 +513,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
* Make sure the requested values and current defaults are sane.
*/
num_buffers = min_t(unsigned int, req->count, VIDEO_MAX_FRAME);
- memset(plane_sizes, 0, sizeof(plane_sizes));
+ memset(q->plane_sizes, 0, sizeof(q->plane_sizes));
memset(q->alloc_ctx, 0, sizeof(q->alloc_ctx));
q->memory = req->memory;
@@ -525,13 +522,12 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
* Driver also sets the size and allocator context for each plane.
*/
ret = call_qop(q, queue_setup, q, &num_buffers, &num_planes,
- plane_sizes, q->alloc_ctx);
+ q->plane_sizes, q->alloc_ctx);
if (ret)
return ret;
/* Finally, allocate buffers and video memory */
- ret = __vb2_queue_alloc(q, req->memory, num_buffers, num_planes,
- plane_sizes);
+ ret = __vb2_queue_alloc(q, req->memory, num_buffers, num_planes);
if (ret == 0) {
dprintk(1, "Memory allocation failed\n");
return -ENOMEM;
@@ -545,7 +541,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
orig_num_buffers = num_buffers = ret;
ret = call_qop(q, queue_setup, q, &num_buffers, &num_planes,
- plane_sizes, q->alloc_ctx);
+ q->plane_sizes, q->alloc_ctx);
if (ret)
goto free_mem;
@@ -745,12 +741,20 @@ static int __qbuf_userptr(struct vb2_buffer *vb, struct
v4l2_buffer *b)
dprintk(3
Re: [Workshop-2011] Media Subsystem Workshop 2011
Hi, On 08/10/2011 02:34 AM, Theodore Kilgore wrote: but this is the way how the current discussion feels to me. If we agree on aiming for "doing it right" then with that comes to me doing a software design from scratch, so without taking into account what is already there. Here, a counter-argument is to point out, as I did in a mail earlier this afternoon, that "without taking account what is already there" might possibly let one overlook something important. And, no, I am not referring to the userspace-kernelspace problem with this. I am referring to the fact that simply to dump the entire contents of the camera "into cache" (and to keep it there for quite a while) might not necessarily be a good idea and it had been quite consciously rejected to do that in the design of libgphoto2. Not because it is in userspace, but because to do that eats up and ties up RAM of which one cannot assume there is a surplus. This is an implementation detail which has little to do with the fundamental choice of whether or not we want 2 separate drivers or 1 single driver. In part of the snipped message you called me impatient (no offense taken), my perceived impatience is stemming from what to me feels like we are dancing around the real issue here. The fundamental question is do we want 2 separate drivers or 1 single driver for these devices. Lets answer that first, using all we've learned from the past. But without taking into account that one choice or the other will involve re-doing lots of code, as to me that is a poor argument from a technical pov. There are of course limits to the from scratch part, in the end we want this to slot into the existing Linux practices for webcams and stillcams, which means: 1) offering a v4l2 /dev/video# node for streaming; and 2) access to the pictures stored on the camera through libgphoto Taking these 2 constrictions into account, and combining that with my firm believe that the solution to all the device sharing problems is handling both functions in a single driver, I end up with only 1 option: Have a kernel driver which provides both functions of the device, with the streaming exported as a standard v4l2 device, and the stillcam function exported with some to be defined API. Combined with a libgphoto2 portlib and camlib for this new API, so that existing libgphoto2 apps can still access the pictures as if nothing was changed. Well, what I _do_ think is that we need to agree about precisely what is supposed to work and what is not, in an operational sense. But we are still fuzzy about that. For example, you seemed to assert this morning that the webcam functionality needs to be able to preempt any running stillcam app and to grab the camera. Why? Or did I misunderstand you? You've misunderstood me. We need to distinguish between an application having a tie to the device (so having a fd open) and the application doing an actual operation on the device. No application should be able to pre-empt an ongoing operation by another application. Attempting an operation while another operation is ongoing should result in -EBUSY. This differs significantly from what we've currently where: 1) There is no distinguishing going on between an app having a tie and an app actually doing an operation. Only one app can have a fd open 2) Some apps (userspace apps) can pre-empt other apps, taking away their fd and cancelling any ongoing operations The above is what leads me to me still firm believe that having a single driver is the only solution. My reasoning is as follows 1) We cannot count on apps closing the fd when they have no immediate use for the device, iow open != in-use 2) Thus we need to allow both libgphoto2 and v4l2 apps to have the device open at the same time 3) When actual in-use (so an operation is ongoing) attempt by another apps to start an operation will result in -EBUSY 4) 2 + 3 can only be realized by having a single driver Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
