[PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-10 12:08:47.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB= 0x40, FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8= 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING= 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.0 +0200 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 + FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8 }, .release = gp8psk_fe_release, --- linux/drivers/media/dvb/frontends/cx24116.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.0 +0200 @@ -1496,7 +1496,7 @@ FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_2G_MODULATION | - FE_CAN_QPSK | FE_CAN_RECOVER + FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8 }, .release = cx24116_release, -- 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: webcam problem after suspend/hibernate
On Sunday 04 April 2010 21:34:06 Pavel Machek wrote:
Hi!
If unload/reload of uvcvideo helps, it is most likely problem in that.
If unload/reload of ehci_hcd is needed, it is most likely ehci problem.
My testing shows that:
1. If I remove uvcvideo BEFORE suspend and reinsert it after resume,
it works. However, I cannot always rmmod uvcvideo before suspend
as it may be in use.
2. As a work around, removing ehci_hcd and reinserting ehci_hcd upon
resume works as well.
3. Since my distribution's kernels come with ehci_hcd built into the
kernel, and I cannot do #2 any more, I also found that unbinding
and rebinding the device (with the script I sent earlier on) works
as well.
I think uvcvideo is failing to reinitialize the camera on resume, and
forcing an uvcvideo reset with either of these three methods kicks
uvcvideo into working again.
Ok, that puts the problem firmly into uvcvideo area.
No, it doesn't.
First of all, the dmesg output available on pastebin.com is difficult to
understand. As it seems you perform several suspend/resume cycles there.
Mohamed, could you please
- clear the kernel log ('dmesg -c' as root)
- suspend and resume your system
- post the kernel log content ('dmesg')
- clear the kernel log
- try to use your webcam with whatever test software your prefer
- describe the failure (application error messages, ...)
- post the kernel log content
Try changing its _resume routine to whatever is done on device
unplug... it should be rather easy, and is quite close to correct
solution.
That's not a solution. Devices are supposed to resume properly without being
reset. The camera might be crashing, or the USB core might be doing something
wrong, requiring some kind of reset. I'd like to diagnose the problem
correctly before trying to fix it.
--
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: cx18: missing audio for analog recordings
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). I fixed #2. I had a bug so the first patch didn't properly set the fallback audio mode. I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take into consideration that we might be using a forced audio mode vs. auto detection. However, that is not essential for testing; this should be good enough for testing. 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: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
on Tue, 30 Mar 2010 07:52 am in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure hermann pitton wrote: Hi Peter, Am Montag, den 29.03.2010, 23:10 +1100 schrieb 0123pe...@gmail.com: Hi Hermann, I've been fixing my PC to the state that it stopped working. Hence the delay. Hi Peter, Am Samstag, den 20.03.2010, 16:20 +1100 schrieb 0123pe...@gmail.com: [snip] unfortunately the problem with these cards is known, but no good solution for now. Best description is from Hartmut and starts here. http://www.spinics.net/lists/linux-dvb/msg26683.html [snip] Interesting link. I have one of the cards mentioned (an MSI TV(at)nywhere A/D hybrid). I've decided not to throw it away. to not leave you without any response at least. In hind sight, seeing how unfortunate using such devices can be, mainly because of being forced to try at random again with a cold boot after some i2c war brought down the tuner, we better should have such only in a still experimental league and not as supported. This was not foreseeable in such rudeness and neither Hartmut nor me have such devices. The Asus triple OEM 3in1 I have does not have any problems with loading firmware from file, the others do all get it from eeprom. So, actually nobody is investigating on it with real hardware. Maybe you can catch something with gpio_tracking and i2c_debug=1. I would expect that the complex analog tuner initialization gets broken somehow. This is at least known to be good to bring all down. Cheers, Hermann There was a patch about alignment that went through recently. Revert V4L/DVB (11906): saa7134: Use v4l bounding/alignment function Maybe that was it. did not even notice a problem with Trent's prior patch. The same is also at vivi. Should I have a file called /etc/modprobe.d/TVanywhereAD that contains the line, options saa7134 card=94 gpio_tracking i2c_debug=1 and then watch the command line output of kaffeine? I've found a GUI that allows tweaking lots of module parameters that I have never heard of. Card=94 in the config file, gpio_tracking and i2c_debug are set to 1 in the GUI. Strange things are appearing in dmesg and syslog. I assume that [snip] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-0: Invalid 7-bit address 0x7a saa7133[0]: i2c xfer: 8e ERROR: NO_DEVICE [snip] is significant. If you want to produce debug output for failing firmware loading from file after a cold boot, yes, you might eventually be able to see that failing tuner initialization brings down i2c. If it is a additional new regression, then mercurial bisect can find the patch in question fairly quick. That sounds like something that I should be able to do, if only I'd read the instructions. Mauro has a MSI cardbus device using also the card=94 entry, but at home he has no DVB-T. Cheers, Hermann Would you like me to post a 2000 line /var/log/dmesg? -- Sig goes here... Peter D. -- 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: cx18: missing audio for analog recordings
On 11/04/10 07:47 AM, Andy Walls wrote: On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). I fixed #2. I had a bug so the first patch didn't properly set the fallback audio mode. I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take into consideration that we might be using a forced audio mode vs. auto detection. However, that is not essential for testing; this should be good enough for testing. .. Those new patches don't want to coexist with the earlier hard/soft reset changes. There's always a chance that *both* things might be needed, and the reset stuff didn't look obviously bad. Why dropped? Thanks -- Mark Lord Real-Time Remedies Inc. ml...@pobox.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
[GIT PATCHES FOR 2.6.35] - Adding OMAP2/3 V4l2 display driver
Hi Mauro, Please pull from:- The following changes since commit 184b7c85f31583632ad00c062a295b622759eef3: Mauro Carvalho Chehab (1): ir-core: Fix the delete logic are available in the git repository at: git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream_04_11 Vaibhav Hiremath (2): V4L2: Add support for OMAP2/3 V4L2 display driver on top of DSS2 omap_vout:V4L2 Display: Changed enum return type to int drivers/media/video/Kconfig |2 + drivers/media/video/Makefile|2 + drivers/media/video/omap/Kconfig| 11 + drivers/media/video/omap/Makefile |7 + drivers/media/video/omap/omap_vout.c| 2643 +++ drivers/media/video/omap/omap_voutdef.h | 147 ++ drivers/media/video/omap/omap_voutlib.c | 293 drivers/media/video/omap/omap_voutlib.h | 34 + 8 files changed, 3139 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/omap/Kconfig create mode 100644 drivers/media/video/omap/Makefile create mode 100644 drivers/media/video/omap/omap_vout.c create mode 100644 drivers/media/video/omap/omap_voutdef.h create mode 100644 drivers/media/video/omap/omap_voutlib.c create mode 100644 drivers/media/video/omap/omap_voutlib.h -- Murali Karicheri mkarich...@gmail.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: webcam problem after suspend/hibernate
Hi!
My testing shows that:
1. If I remove uvcvideo BEFORE suspend and reinsert it after resume,
it works. However, I cannot always rmmod uvcvideo before suspend
as it may be in use.
...
I think uvcvideo is failing to reinitialize the camera on resume, and
forcing an uvcvideo reset with either of these three methods kicks
uvcvideo into working again.
Ok, that puts the problem firmly into uvcvideo area.
No, it doesn't.
I believe that the fact that rmmod/insmod fixes it means that problem
is in the driver (and not in ehci or something like that).
First of all, the dmesg output available on pastebin.com is difficult to
understand. As it seems you perform several suspend/resume cycles there.
Mohamed, could you please
- clear the kernel log ('dmesg -c' as root)
- suspend and resume your system
- post the kernel log content ('dmesg')
- clear the kernel log
- try to use your webcam with whatever test software your prefer
- describe the failure (application error messages, ...)
- post the kernel log content
Good idea.
Try changing its _resume routine to whatever is done on device
unplug... it should be rather easy, and is quite close to correct
solution.
That's not a solution. Devices are supposed to resume properly without being
reset. The camera might be crashing, or the USB core might be doing something
wrong, requiring some kind of reset. I'd like to diagnose the problem
correctly before trying to fix it.
Ok. (You are right that simulating rmmod/insmod is not the same as
proper suspend/resume support, but I still guess it would help with
debugging.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: cx18: missing audio for analog recordings
On Sun, 2010-04-11 at 09:24 -0400, Mark Lord wrote: On 11/04/10 07:47 AM, Andy Walls wrote: On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). I fixed #2. I had a bug so the first patch didn't properly set the fallback audio mode. I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take into consideration that we might be using a forced audio mode vs. auto detection. However, that is not essential for testing; this should be good enough for testing. .. Those new patches don't want to coexist with the earlier hard/soft reset changes. There's always a chance that *both* things might be needed, and the reset stuff didn't look obviously bad. Why dropped? Because... 1. Darren had problems with a black video screen with them and so did I (once I found an analog OTA station). 2. I also suspect those previous patches were not performing the format detection loop reset properly. 3. One could possibly reset the microcontroller all day long without auto-detection ever working. Also autodetection will auto-mute, and restart the detection loop, if it thinks the audio carrier went away. 4. Falling back to a known used audio standard, format, and mode is guaranteed to work. I guess it can be a problem in some region for some video stanadrd where one just can't know what each broadcaster is using. For NTSC-M this is not the case: BTSC at 4.5 MHz is always used. 5. I don't understand the exact failure mode of why the microcontroller is failing to detect the audio standard, so any other fix that doesn't explicitly set a standard will likely be unreliable. I'm tired of audio detection fixes with unpredictable outcomes based on variations in cable and OTA signal sources. Forcing the microcontroller to a particular standard, after autodetection fails, gives a deterministic outcome. (BTW, we really do need the microcontroller to do some work for us. No documentation accessable to me has enough detail to allow one to fully program the audio decoder portion of the A/V core. We have to rely on the microntroller firmware to set up some of the undocumented or unexplained registers.) I can always throw the other reset patches back in I guess, but this latest patch set should dominate the behavior of the microcontroller (if I didn't miss something because I was tired). I would be interested in hearing how frequent these patches show forced audio standard for you: [ 389.388200] cx18-0 843: Detected format: NTSC-M [ 389.388204] cx18-0 843: Specified standard:NTSC-M [ 389.388208] cx18-0 843: Specified video input: Composite 7 [ 389.388212] cx18-0 843: Specified audioclock freq: 48000 Hz [ 389.388232] cx18-0 843: Detected audio mode: forced mode [ 389.388237] cx18-0 843: Detected audio standard: forced audio standard [ 389.388241] cx18-0 843: Audio muted: no [ 389.388245] cx18-0 843: Audio microcontroller: running [ 389.388249] cx18-0 843: Configured audio standard: BTSC [ 389.388253] cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B) [ 389.388257] cx18-0 843: Specified audio input: Tuner (In8) [ 389.388261] cx18-0 843: Preferred audio mode: stereo meaning that the fallback audio settings were used because auto detection failed. 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Sun Apr 11 19:04:25 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14561:7c0b887911cf git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 184b7c85f31583632ad00c062a295b622759eef3 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: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS 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: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS 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: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/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: cx18: missing audio for analog recordings
Andy Walls wrote: On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). Regards, Andy So far, it seems fine, no black screens, and audio seems to be fine. -- 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: cx18: missing audio for analog recordings
On 11/04/10 03:01 PM, Andy Walls wrote: .. I can always throw the other reset patches back in I guess, but this latest patch set should dominate the behavior of the microcontroller (if I didn't miss something because I was tired). I would be interested in hearing how frequent these patches show forced audio standard for you: .. Thanks. Will do. I've added a printk() to the fallback path, so that it will show up in the syslog whenever the fallback is used. So far, no problem. But prior to now, the HVR-1600 regularly failed about once every 2-3 days according to the script I have which tests for the issue. On a similar note, while checking the logs last evening, I discovered that the muted episode of Survivor Heros Villians (two weeks ago) was actually recorded on the _PVR-250_ card. With no audio. This has happened before, though rarely -- perhaps once every 3-6 months or so. I wonder if a similar fix/workaround could be appropriate for that card as well? In the mean while, I guess I'll update my scripts to test/report for that one as well as the cx18/hvr1600. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] stv090x Fix kernel oops when plugging two cards
Hi linux-media, This patch fix initialization of the TT s2-1600 card when plugging two of them in the same box. The frontend relies on the fact that state-config-tuner_sleep is set to put the tuner sleep. However the config struct is shared amongst all cards. The patch adds a check for fe-tuner_priv to be set, validating that a tuner has been attached to the frontend. This has been introduced in commit 5ff2bc2dc92c on linux-tv's v4l-dvb mercurial. Signed-off-by : Guy Martin gms...@tuxicoman.be For reference, here is the null pointer deref : [ 96.521023] saa7146: register extension 'budget dvb'. [ 96.521052] budget dvb :05:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 96.521070] IRQ 16/: IRQF_DISABLED is not guaranteed on shared IRQs [ 96.521076] saa7146: found saa7146 @ mem c90011182c00 (revision 1, irq 16) (0x13c2,0x101c). [ 96.521080] saa7146 (0): dma buffer size 192512 [ 96.521081] DVB: registering new adapter (TT-Budget S2-1600 PCI) [ 96.539929] adapter has MAC addr = 00:d0:5c:cc:b0:a2 [ 96.890149] stv6110x_attach: Attaching STV6110x [ 96.912516] DVB: registering adapter 0 frontend 0 (STV090x Multistandard)... [ 96.912600] budget dvb :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 96.912639] IRQ 17/: IRQF_DISABLED is not guaranteed on shared IRQs [ 96.912667] saa7146: found saa7146 @ mem c90011314800 (revision 1, irq 17) (0x13c2,0x101c). [ 96.912673] saa7146 (1): dma buffer size 192512 [ 96.912676] DVB: registering new adapter (TT-Budget S2-1600 PCI) [ 96.930893] adapter has MAC addr = 00:d0:5c:cc:b0:a3 [ 97.233478] BUG: unable to handle kernel NULL pointer dereference at 0010 [ 97.233647] IP: [a029c450] stv6110x_set_mode+0x70/0x80 [stv6110x] [ 97.233753] PGD 3c16f067 PUD 3c383067 PMD 0 [ 97.234147] CPU 0 [ 97.234246] Pid: 5200, comm: modprobe Not tainted 2.6.33.2 #1 P5Q SE/P5Q SE [ 97.234317] RIP: 0010:[a029c450] [a029c450] stv6110x_set_mode+0x70/0x80 [stv6110x] [ 97.234456] RSP: 0018:88003c125c98 EFLAGS: 00010246 [ 97.234461] RAX: a029c460 RBX: 88003f84d800 RCX: 88003a19e140 [ 97.234461] RDX: RSI: 0001 RDI: [ 97.234461] RBP: 88003f84d828 R08: 0002 R09: 0004 [ 97.234461] R10: 0003 R11: 0010 R12: 88003f84d800 [ 97.234461] R13: 88003f84d828 R14: 88003f84d828 R15: 0001 [ 97.234461] FS: 7f9f7253e6f0() GS:88000180() knlGS: [ 97.234461] CS: 0010 DS: ES: CR0: 8005003b [ 97.234461] CR2: 0010 CR3: 3c382000 CR4: 06b0 [ 97.234461] DR0: DR1: DR2: [ 97.234461] DR3: DR6: 0ff0 DR7: 0400 [ 97.234461] Process modprobe (pid: 5200, threadinfo 88003c124000, task 88003e893ac0) [ 97.234461] 88003f84d800 88003f84d828 88003f84d800 a0292343 [ 97.234461] 0 88003f84d828 88003ef70ae0 a0280800 a02934d2 [ 97.234461] 0 a0295260 a02948b0 88003df79800 [ 97.234461] [a0292343] ? stv090x_sleep+0x33/0x120 [stv090x] [ 97.234461] [a02934d2] ? stv090x_attach+0x1e2/0x73c [stv090x] [ 97.234461] [81007cc5] ? dma_generic_alloc_coherent+0xa5/0x160 [ 97.234461] [a026e1f5] ? saa7146_init_one+0x7d5/0x910 [saa7146] [ 97.234461] [811b84b2] ? local_pci_probe+0x12/0x20 [ 97.234461] [811b87d0] ? pci_device_probe+0x110/0x120 [ 97.234461] [81221788] ? driver_probe_device+0x98/0x1b0 [ 97.234461] [81221933] ? __driver_attach+0x93/0xa0 [ 97.234461] [812218a0] ? __driver_attach+0x0/0xa0 [ 97.234461] [81220f18] ? bus_for_each_dev+0x58/0x80 [ 97.234461] [8122079d] ? bus_add_driver+0x14d/0x280 [ 97.234461] [a0284000] ? budget_init+0x0/0xc [budget] [ 97.234461] [81221c29] ? driver_register+0x79/0x170 [ 97.234461] [a0284000] ? budget_init+0x0/0xc [budget] [ 97.234461] [811b8a48] ? __pci_register_driver+0x58/0xe0 [ 97.234461] [a0284000] ? budget_init+0x0/0xc [budget] [ 97.234461] [810001d5] ? do_one_initcall+0x35/0x190 [ 97.234461] [81063d37] ? sys_init_module+0xe7/0x260 [ 97.234461] [8100256b] ? system_call_fastpath+0x16/0x1b [ 97.234461] RIP [a029c450] stv6110x_set_mode+0x70/0x80 [stv6110x] [ 97.234461] RSP 88003c125c98 [ 97.240074] ---[ end trace b53ecef15e99 ]--- Regards, Guydiff -r 7c0b887911cf linux/drivers/media/dvb/frontends/stv090x.c --- a/linux/drivers/media/dvb/frontends/stv090x.c Mon Apr 05 22:56:43 2010 -0400 +++ b/linux/drivers/media/dvb/frontends/stv090x.c Sun Apr 11 13:46:43 2010 +0200 @@ -4664,7 +4664,7 @@ if (stv090x_i2c_gate_ctrl(state, 1) 0) goto
[PATCH] TT S2-1600 allow more current for diseqc
Hi linux-media,
The following patch increases the current limit for the isl6423 chip
on the TT S2-1600 card. This allows DiSEqC to work with more complex
and current demanding configurations.
Signed-off-by: Guy Martin gms...@tuxicoman.be
Regards,
Guydiff -r 7c0b887911cf linux/drivers/media/dvb/ttpci/budget.c
--- a/linux/drivers/media/dvb/ttpci/budget.c Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/media/dvb/ttpci/budget.c Sun Apr 11 13:46:43 2010 +0200
@@ -461,7 +461,7 @@
};
static struct isl6423_config tt1600_isl6423_config = {
- .current_max = SEC_CURRENT_515m,
+ .current_max = SEC_CURRENT_800m,
.curlim = SEC_CURRENT_LIM_ON,
.mod_extern = 1,
.addr = 0x08,
Re: [PATCH] Fix default state Beholder H6 tuner.
Hi Mauro Em 01-04-2010 01:33, Dmitri Belimov escreveu: Hi Hermann Hi Dimitry, Am Mittwoch, den 31.03.2010, 13:14 +1000 schrieb Dmitri Belimov: Hi Hermann Hi, Am Dienstag, den 30.03.2010, 16:02 +1000 schrieb Dmitri Belimov: Hi The hybrid tuner FMD1216MEX_MK3 after cold start has disabled IF. This tuner has internal I2C switch. This switch switch I2C bus between DVB-T and IF part. Default state is DVB-T. When module saa7134 is load it can't find IF tda9887 and disable analog TV mode. This patch set internal I2C switch of the tuner to IF by send special value to the tuner as for receive analog TV from low band. It can be usefule for other cards. I didn't set configure a tuner by a tuner model because this tuner can has different I2C address. May be we can do it later after discuss for more robust support a tuners. just as a reminder. It is the same for the FMD1216ME hybrid MK3. After every boot, analog mode fails with missing tda9887. Currently, after tuner modules are not independent anymore, one has to reload the saa7134 driver once. Relevant code in tuner.core.c. case TUNER_PHILIPS_FMD1216ME_MK3: buffer[0] = 0x0b; buffer[1] = 0xdc; buffer[2] = 0x9c; buffer[3] = 0x60; i2c_master_send(c, buffer, 4); mdelay(1); buffer[2] = 0x86; buffer[3] = 0x54; i2c_master_send(c, buffer, 4); if (!dvb_attach(simple_tuner_attach, t-fe, t-i2c-adapter, t-i2c-addr, t-type)) goto attach_failed; break; That is good. I'll try add case TUNER_PHILIPS_FMD1216MEX_MK3 here and test. This is much better. it wont work for any what I can tell. We were forced into such an universal looking solution, but it was broken only a short time later. I for sure don't say that this time, late 2005, it was in anyway perfect, too much random on module load orders and also duplicate address stuff around meanwhile. But, however, it seems to be blocked for a global attempt within the current schemes too. Yes. Not worked. My patch is good for our customers right now. But when this subsystem is ready we can switch to use it. With my best regards, Dmitry. I'll apply the patch for now, but the better is to fix the TUNER_PHILIPS_FMD1216MEX_MK3. Dmitri, could you please try to fix it with a more generic solution? Ok. I'll do it later. With my best regards, Dmitry. Thanks, 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
saa7134 only one MPEG device
Hi Now saa7134 can support only one MPEG device. It can be MPEG2 encoder or DVB frontend. struct saa7134_dev-mops. But our TV card has two different MPEG devices: encoder and DVB frontend. I make some chandes for support both. But pointer to MPEG ops is only one. This is dmesh log with my changes. [ 33.587365] befor request_submodules [ 33.587530] saa7133[0]: registered device video0 [v4l2] [ 33.587592] saa7133[0]: registered device vbi0 [ 33.587658] saa7133[0]: registered device radio0 [ 33.592894] request_mod_async [ 33.592940] request mod empress [ 33.644596] saa7134_ts_register start [ 33.644645] mpeg_ops_attach start [ 33.644730] saa7133[0]: registered device video1 [mpeg] [ 33.644777] mpeg_ops_attach OK stop [ 33.644822] saa7134_ts_register stop [ 33.645894] dvb = 2 [ 33.645940] request mod dvb [ 33.767654] call saa7134_ts_register [ 33.767703] saa7134_ts_register start [ 33.767749] mpeg_ops_attach start [ 33.767800] mpeg_ops_attach FAIL stop, mops already exist FAILURE [ 33.767846] saa7134_ts_register stop Who can help me for add support multiple MPEG devices for saa7134? With my best regards, Dmitry. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
