RE: [PATCH] media: vb2: dma-sg allocator: change scatterlist allocation method
Hello, On Friday, August 12, 2011 11:55 PM Laurent Pinchart wrote: > On Wednesday 10 August 2011 10:23:37 Marek Szyprowski wrote: > > 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. > > Last time I check ARM platforms didn't support SG list chaining. Has that been > fixed ? DMA-mapping code for ARM platform use for_each_sg() macro which has no problems with chained SG lists. (snipped) 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: How to git and build HVR-2200 drivers from Kernel labs ?
Em 14-08-2011 16:23, Declan Mullen escreveu: > On Sunday 14 August 2011 22:14:48 you wrote: >> On Sun, Aug 14, 2011 at 5:21 AM, Declan Mullen >> >> wrote: >>> Hi >>> >>> I've got a 8940 edition of a Hauppauge HVR-2200. The driver is called >>> saa7164. The versions included in my OS (mythbuntu 10.10 x86 32bit, >>> kernel 2.6.35-30) and from linuxtv.org are too old to recognise the 8940 >>> edition. Posts #124 to #128 in the "Hauppauge HVR-2200 Tuner Install >>> Guide" topic >>> (http://www.pcmediacenter.com.au/forum/topic/37541-hauppauge-hvr-2200-tun >>> er- install-guide/page__view__findpost__p__321195) document my efforts >>> with those versions. >>> >>> So I wish to use the latest stable drivers from the driver maintainers, >>> ie http://kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=summary >>> >>> Problem is, I don't know git and I don't know how I'm suppose to git, >>> build and install it. >>> >>> Taking a guess I've tried: >>> git clone git://kernellabs.com/stoth/saa7164-stable.git >>> cd saa7164-stable >>> make menuconfig >>> make >>> >>> However I suspect these are not the optimum steps, as it seems to have >>> downloaded and built much more than just the saa7164 drivers. The git >>> pulled down nearly 1GB (which seems a lot) and the resultant menuconfig >>> produced a very big ".config". >>> >>> Am I doing the right steps or should I be doing something else to git, >>> build and install the latest drivers ? >>> >>> Thanks, >>> Declan >> >> Hello Declan, >> >> Blame Mauro and the other LinuxTV developers for moving to Git. When >> we had HG you could do just the v4l-dvb stack and apply it to your >> existing kernel. Now you have to suck down the *entire* kernel, and >> there's no easy way to separate out just the v4l-dvb stuff (like the >> saa7164 driver). The net effect is it's that much harder for >> end-users to try out new drivers, and even harder still for developers >> to maintain drivers out-of-tree. Devin, Please stop blaming somebody else for that. Nobody including you didn't have time to keep maintaining two trees. As you know, git _IS_ the SCM used for all kernel submission. So, it was not a matter of choice, but the lack of a develper with available time to keep maintaining the -hg. This is a community work. As such, if someone has a good idea and has enough time for it, he/she can just go ahead and implement it. On the other hand, when time starves, one needs to priorize in order to focus on the tasks that are more relevant. Also, there's no need to download the entire kernel tree. The media-build git tree can download just a tarball. Tarballs with the latest development drivers are daily generated. What makes harder for people to try out new drivers/patches is when developers take months or even years to submit new stuff upstream. Even so, the media-build can work together with another tree that can be a full tree or a tree with just the drivers (using build --git option). I've tested it only with git trees, but it probably works properly also with any other SCM. Regards, 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
Possible cause of replug lockup in em28xx-dvb
Hi, I've been "plugging away" at the locking issue in the em28xx / em28xx-dvb modules, and I think I've found the reason. Basically, we're trying to acquire the dev->lock mutex again in dvb_init() when we've already acquired it in em28xx_init_dev(). The exact sequence is: em28xx_init_dev() - em28xx_init_extension() -- ops->init(dev) function for each extension where ops->init = dvb_init() for the em28xx-dvb extension. However, if you remove the em28xx-dvb module first then the em28xx_extension_devlist is empty and you avoid calling dvb_init(). As to the fix, I'm thinking of moving the mutex_lock() / mutex_unlock() calls from dvb_init() to em28xx_register_extension() instead. This way, we ensure that dvb_init() is still always called with the dvb->lock mutex held. I'll submit a patch for review in the morning. (Or should I say, "later this morning"...) Cheers, Chris -- 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 15-08-2011 05:45, Laurent Pinchart escreveu: > Hi Mauro, >> 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. > > Once again we're not trying to remove controls, but expose them differently. See the comments at the patch series, starting from the patches that removes support for S_INPUT. I'm aware that the controls will be exposed by both MC and V4L2 API, althrough having ways to expose/hide controls via V4L2 API makes patch review a way more complicated than it used to be before the MC patches. Regards, 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: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Em 15-08-2011 09:30, Laurent Pinchart escreveu: > Hi Mauro, > > On Tuesday 09 August 2011 22:05:47 Mauro Carvalho Chehab wrote: >> Em 29-07-2011 05:36, Laurent Pinchart escreveu: >>> 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. >> >> If the sensors aren't mutually exclusive, then two different video nodes >> will be shown in userspace. > > It's more complex than that. The OMAP3 ISP driver exposes 7 video nodes > regardless of the number of sensors. Sensors can be mutually exclusive or > not, > depending on the board. S_INPUT has its use cases, but is less useful on > embedded hardware. Sorry, but exposing a video node that can't be used doesn't make sense. >>> 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? >> >> 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. >> >> 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 something relevant for some users. > > It is, but on embedded devices that usually requires the application to be > hardware-aware. Exposure time limits depend on blanking, which in turn > influences the frame rate along with the pixel clock (often configurable as > well). Programming those settings wrong can exceed the ISP available > bandwidth. > > The world unfortunately stopped being simple some time ago :-) > > Also there might be some preference at user space, at which stage of > the pipeline to apply some controls. This is where the subdev API > helps, and plain video node API does not. Again, this is for specific usecases. On such cases, what is expected is that the more generic control will be exported via V4L2 API. >>> Thus it's a bit hard to imagine that we could do something like >>> "optionally not to inherit controls" as the subdev/MC API is >>> optional. >>> >>> :) >> >> This was actually implemented. There are some cases at ivtv/cx18 >> driver where both the bridge and a subdev provides the same control >> (audio volume, for example). The idea is to allow the bridge driver >> to touch at the subdev control without exposing it to userspace, >> since the desire was that the bridge driver itself would expose such >> control, using a logic that combines changing the subdev and the >> bridge registers for volume. > > This seem like hard coding a policy in the driver;) Then there is no > way (it might not be worth the effort though) to play with volume > level at both devices, e.g. to obtain optimal S/N ratio. In general, playing with just one control is enough. Andy had a different opinion when this issue were discussed, and he thinks that playing with both is better. At the end, this is a developers decis
Re: Afatech AF9013
On Martes, 16 de Agosto de 2011 00:22:05 Josu Lazkano escribió: > 2011/8/16 Jose Alberto Reguero : > > I have problems with a dual usb tuner. I limit the bandwith using pid > > filters and the problem was gone. > > > > Jose alberto > > > > On Lunes, 15 de Agosto de 2011 15:34:20 Josu Lazkano escribió: > >> Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick (DVB-T > >> 399U): > >> http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_(DV > >> B- T_399U) > >> > >> I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual > >> device, sometimes the second adapter works great, but sometimes has a > >> pixeled images. The first adapter always has pixeled images, I don't > >> know how to describe the pixeled images, so here is a mobile record: > >> http://dl.dropbox.com/u/1541853/kworld.3gp > >> > >> I have this firmware: > >> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015 > >> .fw > >> > >> I read on the linuxtv wiki and there are some problems with dual mode, > >> there is some links for how to patch the similar driver (Afatech/ITE > >> IT9135), but I am not good enough to understand the code. > >> > >> I check the kernel messages: > >> > >> Aug 15 13:53:58 htpc kernel: [ 516.285369] af9013: I2C read failed > >> reg:d2e6 Aug 15 13:54:29 htpc kernel: [ 547.407504] af9013: I2C read > >> failed reg:d330 Aug 15 13:54:44 htpc kernel: [ 561.902710] af9013: I2C > >> read failed reg:d2e6 > >> > >> It looks I2C problem, but I don't know how to debug it deeper. > >> > >> I don't know if this is important, but I compile the s2-liplianin for > >> other devices this way: > >> > >> apt-get install linux-headers-`uname -r` build-essential > >> mkdir /usr/local/src/dvb > >> cd /usr/local/src/dvb > >> wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip > >> unzip s2-liplianin-0b7d3cc65161.zip > >> cd s2-liplianin-0b7d3cc65161 > >> make CONFIG_DVB_FIREDTV:=n > >> make install > >> > >> Can you help with this? This hardware is a very cheap and works well > >> for HD channels but, I don't know why sometimes has pixeled images. > >> > >> Thanks for your help, best regards. > > Thanks Jose Alberto, I search on google for pid filters but I don't > find any interesting info. > > How can I limit bandwidth on dvb? > > Thanks for your help, I have two dual devices waiting for this fix on my > HTPC. > > Best regards. If the driver has pid filters you can enable it with the parameter force_pid_filter_usage=1 of dvb-usb. Jose Alberto -- 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: Afatech AF9013
2011/8/16 Jose Alberto Reguero : > I have problems with a dual usb tuner. I limit the bandwith using pid filters > and the problem was gone. > > Jose alberto > > On Lunes, 15 de Agosto de 2011 15:34:20 Josu Lazkano escribió: >> Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick (DVB-T >> 399U): >> http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_(DVB- >> T_399U) >> >> I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual >> device, sometimes the second adapter works great, but sometimes has a >> pixeled images. The first adapter always has pixeled images, I don't >> know how to describe the pixeled images, so here is a mobile record: >> http://dl.dropbox.com/u/1541853/kworld.3gp >> >> I have this firmware: >> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw >> >> I read on the linuxtv wiki and there are some problems with dual mode, >> there is some links for how to patch the similar driver (Afatech/ITE >> IT9135), but I am not good enough to understand the code. >> >> I check the kernel messages: >> >> Aug 15 13:53:58 htpc kernel: [ 516.285369] af9013: I2C read failed >> reg:d2e6 Aug 15 13:54:29 htpc kernel: [ 547.407504] af9013: I2C read >> failed reg:d330 Aug 15 13:54:44 htpc kernel: [ 561.902710] af9013: I2C >> read failed reg:d2e6 >> >> It looks I2C problem, but I don't know how to debug it deeper. >> >> I don't know if this is important, but I compile the s2-liplianin for >> other devices this way: >> >> apt-get install linux-headers-`uname -r` build-essential >> mkdir /usr/local/src/dvb >> cd /usr/local/src/dvb >> wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip >> unzip s2-liplianin-0b7d3cc65161.zip >> cd s2-liplianin-0b7d3cc65161 >> make CONFIG_DVB_FIREDTV:=n >> make install >> >> Can you help with this? This hardware is a very cheap and works well >> for HD channels but, I don't know why sometimes has pixeled images. >> >> Thanks for your help, best regards. > Thanks Jose Alberto, I search on google for pid filters but I don't find any interesting info. How can I limit bandwidth on dvb? Thanks for your help, I have two dual devices waiting for this fix on my HTPC. Best regards. -- Josu Lazkano -- 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: Afatech AF9013
I have problems with a dual usb tuner. I limit the bandwith using pid filters and the problem was gone. Jose alberto On Lunes, 15 de Agosto de 2011 15:34:20 Josu Lazkano escribió: > Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick (DVB-T > 399U): > http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_(DVB- > T_399U) > > I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual > device, sometimes the second adapter works great, but sometimes has a > pixeled images. The first adapter always has pixeled images, I don't > know how to describe the pixeled images, so here is a mobile record: > http://dl.dropbox.com/u/1541853/kworld.3gp > > I have this firmware: > http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw > > I read on the linuxtv wiki and there are some problems with dual mode, > there is some links for how to patch the similar driver (Afatech/ITE > IT9135), but I am not good enough to understand the code. > > I check the kernel messages: > > Aug 15 13:53:58 htpc kernel: [ 516.285369] af9013: I2C read failed > reg:d2e6 Aug 15 13:54:29 htpc kernel: [ 547.407504] af9013: I2C read > failed reg:d330 Aug 15 13:54:44 htpc kernel: [ 561.902710] af9013: I2C > read failed reg:d2e6 > > It looks I2C problem, but I don't know how to debug it deeper. > > I don't know if this is important, but I compile the s2-liplianin for > other devices this way: > > apt-get install linux-headers-`uname -r` build-essential > mkdir /usr/local/src/dvb > cd /usr/local/src/dvb > wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip > unzip s2-liplianin-0b7d3cc65161.zip > cd s2-liplianin-0b7d3cc65161 > make CONFIG_DVB_FIREDTV:=n > make install > > Can you help with this? This hardware is a very cheap and works well > for HD channels but, I don't know why sometimes has pixeled images. > > Thanks for your help, best 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: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?
On Mon, 2011-08-15 at 06:19 -0400, Andy Walls wrote: > One of the bigger problems with the cx23885 driver and hardware was that > things don't appear to work well with MSI enabled in the driver. Hack your > version of the driver to make sure MSI is not enabled for CX2388[578] chips. > > As far as the unclearable IR interrupt with MSI disabled, I've only seen that > with the CX23885 on nonHauppauge cards; the CX23888 seems to be ok. I'm sure > the problem on nonHauppauge cards is simply me no knowing for sure how some > of the pins on the CX23885 were wired up. Thanks for your pointers on the pitfalls and CX25840 similarity. That helps considerably. Progressing well at present. Will keep you posted. How would it stand legally etc if I posted a patch to this list to support the tbs6981? Two possible scenarios: 1. Referencing, but not requiring, a blob module built from from TBS's tuner FE object file that they distribute. 2. Using a reversed engineered FE driver. -- Lawrence -- 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:Mon Aug 15 19:00:32 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: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The 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: New Hauppauge HVR-2200 Revision?
Hi, I've recently bought two cards HVR-2200 rev 0700:8940 and installed them into one PC. Kernel module saa7164 was launched by linux (under Ubuntu 11.04, with kernel 2.6.38-10-generic-pae), but it didn't recognize my cards (so, it selected card 0 : unknown). I've seen a new patch on your mailing list (see archive [1] and the patch [2]), but it was apparently only applied on kernellabs.org and not in the linuxtv.org archive. So I've downloaded the Ubuntu linux source (with apt-get install linux-source), I've patched it following the diff [2] and I've compiled this new kernel. Now when I reboot it, it works really well : I don't need any more to say which cards I've in /etc/modprobe.d/saa-7164.conf and both were well recognized (I've seen my four adapters in /dev/dvb/adapter[0,1,2,3]). So, could you apply this patch also on your source please (and try it to confirm my tests)? Thank you very much, Adrien Dorsaz a.dor...@gmail.com [1] : http://www.mail-archive.com/linux-media@vger.kernel.org/msg14612.html , and the message which give a patch : http://www.mail-archive.com/linux-media@vger.kernel.org/msg14626.html [2] : the patch on kernellabs.org : http://www.kernellabs.com/hg/saa7164-stable/rev/cf2d7530d676 -- 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
origin/master branch update ?
Hi, When will the origin/master branch be updated regarding the media_tree.git ? --HPS -- 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
em28xx module (Kaiomy TVnPC U2, card=63), loaded but NO output [ioctl VIDIOCGFBUF: Invalid argument]
Hi My system is running Opensuse 11.4 x64 with KDE 4.6. Plugged device Kaiomy TVnPC U2. Followed the instruccions to extract missing firmware xc2038, also updated v4l-dvb tree. Implemented em28xx-new driver. No errors on boot. All modules seemed to be loaded correctly, card seemes to be recognized correctly, but I am not able to get any images/sound from TV nor sound from RADIO. The device is recognized as card=63, /dev/video1, /dev/vbi1 and /dev/radio0, /dev/audio1 I would like to use this card on channel 1 (Composite1) for TV Tried with KMPlayer and VLC, but cannot get any video. Also tried with LD_PRELOAD="/usr/lib64/libv4l/v4lcomvert.so", no success. norm NTSC-M, Video YUYV, framerate 29,70, input: 1 System Informations: uname -r: 2.6.37.6-0.7-desktop lsusb: Bus 002 Device 005: ID eb1a:2863 eMPIA Technology, Inc. dmesg | grep em28: [ 16.023986] em28xx: New device USB 2863 Device @ 480 Mbps (eb1a:2863, interface 0, class 0) [ 16.024358] em28xx #0: chip ID is em2860 [ 16.258872] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 63 28 f0 00 65 03 6a 20 8a 0a [ 16.258883] em28xx #0: i2c eeprom 10: 00 00 24 57 4e 02 08 00 60 00 00 00 02 00 00 00 [ 16.258892] em28xx #0: i2c eeprom 20: 1e 00 13 00 f0 10 01 82 82 00 00 00 5b 00 00 00 [ 16.258900] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 16.258907] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 c4 00 00 [ 16.258915] em28xx #0: i2c eeprom 50: 81 00 00 00 00 00 00 00 00 c3 00 00 00 00 00 00 [ 16.258923] em28xx #0: i2c eeprom 60: 11 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [ 16.258931] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 36 00 33 00 20 00 44 00 [ 16.258939] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 0a 03 31 00 32 00 [ 16.258947] em28xx #0: i2c eeprom 90: 33 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 16.258955] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 16.258963] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 16.258970] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 16.258978] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 16.258986] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 16.258994] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 16.259017] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xc143f201 [ 16.259019] em28xx #0: EEPROM info: [ 16.259020] em28xx #0: I2S audio, 3 sample rates [ 16.259022] em28xx #0: 500mA max power [ 16.259024] em28xx #0: Table at 0x24, strings=0x206a, 0x0a8a, 0x [ 16.260109] em28xx #0: Identified as Kaiomy TVnPC U2 (card=63) [ 16.987726] tuner 11-0061: chip found @ 0xc2 (em28xx #0) [ 26.399413] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-1/2-1.1/rc/rc0/input13 [ 26.399507] rc0: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-1/2-1.1/rc/rc0 [ 26.406261] em28xx #0: Config register raw data: 0xf0 [ 26.406263] em28xx #0: I2S Audio (5 sample rates) [ 26.406265] em28xx #0: No AC97 audio processor [ 26.436058] em28xx #0: v4l2 driver version 0.1.2 [ 33.581230] em28xx #0: Registered radio device as radio0 [ 33.581233] em28xx #0: V4L2 video device registered as video1 [ 33.581234] em28xx #0: V4L2 VBI device registered as vbi1 [ 33.587096] usbcore: registered new interface driver em28xx [ 33.587098] em28xx driver loaded [ 33.607880] em28xx-audio.c: probing for em28x1 non standard usbaudio [ 33.607884] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger xawtv -hwscan: This is xawtv-3.95, running on Linux/x86_64 (2.6.37.6-0.7-desktop) looking for available devices port 86-101 type : Xvideo, image scaler name : Intel(R) Textured Video /dev/video0: OK [ -device /dev/video0 ] type : v4l2 name : CNF7051 flags: capture /dev/video1: OK [ -device /dev/video1 ] type : v4l2 name : Kaiomy TVnPC U2 flags: capture tuner HERE SEEMES TO BE A PROBLEM: v4l-info /dev/video1 | grep invalid: ioctl VIDIOCGFBUF: Invalid argument and here the list of loaded modules lsmod: Module Size Used by em28xx_alsa 7655 1 hdj_mod 153949 0 snd_rawmidi26923 1 hdj_mod rc_kaiomy 1315 0 tuner_xc2028 21545 1 tuner 24130 1 tvp515017692 0 ir_lirc_codec 4843 0 lirc_dev 16018 1 ir_lirc_codec ir_sony_decoder 2453 0 ir_jvc_decoder 2578 0 ir_rc6_decoder 3090 0 ir_rc5_decoder 2546 0 ir_nec_decoder 2738 0 em28xx103656 1 em28xx_alsa v4l2_common12303 3 tuner,tvp5150,em28xx ir_core21236 9 rc_kaiomy,ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_r
Re: [media-ctl][PATCH] libmediactl: engage udev to get devname
Hi Andy,
Thank you for the patch.
What about making it a configuration option to still support systems that
don't provide libudev ? We could keep the current behaviour for those.
On Monday 15 August 2011 14:20:34 Andy Shevchenko wrote:
> Signed-off-by: Andy Shevchenko
> ---
> configure.in| 10
> src/Makefile.am |2 +
> src/media.c | 66
> ++ 3 files changed, 44
> insertions(+), 34 deletions(-)
>
> diff --git a/configure.in b/configure.in
> index fd4c70c..63432ba 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -12,6 +12,16 @@ AC_PROG_CC
> AC_PROG_LIBTOOL
>
> # Checks for libraries.
> +PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)
> +
> +if test x$have_libudev = xyes; then
> +LIBUDEV_CFLAGS="$lbudev_CFLAGS"
> +LIBUDEV_LIBS="$libudev_LIBS"
> +AC_SUBST(LIBUDEV_CFLAGS)
> +AC_SUBST(LIBUDEV_LIBS)
> +else
> +AC_MSG_ERROR([libudev is required])
> +fi
>
> # Kernel headers path.
> AC_ARG_WITH(kernel-headers,
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 267ea83..52628d2 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -5,6 +5,8 @@ mediactl_includedir=$(includedir)/mediactl
> mediactl_include_HEADERS = media.h subdev.h
>
> bin_PROGRAMS = media-ctl
> +media_ctl_CFLAGS = $(LIBUDEV_CFLAGS)
> +media_ctl_LDFLAGS = $(LIBUDEV_LIBS)
> media_ctl_SOURCES = main.c options.c options.h tools.h
> media_ctl_LDADD = libmediactl.la libv4l2subdev.la
>
> diff --git a/src/media.c b/src/media.c
> index e3cab86..000d750 100644
> --- a/src/media.c
> +++ b/src/media.c
> @@ -31,6 +31,8 @@
> #include
> #include
>
> +#include
> +
> #include "media.h"
> #include "tools.h"
>
> @@ -247,15 +249,20 @@ static int media_enum_links(struct media_device
> *media)
>
> static int media_enum_entities(struct media_device *media)
> {
> + struct udev *udev;
> + dev_t devnum;
> + struct udev_device *device;
> struct media_entity *entity;
> - struct stat devstat;
> unsigned int size;
> - char devname[32];
> - char sysname[32];
> - char target[1024];
> - char *p;
> + const char *p;
> __u32 id;
> - int ret;
> + int ret = 0;
> +
> + udev = udev_new();
> + if (udev == NULL) {
> + printf("unable to allocate memory for context\n");
> + return -ENOMEM;
> + }
>
> for (id = 0; ; id = entity->info.id) {
> size = (media->entities_count + 1) * sizeof(*media->entities);
> @@ -268,9 +275,9 @@ static int media_enum_entities(struct media_device
> *media)
>
> ret = ioctl(media->fd, MEDIA_IOC_ENUM_ENTITIES, &entity->info);
> if (ret < 0) {
> - if (errno == EINVAL)
> - break;
> - return -errno;
> + if (errno != EINVAL)
> + ret = -errno;
> + break;
> }
>
> /* Number of links (for outbound links) plus number of pads (for
> @@ -281,8 +288,10 @@ static int media_enum_entities(struct media_device
> *media)
>
> entity->pads = malloc(entity->info.pads *
> sizeof(*entity->pads));
> entity->links = malloc(entity->max_links *
> sizeof(*entity->links));
> - if (entity->pads == NULL || entity->links == NULL)
> - return -ENOMEM;
> + if (entity->pads == NULL || entity->links == NULL) {
> + ret = -ENOMEM;
> + break;
> + }
>
> media->entities_count++;
>
> @@ -291,32 +300,21 @@ static int media_enum_entities(struct media_device
> *media) media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> continue;
>
> - sprintf(sysname, "/sys/dev/char/%u:%u", entity->info.v4l.major,
> - entity->info.v4l.minor);
> - ret = readlink(sysname, target, sizeof(target));
> - if (ret < 0)
> - continue;
> -
> - target[ret] = '\0';
> - p = strrchr(target, '/');
> - if (p == NULL)
> - continue;
> -
> - sprintf(devname, "/dev/%s", p + 1);
> - ret = stat(devname, &devstat);
> - if (ret < 0)
> - continue;
> + devnum = makedev(entity->info.v4l.major,
> entity->info.v4l.minor);
> + printf("looking up device: %u:%u\n", major(devnum),
> minor(devnum));
> + device = udev_device_new_from_devnum(udev, 'c', devnum);
> + if (device) {
> + p = udev_device_get_devnode(device);
> + if (p)
> + snprintf(entity->devname,
> sizeof(entity->devname),
> + "%s", p);
> + }
>
> - /* Sanity check: udev might have reordered the device node
Re: How to git and build HVR-2200 drivers from Kernel labs ?
On Monday, August 15, 2011 09:28:44 am Devin Heitmueller wrote: > Only Steven can look at the schematic and know for sure what prompted > them to update to a new PCI ID. However, you can definitely try doing > "card=4" and see if it works. > > Card=9 won't work since that card number is not valid given the card > list in your driver. > > Devin > > On Sun, Aug 14, 2011 at 7:23 PM, Declan Mullen > > wrote: > > On Sunday 14 August 2011 22:14:48 you wrote: > >> On Sun, Aug 14, 2011 at 5:21 AM, Declan Mullen > >> > >> wrote: > >> > Hi > >> > > >> > I've got a 8940 edition of a Hauppauge HVR-2200. The driver is called > >> > saa7164. The versions included in my OS (mythbuntu 10.10 x86 32bit, > >> > kernel 2.6.35-30) and from linuxtv.org are too old to recognise the > >> > 8940 edition. Posts #124 to #128 in the "Hauppauge HVR-2200 Tuner > >> > Install Guide" topic > >> > (http://www.pcmediacenter.com.au/forum/topic/37541-hauppauge-hvr-2200- > >> > tun er- install-guide/page__view__findpost__p__321195) document my > >> > efforts with those versions. > >> > > >> > So I wish to use the latest stable drivers from the driver > >> > maintainers, ie > >> > http://kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=summary > >> > > >> > Problem is, I don't know git and I don't know how I'm suppose to git, > >> > build and install it. > >> > > >> > Taking a guess I've tried: > >> > git clone git://kernellabs.com/stoth/saa7164-stable.git > >> > cd saa7164-stable > >> > make menuconfig > >> > make > >> > > >> > However I suspect these are not the optimum steps, as it seems to have > >> > downloaded and built much more than just the saa7164 drivers. The git > >> > pulled down nearly 1GB (which seems a lot) and the resultant > >> > menuconfig produced a very big ".config". > >> > > >> > Am I doing the right steps or should I be doing something else to git, > >> > build and install the latest drivers ? > >> > > >> > Thanks, > >> > Declan > >> > >> Hello Declan, > >> > >> Blame Mauro and the other LinuxTV developers for moving to Git. When > >> we had HG you could do just the v4l-dvb stack and apply it to your > >> existing kernel. Now you have to suck down the *entire* kernel, and > >> there's no easy way to separate out just the v4l-dvb stuff (like the > >> saa7164 driver). The net effect is it's that much harder for > >> end-users to try out new drivers, and even harder still for developers > >> to maintain drivers out-of-tree. > >> > >> All that said, Ubuntu 10.10 deviates very little in terms of the > >> saa7164 driver. What you have is probably already identical to what's > >> in the kernellabs.com tree. > >> > >> And yes, PAL support is broken even in the kernellabs tree, so if that > >> was your motivation then updating to the current KL stable tree won't > >> help you. > >> > >> Cheers, > >> > >> Devin > > > > Many thanks for the clarification about git. > > > > The only reason why I'm attempting to use a newer saa7164 driver is > > because the driver in my ubuntu 10.10 (2.6.35-30, x86 32bit) doesn't > > recognise the 8940 edition of my HVR-2200 (and doesn't support the > > "card=9" option that I believe is specifically for the 8940 edition). > > > > Example dmesg output: > > $ dmesg | grep saa7 > > [ 18.367431] saa7164 driver loaded > > [ 18.367467] saa7164 :02:00.0: PCI INT A -> GSI 16 (level, low) -> > > IRQ 16 [ 18.367472] saa7164[0]: Your board isn't known (yet) to the > > driver. [ 18.367473] saa7164[0]: Try to pick one of the existing card > > configs via [ 18.367474] saa7164[0]: card= insmod option. Updating > > to the latest [ 18.367475] saa7164[0]: version might help as well. > > [ 18.367684] saa7164[0]: Here are valid choices for the card= > > insmod option: [ 18.367739] saa7164[0]:card=0 -> Unknown > > [ 18.367789] saa7164[0]:card=1 -> Generic Rev2 > > [ 18.367840] saa7164[0]:card=2 -> Generic Rev3 > > [ 18.367891] saa7164[0]:card=3 -> Hauppauge WinTV-HVR2250 > > [ 18.367943] saa7164[0]:card=4 -> Hauppauge WinTV-HVR2200 > > [ 18.367995] saa7164[0]:card=5 -> Hauppauge WinTV-HVR2200 > > [ 18.368059] saa7164[0]:card=6 -> Hauppauge WinTV-HVR2200 > > [ 18.368112] saa7164[0]:card=7 -> Hauppauge WinTV-HVR2250 > > [ 18.368164] saa7164[0]:card=8 -> Hauppauge WinTV-HVR2250 > > [ 18.369142] CORE saa7164[0]: subsystem: 0070:8940, board: Unknown > > [card=0,autodetected] [ 18.369147] saa7164[0]/0: found at > > :02:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xfd40 [ > > 18.369152] saa7164 :02:00.0: setting latency timer to 64 [ > > 18.369162] saa7164_initdev() Unsupported board detected, registering > > without firmware > > > > To get this 8940 card working with my ubuntu 10.10 system, > > what would you recommend I try ? > > > > Should I be trying to extract the new driver from what the above > > git and makes, ie just copy into place the new saa7164.ko file ? > > Or should my e
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Mon, 15 Aug 2011, Hans Verkuil wrote:
> On Monday, August 15, 2011 13:28:23 Guennadi Liakhovetski wrote:
> > Hi Hans
> >
> > On Mon, 8 Aug 2011, Hans Verkuil wrote:
> >
> > > Hi Guennadi!
> > >
> > > On Friday, August 05, 2011 09:47:13 Guennadi Liakhovetski wrote:
> > > > A possibility to preallocate and initialise buffers of different sizes
> > > > in V4L2 is required for an efficient implementation of asnapshot mode.
> > > > This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
> > > > VIDIOC_PREPARE_BUF and defines respective data structures.
> > > >
> > > > Signed-off-by: Guennadi Liakhovetski
> > > > ---
> > > >
> > > > v4:
> > > >
> > > > 1. CREATE_BUFS now takes an array of plane sizes and a fourcc code in
> > > > its
> > > >argument, instead of a frame format specification, including
> > > >documentation update
> > > > 2. documentation improvements, as suggested by Hans
> > > > 3. increased reserved fields to 18, as suggested by Sakari
> > > >
> > > > Documentation/DocBook/media/v4l/io.xml | 17 ++
> > > > Documentation/DocBook/media/v4l/v4l2.xml |2 +
> > > > .../DocBook/media/v4l/vidioc-create-bufs.xml | 161
> > >
> > > > .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96
> > > > drivers/media/video/v4l2-compat-ioctl32.c |6 +
> > > > drivers/media/video/v4l2-ioctl.c | 26 +++
> > > > include/linux/videodev2.h | 18 +++
> > > > include/media/v4l2-ioctl.h |2 +
> > > > 8 files changed, 328 insertions(+), 0 deletions(-)
> > > > create mode 100644
> > > > Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
> > > > create mode 100644
> > > > Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
> > > >
> > >
> > >
> > >
> > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > index fca24cc..3cd0cb3 100644
> > > > --- a/include/linux/videodev2.h
> > > > +++ b/include/linux/videodev2.h
> > > > @@ -653,6 +653,9 @@ struct v4l2_buffer {
> > > > #define V4L2_BUF_FLAG_ERROR0x0040
> > > > #define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
> > > > #define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
> > > > +/* Cache handling flags */
> > > > +#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0400
> > > > +#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
> > > >
> > > > /*
> > > > * O V E R L A Y P R E V I E W
> > > > @@ -2092,6 +2095,18 @@ struct v4l2_dbg_chip_ident {
> > > > __u32 revision;/* chip revision, chip specific */
> > > > } __attribute__ ((packed));
> > > >
> > > > +/* VIDIOC_CREATE_BUFS */
> > > > +struct v4l2_create_buffers {
> > > > + __u32 index; /* output: buffers index...index + count - 1
> > > > have been
> > > created */
> > > > + __u32 count;
> > > > + __u32 type;
> > > > + __u32 memory;
> > > > + __u32 fourcc;
> > > > + __u32 num_planes;
> > > > + __u32 sizes[VIDEO_MAX_PLANES];
> > > > + __u32 reserved[18];
> > > > +};
> > >
> > > I know you are going to hate me for this,
> >
> > hm, I'll consider this possibility;-)
> >
> > > but I've changed my mind: I think
> > > this should use a struct v4l2_format after all.
While switching back, I have to change the struct vb2_ops::queue_setup()
operation to take a struct v4l2_create_buffers pointer. An earlier version
of this patch just added one more parameter to .queue_setup(), which is
easier - changes to videobuf2-core.c are smaller, but it is then
redundant. We could use the create pointer for both input and output. The
video plane configuration in frame format is the same as what is
calculated in .queue_setup(), IIUC. So, we could just let the driver fill
that one in. This would require then the videobuf2-core.c to parse struct
v4l2_format to decide which union member we need, depending on the buffer
type. Do we want this or shall drivers duplicate plane sizes in separate
.queue_setup() parameters?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Afatech AF9013
Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick (DVB-T 399U): http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_(DVB-T_399U) I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual device, sometimes the second adapter works great, but sometimes has a pixeled images. The first adapter always has pixeled images, I don't know how to describe the pixeled images, so here is a mobile record: http://dl.dropbox.com/u/1541853/kworld.3gp I have this firmware: http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw I read on the linuxtv wiki and there are some problems with dual mode, there is some links for how to patch the similar driver (Afatech/ITE IT9135), but I am not good enough to understand the code. I check the kernel messages: Aug 15 13:53:58 htpc kernel: [ 516.285369] af9013: I2C read failed reg:d2e6 Aug 15 13:54:29 htpc kernel: [ 547.407504] af9013: I2C read failed reg:d330 Aug 15 13:54:44 htpc kernel: [ 561.902710] af9013: I2C read failed reg:d2e6 It looks I2C problem, but I don't know how to debug it deeper. I don't know if this is important, but I compile the s2-liplianin for other devices this way: apt-get install linux-headers-`uname -r` build-essential mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip unzip s2-liplianin-0b7d3cc65161.zip cd s2-liplianin-0b7d3cc65161 make CONFIG_DVB_FIREDTV:=n make install Can you help with this? This hardware is a very cheap and works well for HD channels but, I don't know why sometimes has pixeled images. Thanks for your help, best regards. -- Josu Lazkano -- 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: How to git and build HVR-2200 drivers from Kernel labs ?
On Monday, August 15, 2011 11:23:39 pm Declan Mullen wrote: > On Monday, August 15, 2011 11:04:03 pm Steven Toth wrote: > > > So how do I get a 8940 edition of a HVR-2200 working with Ubuntu ? > > > > Hello Declan, > > > > You'll need to install the entire new kernel and all of its modules, > > you should avoid cherry picking small pieces. > > > > Incidentally, I've had confirmation from another user that the tree > > works and automatically detects type 9 cards. > > > > - Steve > > No worries. Many thanks for the clarification. > > BTW, given that I only need the card's DVB-T functionality (don't need > analog,...) could I get that by using ubuntu 10.10's existing driver and > one of its card types 1to 8 ? If so, which card type would you recommend > ? > > Thanks, > Declan P.S. I'ld be using it in Australia which uses PAL-BG -- 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: How to git and build HVR-2200 drivers from Kernel labs ?
On Monday, August 15, 2011 11:04:03 pm Steven Toth wrote: > > So how do I get a 8940 edition of a HVR-2200 working with Ubuntu ? > > Hello Declan, > > You'll need to install the entire new kernel and all of its modules, > you should avoid cherry picking small pieces. > > Incidentally, I've had confirmation from another user that the tree > works and automatically detects type 9 cards. > > - Steve No worries. Many thanks for the clarification. BTW, given that I only need the card's DVB-T functionality (don't need analog,...) could I get that by using ubuntu 10.10's existing driver and one of its card types 1to 8 ? If so, which card type would you recommend ? Thanks, Declan -- 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: How to git and build HVR-2200 drivers from Kernel labs ?
> So how do I get a 8940 edition of a HVR-2200 working with Ubuntu ? Hello Declan, You'll need to install the entire new kernel and all of its modules, you should avoid cherry picking small pieces. Incidentally, I've had confirmation from another user that the tree works and automatically detects type 9 cards. - 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
Re: [PATCH 2/2] omap3: ISP: Kernel crash when attempting suspend
Hi,
On Wednesday 10 August 2011 16:03:26 Deepthy Ravi wrote:
> 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.
What about squashing this with the previous patch then ?
I'll review patch 1/2, just give me a bit more time. The race condition is
tricky so I need to rest a bit before attacking it :-)
> 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 */
--
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] media: vb2: add a check if queued userptr buffer is large enough
HI Marek,
Thanks for the patch.
On Wednesday 10 August 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
Acked-by: Laurent Pinchart
Just one small comment below though.
> ---
> drivers/media/video/videobuf2-core.c | 41
> +++-- include/media/videobuf2-core.h |
> 1 +
> 2 files changed, 25 insertions(+), 17 deletions(-)
[snip]
> 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];
What about unsigned int ? That 4GB should be more than enough :-)
> unsigned intstreaming:1;
--
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 PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Wednesday 10 August 2011 02:22:00 Mauro Carvalho Chehab wrote: > Em 09-08-2011 20:18, Sakari Ailus escreveu: > > On Tue, Aug 09, 2011 at 05:05:47PM -0300, Mauro Carvalho Chehab wrote: > >> Em 29-07-2011 05:36, Laurent Pinchart escreveu: > >>> 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: [snip] > >>> 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. We're not trying to remove the controls. We expose them differently. That's a big difference :-) > >> 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 something relevant for some users. > > > > You do want the 3A algorithms even if you use manual white balance. What > > the automatic white balance algorithm produces is (among other things) > > gamma tables, rgb-to-rgb conversion matrices and lens shading correction > > tables. I doubt any end user, even if it was you, would like to fiddle > > with such large tables directly when capturing photos. > > There are some hacks for several professional and amateur cameras that > replace the existing 3A algorithms by... NONE. The idea is to get the raw > data directly from the sensor, and use some software like Gimp or > Photoshop to do lens correction, temperature correction, whitespace > ballance, etc, at post-processing. The advantage of such type of usage is > that the photographer can fine-tune the generated image to produce what he > wants, using more sophisticated (and not real-time) algorithms. > > [1] for example, one of such firmwares, that I use on my Canon Digital > Camera is available at: > http://chdk.wikia.com/wiki/CHDK That's something you can very easily do with http://git.ideasonboard.org/?p=media-ctl.git;a=summary to configure the pipeline and http://git.ideasonboard.org/?p=yavta.git;a=summary to set controls and capture video. The later uses standard V4L2 ioctls only, even to set control on subdevs. > > The size of this configuration could > > easily be around 10 kB. A higher level control is required; colour > > temperature, for instance. And its implementation involves the same > > automatic white balance algorithm. > > > > You must know your hardware very, very well to use the aforementioned low > > level controls and in such a case you have no reason not to use the MC > > interface to configure the device either. Configuring the device image > > pipe using MC is actually a number of magnitudes less complex, and I say > > it's been quite an achievement that we have such an interface which > > makes it so effortless to do. > > For sure, such kind of controls that exposes the 3A correction algorithm at > the DSP level shouldn't be exposed via V4L2 interface, but things like > disabling 3A and manually controlling the sensor, like aperture, exposure, > analog zoom, etc, makes sense to be exported. Drivers can't export 3A enable/disable controls, as 3A is implement in userspace. All manual controls are exported on subdev nodes, there's no issue with that. Any application (including the 3A implementation in libv4l) can use them. > > Also there might be some preference at user space, at which stage of > > the pipeline to apply some controls. This is where the subdev API > >>>
Re: How to git and build HVR-2200 drivers from Kernel labs ?
On Monday, August 15, 2011 09:09:53 pm Declan Mullen wrote: > On Monday, August 15, 2011 09:28:44 am Devin Heitmueller wrote: > > Only Steven can look at the schematic and know for sure what prompted > > them to update to a new PCI ID. However, you can definitely try doing > > "card=4" and see if it works. > > > > Card=9 won't work since that card number is not valid given the card > > list in your driver. > > > > Devin > > > > On Sun, Aug 14, 2011 at 7:23 PM, Declan Mullen > > > > wrote: > > > On Sunday 14 August 2011 22:14:48 you wrote: > > >> On Sun, Aug 14, 2011 at 5:21 AM, Declan Mullen > > >> > > >> wrote: > > >> > Hi > > >> > > > >> > I've got a 8940 edition of a Hauppauge HVR-2200. The driver is > > >> > called saa7164. The versions included in my OS (mythbuntu 10.10 x86 > > >> > 32bit, kernel 2.6.35-30) and from linuxtv.org are too old to > > >> > recognise the 8940 edition. Posts #124 to #128 in the "Hauppauge > > >> > HVR-2200 Tuner Install Guide" topic > > >> > (http://www.pcmediacenter.com.au/forum/topic/37541-hauppauge-hvr-220 > > >> > 0- tun er- install-guide/page__view__findpost__p__321195) document > > >> > my efforts with those versions. > > >> > > > >> > So I wish to use the latest stable drivers from the driver > > >> > maintainers, ie > > >> > http://kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=summary > > >> > > > >> > Problem is, I don't know git and I don't know how I'm suppose to > > >> > git, build and install it. > > >> > > > >> > Taking a guess I've tried: > > >> > git clone git://kernellabs.com/stoth/saa7164-stable.git > > >> > cd saa7164-stable > > >> > make menuconfig > > >> > make > > >> > > > >> > However I suspect these are not the optimum steps, as it seems to > > >> > have downloaded and built much more than just the saa7164 drivers. > > >> > The git pulled down nearly 1GB (which seems a lot) and the > > >> > resultant menuconfig produced a very big ".config". > > >> > > > >> > Am I doing the right steps or should I be doing something else to > > >> > git, build and install the latest drivers ? > > >> > > > >> > Thanks, > > >> > Declan > > >> > > >> Hello Declan, > > >> > > >> Blame Mauro and the other LinuxTV developers for moving to Git. When > > >> we had HG you could do just the v4l-dvb stack and apply it to your > > >> existing kernel. Now you have to suck down the *entire* kernel, and > > >> there's no easy way to separate out just the v4l-dvb stuff (like the > > >> saa7164 driver). The net effect is it's that much harder for > > >> end-users to try out new drivers, and even harder still for developers > > >> to maintain drivers out-of-tree. > > >> > > >> All that said, Ubuntu 10.10 deviates very little in terms of the > > >> saa7164 driver. What you have is probably already identical to what's > > >> in the kernellabs.com tree. > > >> > > >> And yes, PAL support is broken even in the kernellabs tree, so if that > > >> was your motivation then updating to the current KL stable tree won't > > >> help you. > > >> > > >> Cheers, > > >> > > >> Devin > > > > > > Many thanks for the clarification about git. > > > > > > The only reason why I'm attempting to use a newer saa7164 driver is > > > because the driver in my ubuntu 10.10 (2.6.35-30, x86 32bit) doesn't > > > recognise the 8940 edition of my HVR-2200 (and doesn't support the > > > > > > "card=9" option that I believe is specifically for the 8940 edition). > > > > > > Example dmesg output: > > > $ dmesg | grep saa7 > > > [ 18.367431] saa7164 driver loaded > > > [ 18.367467] saa7164 :02:00.0: PCI INT A -> GSI 16 (level, low) > > > -> > > > > > > IRQ 16 [ 18.367472] saa7164[0]: Your board isn't known (yet) to the > > > driver. [ 18.367473] saa7164[0]: Try to pick one of the existing card > > > configs via [ 18.367474] saa7164[0]: card= insmod option. > > > Updating to the latest [ 18.367475] saa7164[0]: version might help > > > as well. > > > > > > [ 18.367684] saa7164[0]: Here are valid choices for the card= > > > > > > insmod option: [ 18.367739] saa7164[0]:card=0 -> Unknown > > > > > > [ 18.367789] saa7164[0]:card=1 -> Generic Rev2 > > > [ 18.367840] saa7164[0]:card=2 -> Generic Rev3 > > > [ 18.367891] saa7164[0]:card=3 -> Hauppauge WinTV-HVR2250 > > > [ 18.367943] saa7164[0]:card=4 -> Hauppauge WinTV-HVR2200 > > > [ 18.367995] saa7164[0]:card=5 -> Hauppauge WinTV-HVR2200 > > > [ 18.368059] saa7164[0]:card=6 -> Hauppauge WinTV-HVR2200 > > > [ 18.368112] saa7164[0]:card=7 -> Hauppauge WinTV-HVR2250 > > > [ 18.368164] saa7164[0]:card=8 -> Hauppauge WinTV-HVR2250 > > > [ 18.369142] CORE saa7164[0]: subsystem: 0070:8940, board: Unknown > > > > > > [card=0,autodetected] [ 18.369147] saa7164[0]/0: found at > > > :02:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xfd40 [ > > > 18.369152] saa7164 :02:00.0: setting latency timer to 64 [ > > > 18.369162] saa7164_initdev() Unsuppo
Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Tuesday 09 August 2011 22:05:47 Mauro Carvalho Chehab wrote: > Em 29-07-2011 05:36, Laurent Pinchart escreveu: > > 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. > > If the sensors aren't mutually exclusive, then two different video nodes > will be shown in userspace. It's more complex than that. The OMAP3 ISP driver exposes 7 video nodes regardless of the number of sensors. Sensors can be mutually exclusive or not, depending on the board. S_INPUT has its use cases, but is less useful on embedded hardware. > > 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? > > 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. > > 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 something relevant for some users. It is, but on embedded devices that usually requires the application to be hardware-aware. Exposure time limits depend on blanking, which in turn influences the frame rate along with the pixel clock (often configurable as well). Programming those settings wrong can exceed the ISP available bandwidth. The world unfortunately stopped being simple some time ago :-) > >>> Also there might be some preference at user space, at which stage of > >>> the pipeline to apply some controls. This is where the subdev API > >>> helps, and plain video node API does not. > >> > >> Again, this is for specific usecases. On such cases, what is expected is > >> that the more generic control will be exported via V4L2 API. > >> > > Thus it's a bit hard to imagine that we could do something like > > "optionally not to inherit controls" as the subdev/MC API is > > optional. > > > > :) > > This was actually implemented. There are some cases at ivtv/cx18 > driver where both the bridge and a subdev provides the same control > (audio volume, for example). The idea is to allow the bridge driver > to touch at the subdev control without exposing it to userspace, > since the desire was that the bridge driver itself would expose such > control, using a logic that combines changing the subdev and the > bridge registers for volume. > >>> > >>> This seem like hard coding a policy in the driver;) Then there is no > >>> way (it might not be worth the effort though) to play with volume > >>> level at both devices, e.g. to obtain optimal S/N ratio. > >> > >> In general, playing with just one control is enough. Andy had a > >> different opinion when this issue were discussed, and he thinks that > >> playing with both is better. At the end, this is a developers decision, > >> depending on how much information (and bug reports) he had. > > > > ivtv/cx18 is a completely different use case, where hardware > > configurations are kno
[media-ctl][PATCH] libmediactl: engage udev to get devname
Signed-off-by: Andy Shevchenko
---
configure.in| 10
src/Makefile.am |2 +
src/media.c | 66 ++
3 files changed, 44 insertions(+), 34 deletions(-)
diff --git a/configure.in b/configure.in
index fd4c70c..63432ba 100644
--- a/configure.in
+++ b/configure.in
@@ -12,6 +12,16 @@ AC_PROG_CC
AC_PROG_LIBTOOL
# Checks for libraries.
+PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)
+
+if test x$have_libudev = xyes; then
+LIBUDEV_CFLAGS="$lbudev_CFLAGS"
+LIBUDEV_LIBS="$libudev_LIBS"
+AC_SUBST(LIBUDEV_CFLAGS)
+AC_SUBST(LIBUDEV_LIBS)
+else
+AC_MSG_ERROR([libudev is required])
+fi
# Kernel headers path.
AC_ARG_WITH(kernel-headers,
diff --git a/src/Makefile.am b/src/Makefile.am
index 267ea83..52628d2 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -5,6 +5,8 @@ mediactl_includedir=$(includedir)/mediactl
mediactl_include_HEADERS = media.h subdev.h
bin_PROGRAMS = media-ctl
+media_ctl_CFLAGS = $(LIBUDEV_CFLAGS)
+media_ctl_LDFLAGS = $(LIBUDEV_LIBS)
media_ctl_SOURCES = main.c options.c options.h tools.h
media_ctl_LDADD = libmediactl.la libv4l2subdev.la
diff --git a/src/media.c b/src/media.c
index e3cab86..000d750 100644
--- a/src/media.c
+++ b/src/media.c
@@ -31,6 +31,8 @@
#include
#include
+#include
+
#include "media.h"
#include "tools.h"
@@ -247,15 +249,20 @@ static int media_enum_links(struct media_device *media)
static int media_enum_entities(struct media_device *media)
{
+ struct udev *udev;
+ dev_t devnum;
+ struct udev_device *device;
struct media_entity *entity;
- struct stat devstat;
unsigned int size;
- char devname[32];
- char sysname[32];
- char target[1024];
- char *p;
+ const char *p;
__u32 id;
- int ret;
+ int ret = 0;
+
+ udev = udev_new();
+ if (udev == NULL) {
+ printf("unable to allocate memory for context\n");
+ return -ENOMEM;
+ }
for (id = 0; ; id = entity->info.id) {
size = (media->entities_count + 1) * sizeof(*media->entities);
@@ -268,9 +275,9 @@ static int media_enum_entities(struct media_device *media)
ret = ioctl(media->fd, MEDIA_IOC_ENUM_ENTITIES, &entity->info);
if (ret < 0) {
- if (errno == EINVAL)
- break;
- return -errno;
+ if (errno != EINVAL)
+ ret = -errno;
+ break;
}
/* Number of links (for outbound links) plus number of pads (for
@@ -281,8 +288,10 @@ static int media_enum_entities(struct media_device *media)
entity->pads = malloc(entity->info.pads *
sizeof(*entity->pads));
entity->links = malloc(entity->max_links *
sizeof(*entity->links));
- if (entity->pads == NULL || entity->links == NULL)
- return -ENOMEM;
+ if (entity->pads == NULL || entity->links == NULL) {
+ ret = -ENOMEM;
+ break;
+ }
media->entities_count++;
@@ -291,32 +300,21 @@ static int media_enum_entities(struct media_device *media)
media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
continue;
- sprintf(sysname, "/sys/dev/char/%u:%u", entity->info.v4l.major,
- entity->info.v4l.minor);
- ret = readlink(sysname, target, sizeof(target));
- if (ret < 0)
- continue;
-
- target[ret] = '\0';
- p = strrchr(target, '/');
- if (p == NULL)
- continue;
-
- sprintf(devname, "/dev/%s", p + 1);
- ret = stat(devname, &devstat);
- if (ret < 0)
- continue;
+ devnum = makedev(entity->info.v4l.major,
entity->info.v4l.minor);
+ printf("looking up device: %u:%u\n", major(devnum),
minor(devnum));
+ device = udev_device_new_from_devnum(udev, 'c', devnum);
+ if (device) {
+ p = udev_device_get_devnode(device);
+ if (p)
+ snprintf(entity->devname,
sizeof(entity->devname),
+"%s", p);
+ }
- /* Sanity check: udev might have reordered the device nodes.
-* Make sure the major/minor match. We should really use
-* libudev.
-*/
- if (major(devstat.st_rdev) == entity->info.v4l.major &&
- minor(devstat.st_rdev) == entity->info.v4l.minor)
- strcpy(entity->devname, devname);
+ udev_device_unref(device);
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Monday, August 15, 2011 13:28:23 Guennadi Liakhovetski wrote:
> Hi Hans
>
> On Mon, 8 Aug 2011, Hans Verkuil wrote:
>
> > Hi Guennadi!
> >
> > On Friday, August 05, 2011 09:47:13 Guennadi Liakhovetski wrote:
> > > A possibility to preallocate and initialise buffers of different sizes
> > > in V4L2 is required for an efficient implementation of asnapshot mode.
> > > This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
> > > VIDIOC_PREPARE_BUF and defines respective data structures.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > >
> > > v4:
> > >
> > > 1. CREATE_BUFS now takes an array of plane sizes and a fourcc code in its
> > >argument, instead of a frame format specification, including
> > >documentation update
> > > 2. documentation improvements, as suggested by Hans
> > > 3. increased reserved fields to 18, as suggested by Sakari
> > >
> > > Documentation/DocBook/media/v4l/io.xml | 17 ++
> > > Documentation/DocBook/media/v4l/v4l2.xml |2 +
> > > .../DocBook/media/v4l/vidioc-create-bufs.xml | 161
> >
> > > .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96
> > > drivers/media/video/v4l2-compat-ioctl32.c |6 +
> > > drivers/media/video/v4l2-ioctl.c | 26 +++
> > > include/linux/videodev2.h | 18 +++
> > > include/media/v4l2-ioctl.h |2 +
> > > 8 files changed, 328 insertions(+), 0 deletions(-)
> > > create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
> > > create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
> > >
> >
> >
> >
> > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > index fca24cc..3cd0cb3 100644
> > > --- a/include/linux/videodev2.h
> > > +++ b/include/linux/videodev2.h
> > > @@ -653,6 +653,9 @@ struct v4l2_buffer {
> > > #define V4L2_BUF_FLAG_ERROR 0x0040
> > > #define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
> > > #define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
> > > +/* Cache handling flags */
> > > +#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0400
> > > +#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
> > >
> > > /*
> > > * O V E R L A Y P R E V I E W
> > > @@ -2092,6 +2095,18 @@ struct v4l2_dbg_chip_ident {
> > > __u32 revision;/* chip revision, chip specific */
> > > } __attribute__ ((packed));
> > >
> > > +/* VIDIOC_CREATE_BUFS */
> > > +struct v4l2_create_buffers {
> > > + __u32 index; /* output: buffers index...index + count - 1 have been
> > created */
> > > + __u32 count;
> > > + __u32 type;
> > > + __u32 memory;
> > > + __u32 fourcc;
> > > + __u32 num_planes;
> > > + __u32 sizes[VIDEO_MAX_PLANES];
> > > + __u32 reserved[18];
> > > +};
> >
> > I know you are going to hate me for this,
>
> hm, I'll consider this possibility;-)
>
> > but I've changed my mind: I think
> > this should use a struct v4l2_format after all.
> >
> > This change of heart came out of discussions during the V4L2 brainstorm
> > meeting last week. The only way to be sure the buffers are allocated
> > optimally
> > is if the driver has all the information. The easiest way to do that is by
> > passing struct v4l2_format. This is also consistent with REQBUFS since that
> > uses the information from the currently selected format (i.e. what you get
> > back from VIDIOC_G_FMT).
> >
> > There can be subtle behaviors such as allocating from different memory back
> > based on the fourcc and the size of the image.
> >
> > One reason why I liked passing sizes directly is that it allows the caller
> > to
> > ask for more memory than is strictly necessary.
> >
> > However, while brainstorming last week the suggestion was made that there
> > is
> > no reason why the user can't set the sizeimage field in
> > v4l2_pix_format(_mplane) to something higher. The S/TRY_FMT spec explicitly
> > mentions that the sizeimage field is set by the driver, but for the new
> > CREATEBUFS ioctl no such limitation has to be placed. The only thing
> > necessary
> > is to ensure that sizeimage is not too small (and you probably want some
> > sanity check against crazy values as well).
>
> Centrally in videobuf2 or in each driver?
The 'too small' check can only be done in the driver since the driver has to
calculate the size based on the format. The 'is crazy value' check can be done
centrally. But note the discussion on what constitutes 'crazy'.
> > This way the decision on how to allocate memory is the same between REQBUFS
> > and CREATEBUFS (i.e. both use v4l2_format information), but there is no
> > need
> > for a union as we had in the initial proposal since apps can set the
> > sizeimage
> > to something larger than strictly necessary (or just leave it to 0 to get
> > the
> > smallest size).
>
> There was no union in previous
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Hans
On Mon, 8 Aug 2011, Hans Verkuil wrote:
> Hi Guennadi!
>
> On Friday, August 05, 2011 09:47:13 Guennadi Liakhovetski wrote:
> > A possibility to preallocate and initialise buffers of different sizes
> > in V4L2 is required for an efficient implementation of asnapshot mode.
> > This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
> > VIDIOC_PREPARE_BUF and defines respective data structures.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> >
> > v4:
> >
> > 1. CREATE_BUFS now takes an array of plane sizes and a fourcc code in its
> >argument, instead of a frame format specification, including
> >documentation update
> > 2. documentation improvements, as suggested by Hans
> > 3. increased reserved fields to 18, as suggested by Sakari
> >
> > Documentation/DocBook/media/v4l/io.xml | 17 ++
> > Documentation/DocBook/media/v4l/v4l2.xml |2 +
> > .../DocBook/media/v4l/vidioc-create-bufs.xml | 161
>
> > .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96
> > drivers/media/video/v4l2-compat-ioctl32.c |6 +
> > drivers/media/video/v4l2-ioctl.c | 26 +++
> > include/linux/videodev2.h | 18 +++
> > include/media/v4l2-ioctl.h |2 +
> > 8 files changed, 328 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
> > create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
> >
>
>
>
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index fca24cc..3cd0cb3 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -653,6 +653,9 @@ struct v4l2_buffer {
> > #define V4L2_BUF_FLAG_ERROR0x0040
> > #define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
> > #define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
> > +/* Cache handling flags */
> > +#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0400
> > +#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
> >
> > /*
> > * O V E R L A Y P R E V I E W
> > @@ -2092,6 +2095,18 @@ struct v4l2_dbg_chip_ident {
> > __u32 revision;/* chip revision, chip specific */
> > } __attribute__ ((packed));
> >
> > +/* VIDIOC_CREATE_BUFS */
> > +struct v4l2_create_buffers {
> > + __u32 index; /* output: buffers index...index + count - 1 have been
> created */
> > + __u32 count;
> > + __u32 type;
> > + __u32 memory;
> > + __u32 fourcc;
> > + __u32 num_planes;
> > + __u32 sizes[VIDEO_MAX_PLANES];
> > + __u32 reserved[18];
> > +};
>
> I know you are going to hate me for this,
hm, I'll consider this possibility;-)
> but I've changed my mind: I think
> this should use a struct v4l2_format after all.
>
> This change of heart came out of discussions during the V4L2 brainstorm
> meeting last week. The only way to be sure the buffers are allocated
> optimally
> is if the driver has all the information. The easiest way to do that is by
> passing struct v4l2_format. This is also consistent with REQBUFS since that
> uses the information from the currently selected format (i.e. what you get
> back from VIDIOC_G_FMT).
>
> There can be subtle behaviors such as allocating from different memory back
> based on the fourcc and the size of the image.
>
> One reason why I liked passing sizes directly is that it allows the caller to
> ask for more memory than is strictly necessary.
>
> However, while brainstorming last week the suggestion was made that there is
> no reason why the user can't set the sizeimage field in
> v4l2_pix_format(_mplane) to something higher. The S/TRY_FMT spec explicitly
> mentions that the sizeimage field is set by the driver, but for the new
> CREATEBUFS ioctl no such limitation has to be placed. The only thing
> necessary
> is to ensure that sizeimage is not too small (and you probably want some
> sanity check against crazy values as well).
Centrally in videobuf2 or in each driver?
> This way the decision on how to allocate memory is the same between REQBUFS
> and CREATEBUFS (i.e. both use v4l2_format information), but there is no need
> for a union as we had in the initial proposal since apps can set the
> sizeimage
> to something larger than strictly necessary (or just leave it to 0 to get the
> smallest size).
There was no union in previous versions of the patch. You mean, we don't
need the .size member?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Smart card reader support for Anysee DVB devices
On 08/15/2011 02:51 AM, Antti Palosaari wrote: > Biggest problem I see whole thing is poor application support. OpenCT is > rather legacy but there is no good alternative. All this kind of serial > drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. Antti -- http://palosaari.fi/ -- 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: Structure of DiSEqC Command
On Thu, Aug 11, 2011 at 2:21 AM, DUBOST Brice wrote: > 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 > Thanks for the response. It really helped :) -- Nima Mohammadi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-apps: update DVB-T intial tuning files for Finland (fi-*)
On 08/15/2011 12:56 PM, Hein Rigolo wrote: > On Mon, Aug 15, 2011 at 2:38 AM, Antti Palosaari wrote: >> Updates all Finnish channels as today. >> >> Antti > > Do we still need to have separate initial tuning files per region in finland? > > For France it was decided that the auto-With167kHzOffsets file would > be enough to find all possible DVB-T transponders in France. It was > suggested to create a fr-All that would be symlinked to the > auto-With167kHzOffsets file, but that was not implemented yet (as far > as I can see from the dvb-apps repository) > > Can this approach also work for Finland? It was spoken ages for creation of EU-All, Taiwan-All, UK-All etc. but I don't remember which have been problem. For example many Windows channels scanner have such files. Finland uses standard EU channels, channels under 20 are VHF 7 MHz and channels over 20 are UHF 8 MHz. Just same used almost everywhere in EU. Antti -- http://palosaari.fi/ -- 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: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?
Lawrence Rust wrote: >On Sun, 2011-08-14 at 17:50 +0200, Harald Gustafsson wrote: >> Thanks for sharing your experience. >> >[snip] >> > Be warned that if you run a 2.6.38 or later kernel then the IR RC >won't >> > work because of significant changes to the RC architecture that TBS >> > don't like (see >http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=929 and >> > http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=110&start=90#p2693 >) >> >> In the links you refer to the driver author (at least he seems to be >> the author) states that he has not upgraded to the latest IR code due >> to compatibility issues between the CX23885 and IR. > >The TBS cards use the same cx23885 device that the Hauppauge HVR 1250 & >1850 use, both of which support RC input. The problem, as I understand >it, is that in some modes the cx23885 can produce an interrupt storm. > >Given that the current v4l RC architecture is unlikely to change >significantly in the near future then instead of bleating, perhaps TBS >should contribute a fix. However, given that to date all of TBS's code >has been kept private then that's unlikely. So the TBS Linux drivers >are likely to become increasingly incompatible with current Linux >kernels. > >I have a need to use my 6981 card so I'm developing my own fix for the >RC problem. I'll post this to linuxmedia when I'm happy it's sound. > >Incidentally, the latest TBS 6981 driver OOPS with linux 2.6.39 even >though their release note says "Ensure compatibility with latest >ArchLinux (with kernel 2.6.39.2-1)". This is due to a change in an i2c >driver structure in 2.6.39 and is a direct consequence of TBS shipping >object modules built with old kernel headers. > >Be warned, the h/w is sound but the software & support suck. > >-- >Lawrence > > >-- >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 BTW, if it helps you develop a fix, the CX23885 IR unit is nearly identical to the IR unit and register set documented in the publicly available CX25840 datasheet. The CX23888 IR unit is also very similar, but it is not I2C connected and has a few register differences. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?
Lawrence Rust wrote: >On Sun, 2011-08-14 at 17:50 +0200, Harald Gustafsson wrote: >> Thanks for sharing your experience. >> >[snip] >> > Be warned that if you run a 2.6.38 or later kernel then the IR RC >won't >> > work because of significant changes to the RC architecture that TBS >> > don't like (see >http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=929 and >> > http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=110&start=90#p2693 >) >> >> In the links you refer to the driver author (at least he seems to be >> the author) states that he has not upgraded to the latest IR code due >> to compatibility issues between the CX23885 and IR. > >The TBS cards use the same cx23885 device that the Hauppauge HVR 1250 & >1850 use, both of which support RC input. The problem, as I understand >it, is that in some modes the cx23885 can produce an interrupt storm. > >Given that the current v4l RC architecture is unlikely to change >significantly in the near future then instead of bleating, perhaps TBS >should contribute a fix. However, given that to date all of TBS's code >has been kept private then that's unlikely. So the TBS Linux drivers >are likely to become increasingly incompatible with current Linux >kernels. > >I have a need to use my 6981 card so I'm developing my own fix for the >RC problem. I'll post this to linuxmedia when I'm happy it's sound. > >Incidentally, the latest TBS 6981 driver OOPS with linux 2.6.39 even >though their release note says "Ensure compatibility with latest >ArchLinux (with kernel 2.6.39.2-1)". This is due to a change in an i2c >driver structure in 2.6.39 and is a direct consequence of TBS shipping >object modules built with old kernel headers. > >Be warned, the h/w is sound but the software & support suck. > >-- >Lawrence > > >-- >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 One of the bigger problems with the cx23885 driver and hardware was that things don't appear to work well with MSI enabled in the driver. Hack your version of the driver to make sure MSI is not enabled for CX2388[578] chips. As far as the unclearable IR interrupt with MSI disabled, I've only seen that with the CX23885 on nonHauppauge cards; the CX23888 seems to be ok. I'm sure the problem on nonHauppauge cards is simply me no knowing for sure how some of the pins on the CX23885 were wired up. -Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-apps: update DVB-T intial tuning files for Finland (fi-*)
On Mon, Aug 15, 2011 at 2:38 AM, Antti Palosaari wrote: > Updates all Finnish channels as today. > > Antti Do we still need to have separate initial tuning files per region in finland? For France it was decided that the auto-With167kHzOffsets file would be enough to find all possible DVB-T transponders in France. It was suggested to create a fr-All that would be symlinked to the auto-With167kHzOffsets file, but that was not implemented yet (as far as I can see from the dvb-apps repository) Can this approach also work for Finland? Hein -- 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: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?
On Sun, 2011-08-14 at 17:50 +0200, Harald Gustafsson wrote: > Thanks for sharing your experience. > [snip] > > Be warned that if you run a 2.6.38 or later kernel then the IR RC won't > > work because of significant changes to the RC architecture that TBS > > don't like (see http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=929 and > > http://www.tbsdtv.com/forum/viewtopic.php?f=22&t=110&start=90#p2693 ) > > In the links you refer to the driver author (at least he seems to be > the author) states that he has not upgraded to the latest IR code due > to compatibility issues between the CX23885 and IR. The TBS cards use the same cx23885 device that the Hauppauge HVR 1250 & 1850 use, both of which support RC input. The problem, as I understand it, is that in some modes the cx23885 can produce an interrupt storm. Given that the current v4l RC architecture is unlikely to change significantly in the near future then instead of bleating, perhaps TBS should contribute a fix. However, given that to date all of TBS's code has been kept private then that's unlikely. So the TBS Linux drivers are likely to become increasingly incompatible with current Linux kernels. I have a need to use my 6981 card so I'm developing my own fix for the RC problem. I'll post this to linuxmedia when I'm happy it's sound. Incidentally, the latest TBS 6981 driver OOPS with linux 2.6.39 even though their release note says "Ensure compatibility with latest ArchLinux (with kernel 2.6.39.2-1)". This is due to a change in an i2c driver structure in 2.6.39 and is a direct consequence of TBS shipping object modules built with old kernel headers. Be warned, the h/w is sound but the software & support suck. -- Lawrence -- 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: PCTV 290e - assorted problems
--- On Mon, 15/8/11, Steve Kerrison wrote: > It depends on whether the problem is a weak signal or a too strong > signal. I suspect that the HD signal is too weak where I am, because I am in the transmitter's "green area". So it's possible that I'll have to wait until April before getting a decent HD service. Hmph! Well, at least I'll have time to look into that locking bug... The em28xx_dvb module's clean-up code might be a good place to start, if unloading this module "fixes" things. Cheers, Chris -- 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: PCTV 290e - assorted problems
Hi Chris, Take a look at this breakdown of muxes on the crystal palace transmitter: http://www.ukfree.tv/txdetail.php?a=TQ339712 You'll see mixed power levels and FFT sizes. I have the same thing (albeit with a larger range of power levels) here in Mendip and as a result its very difficult to get certain muxes. You could try a variable attenuator to see if you can trim things a bit to make the tuner/frontend happier getting a lock on all the muxes. It depends on whether the problem is a weak signal or a too strong signal. Of course it might be something else altogether, but this sort of thing is precisely the kind of rubbish we have to deal with during the UK digital switchover. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Sun, 2011-08-14 at 16:56 -0700, Chris Rankin wrote: > --- On Mon, 15/8/11, Antti Palosaari wrote: > > T 55400 8MHz + auto auto auto etc. > > is enough. > > Hmm, not here it isn't: > > $ scandvb -u -vvv uk-CrystalPalace > scanning uk-CrystalPalace > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder 55400 0 9 9 6 2 4 4 > >>> tune to: > >>> 55400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > WARNING: >>> tuning failed!!! > >>> tune to: > >>> 55400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO > >>> (tuning failed) > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x00 > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > >>> tuning status == 0x0f > WARNING: >>> tuning failed!!! > ERROR: initial tuning failed > dumping lists (0 services) > Done. > > Although it was working (briefly) on Saturday morning. > > > Have you tried it on Windows? > > No, because I don't own a Windows machine. > > Cheers, > Chris > > -- > 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: PCTV 290e - assorted problems
That is most likely the em28xx locking bug. It'll happen when you plug a second em28xx device in, or plug one in for a second time. The steps you've shown include that process. Try doing `rmmod em28xx-dvb` before re-plugging the device. If that 'cures' it, you're a victim of the same problem. I'm not overtly familiar with the interactions of em28xx with the rest of the kernel & userland and why the bug manifests, but it is on my list of things to (try to) fix, although I'm hoping somebody more able than me figures it out first :) Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Sun, 2011-08-14 at 17:05 -0700, Chris Rankin wrote: > >> INFO: task khubd:1100 blocked for more than 120 seconds. > >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > >> khubd D 0 1100 2 0x > >> 8801a694e930 0046 8801a691ffd8 8162b020 > >> 00010280 8801a691ffd8 4000 00010280 > >> 8801a691ffd8 8801a694e930 00010280 8801a691e000 > >> Call Trace: > >> [] ? apic_timer_interrupt+0xe/0x20 > >> [] ? memscan+0x3/0x18 > >> [] ? __mutex_lock_slowpath+0x15c/0x295 > >> [] ? mutex_lock+0x9/0x18 > >> [] ? dvb_init+0x99/0xcc8 [em28xx_dvb] > >> [] ? em28xx_init_extension+0x35/0x53 [em28xx] > >> [] ? em28xx_usb_probe+0x827/0x8df [em28xx] > > > > I think it crashes before it even goes to PCTV 290e specific part. I > > suspect it is bug somewhere in em28xx driver. > > The scenario that triggers this crash is: > a) Plug the 290e in, and allow it to initialise correctly > b) Use xine to watch any DVB-T channel successfully > c) Try switching to previously-tuned DVB-T2 channel; this makes xine hang. > d) Kill xine > e) Physically replug adapter > > em28xx re-initialisation will now fail: > > ... > tda18271: performing RF tracking filter calibration > tda18271: RF tracking filter calibration complete > usb 4-1: USB disconnect, device number 3 > em28xx #0: disconnecting em28xx #0 video > em28xx #0: V4L2 device video1 deregistered > tda18271 7-0060: destroying instance > usb 4-1: new high speed USB device number 4 using ehci_hcd > em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, > class 0) > em28xx #0: chip ID is em28174 > em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) > Registered IR keymap rc-pinnacle-pctv-hd > input: em28xx IR (em28xx #0) as > /devices/pci:00/:00:1d.7/usb4/4-1/rc/rc1/input8 > rc1: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb4/4-1/rc/rc1 > em28xx #0: v4l2 driver version 0.1.2 > em28xx #0: V4L2 video device registered as video1 > INFO: task khubd:1217 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > khubd D 0 1217 2 0x > 8801a7081ef0 0046 8801a69a9fd8 8162b020 > 00010280 8801a69a9fd8 4000 00010280 > 8801a69a9fd8 8801a7081ef0 00010280 8801a69a8000 > Call Trace: > [] ? apic_timer_interrupt+0xe/0x20 > [] ? memscan+0x3/0x18 > [] ? __mutex_lock_slowpath+0x15c/0x295 > [] ? mutex_lock+0x9/0x18 > [] ? dvb_init+0x99/0xcc8 [em28xx_dvb] > [] ? em28xx_init_extension+0x35/0x53 [em28xx] > [] ? em28xx_usb_probe+0x827/0x8df [em28xx] > > Cheers, > Chris > > -- > 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
16APSK / 32APSK / Constellation diagrams
Hi I see the constellation diagrams in the wiki for the 16APSK / 32APSK support on the STV0900A based cards. How were these constellation diagrams produced? Is there any source kicking around for this? I would like to be able to give a frequency and symbolrate, and get a similar constellation diagram back (in quasi realtime?), obviously using a STV0900A based card. I know there's a windows program that does this (crazyscan) but it would be nice to be able to do it in linux. I don't expect any polished programs, but any source that shows how to do this (i.e. get raw I and Q data from the card) would be very handy. Thanks, Andrew -- 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
