Re: [PATCHv6] mx2_camera: Add soc_camera support for i.MX25/i.MX27
On Sun, 4 Jul 2010, Baruch Siach wrote: This is the soc_camera support developed by Sascha Hauer for the i.MX27. Alan Carvalho de Assis modified the original driver to get it working on more recent kernels. I modified it further to add support for i.MX25. This driver has been tested on i.MX25 and i.MX27 based platforms. Signed-off-by: Baruch Siach bar...@tkos.co.il Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de So, who shall be taking this patch? I'd prefer it go via ARM. Then you can easier satisfy any dependencies and enforce a certain patch order. It has my ack, just verified v6 - my ack still holds (I hope, Baruch did compile-test this new version on various i.MX2x versions). However, if you prefer, I can also take it via soc-camera / v4l. Sascha, what's your take? Thanks Guennadi --- Changes v5 - v6 Typo fix: s/CONFIG_MX2_VIDEO/CONFIG_VIDEO_MX2_HOSTSUPPORT/ Changes v4 - v5 Comments from Uwe Kleine-König: Enclose mx27 DMA related stuff in #ifdefs since the dma-mx1-mx2.h is no longer accessible to mx25 builds s/MX2_VIDEO/VIDEO_MX2_HOSTSUPPORT/ Changes v3 - v4 Address more comments from Guennadi Liakhovetski, including: * Fix the double trigger handling of mx27 eMMA * Add a FIXME comment in the code of eMMA overflow handling Changes v2 - v3 Address more comments from Guennadi Liakhovetski. Applied part of Sashca's patch that I forgot in v2. Changes v1 - v2 Addressed the comments of Guennadi Liakhovetski except from the following: 1. The mclk_get_divisor implementation, since I don't know what this code is good for 2. mx2_videobuf_release should not set pcdev-active on i.MX27, because mx27_camera_frame_done needs this pointer 3. In mx27_camera_emma_buf_init I don't know the meaning of those hard coded magic numbers Applied i.MX27 fixes from Sascha. arch/arm/plat-mxc/include/mach/memory.h |4 +- arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 + drivers/media/video/Kconfig | 13 + drivers/media/video/Makefile |1 + drivers/media/video/mx2_camera.c | 1513 ++ 5 files changed, 1575 insertions(+), 2 deletions(-) create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h create mode 100644 drivers/media/video/mx2_camera.c diff --git a/arch/arm/plat-mxc/include/mach/memory.h b/arch/arm/plat-mxc/include/mach/memory.h index c4b40c3..564ec9d 100644 --- a/arch/arm/plat-mxc/include/mach/memory.h +++ b/arch/arm/plat-mxc/include/mach/memory.h @@ -44,12 +44,12 @@ */ #define CONSISTENT_DMA_SIZE SZ_8M -#elif defined(CONFIG_MX1_VIDEO) +#elif defined(CONFIG_MX1_VIDEO) || defined(CONFIG_VIDEO_MX2_HOSTSUPPORT) /* * Increase size of DMA-consistent memory region. * This is required for i.MX camera driver to capture at least four VGA frames. */ #define CONSISTENT_DMA_SIZE SZ_4M -#endif /* CONFIG_MX1_VIDEO */ +#endif /* CONFIG_MX1_VIDEO || CONFIG_VIDEO_MX2_HOSTSUPPORT */ #endif /* __ASM_ARCH_MXC_MEMORY_H__ */ diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h b/arch/arm/plat-mxc/include/mach/mx2_cam.h new file mode 100644 index 000..3c080a3 --- /dev/null +++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h @@ -0,0 +1,46 @@ +/* + * mx2-cam.h - i.MX27/i.MX25 camera driver header file + * + * Copyright (C) 2003, Intel Corporation + * Copyright (C) 2008, Sascha Hauer s.ha...@pengutronix.de + * Copyright (C) 2010, Baruch Siach bar...@tkos.co.il + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. + */ + +#ifndef __MACH_MX2_CAM_H_ +#define __MACH_MX2_CAM_H_ + +#define MX2_CAMERA_SWAP16(1 0) +#define MX2_CAMERA_EXT_VSYNC (1 1) +#define MX2_CAMERA_CCIR (1 2) +#define MX2_CAMERA_CCIR_INTERLACE(1 3) +#define MX2_CAMERA_HSYNC_HIGH(1 4) +#define MX2_CAMERA_GATED_CLOCK (1 5) +#define MX2_CAMERA_INV_DATA (1 6) +#define MX2_CAMERA_PCLK_SAMPLE_RISING(1 7) +#define MX2_CAMERA_PACK_DIR_MSB (1 8) + +/** + * struct mx2_camera_platform_data - optional platform data for mx2_camera + * @flags: any combination of MX2_CAMERA_* + * @clk:
Re: RFC: Use of s_std calling s_freq when tuner powered down
On Fri, 2010-07-09 at 14:09 -0400, Devin Heitmueller wrote: Hello all, Here's the scenario: 1. I have a USB device that supports both an analog tuner and composite/s-video inputs 2. The bridge is smart enough to power down the tuner when capturing on composite/s-video 3. Changing the video standard appears to send set_freq() calls to the tuner, which in i2c fail because it's powered down. So I looked at the tuner-core code, and I'm seeing that tuner_s_std() will call set_freq() if the tuner-tv_freq field is nonzero. This seems reasonable, except as far as I can tell there is no way to set it to zero (because the places that set the value to zero will return failure because zero is outside the tuning range). This behavior happens with tvtime, which always does a tuning on startup, before switching to the A/V inputs. While I agree that I should probably fix tvtime so it doesn't do this, it seems strange that there is no way to reset tv_freq to zero when toggling away from the tuner input, so that these errors don't occur. Any thoughts? At the risk of missing something obvious: In your bridge driver's VIDIOC_S_STD ioctl() a. power up the analog tuner if it is not already b. call s_std for the subdevices (including the tuner), c. power down that analog tuner if not using the tuner input. No I2C errors in the log and the tuner is powered down when not in use, IMO, VIDIOC_S_STD is not a timing critical operation from userspace and it doesn't happen that often. You can also filter the cases when VIDIOC_S_STD is called on the same input, but the standard is not being changed. Regards, Andy Obviously I would like to eliminate the i2c errors from littering the dmesg log when there is no real failure condition. Devin -- 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: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Sat, 10 Jul 2010 22:30:58 -0400 Kyle Baker kyleaba...@gmail.com wrote: Is this change from 0x40 to 0x44 intended to fix the bad interface messages as well as the mic becoming disabled? Also, is a reboot after installing these drivers and changes required? I'm only curious because it takes so much longer to test changes. The change from 0x40 to 0x44 is applied to the GPIO register of the SN9C105 which is the bridge of the webcam. I was thinking that some values of this register could break the audio input. It does not seem so. The bad interface messages are printed when the audio interfaces are called by HAL for probe by the video driver. This is not an error. I will remove this message in the next version. Rebooting after installing a new version of a module is not needed. The module may be removed from memory by 'rmmod'. In your case, when updating sonixj, you just need to unplug the webcam, do rmmod gspca_sonixj and replug the webcam. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: RFC: Use of s_std calling s_freq when tuner powered down
Hi Andy, On Sun, Jul 11, 2010 at 9:23 AM, Andy Walls awa...@md.metrocast.net wrote: At the risk of missing something obvious: In your bridge driver's VIDIOC_S_STD ioctl() a. power up the analog tuner if it is not already b. call s_std for the subdevices (including the tuner), c. power down that analog tuner if not using the tuner input. No I2C errors in the log and the tuner is powered down when not in use, IMO, VIDIOC_S_STD is not a timing critical operation from userspace and it doesn't happen that often. You can also filter the cases when VIDIOC_S_STD is called on the same input, but the standard is not being changed. Thanks for taking the time to provide feedback. It's not timing critical, but on some tuners initialization can take several seconds (e.g. tda18271, xc5000). I'm not thrilled about it taking 3-5 seconds to change the standard (something which some applications may very well do on every channel change). I'm tempted to just jam a zero into the tuner-tv_freq when powering down the tuner, but that's not a very clean solution obviously. The tuner core makes decisions based on tuner-tv_freq not being zero, so I believe tuner_core should provide some way to reset it back to zero as needed. 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: Support for Pinnacle PCTV Quatro stick
On Sun, Jul 11, 2010 at 9:18 AM, Alexander Wirt formo...@formorer.de wrote: Hi, I recently got a Pinnacle PCTV Quatro stick which announces itself as PCTV 510e (ID: 2304:0242). It seemed that the em28xx-new driver had support for that stick, but as this is dead I know need some help. Is there anywhere support for this stick available? Not currently. The problem isn't the em28xx driver. The device uses the Micronas drx-k demodulator, for which there is not currently any open source driver. 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
Thoughts about suspending DVB C PCI device transparently
Hi all.
Once in a time I wrote into Mantis driver Suspend / resume
code. The idea was, that bridge driver (mantis_dvb.c) will
handle the suspend / resume transparently to the application.
With a PCI device this was rather easy to achieve.
With xine, there was just a glitch with video and audio
after resume.
So after suspend, frontend was tuned into the original
frequency, and the DMA transfer state was restored.
Suspend:
1. Turn off possible DMA transfer if active (feeds 0)
2. Remember tuner power on state.
3. Do tuner and fronted power off.
Resume:
1. Restore frontend and tuner power.
2. (feeds 0)? Set frequency for the tuner.
3. (feeds 0)? Restore DMA transfer into previous state.
What do you think about this?
I need some feedback: is it worth coding?
Other needed code is usual suspend / resume stuff.
Is it worth powering off the tuner, if it isn't
used?
For my current usage, powering off the unused tuner
gives more power savings than implementing suspend/resume.
Marko Ristola
--
// suspend to standby, ram or disk.
int mantis_dvb_suspend(struct mantis_pci *mantis, pm_message_t
prevState, pm_message_t mesg)
{
if (mantis-feeds 0)
mantis_dma_stop(mantis);
if (mantis-has_power)
mantis_fe_powerdown(mantis); // power off tuner.
return 0;
}
void mantis_dvb_resume(struct mantis_pci *mantis, pm_message_t prevMesg)
{
// power on frontend and tuner.
mantis_frontend_tuner_init(mantis);
if (mantis-feeds 0 mantis-fe-ops.tuner_ops.init)
(mantis-fe-ops.init)(mantis-fe);
if (mantis-feeds 0) {
(mantis-fe-ops.set_frontend)(mantis-fe, NULL);
mantis_dma_start(mantis);
}
}
--
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 Jul 11 19:00:26 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 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-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS 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: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS 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: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS 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: OK linux-git-powerpc64: OK 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: ERRORS 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: 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
[PATCH 04/12] media: autoconvert trivial BKL users to private mutex
All these files use the big kernel lock in a trivial
way to serialize their private file operations,
typically resulting from an earlier semi-automatic
pushdown from VFS.
None of these drivers appears to want to lock against
other code, and they all use the BKL as the top-level
lock in their file operations, meaning that there
is no lock-order inversion problem.
Consequently, we can remove the BKL completely,
replacing it with a per-file mutex in every case.
Using a scripted approach means we can avoid
typos.
file=$1
name=$2
if grep -q lock_kernel ${file} ; then
if grep -q 'include.*linux.mutex.h' ${file} ; then
sed -i '/include.*linux\/smp_lock.h/d' ${file}
else
sed -i 's/include.*linux\/smp_lock.h.*$/include
linux\/mutex.h/g' ${file}
fi
sed -i ${file} \
-e /^#include.*linux.mutex.h/,$ {
1,/^\(static\|int\|long\)/ {
/^\(static\|int\|long\)/istatic
DEFINE_MUTEX(${name}_mutex);
} } \
-e s/\(un\)*lock_kernel\[ ]*()/mutex_\1lock(\${name}_mutex)/g \
-e '/[ ]*cycle_kernel_lock();/d'
else
sed -i -e '/include.*\smp_lock.h\/d' ${file} \
-e '/cycle_kernel_lock()/d'
fi
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/bt8xx/dst_ca.c |7 ---
drivers/media/video/cx88/cx88-blackbird.c | 13 +++--
drivers/media/video/dabusb.c | 18 +-
drivers/media/video/se401.c |9 +
drivers/media/video/stradis.c |9 +
drivers/media/video/usbvideo/vicam.c | 14 +++---
6 files changed, 37 insertions(+), 33 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dst_ca.c b/drivers/media/dvb/bt8xx/dst_ca.c
index 770243c..f0c59c0 100644
--- a/drivers/media/dvb/bt8xx/dst_ca.c
+++ b/drivers/media/dvb/bt8xx/dst_ca.c
@@ -22,7 +22,7 @@
#include linux/module.h
#include linux/slab.h
#include linux/init.h
-#include linux/smp_lock.h
+#include linux/mutex.h
#include linux/string.h
#include linux/dvb/ca.h
#include dvbdev.h
@@ -52,6 +52,7 @@
} while(0)
+static DEFINE_MUTEX(dst_ca_mutex);
static unsigned int verbose = 5;
module_param(verbose, int, 0644);
MODULE_PARM_DESC(verbose, verbose startup messages, default is 1 (yes));
@@ -564,7 +565,7 @@ static long dst_ca_ioctl(struct file *file, unsigned int
cmd, unsigned long ioct
void __user *arg = (void __user *)ioctl_arg;
int result = 0;
- lock_kernel();
+ mutex_lock(dst_ca_mutex);
dvbdev = (struct dvb_device *)file-private_data;
state = (struct dst_state *)dvbdev-priv;
p_ca_message = kmalloc(sizeof (struct ca_msg), GFP_KERNEL);
@@ -652,7 +653,7 @@ static long dst_ca_ioctl(struct file *file, unsigned int
cmd, unsigned long ioct
kfree (p_ca_slot_info);
kfree (p_ca_caps);
- unlock_kernel();
+ mutex_unlock(dst_ca_mutex);
return result;
}
diff --git a/drivers/media/video/cx88/cx88-blackbird.c
b/drivers/media/video/cx88/cx88-blackbird.c
index e46e1ce..6bb59f1 100644
--- a/drivers/media/video/cx88/cx88-blackbird.c
+++ b/drivers/media/video/cx88/cx88-blackbird.c
@@ -33,7 +33,7 @@
#include linux/delay.h
#include linux/device.h
#include linux/firmware.h
-#include linux/smp_lock.h
+#include linux/mutex.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/cx2341x.h
@@ -44,6 +44,7 @@ MODULE_DESCRIPTION(driver for cx2388x/cx23416 based mpeg
encoder cards);
MODULE_AUTHOR(Jelle Foks je...@foks.us, Gerd Knorr kra...@bytesex.org
[SuSE Labs]);
MODULE_LICENSE(GPL);
+static DEFINE_MUTEX(mpeg_mutex);
static unsigned int mpegbufs = 32;
module_param(mpegbufs,int,0644);
MODULE_PARM_DESC(mpegbufs,number of mpeg buffers, range 2-32);
@@ -1057,7 +1058,7 @@ static int mpeg_open(struct file *file)
dprintk( 1, %s\n, __func__);
- lock_kernel();
+ mutex_lock(mpeg_mutex);
/* Make sure we can acquire the hardware */
drv = cx8802_get_driver(dev, CX88_MPEG_BLACKBIRD);
@@ -1065,7 +1066,7 @@ static int mpeg_open(struct file *file)
err = drv-request_acquire(drv);
if(err != 0) {
dprintk(1,%s: Unable to acquire hardware, %d\n,
__func__, err);
- unlock_kernel();
+ mutex_unlock(mpeg_mutex);
return err;
}
}
@@ -1073,7 +1074,7 @@ static int mpeg_open(struct file *file)
if (!atomic_read(dev-core-mpeg_users)
blackbird_initialize_codec(dev) 0) {
if (drv)
drv-request_release(drv);
- unlock_kernel();
+ mutex_unlock(mpeg_mutex);
return -EINVAL;
}
dprintk(1, open dev=%s\n, video_device_node_name(vdev));
@@ -1083,7 +1084,7 @@ static int mpeg_open(struct file *file)
if
[PATCH 00/12] autoconvert trivial BKL users to private mutex
This is a repost of an earlier patch to remove those users of the big kernel lock that can be converted to a mutex using a simple script. The only use of the BKL is in file operations that are called without any other lock, so the new mutex is the top-level serialization and cannot introduce any AB-BA deadlock. Please apply to the respective maintainer trees if the patches look good. Arnd Bergmann (12): staging: autoconvert trivial BKL users to private mutex isdn: autoconvert trivial BKL users to private mutex scsi: autoconvert trivial BKL users to private mutex media: autoconvert trivial BKL users to private mutex usb: autoconvert trivial BKL users to private mutex net: autoconvert trivial BKL users to private mutex cris: autoconvert trivial BKL users to private mutex sbus: autoconvert trivial BKL users to private mutex mtd: autoconvert trivial BKL users to private mutex mac: autoconvert trivial BKL users to private mutex ipmi: autoconvert trivial BKL users to private mutex drivers: autoconvert trivial BKL users to private mutex arch/cris/arch-v10/drivers/eeprom.c|2 - arch/cris/arch-v10/drivers/i2c.c |2 - arch/cris/arch-v32/drivers/cryptocop.c |2 - arch/cris/arch-v32/drivers/i2c.c | 12 drivers/block/paride/pg.c |7 ++-- drivers/block/paride/pt.c | 19 ++-- drivers/char/apm-emulation.c | 11 --- drivers/char/applicom.c|9 +++-- drivers/char/ds1302.c | 15 + drivers/char/ds1620.c |8 ++-- drivers/char/dsp56k.c | 27 + drivers/char/dtlk.c|8 ++-- drivers/char/generic_nvram.c |7 ++-- drivers/char/genrtc.c | 13 drivers/char/i8k.c |7 ++-- drivers/char/ip2/ip2main.c |8 ++-- drivers/char/ipmi/ipmi_devintf.c | 14 drivers/char/ipmi/ipmi_watchdog.c |8 ++-- drivers/char/lp.c | 15 + drivers/char/mbcs.c|8 ++-- drivers/char/mmtimer.c |7 ++-- drivers/char/mwave/mwavedd.c | 44 ++-- drivers/char/nvram.c | 11 --- drivers/char/nwflash.c | 12 drivers/char/pcmcia/cm4000_cs.c| 11 --- drivers/char/pcmcia/cm4040_cs.c|7 ++-- drivers/char/ppdev.c |8 ++-- drivers/char/rio/rio_linux.c |7 ++-- drivers/char/snsc.c|9 +++-- drivers/char/toshiba.c |9 +++-- drivers/char/viotape.c | 11 --- drivers/char/xilinx_hwicap/xilinx_hwicap.c |6 ++-- drivers/hwmon/fschmd.c |6 ++-- drivers/hwmon/w83793.c |6 ++-- drivers/input/misc/hp_sdc_rtc.c|7 ++-- drivers/isdn/capi/capi.c |6 ++-- drivers/isdn/divert/divert_procfs.c|7 ++-- drivers/isdn/hardware/eicon/divamnt.c |7 ++-- drivers/isdn/hardware/eicon/divasi.c |2 - drivers/isdn/hardware/eicon/divasmain.c|2 - drivers/isdn/hysdn/hysdn_procconf.c| 21 +++-- drivers/isdn/hysdn/hysdn_proclog.c | 15 + drivers/isdn/i4l/isdn_common.c | 27 + drivers/isdn/mISDN/timerdev.c |7 ++-- drivers/macintosh/adb.c| 10 +++--- drivers/macintosh/smu.c|6 ++-- drivers/macintosh/via-pmu.c| 11 --- drivers/media/dvb/bt8xx/dst_ca.c |7 ++-- drivers/media/video/cx88/cx88-blackbird.c | 13 drivers/media/video/dabusb.c | 18 ++-- drivers/media/video/se401.c|9 +++-- drivers/media/video/stradis.c |9 +++-- drivers/media/video/usbvideo/vicam.c | 14 drivers/message/fusion/mptctl.c| 15 + drivers/message/i2o/i2o_config.c | 23 +++--- drivers/misc/phantom.c | 11 --- drivers/mtd/mtdchar.c | 15 + drivers/net/ppp_generic.c | 19 ++-- drivers/net/wan/cosa.c | 10 +++--- drivers/pci/hotplug/cpqphp_sysfs.c | 13 drivers/rtc/rtc-m41t80.c | 13 drivers/sbus/char/display7seg.c|8 ++-- drivers/sbus/char/envctrl.c|2 - drivers/sbus/char/flash.c | 15 + drivers/sbus/char/openprom.c | 15 + drivers/sbus/char/uctrl.c |7 ++-- drivers/scsi/3w-9xxx.c |7 ++--
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Sun, Jul 11, 2010 at 9:50 AM, Jean-Francois Moine moin...@free.fr wrote: The change from 0x40 to 0x44 is applied to the GPIO register of the SN9C105 which is the bridge of the webcam. I was thinking that some values of this register could break the audio input. It does not seem so. It looks like this webcam has not been working properly since Ubuntu Hardy. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/280657 I'm not sure of the version included in Hardy. Would it help if I tried to find the GSPCA version from Hardy to compare the changes? In searching for details on this webcam model, I came across some patches that you submitted a while back that initialize the GPIO with different values. I tested those, but saw no results. I see you've worked on this specific driver quiet a bit in the past: http://linuxtv.org/hg/~hgoede/gspca/rev/65247a979498 Is the previous maintainer, Michel Xhaard, still working on this driver at all? I wonder if he might be able to help identify the problem or narrow it down. Which function is called when I open Cheese or other video applications? Initializing the webcam appears to be correct, however, sd_start() or the one that starts the video capture appears to be toggling or changing some setting. If I knew of a way, I would insert more debug messages to help pinpoint the place where the microphone breaks along with some boolean to show that its working or not. Thanks. -- Kyle Baker -- 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: Status of the patches under review at LMML (60 patches)
Hi Mauro, Sorry for the late reply about Mar, 1 2010: firedtv: add parameter to fake ca_system_ids in CA_INFO http://patchwork.kernel.org/patch/82912 The reason why I wanted to make this fix in the kernel driver and not in MythTV was that the problem was hardware related and not MythTV related. I.e. I wanted to compensate in the kernel driver and not in the specific application for the shortcoming of this one hardware. MythTV uses the CI as allowed by the specification, but due to the shortcomings in the card's firmware, the driver is unable to answer one of the CI messages correctly. The current implementation tries to guess an answer (which is often the correct one) using the manufacturer ID as the CA_system_id, but since that is not always true, sometimes the driver will simply lie in its answer. I can understand your reluctance to the patch since it adds a parameter that requires quite some low level knowledge to use. However, I still see that this should be corrected in the kernel driver of the faulty hardware and not in a specific application. Regards, Henrik This is the summary of the patches that are currently under review at Linux Media Mailing List linux-media@vger.kernel.org. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). P.S.: This email is c/c to the developers where some action is expected. If you were copied, please review the patches, acking/nacking or submitting an update. == New patches - waiting for some days for more review == Jul, 1 2010: v4l2-dev: fix memory leak http://patchwork.kernel.org/patch/109191 Jul, 5 2010: soc-camera: module_put() fix http://patchwork.kernel.org/patch/110202 Jul, 4 2010: IR/mceusb: unify and simplify different gen device init http://patchwork.kernel.org/patch/110078 Jul, 6 2010: [1/2] Added Technisat Skystar USB HD CI http://patchwork.kernel.org/patch/110395 Jul, 6 2010: [2/2] Retrieve firmware for az6027 http://patchwork.kernel.org/patch/110394 == Need more tests/acks from DVB users == Jun,27 2010: Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function http://patchwork.kernel.org/patch/108274 == Better to wait for videobuf changes == Mar,17 2010: [2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memor http://patchwork.kernel.org/patch/97263 May,26 2010: [1/2] media: Add timberdale video-in driver http://patchwork.kernel.org/patch/102414 == Waiting for a new version from Jonathan Corbet cor...@lwn.net == Jun, 7 2010: Add the viafb video capture driver http://patchwork.kernel.org/patch/104840 == Depends on input get_bigkeycode stuff that got postponed == May,20 2010: input: fix error at the default input_get_keycode call http://patchwork.kernel.org/patch/101122 == Waiting for Pawel Osciak p.osc...@samsung.com comments - are they ready for review/merge ? == Jun,16 2010: [1/7] ARM: Samsung: Add FIMC driver register definition and platform h http://patchwork.kernel.org/patch/106457 Jun,16 2010: [2/7] ARM: Samsung: Add platform definitions for local FIMC/FIMD fifo http://patchwork.kernel.org/patch/106459 Jun,16 2010: [3/7] s3c-fb: Add v4l2 subdevice to support framebuffer local fifo inp http://patchwork.kernel.org/patch/106445 Jun,16 2010: [4/7] v4l: Add Samsung FIMC (video postprocessor) driver http://patchwork.kernel.org/patch/106448 Jun,16 2010: [5/7] ARM: S5PV210: Add fifo link definitions for fimc and framebuffer http://patchwork.kernel.org/patch/106447 Jun,16 2010: [6/7] ARM: S5PV210: enable FIMC on Aquila http://patchwork.kernel.org/patch/106449 Jun,16 2010: [7/7] ARM: S5PC100: enable FIMC on SMDKC100 http://patchwork.kernel.org/patch/106454 Jun,28 2010: v4l: mem2mem_testdev: fix g_fmt NULL pointer dereference http://patchwork.kernel.org/patch/108321 == Soc_camera waiting for Guennadi Liakhovetski g.liakhovet...@gmx.de review == May,11 2010: [v3] soc_camera_platform: Add necessary v4l2_subdev_video_ops method http://patchwork.kernel.org/patch/98660 Jun,21 2010: mx2_camera: Add soc_camera support for i.MX25/i.MX27 http://patchwork.kernel.org/patch/107126 Jun,21 2010: mx27: add support for the CSI device http://patchwork.kernel.org/patch/107124 Jun,21 2010: mx25: add support for the CSI device http://patchwork.kernel.org/patch/107125 Jul, 4 2010: mx2_camera: Add soc_camera support for i.MX25/i.MX27
