[PATCH] drx-k: Fix QAM Annex C selection
Ralph/Oliver,
As I said before,the DRX-K logic to select DVB-C annex A seems wrong.
Basically, it sets Annex A at setEnvParameters, but this var is not
used anywhere. However, as setParamParameters[2] is not used, I suspect
that this is a typo.
The enclosed patch fixes it, but, on my tests here with devices with
drx-3913k and drx-3926k, DVB-C is not working with the drxk_a3.mc firmware.
So, I'm not sure if the devices I have don't support that firmware,
or if the DVB-C code is broken or is not supported by such firmware.
I'm getting the drxk_a3.mc via Documentation/dvb/get_dvb_firmware
from:
http://l4m-daten.de/files/DDTuner.zip
With the firmware I'm using, SCU_RAM_COMMAND_CMD_DEMOD_SET_PARAM only
accepts 1 parameter.
So, I can't actually test it.
Could you please double-check it?
Thanks!
Mauro
-
Fix the DRX-K logic to select DVB-C annex A
setEnvParameters, but this var is not used anywhere. However, as
setParamParameters[2] is not used, it seems to be a typo.
The enclosed patch fixes it.
This patch was not tested.
While here, corrects a bad identation at the fallback code for
other types of firmware.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index b3dbe82..d420464 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -5384,8 +5384,6 @@ static int SetQAM(struct drxk_state *state, u16
IntermediateFreqkHz,
s32 tunerFreqOffset)
{
int status;
- u8 parameterLen;
- u16 setEnvParameters[5] = { 0, 0, 0, 0, 0 };
u16 setParamParameters[4] = { 0, 0, 0, 0 };
u16 cmdResult;
@@ -5416,13 +5414,12 @@ static int SetQAM(struct drxk_state *state, u16
IntermediateFreqkHz,
goto error;
/* Env parameters */
- setEnvParameters[2] = QAM_TOP_ANNEX_A; /* Annex */
+ setParamParameters[2] = QAM_TOP_ANNEX_A;/* Annex */
if (state-m_OperationMode == OM_QAM_ITU_C)
- setEnvParameters[2] = QAM_TOP_ANNEX_C; /* Annex */
+ setParamParameters[2] = QAM_TOP_ANNEX_C;/* Annex */
setParamParameters[3] |= (QAM_MIRROR_AUTO_ON);
/* check for LOCKRANGE Extented */
/* setParamParameters[3] |= QAM_LOCKRANGE_NORMAL; */
- parameterLen = 4;
/* Set params */
switch (state-param.u.qam.modulation) {
@@ -5453,6 +5450,7 @@ static int SetQAM(struct drxk_state *state, u16
IntermediateFreqkHz,
status = scu_command(state, SCU_RAM_COMMAND_STANDARD_QAM |
SCU_RAM_COMMAND_CMD_DEMOD_SET_PARAM, 4, setParamParameters, 1, cmdResult);
if (status 0) {
+ u16 setEnvParameters[5] = { 0, 0, 0, 0, 0 };
/* Fall-back to the simpler call */
setParamParameters[0] = QAM_TOP_ANNEX_A;
if (state-m_OperationMode == OM_QAM_ITU_C)
@@ -5461,8 +5459,8 @@ static int SetQAM(struct drxk_state *state, u16
IntermediateFreqkHz,
setEnvParameters[0] = 0;
status = scu_command(state, SCU_RAM_COMMAND_STANDARD_QAM |
SCU_RAM_COMMAND_CMD_DEMOD_SET_ENV, 1, setEnvParameters, 1, cmdResult);
- if (status 0)
- goto error;
+ if (status 0)
+ goto error;
setParamParameters[0] = state-m_Constellation; /*
constellation */
setParamParameters[1] = DRXK_QAM_I12_J17; /* interleave
mode */
--
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] Fix regression introduced which broke the Hauppauge USBLive 2
Hi Devin,
Em 23-07-2011 22:17, Devin Heitmueller escreveu:
The following patch addresses the regression introduced in the cx231xx
driver which stopped the Hauppauge USBLive2 from working.
Confirmed working by both myself and the user who reported the issue
on the KernelLabs blog (Robert DeLuca).
cx231xx: Fix regression introduced which broke the Hauppauge USBLive 2
From: Devin Heitmueller dheitmuel...@kernellabs.com
At some point during refactoring of the cx231xx driver, the USBLive 2 device
became broken. This patch results in the device working again.
Thanks to Robert DeLuca for sponsoring this work.
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
Cc: Robert DeLuca robertdel...@me.com
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 4b22afe..d02c63a 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -387,6 +387,7 @@ struct cx231xx_board cx231xx_boards[] = {
.norm = V4L2_STD_NTSC,
.no_alt_vanc = 1,
.external_av = 1,
+ .dont_use_port_3 = 1,
.input = {{
.type = CX231XX_VMUX_COMPOSITE1,
.vmux = CX231XX_VIN_2_1,
I proposed the same fix sometime ago, when Gerd reported this issue
for me. His feedback was that this partially fixed the issue, but
he reported that he also needed to increase the set_power_mode delay
from 5 to 50 ms in order to fully initialize the cx231xx hardware,
as on the enclosed patch. It seems he tested with vanilla Fedora kernel.
So, I suspect that HZ may be affecting this driver as well. As you know,
if HZ is configured with 100, the minimum msleep() delay will be 10.
so, instead of waiting for 5ms, it will wait for 10ms for the device
to powerup.
It would be great to configure HZ with 1000 and see the differences with
and without Gerd's patch.
Cheers,
Mauro.
-
From a83a7574e07b48b1c6a222d833a7fa0a67133b5c Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kra...@gmail.com
Date: Thu, 16 Dec 2010 17:39:17 +0100
Subject: [PATCH] cx231xx: raise delay after powerup.
Wait a bit longer after power up so the chips have enougth
time to come up before we try talking to them via i2c.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/media/video/cx231xx/cx231xx-avcore.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c
b/drivers/media/video/cx231xx/cx231xx-avcore.c
index cf50faf..cf412cd 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -2412,7 +2412,7 @@ int cx231xx_set_power_mode(struct cx231xx *dev, enum
AV_MODE mode)
break;
}
- msleep(PWR_SLEEP_INTERVAL);
+ msleep(PWR_SLEEP_INTERVAL * 10);
/* For power saving, only enable Pwr_resetout_n
when digital TV is selected. */
--
--
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] Fix regression introduced which broke the Hauppauge USBLive 2
On Sun, Jul 24, 2011 at 8:57 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: I proposed the same fix sometime ago, when Gerd reported this issue for me. His feedback was that this partially fixed the issue, but he reported that he also needed to increase the set_power_mode delay from 5 to 50 ms in order to fully initialize the cx231xx hardware, as on the enclosed patch. It seems he tested with vanilla Fedora kernel. So, I suspect that HZ may be affecting this driver as well. As you know, if HZ is configured with 100, the minimum msleep() delay will be 10. so, instead of waiting for 5ms, it will wait for 10ms for the device to powerup. It would be great to configure HZ with 1000 and see the differences with and without Gerd's patch. Cheers, Mauro. I don't dispute the possibility that there is some *other* bug that effects users who have some other value for HZ, but neither I nor the other use saw it. Without this patch though, the device is broken for *everybody*. I would suggest checking in this patch, and separately the HZ issue can be investigated. I'll see if I can find some cycles today to reconfigure my kernel with a different HZ. Will also check the datasheets and see if Conexant documented any sort of time for power ramping. It's not uncommon for such documentation to include a diagram showing timing for power up. 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: [PATCH] Fix regression introduced which broke the Hauppauge USBLive 2
On Sun, Jul 24, 2011 at 9:02 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: I don't dispute the possibility that there is some *other* bug that effects users who have some other value for HZ, but neither I nor the other use saw it. Without this patch though, the device is broken for *everybody*. I would suggest checking in this patch, and separately the HZ issue can be investigated. I'll see if I can find some cycles today to reconfigure my kernel with a different HZ. Will also check the datasheets and see if Conexant documented any sort of time for power ramping. It's not uncommon for such documentation to include a diagram showing timing for power up. Reconfigured CONFIG_HZ to 1000 and indeed I am seeing the problem. Will try to track down the correct fix this afternoon. -- 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
[GIT FIXES FOR 3.1] pwc: various fixes
Hi Mauro, Please pull from my tree for 2 bug fixes patches + support for control events for the pwc driver. Note that the control events patch depends upon the patches from hverkuils poll tree (and those patches are thus also in my tree, but not part of this pull req). The following changes since commit 30178e8623281063c18592a848cdcd71f78f603d: vivi: let vb2_poll handle events. (2011-07-18 13:07:28 +0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.1 Dan Carpenter (1): pwc: precedence bug in pwc_init_controls() Hans de Goede (2): pwc: Add support for control events pwc: properly mark device_hint as unused in all probe error paths drivers/media/video/pwc/pwc-if.c | 79 ++-- drivers/media/video/pwc/pwc-v4l.c | 18 +++-- drivers/media/video/pwc/pwc.h |4 ++ 3 files changed, 49 insertions(+), 52 deletions(-) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] pwc: precedence bug in pwc_init_controls()
Hi, Thanks I've added your patch to my gspca/pwc tree and send an updated pull request to Mauro including your patch. Regards, Hans On 07/23/2011 08:53 PM, Dan Carpenter wrote: '!' has higher precedence than'' so we need parenthesis here. Signed-off-by: Dan Carpentererro...@gmail.com diff --git a/drivers/media/video/pwc/pwc-v4l.c b/drivers/media/video/pwc/pwc-v4l.c index e9a0e94..8c70e64 100644 --- a/drivers/media/video/pwc/pwc-v4l.c +++ b/drivers/media/video/pwc/pwc-v4l.c @@ -338,7 +338,7 @@ int pwc_init_controls(struct pwc_device *pdev) if (pdev-restore_factory) pdev-restore_factory-flags = V4L2_CTRL_FLAG_UPDATE; - if (!pdev-features FEATURE_MOTOR_PANTILT) + if (!(pdev-features FEATURE_MOTOR_PANTILT)) return hdl-error; /* Motor pan / tilt / reset */ -- 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
s2ram/resume issue w/ kernel 3.0 and Terratec Cinergy T USB XXS (HD)/ T3
Hello, s2ram and resume a docked ThinkPad T400 with a plugged in DVB-stick gives this with the new kernel 3.0 under an almost stable Gentoo linux : 2011-07-24T17:53:34.252+02:00 n22 kernel: PM: resume of devices complete after 2093.868 msecs 2011-07-24T17:53:34.252+02:00 n22 kernel: dvb-usb: found a 'Terratec Cinergy T USB XXS (HD)/ T3' in cold state, will try to load a firmware 2011-07-24T17:53:34.252+02:00 n22 kernel: [ cut here ] 2011-07-24T17:53:34.252+02:00 n22 kernel: WARNING: at drivers/base/firmware_class.c:524 _request_firmware+0x35e/0x380() 2011-07-24T17:53:34.252+02:00 n22 kernel: Hardware name: 6474B84 2011-07-24T17:53:34.252+02:00 n22 kernel: Modules linked in: rc_dib0700_rc5 ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder dvb_usb_dib0700 dib7000p dib0090 dib7000m dib0070 dvb_usb dib8000 dvb_core dib3000mc rc_core dibx000_common loop rfcomm bnep ipt_MASQUERADE ipt_REJECT xt_recent xt_tcpudp xt_mac nf_conntrack_ftp xt_state xt_limit ipt_LOG iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter xt_owner xt_multiport ip_tables x_tables af_packet pppoe pppox ppp_generic slhc bridge stp llc tun snd_seq snd_seq_device fuse dm_mod acpi_cpufreq mperf hid_cherry btusb bluetooth cryptomgr usbhid crypto_hash aead pcompress crypto_blkcipher usblp hid arc4 crypto_algapi snd_hda_codec_conexant fbcon crc16 font sr_mod bitblit sg cdrom i915 softcursor drm_kms_helper drm mac80211 fb snd_hda_intel fbdev snd_hda_codec cfg80211 snd_pcm i2c_algo_bit i2c_i801 cfbcopyarea snd_timer 8250_pnp i2c_core intel_agp thinkpad_acpi hwmon rfkill uhci_hcd 8250_pci snd ehci_hcd snd_page_alloc usbcore intel_gtt 8250 psmouse agpgart rtc_cmos wmi evdev soundcore e1000e nvram processor serial_core video thermal battery cfbimgblt ac button cfbfillrect [last unloaded: iwlagn] 2011-07-24T17:53:34.252+02:00 n22 kernel: Pid: 30451, comm: default.sh Not tainted 3.0.0 #2 2011-07-24T17:53:34.252+02:00 n22 kernel: Call Trace: 2011-07-24T17:53:34.252+02:00 n22 kernel: [c1039272] warn_slowpath_common+0x72/0xa0 2011-07-24T17:53:34.252+02:00 n22 kernel: [c11fc6de] ? _request_firmware+0x35e/0x380 2011-07-24T17:53:34.252+02:00 n22 kernel: [c11fc6de] ? _request_firmware+0x35e/0x380 2011-07-24T17:53:34.252+02:00 n22 kernel: [c10392c2] warn_slowpath_null+0x22/0x30 2011-07-24T17:53:34.252+02:00 n22 kernel: [c11fc6de] _request_firmware+0x35e/0x380 2011-07-24T17:53:34.252+02:00 n22 kernel: [c11fc79f] request_firmware+0x1f/0x30 2011-07-24T17:53:34.252+02:00 n22 kernel: [f837233d] dvb_usb_download_firmware+0x2d/0xe0 [dvb_usb] 2011-07-24T17:53:34.252+02:00 n22 kernel: [f934cf60] ? dib0700_download_firmware+0x380/0x380 [dvb_usb_dib0700] 2011-07-24T17:53:34.252+02:00 n22 kernel: [f934cf60] ? dib0700_download_firmware+0x380/0x380 [dvb_usb_dib0700] 2011-07-24T17:53:34.252+02:00 n22 kernel: [f837299f] dvb_usb_device_init+0x43f/0x5e0 [dvb_usb] 2011-07-24T17:53:34.252+02:00 n22 kernel: [f934c9e9] dib0700_probe+0x59/0xd0 [dvb_usb_dib0700] 2011-07-24T17:53:34.252+02:00 n22 kernel: [f8199922] usb_probe_interface+0xd2/0x1d0 [usbcore] 2011-07-24T17:53:34.252+02:00 n22 kernel: [c113c157] ? sysfs_create_link+0x17/0x20 2011-07-24T17:53:34.252+02:00 n22 kernel: [c11f30c7] driver_probe_device+0x77/0x1a0 2011-07-24T17:53:34.253+02:00 n22 kernel: [f8198739] ? usb_match_id+0x49/0x70 [usbcore] 2011-07-24T17:53:34.253+02:00 n22 kernel: [c11f32d9] __device_attach+0x49/0x60 2011-07-24T17:53:34.253+02:00 n22 kernel: [c11f2433] bus_for_each_drv+0x53/0x80 2011-07-24T17:53:34.253+02:00 n22 kernel: [c11f33ba] device_attach+0x8a/0xa0 2011-07-24T17:53:34.253+02:00 n22 kernel: [c11f3290] ? __driver_attach+0xa0/0xa0 2011-07-24T17:53:34.253+02:00 n22 kernel: [f8199ade] usb_rebind_intf+0x3e/0x60 [usbcore] 2011-07-24T17:53:34.253+02:00 n22 kernel: [c11f829f] ? dpm_show_time+0xef/0x150 2011-07-24T17:53:34.253+02:00 n22 kernel: [f8199b85] do_unbind_rebind+0x65/0x90 [usbcore] 2011-07-24T17:53:34.253+02:00 n22 kernel: [f8199c21] usb_resume+0x71/0xc0 [usbcore] 2011-07-24T17:53:34.253+02:00 n22 kernel: [f818e16f] usb_dev_complete+0xf/0x20 [usbcore] 2011-07-24T17:53:34.253+02:00 n22 kernel: [c11f7abb] dpm_complete+0x4b/0x140 2011-07-24T17:53:34.253+02:00 n22 kernel: [c11f87d7] dpm_resume_end+0x17/0x20 2011-07-24T17:53:34.253+02:00 n22 kernel: [c10735d7] suspend_devices_and_enter+0xa7/0x260 2011-07-24T17:53:34.253+02:00 n22 kernel: [c107389d] enter_state+0x10d/0x130 2011-07-24T17:53:34.253+02:00 n22 kernel: [c1072e13] state_store+0x73/0xb0 2011-07-24T17:53:34.253+02:00 n22 kernel: [c1072da0] ? pm_async_store+0x40/0x40 2011-07-24T17:53:34.253+02:00 n22 kernel: [c1184320] kobj_attr_store+0x20/0x30 2011-07-24T17:53:34.253+02:00 n22 kernel: [c113a409] sysfs_write_file+0x99/0xf0 2011-07-24T17:53:34.253+02:00 n22 kernel: [c10eca5a] vfs_write+0x9a/0x160 2011-07-24T17:53:34.253+02:00 n22 kernel: [c113a370] ? sysfs_open_file+0x200/0x200
Re: [PATCH v4 1/1] libv4l: Add plugin support to libv4l
Hi, On 07/22/2011 05:39 PM, Yordan Kamenov wrote: Hi Hans, Hans de Goede wrote: Hi, Sorry it took so long, but I've just merged the plugin support into v4l-utils git. I did make some minor mods / bugfixes before merging, see the commit message in git. Regards, Hans p.s. I think we should expand the plugin support with support for a output devices, iow add a write() dev_op. If you guys agree I can easily do so myself, we should do this asap before people start depending on the ABI (although there is no ABI stability promise until I release 0.10.x, see my message to the list wrt the start of the 0.9.x cycle). I think that it is a good point, you can add write() and reserved dev_ops. Ok, done, this is in v4l-utils git master now. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
23.07.2011 19:09, Mauro Carvalho Chehab wrote: In this case, it will not be autounmuted after tuning. Hard to tell about your solution without seeing a patch. OK, it turns out the automute code is already there, but it doesn't work. The driver for some reasons starts the scan on initialization, finds the carrier: --- saa7134[0]/audio: found PAL main sound carrier @ 6.000 MHz [3969/324] --- and, because of that, disables the automute. If the real mute is not enabled at that point, you get the white noise right away. Since I have no idea why it finds some carrier, I can't fix that in any way. Or, maybe, not to call the scan on driver init? What will that break? Anyway, as long as the automute code is broken, we should either start fixing it, or fix PA, or fix mplayer... Dunno. I wonder how come so many bugs left unfixed for so long, resulting in a white noise to people... -- 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] do not change mute state for capturing audio
Em 24-07-2011 14:45, Stas Sergeev escreveu: 23.07.2011 19:09, Mauro Carvalho Chehab wrote: In this case, it will not be autounmuted after tuning. Hard to tell about your solution without seeing a patch. OK, it turns out the automute code is already there, but it doesn't work. The driver for some reasons starts the scan on initialization, finds the carrier: --- saa7134[0]/audio: found PAL main sound carrier @ 6.000 MHz [3969/324] --- and, because of that, disables the automute. If the real mute is not enabled at that point, you get the white noise right away. The automute code works fine. Maybe you have a strong interference at the default tuning frequency, leading into saa7134 miss-detection. For saa7134 driver: 1) There is an audio carrier; 2) an application wants to listen audio; 3) the device is at automute mode. So, when there's an audio carrier, it will unmute the audio at streaming start. The driver is doing the _right_ thing by letting the audio to flow to PA, when it starts the capture. Unfortunately, on your specific device, starting audio capture also enables audio at the audio output pin. So, you're noticing a problem. People with a saa7134 device without alsa stream won't notice it (old devices). People with alsa stream without anything connected to the LINE OUT people aren't noticing it, if PA is not copying the saa7134 PCM IN stream to the sound card PCM out device (the default, for PA). So, only people that has saa7134 with alsa stream that opted to wire the saa7134 device to the sound card, and with a strong interference at the default tunning frequency (400 MHz) would notice a problem. Since I have no idea why it finds some carrier, I can't fix that in any way. Or, maybe, not to call the scan on driver init? What will that break? Analog tuners need to be tuned at the device init on a high frequency according with their datasheets, otherwise the PLL may fail. Anyway, as long as the automute code is broken, we should either start fixing it, or fix PA, or fix mplayer... As I always said, the fix should be at PA, as it makes no sense to start capturing at saa7134 without first configuring it. So, or PA should be converted into a V4L2-aware application, in order to properly init the device (with seems to be the wrong approach) or it _SHOULD_NOT_ automatically enable capture on those devices, as this may cause undesired side effects, on the devices that have the capture pin directly wired to the output pin, witch seems to be the case of your device. PS.: it seems that you've removed Lennart/alsa people from the c/c. I'm re-adding them, as I'm expecting a fix from their side. Dunno. I wonder how come so many bugs left unfixed for so long, resulting in a white noise to people... You're the first one that reported it, and the code is there for _years_. So, this is not a commonly noticed problem at all. 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
[PATCH] cx231xx: Fix power ramping issue
Attached is a patch which addresses the issue discussed by Mauro and Gerd for the -32 errors seen with the Hauppauge USBLive 2. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com cx231xx: Fix power ramp time to be consistent regardless of CONFIG_HZ From: Devin Heitmueller dheitmuel...@kernellabs.com On platforms that have CONFIG_HZ set to 100, the power ramp time effectively ends up being 10ms. However, on those that have a higher CONFIG_HZ, the time ends up *actually* being 5ms, which doesn't allow enough time for the hardware to be fully powered up before attempting to address it via i2c. Change the constant to 10ms, which is long enough for the hardware to power up, and won't really be anymore time than it was previously on platforms with CONFIG_HZ being 100. Credit goes to Mauro Carvalho Chehab and Gerd Hoffmann who previously investigated this issue. Tested with the Hauppauge USBLive 2, with which the problem was readily reproducible after setting CONFIG_HZ to 1000. Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Gerd Hoffmann kra...@redhat.com diff --git a/drivers/media/video/cx231xx/cx231xx.h b/drivers/media/video/cx231xx/cx231xx.h index b39b85e..472d169 100644 --- a/drivers/media/video/cx231xx/cx231xx.h +++ b/drivers/media/video/cx231xx/cx231xx.h @@ -43,7 +43,7 @@ #include cx231xx-conf-reg.h #define DRIVER_NAME cx231xx -#define PWR_SLEEP_INTERVAL 5 +#define PWR_SLEEP_INTERVAL 10 /* I2C addresses for control block in Cx231xx */ #define AFE_DEVICE_ADDRESS 0x60
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jul 24 19:00:38 CEST 2011 git hash:f0a21151140da01c71de636f482f2eddec2840cc gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS 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][saa7134] do not change mute state for capturing audio
24.07.2011 22:36, Mauro Carvalho Chehab wrote: So, only people that has saa7134 with alsa stream that opted to wire the saa7134 device to the sound card, and with a strong interference at the default tunning frequency (400 MHz) would notice a problem. No, the strong interference thing have nothing to do with it, I think. My card detects signal sometimes, not always. Otherwise it says this: --- saa7134[0]/audio: audio carrier scan failed, using 5.500 MHz [default] --- yet the moise is still there. If you look into a tvaudio_thread() function, you'll notice that it disables automute _unconditionally_! saa7134_tvaudio_do_scan() also disables automute unconditionally. That's why I think there are bugs. Can we start from fixing at least this, and see what happens then? Since I have no idea why it finds some carrier, I can't fix that in any way. Or, maybe, not to call the scan on driver init? What will that break? Analog tuners need to be tuned at the device init on a high frequency according with their datasheets, otherwise the PLL may fail. OK. Maybe, not disabling the automute when the scan was started at init, rather than when it was requested by an app? You're the first one that reported it, and the code is there for _years_. So, this is not a commonly noticed problem at all. I am only the first one who reported it _to that list_. I think most other reports were against pulseaudio. -- 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] cx231xx: Provide signal lock status in G_INPUT
The attached patch reports the signal lock statistics to userland,
which allows apps to know if there is a signal present even in cases
where it cannot rely on G_TUNER since it won't make calls for such if
the device lacks a tuner.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
cx231xx: show real signal status in G_INPUT/ENUM_INPUT ioctl results
From: Devin Heitmueller dheitmuel...@kernellabs.com
Make use of the signal state registers to properly populate the signal lock
registers in the cx231xx driver.
This allows applications to know whether there is a signal present even in
devices which lack a tuner (since such apps typically won't call G_TUNER if
no tuner is present).
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
diff --git a/drivers/media/video/cx231xx/cx231xx-video.c b/drivers/media/video/cx231xx/cx231xx-video.c
index a69c24d..9ed56b7 100644
--- a/drivers/media/video/cx231xx/cx231xx-video.c
+++ b/drivers/media/video/cx231xx/cx231xx-video.c
@@ -1179,7 +1179,8 @@ static int vidioc_enum_input(struct file *file, void *priv,
{
struct cx231xx_fh *fh = priv;
struct cx231xx *dev = fh-dev;
- unsigned int n;
+ u32 gen_stat;
+ unsigned int ret, n;
n = i-index;
if (n = MAX_CX231XX_INPUT)
@@ -1198,6 +1199,20 @@ static int vidioc_enum_input(struct file *file, void *priv,
i-std = dev-vdev-tvnorms;
+ /* If they are asking about the active input, read signal status */
+ if (n == dev-video_input) {
+ ret = cx231xx_read_i2c_data(dev, VID_BLK_I2C_ADDRESS,
+ GEN_STAT, 2, gen_stat, 4);
+ if (ret 0) {
+ if ((gen_stat FLD_VPRES) == 0x00) {
+i-status |= V4L2_IN_ST_NO_SIGNAL;
+ }
+ if ((gen_stat FLD_HLOCK) == 0x00) {
+i-status |= V4L2_IN_ST_NO_H_LOCK;
+ }
+ }
+ }
+
return 0;
}
[PATCH] au8522: set signal field to 100% when signal present
This patch makes the HVR-950q behave consistently with other drivers, which is to show the signal level as 100% in cases where we have a signal present but given we are unable to determine an actual signal level. The old code would set the value to 1, which divided by 65535 is rounded down to 0%. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com au8522: set signal field to 100% when signal present From: Devin Heitmueller dheitmuel...@kernellabs.com The signal state field in G_TUNER is typically scaled from 0-100%. Since we don't know the signal level, we really would prefer the field to contain 100% than 1/256, which in many utilities (such as v4l2-ctl) rounds to 0% even when a signal is actually present. This patch makes the behavior consistent with other drivers. Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com diff --git a/drivers/media/dvb/frontends/au8522_decoder.c b/drivers/media/dvb/frontends/au8522_decoder.c index b537891..2b248c1 100644 --- a/drivers/media/dvb/frontends/au8522_decoder.c +++ b/drivers/media/dvb/frontends/au8522_decoder.c @@ -692,7 +692,7 @@ static int au8522_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt) /* Interrogate the decoder to see if we are getting a real signal */ lock_status = au8522_readreg(state, 0x00); if (lock_status == 0xa2) - vt-signal = 0x01; + vt-signal = 0x; else vt-signal = 0x00;
Re: [PATCH] videobuf2: call buf_finish() on unprocessed buffers
Hi Jon,
There is a misunderstanding here. This patch will call buf_finish for
some buffers twice. A buffer does not get removed from queued_list
even if it is on the done_list. A buffer gets into the queued_list on
qbuf, gets into the done_list after an operation is finished and is
removed from both lists on dqbuf. This means that you shouldn't call
buf_finish for buffers on both lists, only for all buffers in the
queued_list, as it is a superset of both.
--
Best regards,
Pawel Osciak
On Thu, Jul 14, 2011 at 14:09, Jonathan Corbet cor...@lwn.net wrote:
When user space stops streaming, there may be buffers which have been given
to buf_prepare() and which may or may not have been passed to buf_queue().
The videobuf2 core simply takes those buffers back; if buf_prepare() does
work that needs cleaning up (like setting up a DMA mapping), that cleanup
will not happen.
This patch establishes a simple contract with drivers: buffers given to
buf_prepare() will eventually see a buf_finish() call.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/videobuf2-core.c | 8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6ba1461..2ba08ab 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1177,6 +1177,7 @@ EXPORT_SYMBOL_GPL(vb2_streamon);
*/
static void __vb2_queue_cancel(struct vb2_queue *q)
{
+ struct vb2_buffer *vb;
unsigned int i;
/*
@@ -1188,13 +1189,18 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
q-streaming = 0;
/*
- * Remove all buffers from videobuf's list...
+ * Remove all buffers from videobuf's list... Give the driver
+ * a chance to clean them up first, though.
*/
+ list_for_each_entry(vb, q-queued_list, queued_entry)
+ call_qop(q, buf_finish, vb);
INIT_LIST_HEAD(q-queued_list);
/*
* ...and done list; userspace will not receive any buffers it
* has not already dequeued before initiating cancel.
*/
+ list_for_each_entry(vb, q-done_list, done_entry)
+ call_qop(q, buf_finish, vb);
INIT_LIST_HEAD(q-done_list);
wake_up_all(q-done_wq);
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/RFC] media: vb2: change queue initialization order
Hi Jon and Marek, On Thu, Jun 30, 2011 at 15:18, Jonathan Corbet cor...@lwn.net wrote: On Wed, 29 Jun 2011 16:10:45 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: I do still wonder why this is an issue - why not pass the buffers through to the driver at VIDIOC_QBUF time? I assume there must be a reason for doing things this way, I'd like to understand what it is. I want to delay giving the ownership of the buffers to the driver until it is certain that start_streaming method will be called. This way I achieve a well defined states of the queued buffers: 1. successful start_streaming() - the driver is processing the queue buffers 2. unsuccessful start_streaming() - the driver is responsible to discard all queued buffers 3. stop_streaming() called - the driver has finished or discarded all queued buffers So it's a buffer ownership thing. I wonder if there would be value in adding a buf_give_them_all_back_now() callback? You have an implicit change of buffer ownership now that seems easy for drivers to mess up. It might be better to send an explicit signal at such times and, perhaps, even require the driver to explicitly hand each buffer back to vb2? That would make the rules clear and give some flexibility - stopping and starting streaming without needing to start over with buffers, for example. Dunno, I'm just sort of babbling as I think; what's there now clearly works. The original reason behind not passing buffers to the driver at QBUF time was very simple: a driver, when given a buffer by videobuf, was supposed to start using it right away. The drivers did not have to have a notion of streaming state, which was to be managed entirely in videobuf. This greatly simplified drivers, as their logic needed only to be: on buf_queue() start processing immediately and give back the buffer as soon as finished. This approach was assuming that enabling/disabling a device (e.g. making it start or stop capturing) was fast and simple though. And it simplified cancelling/destroying the queue. So yes, it was an ownership thing (and still is). The reality seems to be proving different, the drivers want to know about streaming, as enabling and disabling their devices can be complicated and/or may be taking a significant amount of time (too long to be done on QBUF without slowing down things). On the other hand, V4L2 allows starting streaming without queuing any buffers (not for OUTPUT devices though, for obvious reasons). At first, videobuf would not allow STREAMON only for OUTPUT devices if no buffers were queued. Now it looks like most would prefer, by default, disallowing STREAMON with no buffers queued even for CAPTURE devices, unless a driver requests otherwise (the new flag in the above patch). The buf_give_them_all_back_now() callback is already there actually. It's stop_streaming(). That's why stop_streaming is required, while start_streaming is not. I'll try to clarify that in my incoming documentation patches. I like the general idea of this patch, making the behavior configurable by a driver. We can still have simple drivers that don't care about streaming state this way. Although I'm not sure which variant should be the default. I agree that a better idea would be to make driver check for it itself in start_streaming. Makes it simpler, and there would be no default either. But there is one catch: if we allow buf_queue() to be called without streaming on, all drivers will have to implement start_streaming, so it will have to become mandatory. Am I right Marek? -- Best regards, Pawel Osciak -- 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
webcam doesn't work on some USB ports (gspca_sonixj module)
I have a Microsoft LifeCam VX-3000. My desktop computer has two USB buses. 4 external ports on one bus in the back of the computer, and 2 external ports on another bus in the front. The webcam only works properly on the front-facing ports. I'm using the lastest stable release of the gspca_sonixj module. The problems I experience is that the webcam is not able to work with Google's gchat video chatting. The screen remains black for a few seconds, before fading to gray. Sometimes I see myself for a split-second before it fades to gray permanently. The webcam always work fine with local programs like cheese. syslog output: webcam plugged into bad USB bus: Jul 24 22:09:22 Bluemoon kernel: [432235.451132] usb 1-1.3: new full speed USB device using ehci_hcd and address 10 Jul 24 22:09:22 Bluemoon kernel: [432235.562660] gspca-2.13.2: probing 045e:00f5 Jul 24 22:09:22 Bluemoon kernel: [432235.563467] sonixj-2.13.2: Sonix chip id: 11 Jul 24 22:09:22 Bluemoon kernel: [432235.564042] input: sonixj as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/input/input17 Jul 24 22:09:22 Bluemoon kernel: [432235.564178] gspca-2.13.2: video0 created Jul 24 22:09:22 Bluemoon rtkit-daemon[1365]: Successfully made thread 9824 of process 1506 (n/a) owned by '1000' RT at priority 5. Jul 24 22:09:22 Bluemoon rtkit-daemon[1365]: Supervising 4 threads of 1 processes of 1 users. Jul 24 22:09:40 Bluemoon kernel: [432253.344199] gspca-2.13.2: bandwidth not wide enough - trying again Jul 24 22:09:41 Bluemoon kernel: [432254.622338] gspca-2.13.2: bandwidth not wide enough - trying again Jul 24 22:09:42 Bluemoon kernel: [432255.900844] gspca-2.13.2: bandwidth not wide enough - trying again Jul 24 22:09:44 Bluemoon kernel: [432257.179608] gspca-2.13.2: bandwidth not wide enough - trying again Jul 24 22:09:45 Bluemoon kernel: [432258.457975] gspca-2.13.2: bandwidth not wide enough - trying again ... (repeats) webcam plugged into good USB bus: Jul 24 22:06:47 Bluemoon kernel: [432080.751839] usb 2-1.4: new full speed USB device using ehci_hcd and address 9 Jul 24 22:06:47 Bluemoon kernel: [432080.863272] gspca-2.13.2: probing 045e:00f5 Jul 24 22:06:47 Bluemoon kernel: [432080.863943] sonixj-2.13.2: Sonix chip id: 11 Jul 24 22:06:47 Bluemoon kernel: [432080.864304] input: sonixj as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.4/input/input15 Jul 24 22:06:47 Bluemoon kernel: [432080.864578] gspca-2.13.2: video0 created Jul 24 22:06:47 Bluemoon rtkit-daemon[1365]: Successfully made thread 9637 of process 1506 (n/a) owned by '1000' RT at priority 5. Jul 24 22:06:47 Bluemoon rtkit-daemon[1365]: Supervising 4 threads of 1 processes of 1 users. Jul 24 22:07:22 Bluemoon kernel: [432116.213808] gspca-2.13.2: bandwidth not wide enough - trying again Jul 24 22:07:24 Bluemoon kernel: [432117.542586] gspca-2.13.2: bandwidth not wide enough - trying again Jul 24 22:07:25 Bluemoon kernel: [432118.831024] gspca-2.13.2: bandwidth not wide enough - trying again (webcam operates normally at this point) Has anyone seen this before? Any suggestions to help debug this? -Dave -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
