Re: [PATCH] DTV2000 H Plus issues
On Sun, Mar 14, 2010 at 1:58 PM, istva...@mailbox.hu wrote: > On 02/18/2010 01:11 AM, Devin Heitmueller wrote: > >> Yeah, my plan at this point was to submit a PULL request once I felt >> the driver is stable > > For those particular cards that my patch adds support for, it seems to > be stable, and I have been using it for months. Perhaps stability issues > in xc4000.c are specific to the PCTV 340e and its dib0700 I2C problems ? Different people have different standards of quality. For example, I've done essentially no analysis into the tuning performance of the current driver - validating different frequency ranges and modulation types or bandwidths. I've done no testing of tuning lock time, minimal application validation, and no effort toward making sure the power management works. Sure, I can just throw the driver upstream as-is, but I've been hesitant to merge something with questionable quality, as it reflects poorly on my reputation. Right now it's in a development tree because it's what I would consider "alpha quality", where only advanced users will install it and they know to "proceed at your own risk". And none of the above is related to the problem with the dib0700 i2c master. All that said, the situation hasn't been helped by the fact that I'm working on five different projects currently (as102, drx-d, xc4000, em28xx, and now ngene), nor the fact that I'm also the maintainer for a variety of other tuner products (and the significant support burden that creates). Bear in mind that I am aware of the frustration that when someone has patches and cannot get the maintainer to find the time to review/comment/merge. I've been in that situation myself more than once. I'll try to go through my tree and see if I can get something upstream this week which you could build on. Once that is done, you will need to break up your huge patch into a series of small incremental patches (with proper descriptions for the changes), since there is no way a single patch is going to be accepted upstream which has all of your changes. Also, you should *not* be submitting board profiles that are completely unvalidated. I saw your email on Feb 19th, where you dumped out a list of tuners that you think might *possibly* work. You should only submit board definitions for devices that either you have tested or you have gotten a user to test. It is far worse to have broken code in there (creating the illusion of a product being supported), then for there to be no support at all. When users complain about a particular board not working, you can work with them to get it supported. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.35] Small miscellaneous fixes
Hans Verkuil wrote: > The following changes since commit daf9fe2ee9a203c4fc555cfe5c5f3d9f660e743c: > Linus Torvalds (1): > Merge branch 'for-linus' of git://git.kernel.org/.../sameo/mfd-2.6 > > are available in the git repository at: > > ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc-fixes > > Hans Verkuil (3): > videobuf-core: fix spelling mistake in debug message. > v4l doc: fix font of field name > v4l2: sort chip IDs in v4l2-chip-ident.h > > Michael Hunold (1): > saa7146: fix up bytesperline if it is an impossible value > > Documentation/DocBook/v4l/vidioc-reqbufs.xml |2 +- > drivers/media/common/saa7146_video.c |8 +- > drivers/media/video/videobuf-core.c |2 +- > include/media/v4l2-chip-ident.h | 120 + > 4 files changed, 69 insertions(+), 63 deletions(-) > Hans, Didn't work. You should add your patches after the "master" branch of my tree, and not after upstream "master". So, if you're sending me patches against the development tree, you should use v4l-dvb.git currently, upstream 2.6.33 + V4L/DVB). If you're sending me fixes patches, please use fixes.git (currently, 2.6.34-rc1). Cheers, Mauro. --- $ gitimport ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc-fixes git checkout -b misc-fixes_tmp work Switched to a new branch 'misc-fixes_tmp' git pull ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc-fixes remote: Counting objects: 70234, done. remote: Compressing objects: 100% (12013/12013), done. remote: Total 57195 (delta 47167), reused 53957 (delta 44076) Receiving objects: 100% (57195/57195), 14.56 MiB | 53 KiB/s, done. Resolving deltas: 100% (47167/47167), completed with 6840 local objects. >From ssh://linuxtv.org/git/hverkuil/v4l-dvb * branchmisc-fixes -> FETCH_HEAD warning: too many files (created: 900 deleted: 332), skipping inexact rename detection CONFLICT (content): Merge conflict in Documentation/DocBook/v4l/vidioc-reqbufs.xml CONFLICT (content): Merge conflict in drivers/media/IR/ir-keymaps.c CONFLICT (content): Merge conflict in drivers/media/IR/ir-keytable.c CONFLICT (add/add): Merge conflict in drivers/media/IR/ir-sysfs.c CONFLICT (content): Merge conflict in drivers/media/dvb/dm1105/dm1105.c CONFLICT (content): Merge conflict in drivers/media/dvb/dvb-usb/af9015.c CONFLICT (add/add): Merge conflict in drivers/media/dvb/dvb-usb/az6027.c CONFLICT (content): Merge conflict in drivers/media/dvb/dvb-usb/dvb-usb-ids.h CONFLICT (content): Merge conflict in drivers/media/dvb/frontends/stv090x.c CONFLICT (content): Merge conflict in drivers/media/dvb/frontends/stv6110x.c CONFLICT (content): Merge conflict in drivers/media/dvb/mantis/mantis_input.c CONFLICT (add/add): Merge conflict in drivers/media/dvb/ngene/ngene-core.c CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/budget-ci.c CONFLICT (content): Merge conflict in drivers/media/video/bt8xx/bttv-input.c CONFLICT (content): Merge conflict in drivers/media/video/cx231xx/cx231xx-input.c CONFLICT (content): Merge conflict in drivers/media/video/cx23885/cx23885-input.c CONFLICT (content): Merge conflict in drivers/media/video/cx88/cx88-dvb.c CONFLICT (content): Merge conflict in drivers/media/video/cx88/cx88-input.c CONFLICT (add/add): Merge conflict in drivers/media/video/davinci/isif_regs.h CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx-cards.c CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx-dvb.c CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx-input.c CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/cpia1.c CONFLICT (content): Merge conflict in drivers/media/video/gspca/ov534.c CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/sn9c2028.c CONFLICT (content): Merge conflict in drivers/media/video/ir-kbd-i2c.c CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-input.c CONFLICT (add/add): Merge conflict in drivers/media/video/tlg2300/pd-dvb.c CONFLICT (add/add): Merge conflict in drivers/media/video/tlg2300/pd-main.c CONFLICT (add/add): Merge conflict in drivers/media/video/tlg2300/pd-radio.c CONFLICT (add/add): Merge conflict in drivers/media/video/tlg2300/pd-video.c CONFLICT (content): Merge conflict in drivers/mfd/Kconfig CONFLICT (content): Merge conflict in drivers/mfd/Makefile CONFLICT (content): Merge conflict in include/media/ir-core.h CONFLICT (content): Merge conflict in include/media/v4l2-chip-ident.h Recorded preimage for 'Documentation/DocBook/v4l/vidioc-reqbufs.xml' Recorded preimage for 'drivers/media/IR/ir-keymaps.c' Recorded preimage for 'drivers/media/IR/ir-keytable.c' Recorded preimage for 'drivers/media/IR/ir-sysfs.c' Recorded preimage for 'drivers/media/dvb/dm1105/dm1105.c' Recorded preimage for 'drivers/media/dvb/dvb-usb/af9015.c' Recorded preimage for 'drivers/media/dvb/dvb-usb/az6027.c' Recorded preimage for 'drivers/media/dvb/dvb-usb/dvb-usb-ids.h' Record
Re: Excessive rc polling interval in dvb_usb_dib0700 causes interference with USB soundcard
On Sun, Mar 14, 2010 at 11:06 AM, Pedro Ribeiro wrote: > Hi Devin, > > after some through investigation I found that your patch solves the > continuous interference. > > However, I have a second problem. It is also interference but appears > to be quite random, by which I mean it is not at a fixed interval, > sometimes it happens past 10 seconds, other times past 30 seconds, > other times 2 to 5 seconds. > > One thing is sure - it only happens when I'm actually streaming from > the DVB adapter. If I just plug it in, there is no interference. But > when I start vdr (for example) the interference starts. > > The DVB adapter and the sound card are not sharing irq's or anything > like that, and there is no system freeze when the interference > happens. I also thought it was either my docking bay or power supply, > but definitely it isn't. > > Any idea what can this be? > > Thank you for your help, > Pedro Hello Pedro, Could you describe in more detail what you mean by "interference"? Do you mean that you get corrupted audio for short bursts? Or do you mean the audio is dropping out for periods of time? Can you elaborate on how long the problem occurs for, and how often it occurs? For example, do you get corrupted audio for 1 second at a time every ten or fifteen seconds? This is a USB audio device, correct? Are both devices on the same USB bus? Is there a USB hub involved? It's also possible that this is just a general latency problem - where the CPU becomes too busy, it does not service the sound card often enough and PCM data is being dropped. Have you tried running "top"? What does your CPU utilization look like when you are experiencing the problem? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx18: "missing audio" for analog recordings
On 03/02/10 07:40, Andy Walls wrote: Again, maybe dynamically allocating these work order objects from the kernel as needed, would be better from a small dynamically allocated pool for each card. I was concerned that the interrupt handler was taking to long at the time I implemented the things the way they are now. .. I haven't seen that particular issue again, with or without increasing the work orders, so hopefully it won't recur. But after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the "no audio" on analog recordings bug much more often. Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. The problem is still there. I have now spent a good many hours trying to isolate *when* it happens, and have narrowed it down to module initialization. Basically, if the audio is working after modprobe cx18, it then continues to work from recording to recording until the next reboot. If the audio is not working after modprobe, then simply doing rmmod/modprobe in a loop (until working audio is achieved) is enough to cure it. So for my Mythtv box here, I now have a script to check for missing audio and do the rmmod/modprobe. This is a good, effective workaround. http://rtr.ca/hvr1600/fix_hvr1600_audio.sh That's a link to my script. As for the actual underlying cause/bug, it's still not clear what is happening. But the problem is a LOT more prevalent (for me, and for two other people I know) with versions of the cx18 driver since spring 2009. My suspicion is that the firmware download for the APU is somehow being corrupted, and now that the driver downloads the firmware *twice* during init, it doubles the odds of said corruption. Just a theory, but it's the best fit so far. I think we have some nasty i2c issues somewhere in the kernel. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.34] sn9c20x patches
Brian Johnson wrote: > The following changes since commit 9178a7c062ff0c43e95d826419f9e9454c52ef15: > Mauro Carvalho Chehab (1): > V4L/DVB: Fix bad whitespacing > > are available in the git repository at: > > git://gitorious.org/v4l-dvb/v4l-dvb.git devel > > Brian Johnson (5): > gspca - sn9c20x: use gspca's input device handling > gspca - sn9c20x: Add support for camera LEDs > gspca - sn9c20x: Add upside down detection > gspca - sn9c20x: Add support for cameras using the MT9M112 sensor > gspca - sn9c20x: Fix bug with OV9655 code Hi Brian, It seems that you're signing the patches with my SOB instead of yours. Please review your procedures. You should add just your SOB at the patches, and let me add mine. After merged, you'll receive some emails from the server warning that the patches got merged. Then, after pulling/rebasing from my tree, you'll have the patches with both SOB's on your tree. Thanks, Mauro. > > Documentation/video4linux/gspca.txt |4 + > drivers/media/video/gspca/Kconfig |6 - > drivers/media/video/gspca/sn9c20x.c | 311 > +-- > 3 files changed, 155 insertions(+), 166 deletions(-) > > Brian Johnson > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.34] gspca development
Hi Jean, It seems that some of the patches are for 2.6.34 and some for 2.6.35 (changes of an existing driver in preparation for a new driver should be added during a merge window). Could you please break them into two separate pull requests? The patches for 2.6.34 will be added at the fixes.git tree, while the others will go to the v4l-dvb.git tree. Jean-Francois Moine wrote: > The following changes since commit > ac8b45fc29b7dc4837c9b541033b62305fdccb85: Max Thrun (1): > V4L/DVB: gspca - ov534: Update copyright info > > are available in the git repository at: > > git://linuxtv.org/jfrancois/gspca.git devel > > Erik Andrén (1): > gspca - stv06xx: Remove the 046d:08da from the stv06xx driver. OK for 2.6.34. > > Olivier Lorin (2): > gspca - gl860: Updates to prepare the new driver for MI2020 sensor. Better to delay to 2.6.35, since this changes the behavior of the driver. - General changes for all drivers because of new MI2020 sensor driver : - add the light source control - control value changes only applied after an end of image - replace msleep with duration less than 5 ms by a busy loop - Fix for an irrelevant OV9655 image resolution identifier name The better is to break it into 4 patches (one for each different logical change). In the case of this change: - replace msleep with duration less than 5 ms by a busy loop Keeping the cpu hold for 5 ms is not a good idea, except if you have a reason for doing that. Long delays will spend more power, and will keep cpu running during all the time the delay will happen. That's why mdelay() is used only in the cases where the delay timing is critical. In this case, you should write a separate patch with this change, clearly stating why this is needed. Also, if this change is needed just because mi2020 driver, you shouldn't be applying penalty to users with other sensors. > gspca - gl860: New driver for MI2020 sensor. Better to delay to 2.6.35, since this changes the behavior of the driver. > > Yong Zhang (1): > gspca - sn9c20x: Correct onstack wait_queue_head declaration. OK for 2.6.34. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tm6000: add new hybrid-stick
Stefan Ringel wrote: > Am 14.03.2010 19:26, schrieb Mauro Carvalho Chehab: >> Stefan Ringel wrote: >> >>> Mauro, >>> >>> you have accepted my patch, but it's not applied. >>> >> This patch were applied on my git tree on Mar, 11: >> >> commit 50e3fe3b336fb2936f05bb9af752ef933c8b74aa >> Author: Stefan Ringel >> AuthorDate: Wed Mar 10 14:57:57 2010 -0300 >> Commit: Mauro Carvalho Chehab >> CommitDate: Thu Mar 11 07:41:43 2010 -0300 >> >> V4L/DVB: tm6000: add new hybrid-stick >> >> That's why it were marked as applied. I have no idea when it were >> backported to -hg, or if it is still on Douglas queue. >> >> Cheers, >> Mauro >> > > that is the lastest entrys in weblog. And no patch can I see from me. > > v4l-dvb.git > > > > 3 days ago > Mauro Carvalho... > V4L/DVB: Fix bad whitespacing master > commit | commitdiff | tree > > > 4 days ago > Max Thrun > V4L/DVB: gspca - ov534: Update copyright info > commit | commitdiff | tree > > > 4 days ago > Mosalam Ebrahimi > V4L/DVB: gspca - ov534: Add Powerline Frequency control > commit | commitdiff | tree > > > 4 days ago > Antonio Ospite > V4L/DVB: gspca - ov534: Cosmetics: fix indentation... > commit | commitdiff | tree > > please check it! I forgot to push from my local tree to the servers. I'm updating them right now. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dual TT C-1501 on a single PCI riser
Hi, On Sun, Mar 14, 2010 at 05:14:33PM +0100, Martin van Es wrote: > ? Pin A11: additional 33 MHz PCI clock > ? Pin B10: additional PCI request signal (i.e., PREQ#2) > ? Pin B14: additional PCI Grant signal (i.e., GNT#2) > - > > I'm 100% sure the Tranquil riser does not support this suggestion > since the A11/B10 and B14 leads are not used on the riser. Your riser card doesn't need these signals thanks to the IT8209R. The drawback is that the cards will be granted less bus time when competing with on board PCI peripherals. > On the other hand, my guess would be that an ordinary > riser with arbiter and the correct wiring should do the trick. My > question is more or less the same as Udo's in the thread I posted: how > do I check if int 17 of the second card is correctly connected to int > A of the second slot and if not, where to start changing things? PCI slots have four interrupts, INTA, INTB, INTC, and INTC. Riser cards usually permute these for the second and following slots to avoid interrupt sharing. The BIOS has a built-in table that tells Linux for every slot which pin of the interrupt controller is connected to these four interrupt lines. So we need to make the second slot appear to the BIOS to be one where INTA is same interrupt as (probably) INTB of the first slot. Slots are addressed using the IDSEL line. Every slot has its own line. To reduce the number of signals (and to allow riser cards) the PCI standards suggests reusing the upper AD lines as IDSEL lines for the slots. So by changing the AD line connected to the IDSEL line of the second slot with the jumper on the riser card, the slot will get another number and thus another interrupt mapping. According to the ICH7 datasheet you should currently have selected AD24, as your card is 08.0 on the bus (strange... at that position should have been the intel ethernet controller..). Just subtract 16 from the AD number to get the slot number. Now try all of them until you find one where interrupts work. Avoid those already in use on the same bus as listed by "lspci -tv". Good luck! Daniel -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
On Sun, 14 Mar 2010 20:34:34 +0100, Daro wrote: > W dniu 14.03.2010 09:26, Jean Delvare pisze: > > It will be easier with the kernel you compiled yourself. First of all, > > download the patch from: > > http://patchwork.kernel.org/patch/75883/raw/ > > > > Then, move to the source directory of your 2.6.32.2 kernel and apply > > the patch: > > > > $ cd ~/src/linux-2.6.32 > > $ patch -p2< > > ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch > > > > Adjust the path in each command to match your own setup. Then just > > build and install the kernel: > > > > $ make > > $ sudo make modules_install > > $ sudo make install > > > > Or whatever method you use to install your self-compiled kernels. Then > > reboot to kernel 2.6.32.2 and test that the remote control works even > > when _not_ passing any card parameter to the driver. > > > > If you ever need to remove the patch, use: > > > > $ cd ~/src/linux-2.6.32 > > $ patch -p2 -R< > > ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch > > > > I hope my instructions are clear enough, if you have any problem, just > > ask. > > > > Thanks, > > > > Hi Jean! > > It works! > dmesg output is attached. Thanks for reporting! Mauro, you can pick my (second) patch now and apply it. > However I will have to go back to "generic" kernel as under my > "self-built" kernels fglrx driver stops working and I did not manage to > solve it :( > Or maybe you could give me a hint what to do with it? I can't help you with that, sorry, I don't use binary drivers. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Mar 14 19:00:23 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14436:1338e96c5a88 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: 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-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: 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-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The 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: [PATCH] tm6000: add new hybrid-stick
Am 14.03.2010 19:26, schrieb Mauro Carvalho Chehab: > Stefan Ringel wrote: > >> Mauro, >> >> you have accepted my patch, but it's not applied. >> > This patch were applied on my git tree on Mar, 11: > > commit 50e3fe3b336fb2936f05bb9af752ef933c8b74aa > Author: Stefan Ringel > AuthorDate: Wed Mar 10 14:57:57 2010 -0300 > Commit: Mauro Carvalho Chehab > CommitDate: Thu Mar 11 07:41:43 2010 -0300 > > V4L/DVB: tm6000: add new hybrid-stick > > That's why it were marked as applied. I have no idea when it were > backported to -hg, or if it is still on Douglas queue. > > Cheers, > Mauro > that is the lastest entrys in weblog. And no patch can I see from me. v4l-dvb.git 3 days ago Mauro Carvalho... V4L/DVB: Fix bad whitespacing master commit | commitdiff | tree 4 days ago Max Thrun V4L/DVB: gspca - ov534: Update copyright info commit | commitdiff | tree 4 days ago Mosalam Ebrahimi V4L/DVB: gspca - ov534: Add Powerline Frequency control commit | commitdiff | tree 4 days ago Antonio Ospite V4L/DVB: gspca - ov534: Cosmetics: fix indentation... commit | commitdiff | tree please check it! Cheers, Stefan -- Stefan Ringel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
W dniu 14.03.2010 09:26, Jean Delvare pisze: Hi Daro, On Sun, 14 Mar 2010 03:38:11 +0100, Daro wrote: Hi Jean, I am back and ready to go :) As I am not much experienced Linux user I would apprieciate some more details: I have few linux kernels installed; which one should I test or it does not matter? 2.6.31-14-generic 2.6.31-16-generic 2.6.31-17-generic 2.6.31-19-generic 2.6.31-20-generic and one I compiled myself 2.6.32.2 I assume that to proceed with a test I should patch the certain version of kernel and compile it or could it be done other way? It will be easier with the kernel you compiled yourself. First of all, download the patch from: http://patchwork.kernel.org/patch/75883/raw/ Then, move to the source directory of your 2.6.32.2 kernel and apply the patch: $ cd ~/src/linux-2.6.32 $ patch -p2< ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch Adjust the path in each command to match your own setup. Then just build and install the kernel: $ make $ sudo make modules_install $ sudo make install Or whatever method you use to install your self-compiled kernels. Then reboot to kernel 2.6.32.2 and test that the remote control works even when _not_ passing any card parameter to the driver. If you ever need to remove the patch, use: $ cd ~/src/linux-2.6.32 $ patch -p2 -R< ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch I hope my instructions are clear enough, if you have any problem, just ask. Thanks, Hi Jean! It works! dmesg output is attached. However I will have to go back to "generic" kernel as under my "self-built" kernels fglrx driver stops working and I did not manage to solve it :( Or maybe you could give me a hint what to do with it? Best regards Daro [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32.2 (r...@domowy) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) ) #2 SMP Sun Mar 14 14:11:25 CET 2010 [0.00] Command line: root=/dev/mapper/isw_bgccbabfgf_SYSTEM2 ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00096c00 (usable) [0.00] BIOS-e820: 00096c00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7ff8 (usable) [0.00] BIOS-e820: 7ff8 - 7ff8e000 (ACPI data) [0.00] BIOS-e820: 7ff8e000 - 7ffd (ACPI NVS) [0.00] BIOS-e820: 7ffd - 8000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff0 - 0001 (reserved) [0.00] DMI present. [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [0.00] e820 update range: - 0001 (usable) ==> (reserved) [0.00] last_pfn = 0x7ff80 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-D write-protect [0.00] E-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Scanning 0 areas for low memory corruption [0.00] modified physical RAM map: [0.00] modified: - 0001 (reserved) [0.00] modified: 0001 - 00096c00 (usable) [0.00] modified: 00096c00 - 000a (reserved) [0.00] modified: 000e4000 - 0010 (reserved) [0.00] modified: 0010 - 7ff8 (usable) [0.00] modified: 7ff8 - 7ff8e000 (ACPI data) [0.00] modified: 7ff8e000 - 7ffd (ACPI NVS) [0.00] modified: 7ffd - 8000 (reserved) [0.00] modified: fee0 - fee01000 (reserved) [0.00] modified: fff0 - 0001 (reserved) [0.00] initial memory mapped : 0 - 2000 [0.00] init_memory_mapping: -7ff8 [0.00] 00 - 007fe0 page 2M [0.00] 007fe0 - 007ff8 page 4k [0.00] kernel direct mapping tables up to 7ff8 @ 1-14000 [
Fwd: Leadtek WinFast PxPVR2200
added come cc -- Forwarded message -- From: Anca Emanuel Date: Sun, Mar 14, 2010 at 5:49 PM Subject: Leadtek WinFast PxPVR2200 To: linux-kernel , Steven Toth in the file drivers\media\video\cx23885\cx23885-cards.c there is: CX23885_BOARD_LEADTEK_WINFAST_PXTV1200 it is possible to add LeadTek WinFast PxPVR2200 to that file ? it uses the CONEXANT PCIe A/V Decoder CX23885-13Z and CONEXANT MPEG II A/V ENCODER CX23417-11Z -- 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] tm6000: add new hybrid-stick
Stefan Ringel wrote: > Mauro, > > you have accepted my patch, but it's not applied. This patch were applied on my git tree on Mar, 11: commit 50e3fe3b336fb2936f05bb9af752ef933c8b74aa Author: Stefan Ringel AuthorDate: Wed Mar 10 14:57:57 2010 -0300 Commit: Mauro Carvalho Chehab CommitDate: Thu Mar 11 07:41:43 2010 -0300 V4L/DVB: tm6000: add new hybrid-stick That's why it were marked as applied. I have no idea when it were backported to -hg, or if it is still on Douglas queue. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: ir: Add a link to associate /sys/class/ir/irrcv with the input device
Dmitry Torokhov wrote: > On Sat, Mar 13, 2010 at 05:59:34PM -0300, Mauro Carvalho Chehab wrote: >> It is representing it right: >> >> usb1/1-3 -> irrcv -> irrcv0 -> input7 -> event7 >> >> The only extra attribute there is the class name "irrcv", but this seems >> coherent with the other classes on this device (dvb, sound, power, >> video4linux). >> > > Ah, yes, I saw where you take input device's parent and use it as > irrcv's parent but missed the piece where you substitute original > input device's parent with irrcv. I bit sneaky to my taste but I guess > can be cleaned up later. Yes. I opted to do this little trick to avoid changing the interfaces on the other modules, and to minimize the needs when porting from input. We can later clean it if/when needed. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DTV2000 H Plus issues
On 02/18/2010 01:11 AM, Devin Heitmueller wrote: > Yeah, my plan at this point was to submit a PULL request once I felt > the driver is stable For those particular cards that my patch adds support for, it seems to be stable, and I have been using it for months. Perhaps stability issues in xc4000.c are specific to the PCTV 340e and its dib0700 I2C problems ? -- 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] DTV2000 H Plus issues
OK, so should I write a new xc4000.c/h from scratch and sign that off ? On 02/18/2010 01:08 AM, Mauro Carvalho Chehab wrote: > Devin Heitmueller wrote: >> On Wed, Feb 17, 2010 at 6:51 PM, Mauro Carvalho Chehab >> wrote: >>> Hi Istvan, >>> >>> istva...@mailbox.hu wrote: The attached new patches contain all the previous changes merged, and are against the latest v4l-dvb revision. >>> Please provide your Signed-off-by. This is a basic requirement for your >>> driver to be accepted. Please read: >>>http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches >>> >>> for instructions on how to submit a patch. >> >> Hi Mauro, >> >> I would hate to come across as a jerk here, but he cannot provide his >> SOB for this patch, as I wrote about 95% of the code here. It's >> derived from a tree I have been working on for the PCTV 340e: >> >> http://kernellabs.com/hg/~dheitmueller/pctv-340e-2/ >> >> I know that istvan wants to see the support merged, but he is going to >> have to wait a bit longer since he is not the author or maintainer of >> the driver in question. > > OK. Then, I need your SOB for the 95% of the code, and his SOB for the > remaining ;) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2_ctrl_get_name(): add missing control names, and make title for V4L2_CID_BG_COLOR consistent
v4l2_ctrl_get_name(): add missing control names, and make title for V4L2_CID_BG_COLOR consistent V4L2_CID_AUTOBRIGHTNESS was introduced with kernel 2.6.31 V4L2_CID_BAND_STOP_FILTER was introduced with kernel 2.6.32 Signed-off-by: Frank Schaefer diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-common.c index 36b5cb8..e679834 100644 --- a/drivers/media/video/v4l2-common.c +++ b/drivers/media/video/v4l2-common.c @@ -431,8 +431,10 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_CHROMA_AGC:return "Chroma AGC"; case V4L2_CID_COLOR_KILLER:return "Color Killer"; case V4L2_CID_COLORFX:return "Color Effects"; +case V4L2_CID_AUTOBRIGHTNESS:return "Brightness, Automatic"; +case V4L2_CID_BAND_STOP_FILTER:return "Band-Stop Filter"; case V4L2_CID_ROTATE:return "Rotate"; -case V4L2_CID_BG_COLOR:return "Background color"; +case V4L2_CID_BG_COLOR:return "Background Color"; /* MPEG controls */ case V4L2_CID_MPEG_CLASS: return "MPEG Encoder Controls"; -- 1.6.0.2 -- 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
0844-Staging-cx25821-fix-coding-style-issues-in-cx25821-a.patch
>From 9473816c446a6ca91905fc49a73732f70b5223b4 Mon Sep 17 00:00:00 2001
From: Olimpiu Pascariu
Date: Sun, 14 Mar 2010 17:44:37 +0200
Subject: [PATCH 844/844] Staging: cx25821: fix coding style issues in
cx25821-alsa.c
This is a patch to the cx25821-alsa.c file that fixes up errors and warnings
found by the checkpatch.pl tool
Signed-off-by: Olimpiu Pascariu
---
drivers/staging/cx25821/cx25821-alsa.c | 104 +---
1 files changed, 55 insertions(+), 49 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-alsa.c
b/drivers/staging/cx25821/cx25821-alsa.c
index e0eef12..bb297ca 100644
--- a/drivers/staging/cx25821/cx25821-alsa.c
+++ b/drivers/staging/cx25821/cx25821-alsa.c
@@ -28,7 +28,7 @@
#include
#include
-#include
+#include
#include
#include
#include
@@ -41,10 +41,10 @@
#define AUDIO_SRAM_CHANNEL SRAM_CH08
-#define dprintk(level,fmt, arg...) if (debug >= level) \
+#define dprintk(level, fmt, arg...)if (debug >= level) \
printk(KERN_INFO "%s/1: " fmt, chip->dev->name , ## arg)
-#define dprintk_core(level,fmt, arg...)if (debug >= level) \
+#define dprintk_core(level, fmt, arg...) if (debug >= level) \
printk(KERN_DEBUG "%s/1: " fmt, chip->dev->name , ## arg)
/
@@ -80,7 +80,6 @@ struct cx25821_audio_dev {
struct snd_pcm_substream *substream;
};
-typedef struct cx25821_audio_dev snd_cx25821_card_t;
/
@@ -89,7 +88,7 @@ typedef struct cx25821_audio_dev snd_cx25821_card_t;
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; /* ID for this card */
-static int enable[SNDRV_CARDS] = { 1,[1 ... (SNDRV_CARDS - 1)] = 1 };
+static int enable[SNDRV_CARDS] = { 1, [1 ... (SNDRV_CARDS - 1)] = 1 };
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable cx25821 soundcard. default enabled.");
@@ -104,7 +103,7 @@ MODULE_PARM_DESC(index, "Index value for cx25821 capture
interface(s).");
MODULE_DESCRIPTION("ALSA driver module for cx25821 based capture cards");
MODULE_AUTHOR("Hiep Huynh");
MODULE_LICENSE("GPL");
-MODULE_SUPPORTED_DEVICE("{{Conexant,25821}"); //"{{Conexant,23881},"
+MODULE_SUPPORTED_DEVICE("{{Conexant,25821}"); /* "{{Conexant,23881}," */
static unsigned int debug;
module_param(debug, int, 0644);
@@ -134,7 +133,7 @@ MODULE_PARM_DESC(debug, "enable debug messages");
* BOARD Specific: Sets audio DMA
*/
-static int _cx25821_start_audio_dma(snd_cx25821_card_t * chip)
+static int _cx25821_start_audio_dma(struct cx25821_audio_dev *chip)
{
struct cx25821_buffer *buf = chip->buf;
struct cx25821_dev *dev = chip->dev;
@@ -142,7 +141,7 @@ static int _cx25821_start_audio_dma(snd_cx25821_card_t *
chip)
&cx25821_sram_channels[AUDIO_SRAM_CHANNEL];
u32 tmp = 0;
- // enable output on the GPIO 0 for the MCLK ADC (Audio)
+ /* enable output on the GPIO 0 for the MCLK ADC (Audio)*/
cx25821_set_gpiopin_direction(chip->dev, 0, 0);
/* Make sure RISC/FIFO are off before changing FIFO/RISC settings */
@@ -156,19 +155,24 @@ static int _cx25821_start_audio_dma(snd_cx25821_card_t *
chip)
/* sets bpl size */
cx_write(AUD_A_LNGTH, buf->bpl);
- /* reset counter */
- cx_write(AUD_A_GPCNT_CTL, GP_COUNT_CONTROL_RESET);
//GP_COUNT_CONTROL_RESET = 0x3
+ /* reset counter
+ GP_COUNT_CONTROL_RESET = 0x3*/
+ cx_write(AUD_A_GPCNT_CTL, GP_COUNT_CONTROL_RESET);
atomic_set(&chip->count, 0);
- //Set the input mode to 16-bit
+ /*Set the input mode to 16-bit*/
tmp = cx_read(AUD_A_CFG);
cx_write(AUD_A_CFG,
tmp | FLD_AUD_DST_PK_MODE | FLD_AUD_DST_ENABLE |
FLD_AUD_CLK_ENABLE);
- //printk(KERN_INFO "DEBUG: Start audio DMA, %d B/line,
cmds_start(0x%x)= %d lines/FIFO, %d periods, %d "
- // "byte buffer\n", buf->bpl, audio_ch->cmds_start,
cx_read(audio_ch->cmds_start + 12)>>1,
- // chip->num_periods, buf->bpl * chip->num_periods);
+ /*printk(KERN_INFO "DEBUG: Start audio DMA, %d B/line,"
+ "cmds_start(0x%x)= %d lines/FIFO, %d periods, "
+ "%d byte buffer\n", buf->bpl,
+ audio_ch->cmds_start,
+ cx_read(audio_ch->cmds_start + 12)>>1,
+ chip->num_periods, buf->bpl *chip->num_periods);
+ */
/* Enables corresponding bits at AUD_INT_STAT */
cx_write(AUD_A_INT_MSK,
@@ -181,7 +185,7 @@ static int _cx25821_start_audio_dma(snd_cx25821_card_t *
chip)
/* enable audio irqs */
cx_set(PCI_INT_MSK, chip->dev->pci_irqmask | PCI_MSK_AUD_INT);
- // Turn on audio downstream fifo and risc enabl
Re: dual TT C-1501 on a single PCI riser
Reply to myself with some extra information: Just found this thread about the same problem, but different MB: http://kerneltrap.org/mailarchive/linux-kernel/2007/2/18/56447 Have to study all the replies in more depth to see if there's a solution hidden in there for me. Another thing to remark is that the D945GSEJT does support a dual riser card as it's described in the manual: - The PCI bus connector also supports single-slot and dual-slot riser cards for use of up to two bus master PCI expansion cards. In order to support two PCI bus master expansion cards, the riser card must support the following PCI signal routing: • Pin A11: additional 33 MHz PCI clock • Pin B10: additional PCI request signal (i.e., PREQ#2) • Pin B14: additional PCI Grant signal (i.e., GNT#2) - I'm 100% sure the Tranquil riser does not support this suggestion since the A11/B10 and B14 leads are not used on the riser. So I'm doubting the remark that this riser is specifically made for the D945GSEJT. On the other hand, my guess would be that an ordinary riser with arbiter and the correct wiring should do the trick. My question is more or less the same as Udo's in the thread I posted: how do I check if int 17 of the second card is correctly connected to int A of the second slot and if not, where to start changing things? Regards Martin On Sun, Mar 14, 2010 at 13:21, Martin van Es wrote: > Hi, > > My name is Martin van Es and I just subscribed to the DVB mailinglist > because I'm currently facing a challenge that's beyond my knowledge so > I hope to find some cooperative minds in the list who could point me > in the right direction. > > My problem is that I try to build a dual DVB-C tuner HTPC, based on an > Intel D945GSEJT mini-itx motherboard. This board is equipped with only > 1 PCI slot, so a PCI riser is the only solution (no single board dual > DVB-C solutions exist today). > > The case I've bought came with a riser but that didn't work so my > first attempt was to order this riser, which, they say is specifically > designed for the D945GSEJT: > http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html (top one, > it's based on a IT8209R PCI Arbiter). > When that didn't work I suspected there's more to this than correct > hardware and started looking for solutions, including mailing a > knowledgable PCI expert but even that didn't bring much relief. I must > add that I'm technically inclined, just lack a background in low-level > (PC) hardware programming. > > So far my quest has revealed the following: > My 2 tunercards both get assigned a unique GSI on PCI interrupt A. > Both cards get detected correctly, but as soon as the second card > starts initialising the front-end it fails due to read/write timeouts > on the saa7146 (i2c). > The interrupt counter assigned to the second card never shows any > activity (cat /proc/interrupts counter for irq 17 is 0). > > Here are the (most) relevant pieces of dmesg output: > First the PCI initialisation. Mind the mentioning of both :05:* > devices (the riser slots): > > [ 0.234259] ACPI: PCI Root Bridge [PCI0] (:00) > [ 0.234500] pci :00:02.0: reg 10 32bit mmio: [0xdfe8-0xdfef] > [ 0.234520] pci :00:02.0: reg 14 io port: [0xf150-0xf157] > [ 0.234537] pci :00:02.0: reg 18 32bit mmio pref: > [0xc000-0xcfff] > [ 0.234555] pci :00:02.0: reg 1c 32bit mmio: [0xdff0-0xdff3] > [ 0.234641] pci :00:02.1: reg 10 32bit mmio: [0xdfe0-0xdfe7] > [ 0.234799] pci :00:1b.0: reg 10 64bit mmio: [0xffe0-0xffe03fff] > [ 0.234875] pci :00:1b.0: PME# supported from D0 D3hot D3cold > [ 0.234889] pci :00:1b.0: PME# disabled > [ 0.235003] pci :00:1c.0: PME# supported from D0 D3hot D3cold > [ 0.235016] pci :00:1c.0: PME# disabled > [ 0.235131] pci :00:1c.1: PME# supported from D0 D3hot D3cold > [ 0.235144] pci :00:1c.1: PME# disabled > [ 0.235259] pci :00:1c.2: PME# supported from D0 D3hot D3cold > [ 0.235272] pci :00:1c.2: PME# disabled > [ 0.235387] pci :00:1c.3: PME# supported from D0 D3hot D3cold > [ 0.235400] pci :00:1c.3: PME# disabled > [ 0.235488] pci :00:1d.0: reg 20 io port: [0xf0a0-0xf0bf] > [ 0.235578] pci :00:1d.1: reg 20 io port: [0xf080-0xf09f] > [ 0.235669] pci :00:1d.2: reg 20 io port: [0xf060-0xf07f] > [ 0.235759] pci :00:1d.3: reg 20 io port: [0xf040-0xf05f] > [ 0.235856] pci :00:1d.7: reg 10 32bit mmio: [0xdff41000-0xdff413ff] > [ 0.235940] pci :00:1d.7: PME# supported from D0 D3hot D3cold > [ 0.235954] pci :00:1d.7: PME# disabled > [ 0.236202] pci :00:1f.0: Force enabled HPET at 0xfed0 > [ 0.236221] pci :00:1f.0: quirk: region 0400-047f claimed by > ICH6 ACPI/GPIO/TCO > [ 0.236236] pci :00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO > [ 0.236251] pci :00:1f.0: ICH7 LPC Generic IO decode 1 PIO at > 0a00 (mask 007f) > [ 0.236265] pci :
Hauppauge MiniStick (Siano 1150-PC) - How to get the IR receiver working?
Hi,
I have a Hauppauge WinTV MiniStick ("55009 LF Rev A1F7 4609") that I
would like to use with MythTV. I wonder if it is possible to get the IR
receiver working?
Apparently the driver looks for IR functionality but does not find it,
judging from the syslog message "IR port has not been detected". (Syslog
and other info below.)
A newer kernel (2.6.33) did not help. Also tried in vain all the
firmware versions I could find:
- sms1xxx-hcw-55xxx-dvbt-0{1,2,3}.fw from
http://steventoth.net/linux/sms1xxx/
- dvb_nova_12mhz_b0.inp from Siano's FTP site
- hcw17dvb.1b0 from Hauppauge's Windows driver archive
Any ideas would be appreciated.
Regards,
Jacob Nielsen
$ uname -r
2.6.33-020633-generic
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 9.10
Release:9.10
Codename: karmic
$ cat /etc/modprobe.d/siano.conf
options smsmdtv debug=3 cards_dbg=3
options smsdvb debug=3
options smsusb debug=3
$ tail -f /var/log/syslog
[insert]
Mar 13 13:17:30 wasabi kernel: [ 1061.936039] usb 1-4: new high speed
USB device using ehci_hcd and address 7
Mar 13 13:17:30 wasabi kernel: [ 1062.070720] smsusb_probe: smsusb_probe
0
Mar 13 13:17:30 wasabi kernel: [ 1062.070728] smsusb_probe: endpoint 0
81 02 512
Mar 13 13:17:30 wasabi kernel: [ 1062.070733] smsusb_probe: endpoint 1
02 02 512
Mar 13 13:17:30 wasabi kernel: [ 1062.072075] smscore_register_device:
allocated 50 buffers
Mar 13 13:17:30 wasabi kernel: [ 1062.072083] smscore_register_device:
device f39b9800 created
Mar 13 13:17:30 wasabi kernel: [ 1062.072091] smsusb_init_device:
smsusb_start_streaming(...).
Mar 13 13:17:30 wasabi kernel: [ 1062.072127] smscore_set_device_mode:
set device mode to 4
Mar 13 13:17:30 wasabi kernel: [ 1062.072673] smscore_onresponse:
Mar 13 13:17:30 wasabi kernel: [ 1062.072675] data rate 10 bytes/secs
Mar 13 13:17:30 wasabi kernel: [ 1062.072681] smscore_onresponse:
MSG_SMS_GET_VERSION_EX_RES id 255 prots 0x0 ver 2.1
Mar 13 13:17:30 wasabi kernel: [ 1062.072951] usb 1-4: firmware:
requesting sms1xxx-hcw-55xxx-dvbt-02.fw
Mar 13 13:17:30 wasabi kernel: [ 1062.084073]
smscore_load_firmware_from_file: read FW sms1xxx-hcw-55xxx-dvbt-02.fw,
size=93292
Mar 13 13:17:30 wasabi kernel: [ 1062.084209]
smscore_load_firmware_family2: loading FW to addr 0x40260 size 93280
Mar 13 13:17:30 wasabi kernel: [ 1062.151531] smscore_onresponse:
MSG_SMS_SWDOWNLOAD_TRIGGER_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.652040]
smscore_load_firmware_family2: rc=0, postload=(null)
Mar 13 13:17:31 wasabi kernel: [ 1062.652070] smscore_set_device_mode:
firmware download success: sms1xxx-hcw-55xxx-dvbt-02.fw
Mar 13 13:17:31 wasabi kernel: [ 1062.652481] smscore_onresponse:
MSG_SMS_INIT_DEVICE_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.652507] DVB: registering new
adapter (Hauppauge WinTV MiniStick)
Mar 13 13:17:31 wasabi kernel: [ 1062.652758] DVB: registering adapter 0
frontend 0 (Siano Mobile Digital MDTV Receiver)...
Mar 13 13:17:31 wasabi kernel: [ 1062.652811] smscore_register_client:
f59fe000 693 1
Mar 13 13:17:31 wasabi kernel: [ 1062.652817] sms_board_dvb3_event:
DVB3_EVENT_HOTPLUG
Mar 13 13:17:31 wasabi kernel: [ 1062.652821] smsdvb_hotplug: success
Mar 13 13:17:31 wasabi kernel: [ 1062.652986] smscore_onresponse:
MSG_SMS_GPIO_CONFIG_EX_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.653107] smscore_onresponse:
MSG_SMS_GPIO_SET_LEVEL_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.653232] smscore_onresponse:
MSG_SMS_GPIO_CONFIG_EX_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.653356] smscore_onresponse:
MSG_SMS_GPIO_SET_LEVEL_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.653481] smscore_onresponse:
MSG_SMS_GPIO_CONFIG_EX_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.653606] smscore_onresponse:
MSG_SMS_GPIO_SET_LEVEL_RES
Mar 13 13:17:31 wasabi kernel: [ 1062.653613] smscore_init_ir: IR port
has not been detected
Mar 13 13:17:31 wasabi kernel: [ 1062.653619] smscore_start_device:
device f39b9800 started, rc 0
Mar 13 13:17:31 wasabi kernel: [ 1062.653624] smsusb_init_device: device
f5a4a000 created
Mar 13 13:17:31 wasabi kernel: [ 1062.653628] smsusb_probe: rc 0
[remove]
Mar 13 13:18:01 wasabi kernel: [ 1092.266210] usb 1-4: USB disconnect,
address 7
Mar 13 13:18:01 wasabi kernel: [ 1092.266286] smsusb_onresponse: line:
70: error, urb status -108 (-ESHUTDOWN), 0 bytes
Mar 13 13:18:01 wasabi kernel: [ 1092.266298] smsusb_onresponse: line:
70: error, urb status -108 (-ESHUTDOWN), 0 bytes
Mar 13 13:18:01 wasabi kernel: [ 1092.266306] smsusb_onresponse: line:
70: error, urb status -108 (-ESHUTDOWN), 0 bytes
Mar 13 13:18:01 wasabi kernel: [ 1092.266313] smsusb_onresponse: line:
70: error, urb status -108 (-ESHUTDOWN), 0 bytes
Mar 13 13:18:01 wasabi kernel: [ 1092.266320] smsusb_onresponse: line:
70: error, urb status -108 (-ESHUTDOWN), 0 bytes
Mar 13 13:18:01 wasabi kernel: [ 1092.266326] smsusb_onresponse: line:
70: error, urb status -108 (-ESHUTDOWN), 0 bytes
Mar 13 13:18:01 wasabi kernel: [ 1092.266333]
Re: Excessive rc polling interval in dvb_usb_dib0700 causes interference with USB soundcard
On 4 March 2010 20:52, Devin Heitmueller wrote: > On Thu, Mar 4, 2010 at 3:44 PM, Pedro Ribeiro wrote: >> I think you are right. I was to quick to blame it. It occurs whether >> or not the DVB adapter is connected. >> >> Once again, thanks. >> >> Pedro > > Ok, that's great to hear. I'm putting linux-media back into the CC in > case anyone else finds this thread in the mailing list archives. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > Hi Devin, after some through investigation I found that your patch solves the continuous interference. However, I have a second problem. It is also interference but appears to be quite random, by which I mean it is not at a fixed interval, sometimes it happens past 10 seconds, other times past 30 seconds, other times 2 to 5 seconds. One thing is sure - it only happens when I'm actually streaming from the DVB adapter. If I just plug it in, there is no interference. But when I start vdr (for example) the interference starts. The DVB adapter and the sound card are not sharing irq's or anything like that, and there is no system freeze when the interference happens. I also thought it was either my docking bay or power supply, but definitely it isn't. Any idea what can this be? Thank you for your help, Pedro -- 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
Aw: Re: v4l-utils, dvb-utils, xawtv and alevt
- Original Nachricht Von: Chicken Shack An: hermann pitton Datum: 14.03.2010 12:13 Betreff: Re: v4l-utils, dvb-utils, xawtv and alevt > Am Sonntag, den 14.03.2010, 06:39 +0100 schrieb hermann pitton: > > Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack: > > > Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede: > > > > Hi, > > > > > > > > On 03/13/2010 11:15 AM, Chicken Shack wrote: > > > > > Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede: > > > > >> Hi, > > > > >> > > > > >> On 03/12/2010 08:10 PM, Chicken Shack wrote: > > > > >>> 1. Alevt 1.7.0 is not just another tool, but it is instead a > > > > >>> self-contained videotext application consisting of three parts: > > > > >>> a. alevt, b. alevt-date c. alevt-cap > > > > >>> > > > > >>> While the packed size of alevt is 78770 the complete size of the > > > > >>> dvb-apps as a whole ranges around 35. > > > > >>> > > > > >>> I am not against hosting this program at linuxtv.org, but if this > > > > >>> decision is made the decision should be an intelligent one: alevt > is a > > > > >>> separate tree, and any other choice is simply a dumb one. > > > > >>> Alevt-1.7.0 needs a lot of external dependencies, while the > dvb-apps > > > > >>> only need the libc6. > > > > More clever would have been never to rename it from alevt-dvb to alevt. > > On the prior you don't have any rights and I seriously doubt you have > > any on the later. > > Only a pure brainless idiot who understands less than nothing can rant > crap like this. > > Typical Pitton, typical no-brain quality > > > > > > > > Good morning Hans, > > > > > > > > > > > > > Good afternoon :) > > > > > > > > > Definitely not. > > > > > 3.95 is analogue only and thus is discontinued as version. > > > > > 4.0 pre is the alpha-state tarball that you can get here: > > > > No, 3.95 is "official" and right for patching and 4x was never released. > > See above. > > > I pointed to mpeg4ip only as a joke. > > > > > > Ah, ok. Well I must honestly say I've no interest in that I'm doing > > > > package maintenance for the 3.95 release in Fedora and I know it > > > > needs a lot of patching, AFAIK other distros are doing the same, > > > > so it would be good to have / become a new upstream for xawtv 3.95, > > > > to have a place to gather all the distro patches mostly and release > > > > that, and where new patches if needed can accumulate and new > > > > releases can be done from. > > > > > > > > > > > > > http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz > > > > > > > > > > Inofficial end of development somewhere in 2005 or 2006, last > external > > > > > contribution from October 2008. > > > > It was on March 08 2005. You even don't know that? > > Completely irrelevant, stupid moron! > > > http://linux.bytesex.org/v4l2/maintainer.txt > > > > Maybe improve your Pinnacle stuff first, I can point you to a lot on the > > TODO list. > > Don't owe no Pinnacle any longer for years now. > > I personally took part in flexcop development as well-informed people > know. > That's a good driver now, and Patrick is someone you can really work > with, not unproblematic, but OK so far. > He's no Abraham, and he's no Pitton > http://www.mail-archive.com/linux-...@linuxtv.org/msg23780.html There is not any progress with you and likely never will be. Cheers, Hermann Topp oder Hopp? Tolle Figur, scharfes Dekolleté oder sehenswertes Tatoo?! Bewerten Sie die besten Bilder und zeigen Sie auch selbst, was Sie haben! Jetzt reinklicken und mitmachen: http://www.arcor.de/rd/footer.toh -- 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
dual TT C-1501 on a single PCI riser
Hi, My name is Martin van Es and I just subscribed to the DVB mailinglist because I'm currently facing a challenge that's beyond my knowledge so I hope to find some cooperative minds in the list who could point me in the right direction. My problem is that I try to build a dual DVB-C tuner HTPC, based on an Intel D945GSEJT mini-itx motherboard. This board is equipped with only 1 PCI slot, so a PCI riser is the only solution (no single board dual DVB-C solutions exist today). The case I've bought came with a riser but that didn't work so my first attempt was to order this riser, which, they say is specifically designed for the D945GSEJT: http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html (top one, it's based on a IT8209R PCI Arbiter). When that didn't work I suspected there's more to this than correct hardware and started looking for solutions, including mailing a knowledgable PCI expert but even that didn't bring much relief. I must add that I'm technically inclined, just lack a background in low-level (PC) hardware programming. So far my quest has revealed the following: My 2 tunercards both get assigned a unique GSI on PCI interrupt A. Both cards get detected correctly, but as soon as the second card starts initialising the front-end it fails due to read/write timeouts on the saa7146 (i2c). The interrupt counter assigned to the second card never shows any activity (cat /proc/interrupts counter for irq 17 is 0). Here are the (most) relevant pieces of dmesg output: First the PCI initialisation. Mind the mentioning of both :05:* devices (the riser slots): [0.234259] ACPI: PCI Root Bridge [PCI0] (:00) [0.234500] pci :00:02.0: reg 10 32bit mmio: [0xdfe8-0xdfef] [0.234520] pci :00:02.0: reg 14 io port: [0xf150-0xf157] [0.234537] pci :00:02.0: reg 18 32bit mmio pref: [0xc000-0xcfff] [0.234555] pci :00:02.0: reg 1c 32bit mmio: [0xdff0-0xdff3] [0.234641] pci :00:02.1: reg 10 32bit mmio: [0xdfe0-0xdfe7] [0.234799] pci :00:1b.0: reg 10 64bit mmio: [0xffe0-0xffe03fff] [0.234875] pci :00:1b.0: PME# supported from D0 D3hot D3cold [0.234889] pci :00:1b.0: PME# disabled [0.235003] pci :00:1c.0: PME# supported from D0 D3hot D3cold [0.235016] pci :00:1c.0: PME# disabled [0.235131] pci :00:1c.1: PME# supported from D0 D3hot D3cold [0.235144] pci :00:1c.1: PME# disabled [0.235259] pci :00:1c.2: PME# supported from D0 D3hot D3cold [0.235272] pci :00:1c.2: PME# disabled [0.235387] pci :00:1c.3: PME# supported from D0 D3hot D3cold [0.235400] pci :00:1c.3: PME# disabled [0.235488] pci :00:1d.0: reg 20 io port: [0xf0a0-0xf0bf] [0.235578] pci :00:1d.1: reg 20 io port: [0xf080-0xf09f] [0.235669] pci :00:1d.2: reg 20 io port: [0xf060-0xf07f] [0.235759] pci :00:1d.3: reg 20 io port: [0xf040-0xf05f] [0.235856] pci :00:1d.7: reg 10 32bit mmio: [0xdff41000-0xdff413ff] [0.235940] pci :00:1d.7: PME# supported from D0 D3hot D3cold [0.235954] pci :00:1d.7: PME# disabled [0.236202] pci :00:1f.0: Force enabled HPET at 0xfed0 [0.236221] pci :00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO [0.236236] pci :00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO [0.236251] pci :00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0a00 (mask 007f) [0.236265] pci :00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 1640 (mask 000f) [0.236352] pci :00:1f.1: reg 10 io port: [0xf140-0xf147] [0.236371] pci :00:1f.1: reg 14 io port: [0xf130-0xf133] [0.236390] pci :00:1f.1: reg 18 io port: [0xf120-0xf127] [0.236408] pci :00:1f.1: reg 1c io port: [0xf110-0xf113] [0.236426] pci :00:1f.1: reg 20 io port: [0xf100-0xf10f] [0.236524] pci :00:1f.2: reg 10 io port: [0xf0f0-0xf0f7] [0.236542] pci :00:1f.2: reg 14 io port: [0xf0e0-0xf0e3] [0.236560] pci :00:1f.2: reg 18 io port: [0xf0d0-0xf0d7] [0.236578] pci :00:1f.2: reg 1c io port: [0xf0c0-0xf0c3] [0.236595] pci :00:1f.2: reg 20 io port: [0xf020-0xf03f] [0.236614] pci :00:1f.2: reg 24 32bit mmio: [0xdff4-0xdff403ff] [0.236668] pci :00:1f.2: PME# supported from D3hot [0.236681] pci :00:1f.2: PME# disabled [0.236765] pci :00:1f.3: reg 20 io port: [0x1180-0x119f] [0.236891] pci :01:00.0: reg 10 io port: [0xe000-0xe0ff] [0.236929] pci :01:00.0: reg 18 64bit mmio pref: [0xffd04000-0xffd04fff] [0.236959] pci :01:00.0: reg 20 64bit mmio pref: [0xffd0-0xffd03fff] [0.236980] pci :01:00.0: reg 30 32bit mmio pref: [0xdfd0-0xdfd1] [0.237045] pci :01:00.0: supports D1 D2 [0.237055] pci :01:00.0: PME# supported from D0 D1 D2 D3hot D3cold [0.237069] pci :01:00.0: PME# disabled [0.237163] pci :00:1c.0: bridge io port: [0xe000-0xefff] [0.237178] pci 00
[GIT PATCHES FOR 2.6.35] Small miscellaneous fixes
The following changes since commit daf9fe2ee9a203c4fc555cfe5c5f3d9f660e743c: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../sameo/mfd-2.6 are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc-fixes Hans Verkuil (3): videobuf-core: fix spelling mistake in debug message. v4l doc: fix font of field name v4l2: sort chip IDs in v4l2-chip-ident.h Michael Hunold (1): saa7146: fix up bytesperline if it is an impossible value Documentation/DocBook/v4l/vidioc-reqbufs.xml |2 +- drivers/media/common/saa7146_video.c |8 +- drivers/media/video/videobuf-core.c |2 +- include/media/v4l2-chip-ident.h | 120 + 4 files changed, 69 insertions(+), 63 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: SuperH Video Output Unit (VOU) driver
On Sunday 14 March 2010 12:08:02 Guennadi Liakhovetski wrote:
> Hi Hans
>
> On Sun, 14 Mar 2010, Hans Verkuil wrote:
>
> > Hi Guennadi,
> >
> > Here is a quick review. It looks good, just a few small points.
>
> Thanks for the review! To most points - right, will update. The ones, that
> I have more questions about:
>
> > On Thursday 11 March 2010 11:24:42 Guennadi Liakhovetski wrote:
> > > A number of SuperH SoCs, including sh7724, include a Video Output Unit.
> > > This
> > > patch adds a video (V4L2) output driver for it. The driver uses
> > > v4l2-subdev and
> > > mediabus APIs to interface to TV encoders.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > >
> > > Tested on ms7724se
> > >
> > > drivers/media/video/Kconfig |7 +
> > > drivers/media/video/Makefile |2 +
> > > drivers/media/video/sh_vou.c | 1437
> > > ++
> > > include/media/sh_vou.h | 35 +
> > > 4 files changed, 1481 insertions(+), 0 deletions(-)
> > > create mode 100644 drivers/media/video/sh_vou.c
> > > create mode 100644 include/media/sh_vou.h
> > >
> > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> > > index 64682bf..be6d016 100644
> > > --- a/drivers/media/video/Kconfig
> > > +++ b/drivers/media/video/Kconfig
>
> [snip]
>
> > > +static int sh_vou_g_fmt_vid_ovrl(struct file *file, void *priv,
> > > + struct v4l2_format *fmt)
> > > +{
> > > + /* This is needed for gstreamer, even if not used... */
> > > + return 0;
> > > +}
> >
> > Shouldn't this return -EINVAL if there is no overlay support?
>
> In fact I would just drop this methos altogether, but gstreamer needs it
> _and_ it shouldn't return an error. In fact, I think, we can persuade
> gstreamer guys to drop this restriction, if we really think this is
> irrelevant. For some reason their v4l2sink is somewhat overlay-centric,
> but I think we can discuss this with them.
This seems to be a true gstreamer bug. If the capabilities of the video device
do not include overlay, then it shouldn't try to use overlay types.
I'm not sure whether we should work around an application bug in the kernel,
that doesn't seem right. I really don't like this.
> > > +enum sh_vou_bus_fmt {
> > > + SH_VOU_BUS_NTSC_16BIT = 0,
> > > + SH_VOU_BUS_NTSC_8BIT = 1,
> > > + SH_VOU_BUS_NTSC_8BIT_REC656 = 3,
> > > + SH_VOU_BUS_PAL_8BIT = 5,
> >
> > Rather than NTSC and PAL it might be better to talk about 50 vs 60 Hz.
>
> Don't know, this is how these modes are called in the datasheet, so... Do
> you think it's better to call them "correctly" or as in the datasheet?
Either call them correctly or add a comment here that clarifies that 'NTSC'
applies to all 60 Hz formats and PAL to all 50 Hz formats and that we keep
these names since the datasheet uses them.
Regards,
Hans
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: v4l-utils, dvb-utils, xawtv and alevt
Am Sonntag, den 14.03.2010, 06:39 +0100 schrieb hermann pitton: > Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack: > > Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede: > > > Hi, > > > > > > On 03/13/2010 11:15 AM, Chicken Shack wrote: > > > > Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede: > > > >> Hi, > > > >> > > > >> On 03/12/2010 08:10 PM, Chicken Shack wrote: > > > >>> 1. Alevt 1.7.0 is not just another tool, but it is instead a > > > >>> self-contained videotext application consisting of three parts: > > > >>> a. alevt, b. alevt-date c. alevt-cap > > > >>> > > > >>> While the packed size of alevt is 78770 the complete size of the > > > >>> dvb-apps as a whole ranges around 35. > > > >>> > > > >>> I am not against hosting this program at linuxtv.org, but if this > > > >>> decision is made the decision should be an intelligent one: alevt is a > > > >>> separate tree, and any other choice is simply a dumb one. > > > >>> Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps > > > >>> only need the libc6. > > More clever would have been never to rename it from alevt-dvb to alevt. > On the prior you don't have any rights and I seriously doubt you have > any on the later. Only a pure brainless idiot who understands less than nothing can rant crap like this. Typical Pitton, typical no-brain quality > > > > > Good morning Hans, > > > > > > > > > > Good afternoon :) > > > > > > > Definitely not. > > > > 3.95 is analogue only and thus is discontinued as version. > > > > 4.0 pre is the alpha-state tarball that you can get here: > > No, 3.95 is "official" and right for patching and 4x was never released. See above. > I pointed to mpeg4ip only as a joke. > > > > Ah, ok. Well I must honestly say I've no interest in that I'm doing > > > package maintenance for the 3.95 release in Fedora and I know it > > > needs a lot of patching, AFAIK other distros are doing the same, > > > so it would be good to have / become a new upstream for xawtv 3.95, > > > to have a place to gather all the distro patches mostly and release > > > that, and where new patches if needed can accumulate and new > > > releases can be done from. > > > > > > > > > > http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz > > > > > > > > Inofficial end of development somewhere in 2005 or 2006, last external > > > > contribution from October 2008. > > It was on March 08 2005. You even don't know that? Completely irrelevant, stupid moron! > http://linux.bytesex.org/v4l2/maintainer.txt > > Maybe improve your Pinnacle stuff first, I can point you to a lot on the > TODO list. Don't owe no Pinnacle any longer for years now. I personally took part in flexcop development as well-informed people know. That's a good driver now, and Patrick is someone you can really work with, not unproblematic, but OK so far. He's no Abraham, and he's no Pitton There's one thing I would really like to know: Is there one example where your personal dumb rant was really helpful? As the alevt example showed you're even too dumb to test a simple application. Where is your quality, where is your positive usable substance please? I do not see any. I never saw any. Whenever I read your postings I am very close to vomit because of the enormous amount of emptyness and thickness speaking between the lines. So why don't you simply fuck off, consume your alcohol / drugs elsewhere and stay away from here? No one needs you, no one will be missing you stinking brainless moron. Dumb rant, pure no-brained dumbness and hostility - that's everything connected with the name "Hermann Pitton". Even ordinary trolls are more agreeable than you will ever be -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: SuperH Video Output Unit (VOU) driver
Hi Hans
On Sun, 14 Mar 2010, Hans Verkuil wrote:
> Hi Guennadi,
>
> Here is a quick review. It looks good, just a few small points.
Thanks for the review! To most points - right, will update. The ones, that
I have more questions about:
> On Thursday 11 March 2010 11:24:42 Guennadi Liakhovetski wrote:
> > A number of SuperH SoCs, including sh7724, include a Video Output Unit. This
> > patch adds a video (V4L2) output driver for it. The driver uses v4l2-subdev
> > and
> > mediabus APIs to interface to TV encoders.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> >
> > Tested on ms7724se
> >
> > drivers/media/video/Kconfig |7 +
> > drivers/media/video/Makefile |2 +
> > drivers/media/video/sh_vou.c | 1437
> > ++
> > include/media/sh_vou.h | 35 +
> > 4 files changed, 1481 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/media/video/sh_vou.c
> > create mode 100644 include/media/sh_vou.h
> >
> > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> > index 64682bf..be6d016 100644
> > --- a/drivers/media/video/Kconfig
> > +++ b/drivers/media/video/Kconfig
[snip]
> > +static int sh_vou_g_fmt_vid_ovrl(struct file *file, void *priv,
> > +struct v4l2_format *fmt)
> > +{
> > + /* This is needed for gstreamer, even if not used... */
> > + return 0;
> > +}
>
> Shouldn't this return -EINVAL if there is no overlay support?
In fact I would just drop this methos altogether, but gstreamer needs it
_and_ it shouldn't return an error. In fact, I think, we can persuade
gstreamer guys to drop this restriction, if we really think this is
irrelevant. For some reason their v4l2sink is somewhat overlay-centric,
but I think we can discuss this with them.
> > +enum sh_vou_bus_fmt {
> > + SH_VOU_BUS_NTSC_16BIT = 0,
> > + SH_VOU_BUS_NTSC_8BIT = 1,
> > + SH_VOU_BUS_NTSC_8BIT_REC656 = 3,
> > + SH_VOU_BUS_PAL_8BIT = 5,
>
> Rather than NTSC and PAL it might be better to talk about 50 vs 60 Hz.
Don't know, this is how these modes are called in the datasheet, so... Do
you think it's better to call them "correctly" or as in the datasheet?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM
Review notes below...
On Thursday 11 March 2010 11:25:42 Guennadi Liakhovetski wrote:
> AK8814 only differs from AK8813 by included Macrovision Copy Protection
> function. This patch adds a driver for AK8813 and AK8814 I2C PAL/NTSC TV
> encoders.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> as is easy to guess, also tested on the same ms7724se
>
> drivers/media/video/Kconfig |7 +
> drivers/media/video/Makefile|2 +
> drivers/media/video/ak881x.c| 360
> +++
> include/media/ak881x.h | 25 +++
> include/media/v4l2-chip-ident.h |4 +
> 5 files changed, 398 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/ak881x.c
> create mode 100644 include/media/ak881x.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index be6d016..d029cc5 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -819,6 +819,13 @@ config VIDEO_CAFE_CCIC
> CMOS camera controller. This is the controller found on first-
> generation OLPC systems.
>
> +config VIDEO_AK881X
> + tristate "ak8813/ak8814 support"
> + depends on I2C
> + help
> + This is a video output driver for AK8813 and AK8814 TV encoders
> + from AKM
> +
> config SOC_CAMERA
> tristate "SoC camera support"
> depends on VIDEO_V4L2 && HAS_DMA && I2C
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 2669d34..6790051 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -149,6 +149,8 @@ obj-$(CONFIG_VIDEO_CX18) += cx18/
> obj-$(CONFIG_VIDEO_VIVI) += vivi.o
> obj-$(CONFIG_VIDEO_CX23885) += cx23885/
>
> +obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
> +
> obj-$(CONFIG_VIDEO_OMAP2)+= omap2cam.o
> obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
> obj-$(CONFIG_SOC_CAMERA_PLATFORM)+= soc_camera_platform.o
> diff --git a/drivers/media/video/ak881x.c b/drivers/media/video/ak881x.c
> new file mode 100644
> index 000..b91f0f6
> --- /dev/null
> +++ b/drivers/media/video/ak881x.c
> @@ -0,0 +1,360 @@
> +/*
> + * Driver for AK8813 / AK8814 TV-ecoders from Asahi Kasei Microsystems Co.,
> Ltd. (AKM)
> + *
> + * Copyright (C) 2010, Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define AK881X_INTERFACE_MODE0
> +#define AK881X_VIDEO_PROCESS11
> +#define AK881X_VIDEO_PROCESS22
> +#define AK881X_VIDEO_PROCESS33
> +#define AK881X_DAC_MODE 5
> +#define AK881X_STATUS0x24
> +#define AK881X_DEVICE_ID 0x25
> +#define AK881X_DEVICE_REVISION 0x26
> +
> +struct ak881x {
> + struct v4l2_subdev subdev;
> + struct ak881x_pdata *pdata;
> + int id; /* DEVICE_ID code V4L2_IDENT_AK881X code from v4l2-chip-ident.h
> */
> + char revision; /* DEVICE_REVISION content */
> +};
> +
> +static int reg_read(struct i2c_client *client, const u8 reg)
> +{
> + return i2c_smbus_read_byte_data(client, reg);
> +}
> +
> +static int reg_write(struct i2c_client *client, const u8 reg,
> + const u8 data)
> +{
> + return i2c_smbus_write_byte_data(client, reg, data);
> +}
I suggest making these inline.
I also recommend using struct v4l2_subdev instead of struct i2c_client as
argument. In my experience it makes the code cleaner if the mapping from
subdev to i2c_client is done at the lowest possible level.
> +
> +static int reg_set(struct i2c_client *client, const u8 reg,
> +const u8 data, u8 mask)
> +{
> + int ret = reg_read(client, reg);
> + if (ret < 0)
> + return ret;
> + return reg_write(client, reg, (ret & ~mask) | (data & mask));
> +}
> +
> +static struct ak881x *to_ak881x(const struct i2c_client *client)
> +{
> + return container_of(i2c_get_clientdata(client), struct ak881x, subdev);
> +}
Ditto for this one.
> +
> +static int ak881x_g_chip_ident(struct v4l2_subdev *sd,
> + struct v4l2_dbg_chip_ident *id)
> +{
> + struct i2c_client *client = sd->priv;
Don't use sd->priv directly. Use v4l2_get_subdevdata(sd) instead.
> + struct ak881x *ak881x = to_ak881x(client);
> +
> + if (id->match.type != V4L2_CHIP_MATCH_I2C_ADDR)
> + return -EINVAL;
> +
> + if (id->match.addr != client->addr)
> + return -ENODEV;
> +
> + id->ident = ak881x->id;
> + id->revision= ak881x->revision;
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +static int ak881x_g_register(struct v4l2_subdev *sd,
> + struct v4l2_dbg_register *reg)
> +{
> + stru
Re: [PATCH] V4L: SuperH Video Output Unit (VOU) driver
Hi Guennadi,
Here is a quick review. It looks good, just a few small points.
On Thursday 11 March 2010 11:24:42 Guennadi Liakhovetski wrote:
> A number of SuperH SoCs, including sh7724, include a Video Output Unit. This
> patch adds a video (V4L2) output driver for it. The driver uses v4l2-subdev
> and
> mediabus APIs to interface to TV encoders.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> Tested on ms7724se
>
> drivers/media/video/Kconfig |7 +
> drivers/media/video/Makefile |2 +
> drivers/media/video/sh_vou.c | 1437
> ++
> include/media/sh_vou.h | 35 +
> 4 files changed, 1481 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/sh_vou.c
> create mode 100644 include/media/sh_vou.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 64682bf..be6d016 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -511,6 +511,13 @@ config DISPLAY_DAVINCI_DM646X_EVM
> To compile this driver as a module, choose M here: the
> module will be called vpif_display.
>
> +config VIDEO_SH_VOU
> + tristate "SuperH VOU video output driver"
> + depends on VIDEO_DEV && (SUPERH || ARCH_SHMOBILE)
> + select VIDEOBUF_DMA_CONTIG
> + help
> + Support for the Video Output Unit (VOU) on SuperH SoCs.
> +
> config CAPTURE_DAVINCI_DM646X_EVM
> tristate "DM646x EVM Video Capture"
> depends on VIDEO_DEV && MACH_DAVINCI_DM6467_EVM
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 2af68ee..2669d34 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -160,6 +160,8 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) +=
> sh_mobile_ceu_camera.o
>
> obj-$(CONFIG_ARCH_DAVINCI) += davinci/
>
> +obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o
> +
> obj-$(CONFIG_VIDEO_AU0828) += au0828/
>
> obj-$(CONFIG_USB_VIDEO_CLASS)+= uvc/
> diff --git a/drivers/media/video/sh_vou.c b/drivers/media/video/sh_vou.c
> new file mode 100644
> index 000..ced3460
> --- /dev/null
> +++ b/drivers/media/video/sh_vou.c
> @@ -0,0 +1,1437 @@
> +/*
> + * SuperH Video Output Unit (VOU) driver
> + *
> + * Copyright (C) 2010, Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Mirror addresses are not available for all registers */
> +#define VOUER0
> +#define VOUCR4
> +#define VOUSTR 8
> +#define VOUVCR 0xc
> +#define VOUISR 0x10
> +#define VOUBCR 0x14
> +#define VOUDPR 0x18
> +#define VOUDSR 0x1c
> +#define VOUVPR 0x20
> +#define VOUIR0x24
> +#define VOUSRR 0x28
> +#define VOUMSR 0x2c
> +#define VOUHIR 0x30
> +#define VOUDFR 0x34
> +#define VOUAD1R 0x38
> +#define VOUAD2R 0x3c
> +#define VOUAIR 0x40
> +#define VOUSWR 0x44
> +#define VOURCR 0x48
> +#define VOURPR 0x50
> +
> +enum sh_vou_status {
> + SH_VOU_IDLE,
> + SH_VOU_INITIALISING,
> + SH_VOU_RUNNING,
> +};
> +
> +#define VOU_MAX_IMAGE_WIDTH 720
> +#define VOU_MAX_IMAGE_HEIGHT 480
> +
> +struct sh_vou_device {
> + struct v4l2_device v4l2_dev;
> + struct video_device *vdev;
> + atomic_t use_count;
> + struct sh_vou_pdata *pdata;
> + spinlock_t lock;
> + void __iomem *base;
> + /* State information */
> + struct v4l2_pix_format pix;
> + struct v4l2_rect rect;
> + struct list_head queue;
> + v4l2_std_id std;
> + int pix_idx;
> + struct videobuf_buffer *active;
> + enum sh_vou_status status;
> +};
> +
> +struct sh_vou_file {
> + struct videobuf_queue vbq;
> +};
> +
> +/* Register access routines for sides A, B and mirror addresses */
> +static void sh_vou_reg_a_write(struct sh_vou_device *vou_dev, unsigned int
> reg,
> +u32 value)
> +{
> + __raw_writel(value, vou_dev->base + reg);
> +}
> +
> +static void sh_vou_reg_ab_write(struct sh_vou_device *vou_dev, unsigned int
> reg,
> + u32 value)
> +{
> + __raw_writel(value, vou_dev->base + reg);
> + __raw_writel(value, vou_dev->base + reg + 0x1000);
> +}
> +
> +static void sh_vou_reg_m_write(struct sh_vou_device *vou_dev, unsigned int
> reg,
> +u32 value)
> +{
> + __raw_writel(value, vou_dev->base + reg + 0x2000);
> +}
> +
> +static u32 sh_vou_reg_a_read(struct sh_vou_device *vou_dev, unsigned int reg)
> +{
> + return __raw_readl(vou_dev->base + reg);
> +}
> +
> +static void s
Re: [PATCH for v4l-utils] qv4l2: fix UVC support
On Sunday 14 March 2010 00:14:15 Mauro Carvalho Chehab wrote: > Hans Verkuil wrote: > > Hans, > > > > Can you apply this to v4l-utils? > > Hans V., > > You have access to v4l-utils. It would be nice if you could try to > apply it directly, for us to double check if the server is properly > working with a shared repository. OK, done. It seems to work well. Hans > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Daro, On Sun, 14 Mar 2010 03:38:11 +0100, Daro wrote: > Hi Jean, > > I am back and ready to go :) > As I am not much experienced Linux user I would apprieciate some more > details: > > I have few linux kernels installed; which one should I test or it does > not matter? > 2.6.31-14-generic > 2.6.31-16-generic > 2.6.31-17-generic > 2.6.31-19-generic > 2.6.31-20-generic > > and one I compiled myself > 2.6.32.2 > > I assume that to proceed with a test I should patch the certain version > of kernel and compile it or could it be done other way? It will be easier with the kernel you compiled yourself. First of all, download the patch from: http://patchwork.kernel.org/patch/75883/raw/ Then, move to the source directory of your 2.6.32.2 kernel and apply the patch: $ cd ~/src/linux-2.6.32 $ patch -p2 < ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch Adjust the path in each command to match your own setup. Then just build and install the kernel: $ make $ sudo make modules_install $ sudo make install Or whatever method you use to install your self-compiled kernels. Then reboot to kernel 2.6.32.2 and test that the remote control works even when _not_ passing any card parameter to the driver. If you ever need to remove the patch, use: $ cd ~/src/linux-2.6.32 $ patch -p2 -R < ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch I hope my instructions are clear enough, if you have any problem, just ask. Thanks, -- Jean Delvare -- 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
