[PATCH] fix dvb frontend lockup
matthieu castet a écrit :
Hi,
With my current kernel (2.6.32), if my dvb device is removed while in
use, I got [1].
After checking the source code, the problem seems to happen also in
master :
If there are users (for example users == -2) :
- dvb_unregister_frontend :
- stop kernel thread with dvb_frontend_stop :
- fepriv->exit = 1;
- thread loop catch stop event and break while loop
- fepriv->thread = NULL; and fepriv->exit = 0;
- dvb_unregister_frontend wait on "fepriv->dvbdev->wait_queue" that
fepriv->dvbdev->users==-1.
The user finish :
- dvb_frontend_release - set users to -1
- don't wait wait_queue because fepriv->exit != 1
=> dvb_unregister_frontend never exit the wait queue.
Matthieu
[ 4920.484047] khubd D c2008000 0 198 2 0x
[ 4920.484056] f64c8000 0046 c2008000 0004 c13fa000
c13fa000 f
64c8000
[ 4920.484066] f64c81bc c2008000 d9d9dce6 0452 0001
f64c8000 c
102daad
[ 4920.484075] 00100100 f64c81bc 0286 f0a7ccc0 f0913404 f0cba404
f644de58 f
092b0a8
[ 4920.484084] Call Trace:
[ 4920.484102] [] ? default_wake_function+0x0/0x8
[ 4920.484147] [] ? dvb_unregister_frontend+0x95/0xcc [dvb_core]
[ 4920.484157] [] ? autoremove_wake_function+0x0/0x2d
[ 4920.484168] [] ? dvb_usb_adapter_frontend_exit+0x12/0x21
[dvb_usb]
[ 4920.484176] [] ? dvb_usb_exit+0x26/0x88 [dvb_usb]
[ 4920.484184] [] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb]
[ 4920.484217] [] ? usb_unbind_interface+0x3f/0xb4 [usbcore]
[ 4920.484227] [] ? __device_release_driver+0x74/0xb7
[ 4920.484233] [] ? device_release_driver+0x15/0x1e
[ 4920.484243] [] ? bus_remove_device+0x6e/0x87
[ 4920.484249] [] ? device_del+0xfa/0x152
[ 4920.484264] [] ? usb_disable_device+0x59/0xb9 [usbcore]
[ 4920.484279] [] ? usb_disconnect+0x70/0xdc [usbcore]
[ 4920.484294] [] ? hub_thread+0x521/0xe1d [usbcore]
[ 4920.484301] [] ? autoremove_wake_function+0x0/0x2d
[ 4920.484316] [] ? hub_thread+0x0/0xe1d [usbcore]
[ 4920.484321] [] ? kthread+0x61/0x66
[ 4920.484327] [] ? kthread+0x0/0x66
[ 4920.484336] [] ? kernel_thread_helper+0x7/0x10
Here a patch that fix the issue
Signed-off-by: Matthieu CASTET
--- 1/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2010-03-27 22:59:50.0 +0100
+++ 2/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2010-03-27 23:01:34.0 +0100
@@ -686,7 +686,10 @@
}
fepriv->thread = NULL;
- fepriv->exit = 0;
+ if (kthread_should_stop())
+ fepriv->exit = 2;
+ else
+ fepriv->exit = 0;
mb();
dvb_frontend_wakeup(fe);
@@ -1929,6 +1932,8 @@
int ret;
dprintk ("%s\n", __func__);
+ if (fepriv->exit == 2)
+ return -ENODEV;
if (adapter->mfe_shared) {
mutex_lock (&adapter->mfe_lock);
@@ -2021,7 +2026,7 @@
ret = dvb_generic_release (inode, file);
if (dvbdev->users == -1) {
- if (fepriv->exit == 1) {
+ if (fepriv->exit) {
fops_put(file->f_op);
file->f_op = NULL;
wake_up(&dvbdev->wait_queue);
[PATCH] V4L/DVB: mx1-camera: compile fix
This fixes a regression of 7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old names) Signed-off-by: Uwe Kleine-König --- arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h |8 +++- drivers/media/video/mx1_camera.c |8 +++- 2 files changed, 10 insertions(+), 6 deletions(-) Hello, changed since last post: - put offset in the definition of MX1_DMA_REG in parenthesis - describe register definitions now moved to dma-mx1-mx2.h with the full register names and order by address. Thanks Uwe diff --git a/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h b/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h index 07be8ad..4b63b05 100644 --- a/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h +++ b/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h @@ -31,7 +31,13 @@ #define DMA_MODE_WRITE 1 #define DMA_MODE_MASK 1 -#define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR) +#define MX1_DMA_REG(offset)MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR + (offset)) + +/* DMA Interrupt Mask Register */ +#define MX1_DMA_DIMR MX1_DMA_REG(0x08) + +/* Channel Control Register */ +#define MX1_DMA_CCR(x) MX1_DMA_REG(0x8c + ((x) << 6)) #define IMX_DMA_MEMSIZE_32 (0 << 4) #define IMX_DMA_MEMSIZE_8 (1 << 4) diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c index c167cc3..aa81acd 100644 --- a/drivers/media/video/mx1_camera.c +++ b/drivers/media/video/mx1_camera.c @@ -48,8 +48,6 @@ /* * CSI registers */ -#define DMA_CCR(x) (0x8c + ((x) << 6)) /* Control Registers */ -#define DMA_DIMR 0x08/* Interrupt mask Register */ #define CSICR1 0x00/* CSI Control Register 1 */ #define CSISR 0x08/* CSI Status Register */ #define CSIRXR 0x10/* CSI RxFIFO Register */ @@ -783,7 +781,7 @@ static int __init mx1_camera_probe(struct platform_device *pdev) pcdev); imx_dma_config_channel(pcdev->dma_chan, IMX_DMA_TYPE_FIFO, - IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0); + IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0); /* burst length : 16 words = 64 bytes */ imx_dma_config_burstlen(pcdev->dma_chan, 0); @@ -797,8 +795,8 @@ static int __init mx1_camera_probe(struct platform_device *pdev) set_fiq_handler(&mx1_camera_sof_fiq_start, &mx1_camera_sof_fiq_end - &mx1_camera_sof_fiq_start); - regs.ARM_r8 = DMA_BASE + DMA_DIMR; - regs.ARM_r9 = DMA_BASE + DMA_CCR(pcdev->dma_chan); + regs.ARM_r8 = (long)MX1_DMA_DIMR; + regs.ARM_r9 = (long)MX1_DMA_CCR(pcdev->dma_chan); regs.ARM_r10 = (long)pcdev->base + CSICR1; regs.ARM_fp = (long)pcdev->base + CSISR; regs.ARM_sp = 1 << pcdev->dma_chan; -- 1.7.0 -- 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:Sat Mar 27 19:00:27 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14527:1ef0265456c8 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: 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: WARNINGS 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/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: Open Source Hardware Video Capture
On Thu, 2010-03-25 at 10:21 -0400, Brian Phelps wrote: > I am looking for help on the following project. > http://www.opencircuits.com/OpenHDCapture > > All the hardware is open source and all specs and design (what little there > is right now) are available via git: > > git clone git:// > openhdcapture.git.sourceforge.net/gitroot/openhdcapture/openhdcapture(read-only) > If anyone has any suggestions or would like to help please contact me off > list. I am still working on setting up a mailing list for this project but > you can email me. You may wish to post such announcements to linux-media@vger.kernel.org . The video4linux-list is about dead. > When we have a working prototype I would like to add in the V4l2 API to the > driver. Good luck. Implementing the V4L2 API can be a large undertaking. A not quite out of date copy of the spec can be found on linuxtv.org: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html 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
tm6000
Hi Mauro,
First, I have a question, in the function "int tm6000_cards_setup(struct
tm6000_core *dev)" have you reset gpio 1 and 4, but why? In my lastest
patch I have add a few sticks and it's works with and without this
part.What for sticks use this part? For a week I have become a email
with usbsnoop log from a tm5600 based stick and I have analysed it.
Resume is that I think it use two reset gpio's.
1. GPIO1 = 0
2. GPIO4 = 0
3. wait a few ms
4. GPIO1 = 1
5. GPIO4 = 1
/*
* Default initialization. Most of the devices seem to use GPIO1
* and GPIO4.on the same way, so, this handles the common sequence
* used by most devices.
* If a device uses a different sequence or different GPIO pins for
* reset, just add the code at the board-specific part
*/
for (i = 0; i < 2; i++) {
rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev->gpio.tuner_reset, 0x00);
if (rc < 0) {
printk(KERN_ERR "Error %i doing GPIO1 reset\n", rc);
return rc;
}
msleep(10); /* Just to be conservative */
rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev->gpio.tuner_reset, 0x01);
if (rc < 0) {
printk(KERN_ERR "Error %i doing GPIO1 reset\n", rc);
return rc;
}
msleep(10);
rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 0);
if (rc < 0) {
printk(KERN_ERR "Error %i doing GPIO4 reset\n", rc);
return rc;
}
msleep(10);
rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 1);
if (rc < 0) {
printk(KERN_ERR "Error %i doing GPIO4 reset\n", rc);
return rc;
}
if (!i) {
rc = tm6000_get_reg16(dev, 0x40, 0, 0);
if (rc >= 0)
printk(KERN_DEBUG "board=%d\n", rc);
}
}
For a week I have become a email with usbsnoop log from a tm5600 based
stick and I have analysed it. Resume is that I think it use two reset
gpio's.
1. GPIO1 = 0
2. GPIO4 = 0
3. wait a few ms
4. GPIO1 = 1
5. GPIO4 = 1
So I think, if it a part from function tm6000_cards_setup is, then is
that part wrong and must remove to tuner_callback function.
Second, I will rewrite the gpio's into a struct.
for example:
in tm6000.h
struct tm6000_gpio {
inttuner_reset;
inttuner_on;
intdemod_reset;
intdemod_on;
intpower_led;
intdvb_led;
intir;
};
in tm6000_card.c
[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
.name = "Terratec Cinergy Hybrid XE / Cinergy Hybrid-Stick",
.tuner_type = TUNER_XC2028, /* has a XC3028 */
.tuner_addr = 0xc2 >> 1,
.demod_addr = 0x1e >> 1,
.type = TM6010,
.caps = {
.has_tuner= 1,
.has_dvb= 1,
.has_zl10353= 1,
.has_eeprom= 1,
.has_remote= 1,
},
.gpio = {
.tuner_reset = TM6010_GPIO_2,
.tuner_on= TM6010_GPIO_3,
.demod_reset= TM6010_GPIO_1,
.demod_on= TM6010_GPIO_4,
.power_led= TM6010_GPIO_7,
.dvb_led= TM6010_GPIO_5,
.ir= TM6010_GPIO_0,
},
},
The rest I send in the patch email. So can the gpio's define in the
board struct and using per label in the functions.
Stefan Ringel
--
Stefan Ringel
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Testers for the cpia2 driver wanted!
On Saturday 27 March 2010 13:25:44 Andy Walls wrote:
> On Wed, 2010-03-24 at 08:55 +0100, Hans Verkuil wrote:
> > Hi all,
> >
> > I'm looking for someone who has hardware that can test the cpia2 driver.
> >
> > I thought I had hardware for that, but it turned out that it used the gspca
> > mars driver instead.
>
> A co-worker just gave me an Intel Play QX3 microscope:
>
> [ 1218.810045] usb 3-3: new full speed USB device using ohci_hcd and
> address 3
> [ 1219.026373] usb 3-3: configuration #1 chosen from 1 choice
> [ 1219.027352] usb 3-3: New USB device found, idVendor=0813,
> idProduct=0001
> [ 1219.027358] usb 3-3: New USB device strings: Mfr=2, Product=1,
> SerialNumber=0
> [ 1219.027363] usb 3-3: Product: Intel Play QX3 Microscope
> [ 1219.027367] usb 3-3: Manufacturer: Mattel Inc.
> [ 1219.145032] gspca: main v2.9.0 registered
> [ 1219.152733] gspca: probing 0813:0001
> [ 1219.152758] cpia1: cpia CPiA camera detected (vid/pid
> 0x0813:0x0001)
> [ 1219.479599] cpia1: CPIA Version: 1.33 (2.10)
> [ 1219.479614] cpia1: CPIA PnP-ID: 0813:0001:0106
> [ 1219.479619] cpia1: VP-Version: 1.0 0100
> [ 1219.481976] gspca: video2 created
> [ 1219.482271] usbcore: registered new interface driver cpia1
> [ 1219.484291] cpia1: registered
> [ 1219.500235] V4L-Driver for Vision CPiA based cameras v1.2.3
> [ 1219.500256] Since in-kernel colorspace conversion is not allowed,
> it is disabled by default now. Users should fix the applications in case they
> don't work without conversion reenabled by setting the 'colorspace_conv'
> module parameter to 1
> [ 1219.508170] USB driver for Vision CPiA based cameras v1.2.3
> [ 1219.508267] usbcore: registered new interface driver cpia
>
>
> But it looks like it is not supported by cpia2:
>
> $ grep 'USB_DEVICE(.*813' cpia* cpia2/* gspca/*
> cpia_usb.c: { USB_DEVICE(0x0813, 0x0001) },
> gspca/cpia1.c: {USB_DEVICE(0x0813, 0x0001)},
> gspca/ov519.c: {USB_DEVICE(0x0813, 0x0002), .driver_info =
> BRIDGE_OV511PLUS },
>
> Is there any testing you need done with this device?
No, thanks. I think that the original QX3 had the cpia2 device, but that later
models switched to other sensors.
Thanks for looking at this!
Hans
>
>
> Regards,
> Andy
>
>
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Mauro, When I had last replied to your email, I didn't check if the patch is actually applied to your v4l_for_linux branch of fixes.git tree. But Today I checked and I can't find the patch merged to this tree as you had mentioned.. So if you haven't merged it for some reason, please merge my updated patch available at https://patchwork.kernel.org/patch/86731/ Murali On Wed, Mar 24, 2010 at 3:50 PM, Mauro Carvalho Chehab wrote: > Hi Murali, > > Karicheri, Muralidharan wrote: >> Please discard this patch. I have sent an updated version to the list. > > The patch were already added at the fixes tree. I can't just discard, since > this > would break any other tree based on it. If the patch is so deadly broken, then > we can add a rollback patch, making our and upstream tree dirty. Another > alternative > would be to add just a diff between the two patches. > > Btw, please send me a patchwork ID when you want to refer to a patch sent > to the mailing list, especially when there are two patches with the same name. > Is this the one you're referring? > X-Patchwork-Id: 86729 > > Cheers, > Mauro. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
[GIT PATCHES FOR 2.6.35] - vpfe capture enhancements to support AM3517
Mauro, Please pull from the following:- The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d: Jonathan Corbet (1): V4L/DVB: ov7670: silence some compiler warnings are available in the git repository at: git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream_03_27 Vaibhav Hiremath (7): V4L: dm644x_ccdc: Debug register read prints removed V4L: vpfe_capture: Add call back function for interrupt clear for vpfe_cfg V4L: dm644x_ccdc: Add 10bit BT support V4L: vpfe_capture: Return 0 from suspend/resume V4L: dm644x_ccdc: Add Suspend/Resume Support V4L: vpfe_capture: Add support for USERPTR mode of operation V4L: tvp514x: Add Powerup sequence during s_input to lock the signal properly drivers/media/video/davinci/dm644x_ccdc.c | 131 +++- drivers/media/video/davinci/dm644x_ccdc_regs.h | 10 ++- drivers/media/video/davinci/vpfe_capture.c | 78 ++- drivers/media/video/tvp514x.c | 13 +++ include/media/davinci/vpfe_capture.h |2 + 5 files changed, 203 insertions(+), 31 deletions(-) -- 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
[PATCH] cx88: fix setting input when using DVB
(Sorry for the double post, the previous one did not include the patch)
In cx88-mpeg.c, there is code that sets core->input to CX88_VMUX_DVB.
However, this may be incorrect, since core->input is actually an
index to core->board.input[], which has not enough elements to be
indexed by the value of CX88_VMUX_DVB. So, the modified code searches
core->board.input[] for an input with a type of CX88_VMUX_DVB, and if
it does not find one, the index is simply set to zero.
The change may not have much effect, though, since it appears the only
case when core->input is actually used is when the current input is
being queried.
Signed-off-by: Istvan Varga
diff -r -d -N -U4 v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-mpeg.c v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-mpeg.c
--- v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-mpeg.c 2010-03-23 03:39:52.0 +0100
+++ v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-mpeg.c 2010-03-23 19:07:26.0 +0100
@@ -637,15 +637,24 @@
/* Driver asked for hardware access. */
static int cx8802_request_acquire(struct cx8802_driver *drv)
{
struct cx88_core *core = drv->core;
+ unsigned int i;
/* Fail a request for hardware if the device is busy. */
if (core->active_type_id != CX88_BOARD_NONE &&
core->active_type_id != drv->type_id)
return -EBUSY;
- core->input = CX88_VMUX_DVB;
+ core->input = 0;
+ for (i = 0;
+ i < (sizeof(core->board.input) / sizeof(struct cx88_input));
+ i++) {
+ if (core->board.input[i].type == CX88_VMUX_DVB) {
+ core->input = i;
+ break;
+ }
+ }
if (drv->advise_acquire)
{
mutex_lock(&drv->core->lock);
[PATCH] cx88: fix setting input when using DVB
In cx88-mpeg.c, there is code that sets core->input to CX88_VMUX_DVB. However, this may be incorrect, since core->input is actually an index to core->board.input[], which has not enough elements to be indexed by the value of CX88_VMUX_DVB. So, the modified code searches core->board.input[] for an input with a type of CX88_VMUX_DVB, and if it does not find one, the index is simply set to zero. The change may not have much effect, though, since it appears the only case when core->input is actually used is when the current input is being queried. Signed-off-by: Istvan Varga -- 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] cx88: implement sharpness control
This patch adds support for V4L2_CID_SHARPNESS by changing the luma peak
filter and notch filter. It can be set in the range 0 to 9, with 0 being
the original and default mode.
One minor problem is that other code that sets the registers being used
(for example when switching TV channels) could reset the control to the
default. This could be avoided by making changes so that the bits used
to implement this control are not overwritten.
Signed-off-by: Istvan Varga
diff -r -d -N -U4 v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-video.c v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-video.c
--- v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-video.c 2010-03-23 03:39:52.0 +0100
+++ v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-video.c 2010-03-23 19:07:26.0 +0100
@@ -220,9 +220,24 @@
.off = 0,
.reg = MO_UV_SATURATION,
.mask = 0x00ff,
.shift = 0,
- },{
+ }, {
+ .v = {
+ .id= V4L2_CID_SHARPNESS,
+ .name = "Sharpness",
+ .minimum = 0,
+ .maximum = 9,
+ .default_value = 0x0,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ },
+ .off = 0,
+ /* NOTE: the value is converted and written to both even
+ and odd registers in the code */
+ .reg = MO_FILTER_ODD,
+ .mask = 7 << 7,
+ .shift = 7,
+ }, {
.v = {
.id= V4L2_CID_CHROMA_AGC,
.name = "Chroma AGC",
.minimum = 0,
@@ -300,8 +315,9 @@
V4L2_CID_HUE,
V4L2_CID_AUDIO_VOLUME,
V4L2_CID_AUDIO_BALANCE,
V4L2_CID_AUDIO_MUTE,
+ V4L2_CID_SHARPNESS,
V4L2_CID_CHROMA_AGC,
V4L2_CID_COLOR_KILLER,
0
};
@@ -1187,8 +1203,13 @@
break;
case V4L2_CID_AUDIO_VOLUME:
ctl->value = 0x3f - (value & 0x3f);
break;
+ case V4L2_CID_SHARPNESS:
+ ctl->value = (value & 0x0380) >> 6;
+ ctl->value = (ctl->value < 8 ? 0 : (ctl->value - 6))
+ | ((cx_read(MO_HTOTAL) & 0x0800) >> 11);
+ break;
default:
ctl->value = ((value + (c->off << c->shift)) & c->mask) >> c->shift;
break;
}
@@ -1246,8 +1267,16 @@
value=(value*0x5a)/0x7f<<8|value;
}
mask=0x;
break;
+ case V4L2_CID_SHARPNESS:
+ /* use 4xFsc or square pixel notch filter */
+ cx_andor(MO_HTOTAL, 0x1800, (ctl->value & 1) << 11);
+ /* 0b000, 0b100, 0b101, 0b110, or 0b111 */
+ value = (ctl->value < 2 ? 0 : (((ctl->value + 6) & 0x0E) << 6));
+ /* needs to be set for both fields */
+ cx_andor(MO_FILTER_EVEN, mask, value);
+ break;
case V4L2_CID_CHROMA_AGC:
/* Do not allow chroma AGC to be enabled for SECAM */
value = ((ctl->value - c->off) << c->shift) & c->mask;
if (core->tvnorm & V4L2_STD_SECAM && value)
[PATCH] cx88: fix checks for analog TV inputs
The following patch fixes code that checks for CX88_VMUX_TELEVISION,
but not CX88_VMUX_CABLE. This prevented for example the audio standard
from being set when using the cable input.
Signed-off-by: Istvan Varga
diff -r -d -N -U4 v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-core.c v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-core.c
--- v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-core.c 2010-03-23 03:39:52.0 +0100
+++ v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-core.c 2010-03-23 19:07:26.0 +0100
@@ -871,9 +871,10 @@
static int set_tvaudio(struct cx88_core *core)
{
v4l2_std_id norm = core->tvnorm;
- if (CX88_VMUX_TELEVISION != INPUT(core->input).type)
+ if (CX88_VMUX_TELEVISION != INPUT(core->input).type &&
+ CX88_VMUX_CABLE != INPUT(core->input).type)
return 0;
if (V4L2_STD_PAL_BG & norm) {
core->tvaudio = WW_BG;
diff -r -d -N -U4 v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-video.c v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-video.c
--- v4l-dvb-a79dd2ae4d0e.old/linux/drivers/media/video/cx88/cx88-video.c 2010-03-23 03:39:52.0 +0100
+++ v4l-dvb-a79dd2ae4d0e/linux/drivers/media/video/cx88/cx88-video.c 2010-03-23 19:07:26.0 +0100
@@ -426,14 +426,15 @@
routes for different inputs. HVR-1300 surely does */
if (core->board.audio_chip &&
core->board.audio_chip == V4L2_IDENT_WM8775) {
call_all(core, audio, s_routing,
- INPUT(input).audioroute, 0, 0);
+ INPUT(input).audioroute, 0, 0);
}
/* cx2388's C-ADC is connected to the tuner only.
When used with S-Video, that ADC is busy dealing with
chroma, so an external must be used for baseband audio */
- if (INPUT(input).type != CX88_VMUX_TELEVISION ) {
+ if (INPUT(input).type != CX88_VMUX_TELEVISION &&
+ INPUT(input).type != CX88_VMUX_CABLE) {
/* "I2S ADC mode" */
core->tvaudio = WW_I2SADC;
cx88_set_tvaudio(core);
} else {
Re: Testers for the cpia2 driver wanted!
On Wed, 2010-03-24 at 08:55 +0100, Hans Verkuil wrote:
> Hi all,
>
> I'm looking for someone who has hardware that can test the cpia2 driver.
>
> I thought I had hardware for that, but it turned out that it used the gspca
> mars driver instead.
A co-worker just gave me an Intel Play QX3 microscope:
[ 1218.810045] usb 3-3: new full speed USB device using ohci_hcd and
address 3
[ 1219.026373] usb 3-3: configuration #1 chosen from 1 choice
[ 1219.027352] usb 3-3: New USB device found, idVendor=0813,
idProduct=0001
[ 1219.027358] usb 3-3: New USB device strings: Mfr=2, Product=1,
SerialNumber=0
[ 1219.027363] usb 3-3: Product: Intel Play QX3 Microscope
[ 1219.027367] usb 3-3: Manufacturer: Mattel Inc.
[ 1219.145032] gspca: main v2.9.0 registered
[ 1219.152733] gspca: probing 0813:0001
[ 1219.152758] cpia1: cpia CPiA camera detected (vid/pid 0x0813:0x0001)
[ 1219.479599] cpia1: CPIA Version: 1.33 (2.10)
[ 1219.479614] cpia1: CPIA PnP-ID: 0813:0001:0106
[ 1219.479619] cpia1: VP-Version: 1.0 0100
[ 1219.481976] gspca: video2 created
[ 1219.482271] usbcore: registered new interface driver cpia1
[ 1219.484291] cpia1: registered
[ 1219.500235] V4L-Driver for Vision CPiA based cameras v1.2.3
[ 1219.500256] Since in-kernel colorspace conversion is not allowed, it
is disabled by default now. Users should fix the applications in case they
don't work without conversion reenabled by setting the 'colorspace_conv' module
parameter to 1
[ 1219.508170] USB driver for Vision CPiA based cameras v1.2.3
[ 1219.508267] usbcore: registered new interface driver cpia
But it looks like it is not supported by cpia2:
$ grep 'USB_DEVICE(.*813' cpia* cpia2/* gspca/*
cpia_usb.c: { USB_DEVICE(0x0813, 0x0001) },
gspca/cpia1.c: {USB_DEVICE(0x0813, 0x0001)},
gspca/ov519.c: {USB_DEVICE(0x0813, 0x0002), .driver_info =
BRIDGE_OV511PLUS },
Is there any testing you need done with this device?
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
[PATCH RFC] DVB: add dvb_generic_nonseekable_open, dvb_generic_unlocked_ioctl, use in firedtv
In order to remove Big Kernel Lock usages from the DVB subsystem,
we need to
- provide .llseek file operations that do not grab the BKL (unlike
fs/read_write.c::default_llseek) or mark files as not seekable,
- provide .unlocked_ioctl file operations.
Add two dvb_generic_ file operations for file interfaces which are not
seekable and, respectively, do not require the BKL in their ioctl
handlers.
Use them in one driver of which I am sure of that these are applicable.
(Affected code paths were not runtime-tested since I don't have a CAM.)
Notes:
- In order to maximize code reuse and minimize API churn, I pass a
dummy NULL struct inode * through dvb_usercopy() to
dvbdev->kernel_ioctl(). Very ugly; it may be better to convert
everything from .ioctl to .unlocked_ioctl in one go and remove the
inode pointer argument everywhere.
- I suspect that actually all dvb_generic_open() users really want
nonseekable_open --- then we should simply change dvb_generic_open()
instead of adding dvb_generic_nonseekable_open() --- but I haven't
checked other users of dvb_generic_open whether they require
.llssek mehods other than fs/read_write.c::no_llseek.
Signed-off-by: Stefan Richter
---
This patch is motivated by Arnd's
"bkl removal: make unlocked_ioctl mandatory"
http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;a=blobdiff;f=drivers/media/dvb/firewire/firedtv-ci.c;h=7ab89035c101240a860d6c72bf8541a0fdf3aed9;hp=853e04b7cb361d45257f80dcafdcf121cd340c63;hb=05e7753338045e9ee3950b2da032c5e5774efa90;hpb=03165e1d096afb4b1d9cfccdad66eed038121cec
"BKL removal: mark remaining users as 'depends on BKL'"
http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;a=blobdiff;f=drivers/media/dvb/firewire/Kconfig;h=ba8938e26414c8c82c41677f87c1361ed8fcebd0;hp=4afa29256df110d3383b6b469762cefbb46436b6;hb=abb83d8fe5f8dcc8fca09bd9117429f73e1417e0;hpb=33c014b118f45516113d4b6823e40ea6f834dc6a
drivers/media/dvb/dvb-core/dvbdev.c | 20
drivers/media/dvb/dvb-core/dvbdev.h | 11 +++
drivers/media/dvb/firewire/firedtv-ci.c |4 ++--
3 files changed, 29 insertions(+), 6 deletions(-)
Index: b/drivers/media/dvb/dvb-core/dvbdev.c
===
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -135,6 +135,18 @@ int dvb_generic_open(struct inode *inode
EXPORT_SYMBOL(dvb_generic_open);
+int dvb_generic_nonseekable_open(struct inode *inode, struct file *file)
+{
+ int retval = dvb_generic_open(inode, file);
+
+ if (retval == 0)
+ retval = nonseekable_open(inode, file);
+
+ return retval;
+}
+EXPORT_SYMBOL(dvb_generic_nonseekable_open);
+
+
int dvb_generic_release(struct inode *inode, struct file *file)
{
struct dvb_device *dvbdev = file->private_data;
@@ -170,6 +182,14 @@ int dvb_generic_ioctl(struct inode *inod
EXPORT_SYMBOL(dvb_generic_ioctl);
+long dvb_generic_unlocked_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ return dvb_generic_ioctl(NULL, file, cmd, arg);
+}
+EXPORT_SYMBOL(dvb_generic_unlocked_ioctl);
+
+
static int dvbdev_get_free_id (struct dvb_adapter *adap, int type)
{
u32 id = 0;
Index: b/drivers/media/dvb/dvb-core/dvbdev.h
===
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -136,10 +136,13 @@ extern int dvb_register_device (struct d
extern void dvb_unregister_device (struct dvb_device *dvbdev);
-extern int dvb_generic_open (struct inode *inode, struct file *file);
-extern int dvb_generic_release (struct inode *inode, struct file *file);
-extern int dvb_generic_ioctl (struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg);
+extern int dvb_generic_open(struct inode *inode, struct file *file);
+extern int dvb_generic_nonseekable_open(struct inode *inode, struct file
*file);
+extern int dvb_generic_release(struct inode *inode, struct file *file);
+extern int dvb_generic_ioctl(struct inode *inode, struct file *file,
+unsigned int cmd, unsigned long arg);
+extern long dvb_generic_unlocked_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg);
/* we don't mess with video_usercopy() any more,
we simply define out own dvb_usercopy(), which will hopefully become
Index: b/drivers/media/dvb/firewire/firedtv-ci.c
===
--- a/drivers/media/dvb/firewire/firedtv-ci.c
+++ b/drivers/media/dvb/firewire/firedtv-ci.c
@@ -217,8 +217,8 @@ static unsigned int fdtv_ca_io_poll(stru
static const struct file_operations fdtv_ca_fops = {
.owner = THIS_MODULE,
- .ioctl = dvb_generic_ioctl,
- .open = dvb_generi
Problem with GIT 30b8f0787e51a3ab0c447e0e3bf4aadc7caf9ffd
Hi Mauro, Your change V4L/DVB: gspca: fixes compilation when input is not selected does not work: when CONFIG_INPUT is not set, the macros gspca_input_xxx are not defined, and the compilation fails. Cheers. -- 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] What are the goals for the architecture of an in-kernel IR system?
On Fri, Mar 26, 2010 at 06:37:41PM -0400, Jon Smirl wrote: > On Fri, Mar 26, 2010 at 1:22 PM, Mauro Carvalho Chehab > wrote: > > 2) create a read/write sysfs node that would indicate the number of > > event/keymaps > > associated with a given IR. By writing a bigger number, it would create new > > devices. > > By writing a smaller number, it will delete some maps. There's an issue > > though: > > what criteria would be used to delete? The newly created ones? > > This is normally handled a sysfs node on the core, something like > 'adddev'. You echo '1' to this node and a new interface is created. > > Each interface has a sysfs node, make a 'remove' attribute in it. Echo > '1' to remove to make it disappear. > > You have to implement the code behind these interfaces but this > convention is used in other subsubsystems. > > BTW - you're recreating everything the configfs interface did. it > achieved the same results with mkdir/rmdir. I liked the configfs > scheme since there are no obscure commands to learn. Everybody can > make files and directories. I've looked at your configfs interface, it was the inspiration for suggesting that each irrcv device should have more than one keymap with one input device for each keytable. However, I don't agree that the configfs interface would somehow be more user-friendly than an ioctl based one. Getting the correct "scancode" (e.g, protocol, device, function values), finding a corresponding keycode (is it KEY_0, no wait, it's KEY_NUMERIC_0), etc are bigger hurdles than mkdir/rmdir/echo or calling a tool similar to input-utils which does the ioctl. mount -t configfs blabla /somewhere (distros don't seem to mount configfs per default) cd /somewhere/somewhere-else mkdir something echo gibberish1 > yada1 echo gibberish2 > yada2 echo gibberish3 > yada3 Doesn't seem all that much less obscure than the command line interface to an ioctl based interface: ir-util load_keytable /usr/share/remotes/blah or ir-util load_keyentry "gibberish1,gibberish2 = gibberish3" Assume the user provides an invalid (e.g. out-of-bounds value for the device field of a RC5 ir command) scancode. With the configfs approach the user will get a standard perror reply from echo/cat. With a dedicated tool the user can get a much more informative error message. But in the end, the majority of users are going to use some GUI to do all of this anyway (and they'll only do it once)start GUI, ask user to press all keys on remote one by one, provide them with a list of possible descriptions (i.e. input.h type keycodes) for each detected key on the remote (something like the keymapping interface most quake-like computer games provide). Once done, save keymap. Load keymap at boot. Configfs or ioctl or sysfs or netlink or blorkfs is a detail which won't matter to those users. -- David Härdeman -- 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
