Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
At that time when I start the installation, it "work" plainly using the steps even though it refer back to old codes. It was good enough for a end user but you are right that if we are to put in mainstream code, there will be a need to do clean up. But that is also provided that it possible to get the necessary approval to use the codes for merging. On Wed, May 5, 2010 at 10:40 PM, Simon Kenyon wrote: > On 05/05/2010 15:07, Bee Hock Goh wrote: >> >> You need to follow this link: >> http://ubuntuforums.org/showthread.php?p=8936585 >> >> If you download the correct version of the antti af9015 tree, you can >> apply the patch correctly and it will work(a tda18218/af9015 stick) >> without any code change. >> > > thanks for your help > > that thread talks about using an old version of the tree > i will try it just to make sure that i am doing the correct thing with my > edits > but it is not a long term solution > > the patch replaces the entry to another stick rather than fix up the code to > add an extra one > i don't think that it will make it into the tree in its current state > that and all the magic constants > > regards > -- > simon > -- 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 v2 2/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers - part 1
On Monday 29 March 2010 08:40:50 Hans Verkuil wrote:
> Hi Xiaolin,
>
> On Sunday 28 March 2010 16:42:30 Zhang, Xiaolin wrote:
> > From 1c18c41be33246e4b766d0e95e28a72dded87475 Mon Sep 17 00:00:00 2001
> > From: Xiaolin Zhang
> > Date: Sun, 28 Mar 2010 21:31:24 +0800
> > Subject: [PATCH 2/10] This patch is second part of intel moorestown isp
> > driver and c files collection which is v4l2 implementation.
> >
>
>
>
> > +struct videobuf_dma_contig_memory {
> > + u32 magic;
> > + void *vaddr;
> > + dma_addr_t dma_handle;
> > + unsigned long size;
> > + int is_userptr;
> > +};
> > +
> > +#define MAGIC_DC_MEM 0x0733ac61
> > +#define MAGIC_CHECK(is, should)
> > \
> > + if (unlikely((is) != (should))) {
> > \
> > + pr_err("magic mismatch: %x expected %x\n", (is), (should));
> > \
> > + BUG();
> > \
> > + }
>
> I will do a more in-depth review in a few days.
I realize that I never got round to this. You have to remind me if you don't
see a follow-up within a week! These things tend to get buried otherwise.
I will try to review this this weekend. Let me know if you prefer me to wait
for the next patch series incorporating the comments already made by others.
Regards,
Hans
> However, I did notice that
> you added your own dma_contig implementation. What were the reasons for doing
> this? I've CC-ed Pawel since he will be interested in this as well.
>
> Another question that came up is: what is 'marvin'? It's clearly a codename,
> but a codename for what? This should be documented at the top of some source
> or header. Apologies if it is already documented, I didn't read everything
> yet.
>
> A final point I noticed: don't cast away a function result:
>
> (void)ci_isp_set_bp_detection(NULL);
>
> No need for (void). The gcc compiler won't warn about this unless the function
> is annotated with __must_check__.
>
> Regards,
>
> Hans
>
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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] tda10048: fix the uncomplete function tda10048_read_ber
Hello Steven, > Thanks Guillaume, I have a pile of other patches I'm ready to present > for merge so I'll pull this into one of my dev trees and present this > for merge also of course, I'll test it first! :) > > Thanks again for working on this. You're welcome. I am just starting reviewing the driver. I have already noticed a few errors in it. I will keep on sending obvious patches. I can quickly summarise some of the missing important features: - missing lock algorithm which should use the SCAN_CPT register to make it efficient - missing frequency offset detection (thanks to AUTOOFFSET=1 and OFFSET_F) -- Guillaume -- 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 2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
Hi Arnout,
Arnout Vandecappelle wrote:
> videobuf_dma_init_user_locked() uses get_user_pages() to get the
> virtual-to-physical address mapping for user-allocated memory.
> However, the user-allocated memory may be non-pageable because it
> is an I/O range or similar. get_user_pages() fails with -EFAULT
> in that case.
>
> If the user-allocated memory is physically contiguous, the approach
> of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still
> returned.
> ---
> drivers/media/video/videobuf-dma-sg.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
Your patch looked sane to my eyes. I just noticed one warning at the dprintk,
when compiled with 32 bits address space, and a few coding style issues.
I needed to rebase it also, due to some changes at videobuf.
However, you missed your SOB. Could you please send it? I'm enclosing
the version with my changes for you to sign.
---
V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
Date: Wed, 17 Mar 2010 22:53:05 -
From: Arnout Vandecappelle
videobuf_dma_init_user_locked() uses get_user_pages() to get the
virtual-to-physical address mapping for user-allocated memory.
However, the user-allocated memory may be non-pageable because it
is an I/O range or similar. get_user_pages() fails with -EFAULT
in that case.
If the user-allocated memory is physically contiguous, the approach
of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still
returned.
[mche...@redhat.com: Fixed CodingStyle and warning at dprintk on i386]
---
drivers/media/video/videobuf-dma-sg.c | 18 ++
drivers/media/video/videobuf-dma-sg.c | 20
1 file changed, 20 insertions(+)
--- work.orig/drivers/media/video/videobuf-dma-sg.c
+++ work/drivers/media/video/videobuf-dma-sg.c
@@ -145,6 +145,7 @@ static int videobuf_dma_init_user_locked
{
unsigned long first, last;
int err, rw = 0;
+ struct vm_area_struct *vma;
dma->direction = direction;
switch (dma->direction) {
@@ -162,6 +163,25 @@ static int videobuf_dma_init_user_locked
last = ((data+size-1) & PAGE_MASK) >> PAGE_SHIFT;
dma->offset = data & ~PAGE_MASK;
dma->nr_pages = last-first+1;
+
+ /* In case the buffer is user-allocated and is actually an IO buffer for
+ some other hardware, we cannot map pages for it. It in fact behaves
+ the same as an overlay. */
+ vma = find_vma(current->mm, data);
+ if (vma && (vma->vm_flags & VM_IO)) {
+ /* Only a single contiguous buffer is supported. */
+ if (vma->vm_end < data + size) {
+ dprintk(1, "init user: non-contiguous IO buffer.\n");
+ /* same error that get_user_pages() would give */
+ return -EFAULT;
+ }
+ dma->bus_addr = (vma->vm_pgoff << PAGE_SHIFT) +
+ (data - vma->vm_start);
+ dprintk(1, "init user IO [0x%lx+0x%lx => %d pages at 0x%llx]\n",
+ data, size, dma->nr_pages, (long long)dma->bus_addr);
+ return 0;
+ }
+
dma->pages = kmalloc(dma->nr_pages * sizeof(struct page *), GFP_KERNEL);
if (NULL == dma->pages)
return -ENOMEM;
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Aguirre, Sergio wrote: > >> -Original Message- >> From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] >> Sent: Wednesday, May 05, 2010 6:24 PM >> To: Aguirre, Sergio >> Cc: linux-media@vger.kernel.org >> Subject: Re: [videobuf] Query: Condition bytesize limit in >> videobuf_reqbufs -> buf_setup() call? >> >> Aguirre, Sergio wrote: >>> Hi all, >>> >>> While working on an old port of the omap3 camera-isp driver, >>> I have faced some problem. >>> >>> Basically, when calling VIDIOC_REQBUFS with a certain buffer >>> Count, we had a software limit for total size, calculated depending on: >>> >>> Total bytesize = bytesperline x height x count >>> >>> So, we had an arbitrary limit to, say 32 MB, which was generic. >>> >>> Now, we want to condition it ONLY when MMAP buffers will be used. >>> Meaning, we don't want to keep that policy when the kernel is not >>> allocating the space >>> >>> But the thing is that, according to videobuf documentation, buf_setup is >>> the one who should put a RAM usage limit. BUT the memory type passed to >>> reqbufs is not propagated to buf_setup, therefore forcing me to go to a >>> non-standard memory limitation in my reqbufs callback function, instead >>> of doing it properly inside buf_setup. >>> >>> Is this scenario a good consideration to change buf_setup API, and >>> propagate buffers memory type aswell? >> I don't see any problem on propagating the memory type to buffer_setup, if >> this is really needed. Yet, I can't see why you would restrict the buffer >> size to 32 MB on one case, and not restrict the size at all with non-MMAP >> types. > > Ok, my reason for doing that is because I thought that there should be a > memory limit in whichever place you're doing the buffer allocations. > > MMAP is allocating buffers in kernel, so kernel should provide a memory > restriction, if applies. > > USERPTR is allocating buffers in userspace, so userspace should provide a > memory restriction, if applies. > > Please correct me if my reasoning is not correct. > Your rationale makes some sense. For the effects of the remaining discussion, let's forget about videobuf-vmalloc, as I'm assuming your troubles are with a driver using videobuf-contig or videobuf-dma_sg. With all memory types, kernel will need to command DMA transfers to those buffers. It still keeps sense to have a restriction on kernelspace, to avoid, for example, the risk of userspace to fill all DMA capable memory with video buffers, preventing its usage by other subsystems (usb, disk, net, etc). So, such limit should still be enforced in kernel, otherwise, you may open an space for DoS attacks. The limit between read(), MMAP, USERPTR and OVERLAY might eventually be different, but I can't see why you might want to put different limits for each case, as the resource that this check is protecting is the DMA-capable memory area. No matter how you're allocating it, you'll need to enforce the same degree of protection. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
> -Original Message- > From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] > Sent: Wednesday, May 05, 2010 6:24 PM > To: Aguirre, Sergio > Cc: linux-media@vger.kernel.org > Subject: Re: [videobuf] Query: Condition bytesize limit in > videobuf_reqbufs -> buf_setup() call? > > Aguirre, Sergio wrote: > > Hi all, > > > > While working on an old port of the omap3 camera-isp driver, > > I have faced some problem. > > > > Basically, when calling VIDIOC_REQBUFS with a certain buffer > > Count, we had a software limit for total size, calculated depending on: > > > > Total bytesize = bytesperline x height x count > > > > So, we had an arbitrary limit to, say 32 MB, which was generic. > > > > Now, we want to condition it ONLY when MMAP buffers will be used. > > Meaning, we don't want to keep that policy when the kernel is not > > allocating the space > > > > But the thing is that, according to videobuf documentation, buf_setup is > > the one who should put a RAM usage limit. BUT the memory type passed to > > reqbufs is not propagated to buf_setup, therefore forcing me to go to a > > non-standard memory limitation in my reqbufs callback function, instead > > of doing it properly inside buf_setup. > > > > Is this scenario a good consideration to change buf_setup API, and > > propagate buffers memory type aswell? > > I don't see any problem on propagating the memory type to buffer_setup, if > this is really needed. Yet, I can't see why you would restrict the buffer > size to 32 MB on one case, and not restrict the size at all with non-MMAP > types. Ok, my reason for doing that is because I thought that there should be a memory limit in whichever place you're doing the buffer allocations. MMAP is allocating buffers in kernel, so kernel should provide a memory restriction, if applies. USERPTR is allocating buffers in userspace, so userspace should provide a memory restriction, if applies. Please correct me if my reasoning is not correct. Regards, Sergio > > > I'll appreciate your inputs on this matter. > > > > Regards, > > Sergio > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" > in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- > > Cheers, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Aguirre, Sergio wrote: > Hi all, > > While working on an old port of the omap3 camera-isp driver, > I have faced some problem. > > Basically, when calling VIDIOC_REQBUFS with a certain buffer > Count, we had a software limit for total size, calculated depending on: > > Total bytesize = bytesperline x height x count > > So, we had an arbitrary limit to, say 32 MB, which was generic. > > Now, we want to condition it ONLY when MMAP buffers will be used. > Meaning, we don't want to keep that policy when the kernel is not > allocating the space > > But the thing is that, according to videobuf documentation, buf_setup is > the one who should put a RAM usage limit. BUT the memory type passed to > reqbufs is not propagated to buf_setup, therefore forcing me to go to a > non-standard memory limitation in my reqbufs callback function, instead > of doing it properly inside buf_setup. > > Is this scenario a good consideration to change buf_setup API, and > propagate buffers memory type aswell? I don't see any problem on propagating the memory type to buffer_setup, if this is really needed. Yet, I can't see why you would restrict the buffer size to 32 MB on one case, and not restrict the size at all with non-MMAP types. > I'll appreciate your inputs on this matter. > > Regards, > Sergio > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
setting up a tevii s660
Hullo I've been struggling with this for a couple of days. I have checked archives, but missed anything useful. I've got a tevii s660 (dvbs2 via usb). It works with some limitations on windows xp (I cannot get HD signals decoded, but think that's a limitation of the software that comes on the CD). I'm trying to get this working on Linux. I've tried VMs based on fedora 12 and mythbuntu (VMWare Fusion on a MacBookPro, both based on kernel 2.6.32), using the drivers from tevii's site (www.tevii.com/support.asp) . these drivers are slightly modified versions of the v4l tip - but don't appear to be modified where I've not yet managed to get the drivers working :-(. Mythbuntu seems to be closest to working. Goodness knows how tevii tested the code, but it doesn't seem to work as far as I can see. My issues could just be down to using a VM. I believe that I need to load up the modules ds3000 and dvb-usb- dw2102, + add a rule to /etc/udev/rules.d and a script to /etc/udev/ scripts. I think that I must be missing quite a lot of context, tho'. When I look at the code in dw2102.c, which seems to support the s660, the bit that downloads the firmware looks broken and if I add a default clause to the switch that does the download, the s660's missed the download process. This could be why when I do get anything out of the device it looks like I'm just getting repeated bytes (the same value repeated, different values at different times, sometimes nothing). I'm finding it non-trivial working out the call sequences of the code or devising repeatable tests. Can anyone kick me off on getting this working? I'd like to at least get to the point where scandvb can tune the device. It does look like some folk have had success in the past, but probably with totally different codebase (there are posts that refer to the teviis660 module, which I cannot find). Any pointer gratefully accepted. I'll feed back any success if I can be pointed at where to drop document it. tia Tim -- 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 -next] media: fix vivi build error
From: Randy Dunlap vivi uses find_font(), which is only available when FONTS is enabled, so make vivi depend on FONTS. ERROR: "find_font" [drivers/media/video/vivi.ko] undefined! Signed-off-by: Randy Dunlap --- drivers/media/video/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20100505.orig/drivers/media/video/Kconfig +++ linux-next-20100505/drivers/media/video/Kconfig @@ -559,7 +559,7 @@ config VIDEO_DAVINCI_VPIF config VIDEO_VIVI tristate "Virtual Video Driver" - depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64 + depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64 && FONTS select FONT_8x16 select VIDEOBUF_VMALLOC default n -- 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 3/5] viafb: Eliminate some global.h references
The various subdev drivers (other than the framebuffer itself) no longer need this file. Signed-off-by: Jonathan Corbet --- drivers/video/via/via-gpio.c |1 - drivers/video/via/via_i2c.c |4 +++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/via/via-gpio.c b/drivers/video/via/via-gpio.c index 63cb7ac..67d699c 100644 --- a/drivers/video/via/via-gpio.c +++ b/drivers/video/via/via-gpio.c @@ -10,7 +10,6 @@ #include #include "via-core.h" #include "via-gpio.h" -#include "global.h" /* * The ports we know about. Note that the port-25 gpios are not diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c index 84ec2d6..2291765 100644 --- a/drivers/video/via/via_i2c.c +++ b/drivers/video/via/via_i2c.c @@ -20,9 +20,11 @@ */ #include +#include +#include +#include #include "via-core.h" #include "via_i2c.h" -#include "global.h" /* * There can only be one set of these, so there's no point in having -- 1.7.0.1 -- 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 4/5] viafb: move some include files to include/linux
These are the files which should be available to subdevices compiled
outside of drivers/video/via.
Signed-off-by: Jonathan Corbet
---
drivers/video/via/accel.c |2 +-
drivers/video/via/dvi.c |4 +-
drivers/video/via/hw.c |3 +-
drivers/video/via/lcd.c |4 +-
drivers/video/via/via-core.c|6 +-
drivers/video/via/via-core.h| 219 ---
drivers/video/via/via-gpio.c|4 +-
drivers/video/via/via-gpio.h| 14 ---
drivers/video/via/via_i2c.c |4 +-
drivers/video/via/via_i2c.h | 42 ---
drivers/video/via/via_modesetting.c |2 +-
drivers/video/via/via_utility.c |2 +-
drivers/video/via/viafbdev.c|4 +-
drivers/video/via/viamode.c |2 +-
drivers/video/via/vt1636.c |4 +-
include/linux/via-core.h| 219 +++
include/linux/via-gpio.h| 14 +++
include/linux/via_i2c.h | 42 +++
18 files changed, 296 insertions(+), 295 deletions(-)
delete mode 100644 drivers/video/via/via-core.h
delete mode 100644 drivers/video/via/via-gpio.h
delete mode 100644 drivers/video/via/via_i2c.h
create mode 100644 include/linux/via-core.h
create mode 100644 include/linux/via-gpio.h
create mode 100644 include/linux/via_i2c.h
diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c
index 189aba4..e44893e 100644
--- a/drivers/video/via/accel.c
+++ b/drivers/video/via/accel.c
@@ -18,7 +18,7 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include "via-core.h"
+#include
#include "global.h"
/*
diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index 6271b76..39b040b 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -18,8 +18,8 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include "via-core.h"
-#include "via_i2c.h"
+#include
+#include
#include "global.h"
static void tmds_register_write(int index, u8 data);
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index e356fe8..b996803 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -18,7 +18,8 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include "via-core.h"
+
+#include
#include "global.h"
static struct pll_map pll_value[] = {
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 04eec31..2ab0f15 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -18,8 +18,8 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include "via-core.h"
-#include "via_i2c.h"
+#include
+#include
#include "global.h"
#include "lcdtbl.h"
diff --git a/drivers/video/via/via-core.c b/drivers/video/via/via-core.c
index c7d37a0..15fcaab 100644
--- a/drivers/video/via/via-core.c
+++ b/drivers/video/via/via-core.c
@@ -7,9 +7,9 @@
/*
* Core code for the Via multifunction framebuffer device.
*/
-#include "via-core.h"
-#include "via_i2c.h"
-#include "via-gpio.h"
+#include
+#include
+#include
#include "global.h"
#include
diff --git a/drivers/video/via/via-core.h b/drivers/video/via/via-core.h
deleted file mode 100644
index 7ffb521..000
--- a/drivers/video/via/via-core.h
+++ /dev/null
@@ -1,219 +0,0 @@
-/*
- * Copyright 1998-2009 VIA Technologies, Inc. All Rights Reserved.
- * Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
- * Copyright 2009-2010 Jonathan Corbet
- * Copyright 2010 Florian Tobias Schandinat
- *
- * 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, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; 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.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __VIA_CORE_H__
-#define __VIA_CORE_H__
-#include
-#include
-#include
-#include
-
-/*
- * A description of each known serial I2C/GPIO port.
- */
-enum via_port_type {
- VIA_PORT_NONE = 0,
- VIA_PORT_I2C,
- VIA_PORT_GPIO,
-};
-
-enum via_port_mode {
- VIA_MODE_OFF = 0,
- VIA_MODE_I2C, /* Used as I2C port */
- VIA_MODE_GPIO, /* Two GPIO ports */
-};
-
-enum viafb_i2c_adap {
- VIA_PORT_26 = 0,
- VIA_PORT_31,
- VIA_PORT_25,
- VIA_PORT_2C,
- VIA_PORT_3D,
-};
-#define VIAFB_NUM_PORTS 5
-
-struct via_port_cfg
[PATCH 5/5] Add the viafb video capture driver
Add a driver for the video capture port on VIA integrated chipsets. This
version has a remaining OLPCism or two and expects to be talking to an
ov7670; those can be improved as the need arises.
This work was supported by the One Laptop Per Child project.
Signed-off-by: Jonathan Corbet
---
drivers/media/video/Kconfig | 10 +
drivers/media/video/Makefile |2 +
drivers/media/video/via-camera.c | 1368 ++
drivers/media/video/via-camera.h | 93 +++
drivers/video/via/accel.c|2 +-
drivers/video/via/via-core.c | 16 +-
include/linux/via-core.h |4 +-
include/media/v4l2-chip-ident.h |4 +
8 files changed, 1495 insertions(+), 4 deletions(-)
create mode 100644 drivers/media/video/via-camera.c
create mode 100644 drivers/media/video/via-camera.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f8fc865..198636b 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -833,6 +833,16 @@ config VIDEO_CAFE_CCIC
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+config VIDEO_VIA_CAMERA
+ tristate "VIAFB camera controller support"
+ depends on FB_VIA
+ select VIDEOBUF_DMA_SG
+ select VIDEO_OV7670
+ help
+ Driver support for the integrated camera controller in VIA
+ Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems
+ with ov7670 sensors.
+
config SOC_CAMERA
tristate "SoC camera support"
depends on VIDEO_V4L2 && HAS_DMA && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b88b617..089bb24 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -123,6 +123,8 @@ obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
+obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
+
obj-$(CONFIG_USB_DABUSB)+= dabusb.o
obj-$(CONFIG_USB_OV511) += ov511.o
obj-$(CONFIG_USB_SE401) += se401.o
diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c
new file mode 100644
index 000..7b1ff0c
--- /dev/null
+++ b/drivers/media/video/via-camera.c
@@ -0,0 +1,1368 @@
+/*
+ * Driver for the VIA Chrome integrated camera controller.
+ *
+ * Copyright 2009,2010 Jonathan Corbet
+ * Distributable under the terms of the GNU General Public License, version 2
+ *
+ * This work was supported by the One Laptop Per Child project
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "via-camera.h"
+
+MODULE_AUTHOR("Jonathan Corbet ");
+MODULE_DESCRIPTION("VIA framebuffer-based camera controller driver");
+MODULE_LICENSE("GPL");
+
+static int flip_image;
+module_param(flip_image, bool, 0444);
+MODULE_PARM_DESC(flip_image,
+ "If set, the sensor will be instructed to flip the image "
+ "vertically.");
+
+#ifdef CONFIG_OLPC_XO_1_5
+static int override_serial;
+module_param(override_serial, bool, 0444);
+MODULE_PARM_DESC(override_serial,
+ "The camera driver will normally refuse to load if "
+ "the XO 1.5 serial port is enabled. Set this option "
+ "to force the issue.");
+#endif
+
+/*
+ * Basic window sizes.
+ */
+#define VGA_WIDTH 640
+#define VGA_HEIGHT 480
+#define QCIF_WIDTH 176
+#defineQCIF_HEIGHT 144
+
+/*
+ * The structure describing our camera.
+ */
+enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
+
+static struct via_camera {
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct v4l2_subdev *sensor;
+ struct platform_device *platdev;
+ struct viafb_dev *viadev;
+ struct mutex lock;
+ enum viacam_opstate opstate;
+ unsigned long flags;
+ /*
+* GPIO info for power/reset management
+*/
+ int power_gpio;
+ int reset_gpio;
+ /*
+* I/O memory stuff.
+*/
+ void __iomem *mmio; /* Where the registers live */
+ void __iomem *fbmem;/* Frame buffer memory */
+ u32 fb_offset; /* Reserved memory offset (FB) */
+ /*
+* Capture buffers and related. The controller supports
+* up to three, so that's what we have here. These buffers
+* live in frame buffer memory, so we don't call them "DMA".
+*/
+ unsigned int cb_offsets[3]; /* offsets into fb mem */
+ u8 *cb_addrs[3];/* Kernel-space addresses */
+ int n_cap_bufs; /* How many are we using? */
+ int next_buf;
+ struct videobuf_queue vb_queue;
+ struct list_head buffer_queue; /* prot. by reg_lock */
+ /*
+* User tracking.
+*/
+
[PATCH 2/5] viafb: get rid of i2c debug cruft
It's ugly and adds a global.h dependency.
Signed-off-by: Jonathan Corbet
---
drivers/video/via/via_i2c.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c
index febc1dd..84ec2d6 100644
--- a/drivers/video/via/via_i2c.c
+++ b/drivers/video/via/via_i2c.c
@@ -52,7 +52,7 @@ static void via_i2c_setscl(void *data, int state)
val |= 0x80;
break;
default:
- DEBUG_MSG("viafb_i2c: specify wrong i2c type.\n");
+ printk(KERN_ERR "viafb_i2c: specify wrong i2c type.\n");
}
via_write_reg(adap_data->io_port, adap_data->ioport_index, val);
spin_unlock_irqrestore(&i2c_vdev->reg_lock, flags);
@@ -104,7 +104,7 @@ static void via_i2c_setsda(void *data, int state)
val |= 0x40;
break;
default:
- DEBUG_MSG("viafb_i2c: specify wrong i2c type.\n");
+ printk(KERN_ERR "viafb_i2c: specify wrong i2c type.\n");
}
via_write_reg(adap_data->io_port, adap_data->ioport_index, val);
spin_unlock_irqrestore(&i2c_vdev->reg_lock, flags);
@@ -175,8 +175,6 @@ static int create_i2c_bus(struct i2c_adapter *adapter,
struct via_port_cfg *adap_cfg,
struct pci_dev *pdev)
{
- DEBUG_MSG(KERN_DEBUG "viafb: creating bus adap=0x%p,
algo_bit_data=0x%p, adap_cfg=0x%p\n", adapter, algo, adap_cfg);
-
algo->setsda = via_i2c_setsda;
algo->setscl = via_i2c_setscl;
algo->getsda = via_i2c_getsda;
--
1.7.0.1
--
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 1/5] viafb: fold via_io.h into via-core.h
Preparatory move toward the ultimate goal of moving pan-subdevice stuff
into include/linux.
Signed-off-by: Jonathan Corbet
---
drivers/video/via/hw.h |1 -
drivers/video/via/share.h | 11 ++
drivers/video/via/via-core.h| 48 -
drivers/video/via/via_io.h | 67 ---
drivers/video/via/via_modesetting.c |2 +-
drivers/video/via/via_utility.c |1 +
drivers/video/via/viamode.c |1 +
7 files changed, 53 insertions(+), 78 deletions(-)
delete mode 100644 drivers/video/via/via_io.h
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index a58701f..a109de3 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -24,7 +24,6 @@
#include "viamode.h"
#include "global.h"
-#include "via_io.h"
#include "via_modesetting.h"
#define viafb_read_reg(p, i) via_read_reg(p, i)
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 861b414..7f0de7f 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -43,14 +43,9 @@
/* Video Memory Size */
#define VIDEO_MEMORY_SIZE_16M0x100
-/* standard VGA IO port
-*/
-#define VIAStatus 0x3DA
-#define VIACR 0x3D4
-#define VIASR 0x3C4
-#define VIAGR 0x3CE
-#define VIAAR 0x3C0
-
+/*
+ * Lengths of the VPIT structure arrays.
+ */
#define StdCR 0x19
#define StdSR 0x04
#define StdGR 0x09
diff --git a/drivers/video/via/via-core.h b/drivers/video/via/via-core.h
index 087c562..7ffb521 100644
--- a/drivers/video/via/via-core.h
+++ b/drivers/video/via/via-core.h
@@ -1,7 +1,8 @@
/*
* Copyright 1998-2009 VIA Technologies, Inc. All Rights Reserved.
* Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
- * Copyright 2009 Jonathan Corbet
+ * Copyright 2009-2010 Jonathan Corbet
+ * Copyright 2010 Florian Tobias Schandinat
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public
@@ -22,6 +23,8 @@
#ifndef __VIA_CORE_H__
#define __VIA_CORE_H__
+#include
+#include
#include
#include
@@ -170,4 +173,47 @@ int viafb_dma_copy_out_sg(unsigned int offset, struct
scatterlist *sg, int nsg);
#define VGA_WIDTH 640
#define VGA_HEIGHT 480
+/*
+ * Indexed port operations. Note that these are all multi-op
+ * functions; every invocation will be racy if you're not holding
+ * reg_lock.
+ */
+
+#define VIAStatus 0x3DA /* Non-indexed port */
+#define VIACR 0x3D4
+#define VIASR 0x3C4
+#define VIAGR 0x3CE
+#define VIAAR 0x3C0
+
+static inline u8 via_read_reg(u16 port, u8 index)
+{
+ outb(index, port);
+ return inb(port + 1);
+}
+
+static inline void via_write_reg(u16 port, u8 index, u8 data)
+{
+ outb(index, port);
+ outb(data, port + 1);
+}
+
+static inline void via_write_reg_mask(u16 port, u8 index, u8 data, u8 mask)
+{
+ u8 old;
+
+ outb(index, port);
+ old = inb(port + 1);
+ outb((data & mask) | (old & ~mask), port + 1);
+}
+
+#define VIA_MISC_REG_READ 0x03CC
+#define VIA_MISC_REG_WRITE 0x03C2
+
+static inline void via_write_misc_reg_mask(u8 data, u8 mask)
+{
+ u8 old = inb(VIA_MISC_REG_READ);
+ outb((data & mask) | (old & ~mask), VIA_MISC_REG_WRITE);
+}
+
+
#endif /* __VIA_CORE_H__ */
diff --git a/drivers/video/via/via_io.h b/drivers/video/via/via_io.h
deleted file mode 100644
index a3d2aca..000
--- a/drivers/video/via/via_io.h
+++ /dev/null
@@ -1,67 +0,0 @@
-/*
- * Copyright 1998-2008 VIA Technologies, Inc. All Rights Reserved.
- * Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
- * Copyright 2010 Florian Tobias Schandinat
- *
- * 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, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; 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.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-/*
- * basic io functions
- */
-
-#ifndef __VIA_IO_H__
-#define __VIA_IO_H__
-
-#include
-#include
-
-#define VIA_MISC_REG_READ 0x03CC
-#define VIA_MISC_REG_WRITE 0x03C2
-
-/*
- * Indexed port operations. Note that these are all multi-op
- * functions; every invocation will be racy if you're not holding
- * reg_lock.
- */
-static inline u8 via_read_reg(u16 port, u8 index)
-{
- outb(index, port);
- return inb(port + 1);
-}
-
-static inline void via_write_reg(
[RFC] Third OLPC viafb patch series (camera driver)
This is, perhaps, the last set of viafb patches I'll send around before the merge window. This series completes the task of adding the via-camera driver - in the correct spot, this time. To that end, it has to reorganize the viafb header files a bit. V4L2 folks: only the final patch in this series really needs your attention. Note that it has no hope of appying or working without a long series of predecessor patches; the full set, prior to this series, is currently in linux-next. If the driver is acceptable to you, I'd prefer to merge it through my viafb tree to be sure all the prerequisites land in mainline at the right time. As usual, this series can be found at: git://git.lwn.net/linux-2.6.git viafb-posted The camera driver has been cleaned up a bit since the last time around. But the main thing I had to do was to make some of the header files globally visible so I could put the camera driver with the rest of the V4L2 crowd. This will also let us move the core, i2c, and gpio drivers to drivers/mfd, should we want to in the future. There shouldn't be any functionality changes beyond the new driver. Comments? Thanks, jon Jonathan Corbet (5): viafb: fold via_io.h into via-core.h viafb: get rid of i2c debug cruft viafb: Eliminate some global.h references viafb: move some include files to include/linux Add the viafb video capture driver b/drivers/media/video/Kconfig | 10 b/drivers/media/video/Makefile|2 b/drivers/media/video/via-camera.c| 1368 ++ b/drivers/media/video/via-camera.h| 93 ++ b/drivers/video/via/accel.c |4 b/drivers/video/via/dvi.c |4 b/drivers/video/via/hw.c |3 b/drivers/video/via/hw.h |1 b/drivers/video/via/lcd.c |4 b/drivers/video/via/share.h | 11 b/drivers/video/via/via-core.c| 22 b/drivers/video/via/via-gpio.c|5 b/drivers/video/via/via_i2c.c | 14 b/drivers/video/via/via_modesetting.c |2 b/drivers/video/via/via_utility.c |1 b/drivers/video/via/viafbdev.c|4 b/drivers/video/via/viamode.c |1 b/drivers/video/via/vt1636.c |4 b/include/linux/via-core.h| 221 + b/include/linux/via-gpio.h| 14 b/include/linux/via_i2c.h | 42 + b/include/media/v4l2-chip-ident.h |4 drivers/video/via/via-core.h | 173 drivers/video/via/via-gpio.h | 14 drivers/video/via/via_i2c.h | 42 - drivers/video/via/via_io.h| 67 - 26 files changed, 1798 insertions(+), 332 deletions(-) -- 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 v1 1/1] V4L: Add sync before a hardware operation to videobuf.
Pawel Osciak wrote:
> Architectures with non-coherent CPU cache (e.g. ARM) may require a cache
> flush or invalidation before starting a hardware operation if the data in
> a video buffer being queued has been touched by the CPU.
>
> This patch adds calls to sync before a hardware operation that are expected
> to be interpreted and handled by each memory type-specific module.
>
> Whether it is a sync before or after the operation can be determined from
> the current buffer state: VIDEOBUF_DONE and VIDEOBUF_ERROR indicate a sync
> called after an operation.
Hi Pawel,
After analyzing this patch, maybe the better is to add a check for dma
coherency. So, instead of directly calling sync,the better is to check
if !dma_is_consistent(), to avoid adding a penalty on architectures
where the cache is coherent.
>
> diff --git a/drivers/media/video/videobuf-core.c
> b/drivers/media/video/videobuf-core.c
> index bb0a1c8..e56c67a 100644
> --- a/drivers/media/video/videobuf-core.c
> +++ b/drivers/media/video/videobuf-core.c
> @@ -561,6 +561,8 @@ int videobuf_qbuf(struct videobuf_queue *q,
> goto done;
> }
>
> + CALL(q, sync, q, buf);
> +
> list_add_tail(&buf->stream, &q->stream);
> if (q->streaming) {
> spin_lock_irqsave(q->irqlock, flags);
> @@ -761,6 +763,8 @@ static ssize_t videobuf_read_zerocopy(struct
> videobuf_queue *q,
> if (0 != retval)
> goto done;
>
> + CALL(q, sync, q, q->read_buf);
> +
> /* start capture & wait */
> spin_lock_irqsave(q->irqlock, flags);
> q->ops->buf_queue(q, q->read_buf);
> @@ -826,6 +830,8 @@ ssize_t videobuf_read_one(struct videobuf_queue *q,
> goto done;
> }
>
> + CALL(q, sync, q, q->read_buf);
> +
> spin_lock_irqsave(q->irqlock, flags);
> q->ops->buf_queue(q, q->read_buf);
> spin_unlock_irqrestore(q->irqlock, flags);
> @@ -893,6 +899,9 @@ static int __videobuf_read_start(struct videobuf_queue *q)
> err = q->ops->buf_prepare(q, q->bufs[i], field);
> if (err)
> return err;
> +
> + CALL(q, sync, q, q->read_buf);
> +
> list_add_tail(&q->bufs[i]->stream, &q->stream);
> }
> spin_lock_irqsave(q->irqlock, flags);
> diff --git a/drivers/media/video/videobuf-dma-sg.c
> b/drivers/media/video/videobuf-dma-sg.c
> index fa78555..2b153f8 100644
> --- a/drivers/media/video/videobuf-dma-sg.c
> +++ b/drivers/media/video/videobuf-dma-sg.c
> @@ -50,6 +50,9 @@ MODULE_LICENSE("GPL");
> #define dprintk(level, fmt, arg...) if (debug >= level) \
> printk(KERN_DEBUG "vbuf-sg: " fmt , ## arg)
>
> +#define is_sync_after(vb) \
> + (vb->state == VIDEOBUF_DONE || vb->state == VIDEOBUF_ERROR)
> +
> /* - */
>
> struct scatterlist*
> @@ -516,6 +519,9 @@ static int __videobuf_sync(struct videobuf_queue *q,
> BUG_ON(!mem);
> MAGIC_CHECK(mem->magic,MAGIC_SG_MEM);
>
> + if (!is_sync_after(buf))
> + return 0;
> +
> return videobuf_dma_sync(q,&mem->dma);
> }
>
--
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
[videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Hi all, While working on an old port of the omap3 camera-isp driver, I have faced some problem. Basically, when calling VIDIOC_REQBUFS with a certain buffer Count, we had a software limit for total size, calculated depending on: Total bytesize = bytesperline x height x count So, we had an arbitrary limit to, say 32 MB, which was generic. Now, we want to condition it ONLY when MMAP buffers will be used. Meaning, we don't want to keep that policy when the kernel is not allocating the space But the thing is that, according to videobuf documentation, buf_setup is the one who should put a RAM usage limit. BUT the memory type passed to reqbufs is not propagated to buf_setup, therefore forcing me to go to a non-standard memory limitation in my reqbufs callback function, instead of doing it properly inside buf_setup. Is this scenario a good consideration to change buf_setup API, and propagate buffers memory type aswell? I'll appreciate your inputs on this matter. Regards, Sergio -- 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] tvp7002 fixes
The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git tvp7002 Tested on a DM6467T eval board. Regards, Hans Mats Randgaard (3): v4l2-subdev.h: Add support for enum_dv_preset tvp7002.c: Add support for enum_dv_presets tvp7002.c: fix some copy-paste errors in the comments drivers/media/video/tvp7002.c | 40 +--- include/media/v4l2-subdev.h |2 ++ 2 files changed, 31 insertions(+), 11 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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 1/7] dsbr100: implement proper locking
On Wednesday 05 May 2010 19:05:24 David Ellingsworth wrote:
> Signed-off-by: David Ellingsworth
Does this actually fix bugs or does this just clean up the locking?
I ask because I am planning to make it easier to do locking for ioctl calls.
Basically there will be pre-hook and post-hook callbacks that are called before
and after an ioctl and where you can do the locking. I am waiting for a patch
series related to priority handling to go in first, then I will work on this
change.
So from my perspective I am OK with this if it fixes bugs, but if it is
just a clean up, then it might be better to wait until my new callbacks are in.
I won't block this, though. It's just FYI.
Regards,
Hans
> ---
> drivers/media/radio/dsbr100.c | 77 +---
> 1 files changed, 33 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
> index ed9cd7a..673eda8 100644
> --- a/drivers/media/radio/dsbr100.c
> +++ b/drivers/media/radio/dsbr100.c
> @@ -182,7 +182,7 @@ static int dsbr100_start(struct dsbr100_device *radio)
> int retval;
> int request;
>
> - mutex_lock(&radio->lock);
> + BUG_ON(!mutex_is_locked(&radio->lock));
>
> retval = usb_control_msg(radio->usbdev,
> usb_rcvctrlpipe(radio->usbdev, 0),
> @@ -207,11 +207,9 @@ static int dsbr100_start(struct dsbr100_device *radio)
> }
>
> radio->status = STARTED;
> - mutex_unlock(&radio->lock);
> return (radio->transfer_buffer)[0];
>
> usb_control_msg_failed:
> - mutex_unlock(&radio->lock);
> dev_err(&radio->usbdev->dev,
> "%s - usb_control_msg returned %i, request %i\n",
> __func__, retval, request);
> @@ -225,7 +223,7 @@ static int dsbr100_stop(struct dsbr100_device *radio)
> int retval;
> int request;
>
> - mutex_lock(&radio->lock);
> + BUG_ON(!mutex_is_locked(&radio->lock));
>
> retval = usb_control_msg(radio->usbdev,
> usb_rcvctrlpipe(radio->usbdev, 0),
> @@ -250,11 +248,9 @@ static int dsbr100_stop(struct dsbr100_device *radio)
> }
>
> radio->status = STOPPED;
> - mutex_unlock(&radio->lock);
> return (radio->transfer_buffer)[0];
>
> usb_control_msg_failed:
> - mutex_unlock(&radio->lock);
> dev_err(&radio->usbdev->dev,
> "%s - usb_control_msg returned %i, request %i\n",
> __func__, retval, request);
> @@ -269,7 +265,7 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
> int request;
> int freq = (radio->curfreq / 16 * 80) / 1000 + 856;
>
> - mutex_lock(&radio->lock);
> + BUG_ON(!mutex_is_locked(&radio->lock));
>
> retval = usb_control_msg(radio->usbdev,
> usb_rcvctrlpipe(radio->usbdev, 0),
> @@ -306,12 +302,10 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
> }
>
> radio->stereo = !((radio->transfer_buffer)[0] & 0x01);
> - mutex_unlock(&radio->lock);
> return (radio->transfer_buffer)[0];
>
> usb_control_msg_failed:
> radio->stereo = -1;
> - mutex_unlock(&radio->lock);
> dev_err(&radio->usbdev->dev,
> "%s - usb_control_msg returned %i, request %i\n",
> __func__, retval, request);
> @@ -324,7 +318,7 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
> {
> int retval;
>
> - mutex_lock(&radio->lock);
> + BUG_ON(!mutex_is_locked(&radio->lock));
>
> retval = usb_control_msg(radio->usbdev,
> usb_rcvctrlpipe(radio->usbdev, 0),
> @@ -340,8 +334,6 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
> } else {
> radio->stereo = !(radio->transfer_buffer[0] & 0x01);
> }
> -
> - mutex_unlock(&radio->lock);
> }
>
> /* USB subsystem interface begins here */
> @@ -385,10 +377,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
> {
> struct dsbr100_device *radio = video_drvdata(file);
>
> - /* safety check */
> - if (radio->removed)
> - return -EIO;
> -
> if (v->index > 0)
> return -EINVAL;
>
> @@ -410,12 +398,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
> static int vidioc_s_tuner(struct file *file, void *priv,
> struct v4l2_tuner *v)
> {
> - struct dsbr100_device *radio = video_drvdata(file);
> -
> - /* safety check */
> - if (radio->removed)
> - return -EIO;
> -
> if (v->index > 0)
> return -EINVAL;
>
> @@ -428,17 +410,12 @@ static int vidioc_s_frequency(struct file *file, void
> *priv,
> struct dsbr100_device *radio = video_drvdata(file);
> int retval;
>
> - /* safety check */
> - if (radio->removed)
> - return -EIO;
> -
> - mutex_lock(&radio->lock);
> radio->curfreq = f->frequency;
> - mutex_unlock(&radio->lock);
>
> r
[PATCH] videobuf-vmalloc: remove __videobuf_sync()
videobuf-core checks if .sync ops is defined before calling.
So, we don't need a do-nothing function.
Signed-off-by: Mauro Carvalho Chehab
--
Cheers,
Mauro
diff --git a/drivers/media/video/videobuf-vmalloc.c
b/drivers/media/video/videobuf-vmalloc.c
index f8b5b56..583728f 100644
--- a/drivers/media/video/videobuf-vmalloc.c
+++ b/drivers/media/video/videobuf-vmalloc.c
@@ -229,12 +229,6 @@ static int __videobuf_iolock(struct videobuf_queue *q,
return 0;
}
-static int __videobuf_sync(struct videobuf_queue *q,
- struct videobuf_buffer *buf)
-{
- return 0;
-}
-
static int __videobuf_mmap_mapper(struct videobuf_queue *q,
struct videobuf_buffer *buf,
struct vm_area_struct *vma)
@@ -301,7 +295,6 @@ static struct videobuf_qtype_ops qops = {
.alloc= __videobuf_alloc,
.iolock = __videobuf_iolock,
- .sync = __videobuf_sync,
.mmap_mapper = __videobuf_mmap_mapper,
.vaddr= videobuf_to_vmalloc,
};
--
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: -next: staging/cx25821: please revert 7a02f549fcc
On Wed, May 05, 2010 at 12:30:01PM -0300, Mauro Carvalho Chehab wrote:
> This simplifies the code a little bit, and, instead of just return -EINVAL,
> it will return the error condition reported by the called functions.
>
Thanks for that.
There was one return that got missed. Probably you can fold it into
your patch?
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index 7545314..34616dc 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -849,10 +849,8 @@ int medusa_video_init(struct cx25821_dev *dev)
value |= 7;
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], PIN_OE_CTRL, value);
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
+ if (ret_val < 0)
+ goto error;
mutex_unlock(&dev->lock);
--
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] videobuf: remove external function videobuf_dma_sync()
While analyzing one of the videobuf patches, I noticed that
videobuf_dma_sync is only used internally inside videobuf-dma-sg.
So, let's remove this function, merging the code at __videobuf_dma_sync()
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index f733833..b49f1e2 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -279,17 +279,6 @@ int videobuf_dma_map(struct videobuf_queue *q, struct
videobuf_dmabuf *dma)
}
EXPORT_SYMBOL_GPL(videobuf_dma_map);
-int videobuf_dma_sync(struct videobuf_queue *q, struct videobuf_dmabuf *dma)
-{
- MAGIC_CHECK(dma->magic, MAGIC_DMABUF);
- BUG_ON(!dma->sglen);
-
- dma_sync_sg_for_cpu(q->dev, dma->sglist, dma->nr_pages, dma->direction);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(videobuf_dma_sync);
-
int videobuf_dma_unmap(struct videobuf_queue *q, struct videobuf_dmabuf *dma)
{
MAGIC_CHECK(dma->magic, MAGIC_DMABUF);
@@ -542,10 +531,15 @@ static int __videobuf_sync(struct videobuf_queue *q,
struct videobuf_buffer *buf)
{
struct videobuf_dma_sg_memory *mem = buf->priv;
- BUG_ON(!mem);
+ BUG_ON(!mem || !mem->dma.sglen);
+
MAGIC_CHECK(mem->magic, MAGIC_SG_MEM);
+ MAGIC_CHECK(mem->dma.magic, MAGIC_DMABUF);
- return videobuf_dma_sync(q, &mem->dma);
+ dma_sync_sg_for_cpu(q->dev, mem->dma.sglist,
+ mem->dma.nr_pages, mem->dma.direction);
+
+ return 0;
}
static int __videobuf_mmap_mapper(struct videobuf_queue *q,
diff --git a/include/media/videobuf-dma-sg.h b/include/media/videobuf-dma-sg.h
index dbfd8cf..a195f3b 100644
--- a/include/media/videobuf-dma-sg.h
+++ b/include/media/videobuf-dma-sg.h
@@ -97,7 +97,6 @@ int videobuf_dma_init_overlay(struct videobuf_dmabuf *dma,
int direction,
int videobuf_dma_free(struct videobuf_dmabuf *dma);
int videobuf_dma_map(struct videobuf_queue *q, struct videobuf_dmabuf *dma);
-int videobuf_dma_sync(struct videobuf_queue *q, struct videobuf_dmabuf *dma);
int videobuf_dma_unmap(struct videobuf_queue *q, struct videobuf_dmabuf *dma);
struct videobuf_dmabuf *videobuf_to_dma(struct videobuf_buffer *buf);
--
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 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
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 55ea260..6932def 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -95,6 +95,10 @@ MODULE_PARM_DESC(dvb_mfe_wait_time, "Wait up to seconds on open(
* FESTATE_LOSTLOCK. When the lock has been lost, and we're searching it again.
*/
+#define DVB_FE_NO_EXIT 0
+#define DVB_FE_NORMAL_EXIT 1
+#define DVB_FE_DEVICE_REMOVED 2
+
static DEFINE_MUTEX(frontend_mutex);
struct dvb_frontend_private {
@@ -497,7 +501,7 @@ static int dvb_frontend_is_exiting(struct dvb_frontend *fe)
{
struct dvb_frontend_private *fepriv = fe->frontend_priv;
- if (fepriv->exit)
+ if (fepriv->exit != DVB_FE_NO_EXIT)
return 1;
if (fepriv->dvbdev->writers == 1)
@@ -559,7 +563,7 @@ restart:
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
- fepriv->exit = 1;
+ fepriv->exit = DVB_FE_NORMAL_EXIT;
break;
}
@@ -673,7 +677,10 @@ restart:
}
fepriv->thread = NULL;
- fepriv->exit = 0;
+ if (kthread_should_stop())
+ fepriv->exit = DVB_FE_DEVICE_REMOVED;
+ else
+ fepriv->exit = DVB_FE_NO_EXIT;
mb();
dvb_frontend_wakeup(fe);
@@ -686,7 +693,7 @@ static void dvb_frontend_stop(struct dvb_frontend *fe)
dprintk ("%s\n", __func__);
- fepriv->exit = 1;
+ fepriv->exit = DVB_FE_NORMAL_EXIT;
mb();
if (!fepriv->thread)
@@ -755,7 +762,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
dprintk ("%s\n", __func__);
if (fepriv->thread) {
- if (!fepriv->exit)
+ if (fepriv->exit == DVB_FE_NO_EXIT)
return 0;
else
dvb_frontend_stop (fe);
@@ -767,7 +774,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
return -EINTR;
fepriv->state = FESTATE_IDLE;
- fepriv->exit = 0;
+ fepriv->exit = DVB_FE_NO_EXIT;
fepriv->thread = NULL;
mb();
@@ -1490,7 +1497,7 @@ static int dvb_frontend_ioctl(struct inode *inode, struct file *file,
dprintk("%s (%d)\n", __func__, _IOC_NR(cmd));
- if (fepriv->exit)
+ if (fepriv->exit != DVB_FE_NO_EXIT)
return -ENODEV;
if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
@@ -1916,6 +1923,8 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)
int ret;
dprintk ("%s\n", __func__);
+ if (fepriv->exit == DVB_FE_DEVICE_REMOVED)
+ return -ENODEV;
if (adapter->mfe_shared) {
mutex_lock (&adapter->mfe_lock);
@@ -2008,7 +2017,7 @@ static int dvb_frontend_release(struct inode *inode, struct file *file)
ret = dvb_generic_release (inode, file);
if (dvbdev->users == -1) {
- if (fepriv->exit == 1) {
+ if (fepriv->exit != DVB_FE_NO_EXIT) {
fops_put(file->f_op);
file->f_op = NULL;
wake_up(&dvbdev->wait_queue);
[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:Wed May 5 19:00:28 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14644:4a8d6d981f07 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 562dac038aef2a1719710b5703b15732cbc4354b 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: ERRORS linux-2.6.33-armv5: ERRORS linux-2.6.34-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: ERRORS linux-2.6.34-rc1-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: ERRORS linux-2.6.34-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: ERRORS linux-2.6.34-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: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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/RFC 7/7] dsbr100: simplify access to radio device
This patch replaces calls to video_drvdata with
references to struct file->private_data which is
set during usb_dsbr100_open. This value is passed
by video_ioctl2 via the *priv argument and is
accessible via file->private_data otherwise.
Signed-off-by: David Ellingsworth
---
drivers/media/radio/dsbr100.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index cd4eed7..64ba0c8 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -366,7 +366,7 @@ static void usb_dsbr100_disconnect(struct usb_interface
*intf)
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *v)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
strlcpy(v->driver, "dsbr100", sizeof(v->driver));
strlcpy(v->card, "D-Link R-100 USB FM Radio", sizeof(v->card));
@@ -379,7 +379,7 @@ static int vidioc_querycap(struct file *file, void *priv,
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
if (v->index > 0)
return -EINVAL;
@@ -411,7 +411,7 @@ static int vidioc_s_tuner(struct file *file, void *priv,
static int vidioc_s_frequency(struct file *file, void *priv,
struct v4l2_frequency *f)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
int retval = dsbr100_setfreq(radio, f->frequency);
if (retval < 0)
@@ -423,7 +423,7 @@ static int vidioc_s_frequency(struct file *file, void *priv,
static int vidioc_g_frequency(struct file *file, void *priv,
struct v4l2_frequency *f)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
f->type = V4L2_TUNER_RADIO;
f->frequency = radio->curfreq;
@@ -444,7 +444,7 @@ static int vidioc_queryctrl(struct file *file, void *priv,
static int vidioc_g_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
switch (ctrl->id) {
case V4L2_CID_AUDIO_MUTE:
@@ -457,7 +457,7 @@ static int vidioc_g_ctrl(struct file *file, void *priv,
static int vidioc_s_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
int retval;
switch (ctrl->id) {
@@ -518,7 +518,7 @@ static int vidioc_s_audio(struct file *file, void *priv,
static long usb_dsbr100_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = file->private_data;
long retval = 0;
mutex_lock(&radio->lock);
@@ -557,6 +557,7 @@ static int usb_dsbr100_open(struct file *file)
radio->status |= INITIALIZED;
}
+ file->private_data = radio;
unlock:
mutex_unlock(&radio->lock);
return retval;
--
1.7.1
--
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 0/7] dsbr100: driver cleanup
This patch series addresses several issues in the dsbr100 driver. This series is based on the v4l-dvb master git branch and has been compile tested only. It should be tested before applying. The following patches are included in this series: [PATCH/RFC 1/7] dsbr100: implement proper locking [PATCH/RFC 2/7] dsbr100: fix potential use after free [PATCH/RFC 3/7] dsbr100: only change frequency upon success [PATCH/RFC 4/7] dsbr100: remove disconnected indicator [PATCH/RFC 5/7] dsbr100: properly initialize the radio [PATCH/RFC 6/7] dsbr100: cleanup usb probe routine [PATCH/RFC 7/7] dsbr100: simplify access to radio device Regards, David Ellingsworth -- 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 4/7] dsbr100: remove disconnected indicator
Signed-off-by: David Ellingsworth
---
drivers/media/radio/dsbr100.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index b62fe40..c949ace 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -151,7 +151,6 @@ struct dsbr100_device {
struct mutex lock; /* buffer locking */
int curfreq;
int stereo;
- int removed;
int status;
};
@@ -353,7 +352,7 @@ static void usb_dsbr100_disconnect(struct usb_interface
*intf)
usb_set_intfdata (intf, NULL);
mutex_lock(&radio->lock);
- radio->removed = 1;
+ radio->usbdev = NULL;
mutex_unlock(&radio->lock);
v4l2_device_disconnect(&radio->v4l2_dev);
@@ -521,7 +520,7 @@ static long usb_dsbr100_ioctl(struct file *file, unsigned
int cmd,
mutex_lock(&radio->lock);
- if (radio->removed) {
+ if (!radio->usbdev) {
retval = -EIO;
goto unlock;
}
@@ -649,7 +648,6 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
mutex_init(&radio->lock);
- radio->removed = 0;
radio->usbdev = interface_to_usbdev(intf);
radio->curfreq = FREQ_MIN * FREQ_MUL;
radio->status = STOPPED;
--
1.7.1
--
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 6/7] dsbr100: cleanup usb probe routine
This patch simplifies the error paths within the
usb_dsbr100_probe routine. It also removes an unnecessary
local variable.
Signed-off-by: David Ellingsworth
---
drivers/media/radio/dsbr100.c | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index e2fed0b..cd4eed7 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -646,33 +646,28 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct dsbr100_device *radio;
- struct v4l2_device *v4l2_dev;
int retval;
radio = kzalloc(sizeof(struct dsbr100_device), GFP_KERNEL);
-
if (!radio)
return -ENOMEM;
radio->transfer_buffer = kmalloc(TB_LEN, GFP_KERNEL);
-
if (!(radio->transfer_buffer)) {
- kfree(radio);
- return -ENOMEM;
+ retval = -ENOMEM;
+ goto err_nobuf;
}
- v4l2_dev = &radio->v4l2_dev;
-
- retval = v4l2_device_register(&intf->dev, v4l2_dev);
+ retval = v4l2_device_register(&intf->dev, &radio->v4l2_dev);
if (retval < 0) {
- v4l2_err(v4l2_dev, "couldn't register v4l2_device\n");
- kfree(radio->transfer_buffer);
- kfree(radio);
- return retval;
+ v4l2_err(&radio->v4l2_dev, "couldn't register v4l2_device\n");
+ goto err_v4l2;
}
- strlcpy(radio->videodev.name, v4l2_dev->name,
sizeof(radio->videodev.name));
- radio->videodev.v4l2_dev = v4l2_dev;
+ strlcpy(radio->videodev.name, radio->v4l2_dev.name,
+ sizeof(radio->videodev.name));
+
+ radio->videodev.v4l2_dev = &radio->v4l2_dev;
radio->videodev.fops = &usb_dsbr100_fops;
radio->videodev.ioctl_ops = &usb_dsbr100_ioctl_ops;
radio->videodev.release = usb_dsbr100_video_device_release;
@@ -686,14 +681,20 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
retval = video_register_device(&radio->videodev, VFL_TYPE_RADIO,
radio_nr);
if (retval < 0) {
- v4l2_err(v4l2_dev, "couldn't register video device\n");
- v4l2_device_unregister(v4l2_dev);
- kfree(radio->transfer_buffer);
- kfree(radio);
- return -EIO;
+ v4l2_err(&radio->v4l2_dev, "couldn't register video device\n");
+ goto err_vdev;
}
+
usb_set_intfdata(intf, radio);
return 0;
+
+err_vdev:
+ v4l2_device_unregister(&radio->v4l2_dev);
+err_v4l2:
+ kfree(radio->transfer_buffer);
+err_nobuf:
+ kfree(radio);
+ return retval;
}
static int __init dsbr100_init(void)
--
1.7.1
--
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 3/7] dsbr100: only change frequency upon success
Signed-off-by: David Ellingsworth
---
drivers/media/radio/dsbr100.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index 2f96e13..b62fe40 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -259,11 +259,12 @@ usb_control_msg_failed:
}
/* set a frequency, freq is defined by v4l's TUNER_LOW, i.e. 1/16th kHz */
-static int dsbr100_setfreq(struct dsbr100_device *radio)
+static int dsbr100_setfreq(struct dsbr100_device *radio, int freq)
{
int retval;
int request;
- int freq = (radio->curfreq / 16 * 80) / 1000 + 856;
+
+ freq = (freq / 16 * 80) / 1000 + 856;
BUG_ON(!mutex_is_locked(&radio->lock));
@@ -302,6 +303,7 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
}
radio->stereo = !((radio->transfer_buffer)[0] & 0x01);
+ radio->curfreq = freq;
return (radio->transfer_buffer)[0];
usb_control_msg_failed:
@@ -408,11 +410,8 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
struct v4l2_frequency *f)
{
struct dsbr100_device *radio = video_drvdata(file);
- int retval;
-
- radio->curfreq = f->frequency;
+ int retval = dsbr100_setfreq(radio, f->frequency);
- retval = dsbr100_setfreq(radio);
if (retval < 0)
dev_warn(&radio->usbdev->dev, "Set frequency failed\n");
--
1.7.1
--
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 1/7] dsbr100: implement proper locking
Signed-off-by: David Ellingsworth
---
drivers/media/radio/dsbr100.c | 77 +---
1 files changed, 33 insertions(+), 44 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index ed9cd7a..673eda8 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -182,7 +182,7 @@ static int dsbr100_start(struct dsbr100_device *radio)
int retval;
int request;
- mutex_lock(&radio->lock);
+ BUG_ON(!mutex_is_locked(&radio->lock));
retval = usb_control_msg(radio->usbdev,
usb_rcvctrlpipe(radio->usbdev, 0),
@@ -207,11 +207,9 @@ static int dsbr100_start(struct dsbr100_device *radio)
}
radio->status = STARTED;
- mutex_unlock(&radio->lock);
return (radio->transfer_buffer)[0];
usb_control_msg_failed:
- mutex_unlock(&radio->lock);
dev_err(&radio->usbdev->dev,
"%s - usb_control_msg returned %i, request %i\n",
__func__, retval, request);
@@ -225,7 +223,7 @@ static int dsbr100_stop(struct dsbr100_device *radio)
int retval;
int request;
- mutex_lock(&radio->lock);
+ BUG_ON(!mutex_is_locked(&radio->lock));
retval = usb_control_msg(radio->usbdev,
usb_rcvctrlpipe(radio->usbdev, 0),
@@ -250,11 +248,9 @@ static int dsbr100_stop(struct dsbr100_device *radio)
}
radio->status = STOPPED;
- mutex_unlock(&radio->lock);
return (radio->transfer_buffer)[0];
usb_control_msg_failed:
- mutex_unlock(&radio->lock);
dev_err(&radio->usbdev->dev,
"%s - usb_control_msg returned %i, request %i\n",
__func__, retval, request);
@@ -269,7 +265,7 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
int request;
int freq = (radio->curfreq / 16 * 80) / 1000 + 856;
- mutex_lock(&radio->lock);
+ BUG_ON(!mutex_is_locked(&radio->lock));
retval = usb_control_msg(radio->usbdev,
usb_rcvctrlpipe(radio->usbdev, 0),
@@ -306,12 +302,10 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
}
radio->stereo = !((radio->transfer_buffer)[0] & 0x01);
- mutex_unlock(&radio->lock);
return (radio->transfer_buffer)[0];
usb_control_msg_failed:
radio->stereo = -1;
- mutex_unlock(&radio->lock);
dev_err(&radio->usbdev->dev,
"%s - usb_control_msg returned %i, request %i\n",
__func__, retval, request);
@@ -324,7 +318,7 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
{
int retval;
- mutex_lock(&radio->lock);
+ BUG_ON(!mutex_is_locked(&radio->lock));
retval = usb_control_msg(radio->usbdev,
usb_rcvctrlpipe(radio->usbdev, 0),
@@ -340,8 +334,6 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
} else {
radio->stereo = !(radio->transfer_buffer[0] & 0x01);
}
-
- mutex_unlock(&radio->lock);
}
/* USB subsystem interface begins here */
@@ -385,10 +377,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
{
struct dsbr100_device *radio = video_drvdata(file);
- /* safety check */
- if (radio->removed)
- return -EIO;
-
if (v->index > 0)
return -EINVAL;
@@ -410,12 +398,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
- struct dsbr100_device *radio = video_drvdata(file);
-
- /* safety check */
- if (radio->removed)
- return -EIO;
-
if (v->index > 0)
return -EINVAL;
@@ -428,17 +410,12 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
struct dsbr100_device *radio = video_drvdata(file);
int retval;
- /* safety check */
- if (radio->removed)
- return -EIO;
-
- mutex_lock(&radio->lock);
radio->curfreq = f->frequency;
- mutex_unlock(&radio->lock);
retval = dsbr100_setfreq(radio);
if (retval < 0)
dev_warn(&radio->usbdev->dev, "Set frequency failed\n");
+
return 0;
}
@@ -447,10 +424,6 @@ static int vidioc_g_frequency(struct file *file, void
*priv,
{
struct dsbr100_device *radio = video_drvdata(file);
- /* safety check */
- if (radio->removed)
- return -EIO;
-
f->type = V4L2_TUNER_RADIO;
f->frequency = radio->curfreq;
return 0;
@@ -472,10 +445,6 @@ static int vidioc_g_ctrl(struct file *file, void *priv,
{
struct dsbr100_device *radio = video_drvdata(file);
- /* safety check */
- if (radio->removed)
- return -EIO;
-
switch (ctrl->id) {
case V4L2_CID_AUDIO_MUTE:
[PATCH/RFC 5/7] dsbr100: properly initialize the radio
This patch adds a flag to indicate if the radio has been
initialized or not. If the flag has not been set upon open,
the radio initialized to a known state.
It combines the STARTED/STOPPED indicators into a single
MUTED flag and defines a couple of macros for determining
the status of the radio.
Signed-off-by: David Ellingsworth
---
drivers/media/radio/dsbr100.c | 54 +++-
1 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index c949ace..e2fed0b 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -125,10 +125,13 @@ devices, that would be 76 and 91. */
#define FREQ_MAX 108.0
#define FREQ_MUL 16000
-/* defines for radio->status */
-#define STARTED0
-#define STOPPED1
+enum dsbr100_status {
+ INITIALIZED = 1 << 0,
+ MUTED = 1 << 1
+};
+#define radio_initialized(r) (r->status & INITIALIZED)
+#define radio_muted(r) (r->status & MUTED)
#define videodev_to_radio(d) container_of(d, struct dsbr100_device, videodev)
static int usb_dsbr100_probe(struct usb_interface *intf,
@@ -151,7 +154,7 @@ struct dsbr100_device {
struct mutex lock; /* buffer locking */
int curfreq;
int stereo;
- int status;
+ enum dsbr100_status status;
};
static struct usb_device_id usb_dsbr100_device_table [] = {
@@ -205,7 +208,7 @@ static int dsbr100_start(struct dsbr100_device *radio)
goto usb_control_msg_failed;
}
- radio->status = STARTED;
+ radio->status &= ~MUTED;
return (radio->transfer_buffer)[0];
usb_control_msg_failed:
@@ -246,7 +249,7 @@ static int dsbr100_stop(struct dsbr100_device *radio)
goto usb_control_msg_failed;
}
- radio->status = STOPPED;
+ radio->status |= MUTED;
return (radio->transfer_buffer)[0];
usb_control_msg_failed:
@@ -532,6 +535,33 @@ unlock:
return retval;
}
+static int usb_dsbr100_open(struct file *file)
+{
+ struct dsbr100_device *radio = video_drvdata(file);
+ int retval = 0;
+
+ mutex_lock(&radio->lock);
+
+ if (!radio->usbdev) {
+ retval = -EIO;
+ goto unlock;
+ }
+
+ if (unlikely(!radio_initialized(radio))) {
+ retval = dsbr100_stop(radio);
+
+ if (retval < 0)
+ goto unlock;
+
+ retval = 0;
+ radio->status |= INITIALIZED;
+ }
+
+unlock:
+ mutex_unlock(&radio->lock);
+ return retval;
+}
+
/* Suspend device - stop device. */
static int usb_dsbr100_suspend(struct usb_interface *intf, pm_message_t
message)
{
@@ -540,17 +570,17 @@ static int usb_dsbr100_suspend(struct usb_interface
*intf, pm_message_t message)
mutex_lock(&radio->lock);
- if (radio->status == STARTED) {
+ if (!radio_muted(radio)) {
retval = dsbr100_stop(radio);
if (retval < 0)
dev_warn(&intf->dev, "dsbr100_stop failed\n");
- /* After dsbr100_stop() status set to STOPPED.
+ /* After dsbr100_stop() status set to MUTED.
* If we want driver to start radio on resume
-* we set status equal to STARTED.
+* we set status equal to not MUTED
* On resume we will check status and run radio if needed.
*/
- radio->status = STARTED;
+ radio->status &= ~MUTED;
}
mutex_unlock(&radio->lock);
@@ -567,7 +597,7 @@ static int usb_dsbr100_resume(struct usb_interface *intf)
mutex_lock(&radio->lock);
- if (radio->status == STARTED) {
+ if (radio_initialized(radio) && !radio_muted(radio)) {
retval = dsbr100_start(radio);
if (retval < 0)
dev_warn(&intf->dev, "dsbr100_start failed\n");
@@ -593,6 +623,7 @@ static void usb_dsbr100_video_device_release(struct
video_device *videodev)
static const struct v4l2_file_operations usb_dsbr100_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = usb_dsbr100_ioctl,
+ .open = usb_dsbr100_open,
};
static const struct v4l2_ioctl_ops usb_dsbr100_ioctl_ops = {
@@ -650,7 +681,6 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
radio->usbdev = interface_to_usbdev(intf);
radio->curfreq = FREQ_MIN * FREQ_MUL;
- radio->status = STOPPED;
video_set_drvdata(&radio->videodev, radio);
--
1.7.1
--
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 2/7] dsbr100: fix potential use after free
Signed-off-by: David Ellingsworth --- drivers/media/radio/dsbr100.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c index 673eda8..2f96e13 100644 --- a/drivers/media/radio/dsbr100.c +++ b/drivers/media/radio/dsbr100.c @@ -354,8 +354,8 @@ static void usb_dsbr100_disconnect(struct usb_interface *intf) radio->removed = 1; mutex_unlock(&radio->lock); - video_unregister_device(&radio->videodev); v4l2_device_disconnect(&radio->v4l2_dev); + video_unregister_device(&radio->videodev); } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.35] sn9c20x updates
On Sat, May 1, 2010 at 10:36 AM, Brian Johnson wrote: > The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: > Jean-François Moine (1): > V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast > > are available in the git repository at: > > git://gitorious.org/v4l-dvb/v4l-dvb.git devel > Added a bugfix for the mt9v111 sensor gspca - sn9c20x: Fix non working mt9v111 sensor Regards, Brian Johnson -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: -next: staging/cx25821: please revert 7a02f549fcc
Will do. Thanks for passing over the info.
Regards,
Palash
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: Wednesday, May 05, 2010 8:30 AM
To: Dan Carpenter; Palash Bandyopadhyay
Cc: Greg Kroah-Hartman; linux-media@vger.kernel.org
Subject: Re: -next: staging/cx25821: please revert 7a02f549fcc
Dan Carpenter wrote:
> This was my patch: "cx25821: fix double unlock in medusa_video_init()"
>
> It accidentally got merged two times. The version from the staging tree
> is not correct. Please can you revert it:
> 7a02f549fcc30fe6be0c0024beae9a3db22e1af6 "Staging: cx25821: fix double
> unlock in medusa_video_init()"
Hmm... true.
>
> I guess this is going through the V4L/DVB so it needs to be reverted
> there as well as in the -staging tree.
There's no need to touch at staging tree, since this change come from v4l-dvb
tree.
After reviewing the logic at the function, instead of just adding a patch to
revert the wrong one, the better is to apply a different logic: add a goto
that will always unlock and return the error.
This simplifies the code a little bit, and, instead of just return -EINVAL,
it will return the error condition reported by the called functions.
Btw, cx25821-core currently doesn't handle the error returned by
medusa_video_init().
Palash,
Could you please add the proper validation code for the error conditions that
may
happen during device init?
Cheers,
Mauro
--
V4L/DVB: cx25821: fix error condition logic at medusa_video_init()
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index 77ccef4..7545314 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -778,9 +778,9 @@ int medusa_set_saturation(struct cx25821_dev *dev, int
saturation, int decoder)
int medusa_video_init(struct cx25821_dev *dev)
{
- u32 value = 0, tmp = 0;
- int ret_val = 0;
- int i = 0;
+ u32 value, tmp = 0;
+ int ret_val;
+ int i;
mutex_lock(&dev->lock);
@@ -790,20 +790,15 @@ int medusa_video_init(struct cx25821_dev *dev)
value = cx25821_i2c_read(&dev->i2c_bus[0], MON_A_CTRL, &tmp);
value &= 0xF0FF;
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], MON_A_CTRL, value);
+ if (ret_val < 0)
+ goto error;
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
/* Turn off Master source switch enable */
value = cx25821_i2c_read(&dev->i2c_bus[0], MON_A_CTRL, &tmp);
value &= 0xFFDF;
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], MON_A_CTRL, value);
-
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
+ if (ret_val < 0)
+ goto error;
mutex_unlock(&dev->lock);
@@ -817,31 +812,25 @@ int medusa_video_init(struct cx25821_dev *dev)
value &= 0xFF70FF70;
value |= 0x00090008;/* set en_active */
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], DENC_AB_CTRL, value);
+ if (ret_val < 0)
+ goto error;
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
/* enable input is VIP/656 */
value = cx25821_i2c_read(&dev->i2c_bus[0], BYP_AB_CTRL, &tmp);
value |= 0x00040100;/* enable VIP */
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], BYP_AB_CTRL, value);
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
+ if (ret_val < 0)
+ goto error;
+
/* select AFE clock to output mode */
value = cx25821_i2c_read(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL, &tmp);
value &= 0x83FF;
- ret_val =
- cx25821_i2c_write(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL,
- value | 0x1000);
+ ret_val = cx25821_i2c_write(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL,
+ value | 0x1000);
+ if (ret_val < 0)
+ goto error;
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
/* Turn on all of the data out and control output pins. */
value = cx25821_i2c_read(&dev->i2c_bus[0], PIN_OE_CTRL, &tmp);
value &= 0xFEF0FE00;
@@ -868,9 +857,9 @@ int medusa_video_init(struct cx25821_dev *dev)
mutex_unlock(&dev->lock);
ret_val = medusa_set_videostandard(dev);
+ return ret_val;
- if (ret_val < 0)
- return -EINVAL;
-
- return 1;
+error:
+ mutex_unlock(&dev->lock);
+ return ret_val;
}
Conexant E-mail Firewall (Conexant.Com) made the following annotations
-
*
Re: -next: staging/cx25821: please revert 7a02f549fcc
Dan Carpenter wrote:
> This was my patch: "cx25821: fix double unlock in medusa_video_init()"
>
> It accidentally got merged two times. The version from the staging tree
> is not correct. Please can you revert it:
> 7a02f549fcc30fe6be0c0024beae9a3db22e1af6 "Staging: cx25821: fix double
> unlock in medusa_video_init()"
Hmm... true.
>
> I guess this is going through the V4L/DVB so it needs to be reverted
> there as well as in the -staging tree.
There's no need to touch at staging tree, since this change come from v4l-dvb
tree.
After reviewing the logic at the function, instead of just adding a patch to
revert the wrong one, the better is to apply a different logic: add a goto
that will always unlock and return the error.
This simplifies the code a little bit, and, instead of just return -EINVAL,
it will return the error condition reported by the called functions.
Btw, cx25821-core currently doesn't handle the error returned by
medusa_video_init().
Palash,
Could you please add the proper validation code for the error conditions that
may
happen during device init?
Cheers,
Mauro
--
V4L/DVB: cx25821: fix error condition logic at medusa_video_init()
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index 77ccef4..7545314 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -778,9 +778,9 @@ int medusa_set_saturation(struct cx25821_dev *dev, int
saturation, int decoder)
int medusa_video_init(struct cx25821_dev *dev)
{
- u32 value = 0, tmp = 0;
- int ret_val = 0;
- int i = 0;
+ u32 value, tmp = 0;
+ int ret_val;
+ int i;
mutex_lock(&dev->lock);
@@ -790,20 +790,15 @@ int medusa_video_init(struct cx25821_dev *dev)
value = cx25821_i2c_read(&dev->i2c_bus[0], MON_A_CTRL, &tmp);
value &= 0xF0FF;
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], MON_A_CTRL, value);
+ if (ret_val < 0)
+ goto error;
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
/* Turn off Master source switch enable */
value = cx25821_i2c_read(&dev->i2c_bus[0], MON_A_CTRL, &tmp);
value &= 0xFFDF;
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], MON_A_CTRL, value);
-
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
+ if (ret_val < 0)
+ goto error;
mutex_unlock(&dev->lock);
@@ -817,31 +812,25 @@ int medusa_video_init(struct cx25821_dev *dev)
value &= 0xFF70FF70;
value |= 0x00090008;/* set en_active */
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], DENC_AB_CTRL, value);
+ if (ret_val < 0)
+ goto error;
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
/* enable input is VIP/656 */
value = cx25821_i2c_read(&dev->i2c_bus[0], BYP_AB_CTRL, &tmp);
value |= 0x00040100;/* enable VIP */
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], BYP_AB_CTRL, value);
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
+ if (ret_val < 0)
+ goto error;
+
/* select AFE clock to output mode */
value = cx25821_i2c_read(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL, &tmp);
value &= 0x83FF;
- ret_val =
- cx25821_i2c_write(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL,
- value | 0x1000);
+ ret_val = cx25821_i2c_write(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL,
+ value | 0x1000);
+ if (ret_val < 0)
+ goto error;
- if (ret_val < 0) {
- mutex_unlock(&dev->lock);
- return -EINVAL;
- }
/* Turn on all of the data out and control output pins. */
value = cx25821_i2c_read(&dev->i2c_bus[0], PIN_OE_CTRL, &tmp);
value &= 0xFEF0FE00;
@@ -868,9 +857,9 @@ int medusa_video_init(struct cx25821_dev *dev)
mutex_unlock(&dev->lock);
ret_val = medusa_set_videostandard(dev);
+ return ret_val;
- if (ret_val < 0)
- return -EINVAL;
-
- return 1;
+error:
+ mutex_unlock(&dev->lock);
+ return ret_val;
}
--
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] media/IR: Add missing include file to rc-map.c
From: Peter Huewe This patch adds a missing include linux/delay.h to prevent build failures[1-5] Signed-off-by: Peter Huewe --- KernelVersion: linux-next-20100505 References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/2571452/ [2] http://kisskb.ellerman.id.au/kisskb/buildresult/2571188/ [3] http://kisskb.ellerman.id.au/kisskb/buildresult/2571479/ [4] http://kisskb.ellerman.id.au/kisskb/buildresult/2571429/ [5] http://kisskb.ellerman.id.au/kisskb/buildresult/2571432/ drivers/media/IR/rc-map.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c index caf6a27..46a8f15 100644 --- a/drivers/media/IR/rc-map.c +++ b/drivers/media/IR/rc-map.c @@ -14,6 +14,7 @@ #include #include +#include /* Used to handle IR raw handler extensions */ static LIST_HEAD(rc_map_list); -- 1.6.4.4 -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 05/05/2010 15:07, Bee Hock Goh wrote: You need to follow this link: http://ubuntuforums.org/showthread.php?p=8936585 If you download the correct version of the antti af9015 tree, you can apply the patch correctly and it will work(a tda18218/af9015 stick) without any code change. thanks for your help that thread talks about using an old version of the tree i will try it just to make sure that i am doing the correct thing with my edits but it is not a long term solution the patch replaces the entry to another stick rather than fix up the code to add an extra one i don't think that it will make it into the tree in its current state that and all the magic constants regards -- simon -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On Wed, May 5, 2010 at 10:13 PM, Bee Hock Goh wrote: > Use the attached firmware which work well for me. > > An earlier firmware will hung the stick and this version fixed that issue. > > On Wed, May 5, 2010 at 10:07 PM, Bee Hock Goh wrote: >> You need to follow this link: >> http://ubuntuforums.org/showthread.php?p=8936585 >> >> If you download the correct version of the antti af9015 tree, you can >> apply the patch correctly and it will work(a tda18218/af9015 stick) >> without any code change. >> >> On Wed, May 5, 2010 at 10:00 PM, Simon Kenyon wrote: >>> On 05/05/2010 13:36, Bee Hock Goh wrote: Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. >>> >>> i do know about the patch >>> in fact that is what i have been playing with >>> but it just replaces an existing stcik with the definition for the one that >>> i have >>> i thought that was a bit hacky - mainly because the patch failed on my hg >>> checkout >>> >>> so i have been editing the code to try and add it (not replace) >>> and indeed the stick is detected - just no signal >>> trying to work out what the problem is >>> >>> also trying to get the latest firmware - second part of my question to the >>> list >>> i don't know where the original patch came from >>> >>> as an aside: i bought two of these on ebay and if antti wants one so that he >>> can support it then just drop me an email with a postal address and i'll >>> send it >>> -- >>> simon >>> -- >>> 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 >>> >> > dvb-usb-af9015.fw Description: Binary data
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
Use the attached firmware which work well for me. An earlier firmware will hung the stick and this version fixed that issue. On Wed, May 5, 2010 at 10:07 PM, Bee Hock Goh wrote: > You need to follow this link: http://ubuntuforums.org/showthread.php?p=8936585 > > If you download the correct version of the antti af9015 tree, you can > apply the patch correctly and it will work(a tda18218/af9015 stick) > without any code change. > > On Wed, May 5, 2010 at 10:00 PM, Simon Kenyon wrote: >> On 05/05/2010 13:36, Bee Hock Goh wrote: >>> >>> Simon, >>> >>> There is already a patch that will make af9105/tda18218 work. However, >>> it seem that there is no active effort to merge with the mainstream >>> code. >>> >>> I have been running that codes with mythtv(recording only) for quite a >>> while and its working fine. >>> >>> https://patchwork.kernel.org/patch/82494/ >>> >>> Mauro, >>> >>> I have send a mail to Nikola asking if he will be willing to submit >>> the codes to the v4l-dvb tree but I do not have any reply yet. >>> >>> Can I extract thenecessary files/patch from >>> http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git >>> tree? >>> >>> I also notice that in ubuntu, it can detect the card and installed >>> proprietary code. Unfortunately, tda18218 is not supported. >>> >> >> i do know about the patch >> in fact that is what i have been playing with >> but it just replaces an existing stcik with the definition for the one that >> i have >> i thought that was a bit hacky - mainly because the patch failed on my hg >> checkout >> >> so i have been editing the code to try and add it (not replace) >> and indeed the stick is detected - just no signal >> trying to work out what the problem is >> >> also trying to get the latest firmware - second part of my question to the >> list >> i don't know where the original patch came from >> >> as an aside: i bought two of these on ebay and if antti wants one so that he >> can support it then just drop me an email with a postal address and i'll >> send it >> -- >> simon >> -- >> 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 >> > rt73.bin Description: Binary data
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
You need to follow this link: http://ubuntuforums.org/showthread.php?p=8936585 If you download the correct version of the antti af9015 tree, you can apply the patch correctly and it will work(a tda18218/af9015 stick) without any code change. On Wed, May 5, 2010 at 10:00 PM, Simon Kenyon wrote: > On 05/05/2010 13:36, Bee Hock Goh wrote: >> >> Simon, >> >> There is already a patch that will make af9105/tda18218 work. However, >> it seem that there is no active effort to merge with the mainstream >> code. >> >> I have been running that codes with mythtv(recording only) for quite a >> while and its working fine. >> >> https://patchwork.kernel.org/patch/82494/ >> >> Mauro, >> >> I have send a mail to Nikola asking if he will be willing to submit >> the codes to the v4l-dvb tree but I do not have any reply yet. >> >> Can I extract thenecessary files/patch from >> http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git >> tree? >> >> I also notice that in ubuntu, it can detect the card and installed >> proprietary code. Unfortunately, tda18218 is not supported. >> > > i do know about the patch > in fact that is what i have been playing with > but it just replaces an existing stcik with the definition for the one that > i have > i thought that was a bit hacky - mainly because the patch failed on my hg > checkout > > so i have been editing the code to try and add it (not replace) > and indeed the stick is detected - just no signal > trying to work out what the problem is > > also trying to get the latest firmware - second part of my question to the > list > i don't know where the original patch came from > > as an aside: i bought two of these on ebay and if antti wants one so that he > can support it then just drop me an email with a postal address and i'll > send it > -- > simon > -- > 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 05/05/2010 13:36, Bee Hock Goh wrote: Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. i do know about the patch in fact that is what i have been playing with but it just replaces an existing stcik with the definition for the one that i have i thought that was a bit hacky - mainly because the patch failed on my hg checkout so i have been editing the code to try and add it (not replace) and indeed the stick is detected - just no signal trying to work out what the problem is also trying to get the latest firmware - second part of my question to the list i don't know where the original patch came from as an aside: i bought two of these on ebay and if antti wants one so that he can support it then just drop me an email with a postal address and i'll send it -- simon -- 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: tm6000
Dmitri Belimov wrote: > On Wed, 5 May 2010 13:44:38 +0800 > Bee Hock Goh wrote: > >> Did you comment off the code in the get_next_buff that clear the >> previous frame data? > > No. > > Git tree + my last patch. > A "green" tree can happen due to lots of conditions, like: 1) it is not receiving data from xc3028 (or xc5000); 2) wrong gpio setup; 3) data sent too fast to tm6000; 4) need to add some new workarounds to another tm6000 firmware/hardware bug; 5) the device stopped answer and got disconnected from USB buffer; 6) signal were too weak after changing to some channel (it seems that the tm6000 chip stops reception with weak signals - I remember I had to add a code that re-enables xc3028 every time a channel is changed due to this bug, since, after disabled, even if the signal become strong, it keeps showing a green screen); 7) you hit yet another bug on this device ;) -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 05/05/2010 03:36 PM, Bee Hock Goh wrote: There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Do we have kernel merge permission from driver author Lauris Ding? Also this driver is a little but ugly and needs some rework before release. I don't have such device and not even time to hack. I hope someone else could take this driver and fix it for release. regards, Antti -- http://palosaari.fi/ -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
Antti, Thanks for coming out to clarify. So the step going forward is to getting clearance from Lauris? I didnt really look at the codes but the your tree with the tda18218 patch seem to working very well for me. http://ubuntuforums.org/showthread.php?p=8936585 On Wed, May 5, 2010 at 8:58 PM, Antti Palosaari wrote: > On 05/05/2010 03:36 PM, Bee Hock Goh wrote: >> >> There is already a patch that will make af9105/tda18218 work. However, >> it seem that there is no active effort to merge with the mainstream >> code. >> >> I have been running that codes with mythtv(recording only) for quite a >> while and its working fine. >> >> https://patchwork.kernel.org/patch/82494/ > > Do we have kernel merge permission from driver author Lauris Ding? Also this > driver is a little but ugly and needs some rework before release. I don't > have such device and not even time to hack. I hope someone else could take > this driver and fix it for release. > > regards, > Antti > -- > http://palosaari.fi/ > -- 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] tda10048: fix the uncomplete function tda10048_read_ber
> Completes the bit-error-rate read function with the CBER register (before > Viterbi decoder). The returned value is 1e8*actual_ber to be positive. > Also includes some typo mistakes. > > Signed-off-by: Guillaume Audirac Thanks Guillaume, I have a pile of other patches I'm ready to present for merge so I'll pull this into one of my dev trees and present this for merge also of course, I'll test it first! :) Thanks again for working on this. Regards, - Steve -- Steven Toth - 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. On Wed, May 5, 2010 at 5:29 PM, Simon Kenyon wrote: > On 31/03/2009 21:10, Antti Palosaari wrote: >> >> Moi Mauro, >> >> Please pull from http://linuxtv.org/hg/~anttip/af9015/ >> for the following: >> >> af9015: remove experimental >> af9015: add new USB ID for KWorld USB DVB-T TV Stick II (VS-DVB-T 395U) >> af9015: add support for TrekStor DVB-T USB Stick >> af9015: remove wrong definitions >> af9015: add support for AverMedia AVerTV Volar Black HD (A850) >> >> Patches are for the Kernel 2.6.30, only small changes. >> >> regards >> Antti Palosaari >> > > any chance of support for the TDA18218 in this driver > i found patches on the net and i am currently fighting them > > i also note that the driver on ite's web site has been updated and > get_dvb_firmware can no longer extract the firmware > > thanks > -- > simon > -- > 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
Help Central
This is to inform you that you have exceeded your email quota limit of 625MB and you need to increase your email quota limit because in less than 48 hours your email will be disable. Increase your email quota limit and continue to use your webmail account. To increase your email quota limit to 2.7GB, click the below link: http://www.emailmeform.com/fid.php?formid=687794 Thank you for your understanding. Copyright ©2010 Webmail Helpdest Support Centre -- 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] tda10048: fix the uncomplete function tda10048_read_ber
Hello,
Completes the bit-error-rate read function with the CBER register (before
Viterbi decoder). The returned value is 1e8*actual_ber to be positive.
Also includes some typo mistakes.
Signed-off-by: Guillaume Audirac
---
drivers/media/dvb/frontends/tda10048.c | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10048.c
b/drivers/media/dvb/frontends/tda10048.c
index 4e2a7c8..9006107 100644
--- a/drivers/media/dvb/frontends/tda10048.c
+++ b/drivers/media/dvb/frontends/tda10048.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include "dvb_frontend.h"
#include "dvb_math.h"
@@ -112,7 +113,7 @@
#define TDA10048_FREE_REG_10xB2
#define TDA10048_FREE_REG_20xB3
#define TDA10048_CONF_C3_1 0xC0
-#define TDA10048_CYBER_CTRL0xC2
+#define TDA10048_CVBER_CTRL0xC2
#define TDA10048_CBER_NMAX_LSB 0xC4
#define TDA10048_CBER_NMAX_MSB 0xC5
#define TDA10048_CBER_LSB 0xC6
@@ -120,7 +121,7 @@
#define TDA10048_VBER_LSB 0xC8
#define TDA10048_VBER_MID 0xC9
#define TDA10048_VBER_MSB 0xCA
-#define TDA10048_CYBER_LUT 0xCC
+#define TDA10048_CVBER_LUT 0xCC
#define TDA10048_UNCOR_CTRL0xCD
#define TDA10048_UNCOR_CPT_LSB 0xCE
#define TDA10048_UNCOR_CPT_MSB 0xCF
@@ -183,7 +184,7 @@ static struct init_tab {
{ TDA10048_AGC_IF_MAX, 0xff },
{ TDA10048_AGC_THRESHOLD_MSB, 0x00 },
{ TDA10048_AGC_THRESHOLD_LSB, 0x70 },
- { TDA10048_CYBER_CTRL, 0x38 },
+ { TDA10048_CVBER_CTRL, 0x38 },
{ TDA10048_AGC_GAINS, 0x12 },
{ TDA10048_CONF_XO, 0x00 },
{ TDA10048_CONF_TS1, 0x07 },
@@ -765,6 +766,8 @@ static int tda10048_set_frontend(struct dvb_frontend *fe,
/* Enable demod TPS auto detection and begin acquisition */
tda10048_writereg(state, TDA10048_AUTO, 0x57);
+ /* trigger cber and vber acquisition */
+ tda10048_writereg(state, TDA10048_CVBER_CTRL, 0x3B);
return 0;
}
@@ -830,12 +833,27 @@ static int tda10048_read_status(struct dvb_frontend
*fe, fe_status_t *status)
static int tda10048_read_ber(struct dvb_frontend *fe, u32 *ber)
{
struct tda10048_state *state = fe->demodulator_priv;
+ static u32 cber_current;
+ u32 cber_nmax;
+ u64 cber_tmp;
dprintk(1, "%s()\n", __func__);
- /* TODO: A reset may be required here */
- *ber = tda10048_readreg(state, TDA10048_CBER_MSB) << 8 |
- tda10048_readreg(state, TDA10048_CBER_LSB);
+ /* update cber on interrupt */
+ if (tda10048_readreg(state, TDA10048_SOFT_IT_C3) & 0x01) {
+ cber_tmp = tda10048_readreg(state, TDA10048_CBER_MSB) << 8 |
+ tda10048_readreg(state, TDA10048_CBER_LSB);
+ cber_nmax = tda10048_readreg(state, TDA10048_CBER_NMAX_MSB) <<
8 |
+ tda10048_readreg(state, TDA10048_CBER_NMAX_LSB);
+ cber_tmp *= 1;
+ cber_tmp *= 2;
+ cber_tmp = div_u64(cber_tmp, (cber_nmax * 32) + 1);
+ cber_current = (u32)cber_tmp;
+ /* retrigger cber acquisition */
+ tda10048_writereg(state, TDA10048_CVBER_CTRL, 0x39);
+ }
+ /* actual cber is (*ber)/1e8 */
+ *ber = cber_current;
return 0;
}
--
1.6.3.3
--
Guillaume
--
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: UVC Webcam
Hi Gijo, On Thursday 29 April 2010 12:54:16 Gijo Prems wrote: > Hello, > > I have some queries related to linux uvc client driver(uvcvideo) and > general uvc webcam functionality. > > 1. There is a wDelay (during probe-commit) parameter which camera > exposes to the host signifying the delay (Latency) inside the camera. > Does the UVC driver on Linux Host expose this parameter to the > application if they require it? No it doesn't. > And what would be the use case of this parameter? I don't know, and that's exactly why the parameter isn't exposed :-) > 2. How the audio and video sync (lipsync) would happen on host side? There's no sync at the moment. UVC supports timestamping the packets sent to the host, but the driver ignores the timestamps. > 3. How buffers are allocated on the host side? > Which parameter from camera needs to be set to signify the correct > buffer allocation? There are two sets of buffers, the USB buffers and the V4L2 buffers. The uvcvideo driver allocates one USB buffer per URB (the number of URBs is hardcoded to 5). The USB buffer size is set to the payload size returned by the device, bounded to a maximum value of 32 times the endpoint max packet size. For V4L2 buffers, the uvcvideo driver uses the V4L2 MMAP streaming mode. Applications are supposed to first set the format (VIDIOC_S_FMT), and then ask the driver to allocate buffers (VIDIOC_REQBUFS). > 4. Are there any parameters in USB audio class which allocate the > buffers and handles the latency at host? I don't know much about the USB audio class, sorry. > It would be great if someone could put some thoughts on these. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 31/03/2009 21:10, Antti Palosaari wrote: Moi Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: remove experimental af9015: add new USB ID for KWorld USB DVB-T TV Stick II (VS-DVB-T 395U) af9015: add support for TrekStor DVB-T USB Stick af9015: remove wrong definitions af9015: add support for AverMedia AVerTV Volar Black HD (A850) Patches are for the Kernel 2.6.30, only small changes. regards Antti Palosaari any chance of support for the TDA18218 in this driver i found patches on the net and i am currently fighting them i also note that the driver on ite's web site has been updated and get_dvb_firmware can no longer extract the firmware thanks -- simon -- 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: tm6000
If you do that you will get some decent looking video. On Wed, May 5, 2010 at 3:27 PM, Dmitri Belimov wrote: > On Wed, 5 May 2010 13:44:38 +0800 > Bee Hock Goh wrote: > >> Did you comment off the code in the get_next_buff that clear the >> previous frame data? > > No. > > Git tree + my last patch. > > With my best regards, Dmitry. > >> On Wed, May 5, 2010 at 12:50 PM, Dmitri Belimov >> wrote: >> > Hi >> > >> > At this moment I can start mplayer and see green field with some >> > junk without crash. Info from mplayer - received 497 frames, drop >> > 69 incorrect frames. >> > >> > Compile without support DVB-T for our cards. >> > >> > Now try understand init process working drivers and diff with linux. >> > >> > P.S. Linux kernel is 2.6.33 >> > >> > With my best regards, Dmitry. >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rework for support xc5000
On Wed, 5 May 2010 10:16:27 +0800
Bee Hock Goh wrote:
> There does not seem to be any radio support in the tm6000 codes.
>
> tun_setup.mode_mask |= (T_ANALOG_TV | T_RADIO);
>
> Is the T_RADIO mode still required since this is a cleanup?
Now radio may be not work. But we want write complete driver.
This for set T_RADIO
Cleanup is tun_setup.mode_mask &= ~(T_RADIO)
With my best regards, Dmitry.
> On Wed, May 5, 2010 at 6:53 AM, Dmitri Belimov
> wrote:
> > Hi
> >
> > Set correct GPIO number for BEHOLD_WANDER/VOYAGER
> > Add xc5000 callback function
> > Small rework tm6000_cards_setup function
> > Small rework tm6000_config_tuner, build mode_mask by config
> > information Rework for support xc5000 silicon tuner
> > Add some information messages for more better understand an errors.
> >
> > diff --git a/drivers/staging/tm6000/tm6000-cards.c
> > b/drivers/staging/tm6000/tm6000-cards.c index f795a3e..17e3d4c
> > 100644 --- a/drivers/staging/tm6000/tm6000-cards.c
> > +++ b/drivers/staging/tm6000/tm6000-cards.c
> > @@ -231,7 +231,9 @@ struct tm6000_board tm6000_boards[] = {
> > .has_remote = 1,
> > },
> > .gpio = {
> > - .tuner_reset = TM6000_GPIO_2,
> > + .tuner_reset = TM6010_GPIO_0,
> > + .demod_reset = TM6010_GPIO_1,
> > + .power_led = TM6010_GPIO_6,
> > },
> > },
> > [TM6010_BOARD_BEHOLD_VOYAGER] = {
> > @@ -247,7 +249,8 @@ struct tm6000_board tm6000_boards[] = {
> > .has_remote = 1,
> > },
> > .gpio = {
> > - .tuner_reset = TM6000_GPIO_2,
> > + .tuner_reset = TM6010_GPIO_0,
> > + .power_led = TM6010_GPIO_6,
> > },
> > },
> > [TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
> > @@ -320,6 +323,31 @@ struct usb_device_id tm6000_id_table [] = {
> > { },
> > };
> >
> > +/* Tuner callback to provide the proper gpio changes needed for
> > xc5000 */ +int tm6000_xc5000_callback(void *ptr, int component, int
> > command, int arg) +{
> > + int rc = 0;
> > + struct tm6000_core *dev = ptr;
> > +
> > + if (dev->tuner_type != TUNER_XC5000)
> > + return 0;
> > +
> > + switch (command) {
> > + case XC5000_TUNER_RESET:
> > + tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > + dev->gpio.tuner_reset, 0x01);
> > + msleep(15);
> > + tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > + dev->gpio.tuner_reset, 0x00);
> > + msleep(15);
> > + tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > + dev->gpio.tuner_reset, 0x01);
> > + break;
> > + }
> > + return (rc);
> > +}
> > +
> > +
> > /* Tuner callback to provide the proper gpio changes needed for
> > xc2028 */
> >
> > int tm6000_tuner_callback(void *ptr, int component, int command,
> > int arg) @@ -438,6 +466,21 @@ int tm6000_cards_setup(struct
> > tm6000_core *dev) tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > dev->gpio.demod_on, 0x00); msleep(15);
> > break;
> > + case TM6010_BOARD_BEHOLD_WANDER:
> > + /* Power led on (blue) */
> > + tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > dev->gpio.power_led, 0x01);
> > + msleep(15);
> > + /* Reset zarlink zl10353 */
> > + tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > dev->gpio.demod_reset, 0x00);
> > + msleep(50);
> > + tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > dev->gpio.demod_reset, 0x01);
> > + msleep(15);
> > + break;
> > + case TM6010_BOARD_BEHOLD_VOYAGER:
> > + /* Power led on (blue) */
> > + tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> > dev->gpio.power_led, 0x01);
> > + msleep(15);
> > + break;
> > default:
> > break;
> > }
> > @@ -449,42 +492,38 @@ int tm6000_cards_setup(struct tm6000_core
> > *dev)
> > * 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_rese
-next: staging/cx25821: please revert 7a02f549fcc
This was my patch: "cx25821: fix double unlock in medusa_video_init()" It accidentally got merged two times. The version from the staging tree is not correct. Please can you revert it: 7a02f549fcc30fe6be0c0024beae9a3db22e1af6 "Staging: cx25821: fix double unlock in medusa_video_init()" I guess this is going through the V4L/DVB so it needs to be reverted there as well as in the -staging tree. Sorry for the inconvenience. regards, dan carpenter PS. The correct version is: 423f5c0d016 "V4L/DVB (13955): cx25821: fix double unlock in medusa_video_init()". That one is needed and fixes a bug -- 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: tm6000
On Wed, 5 May 2010 13:44:38 +0800 Bee Hock Goh wrote: > Did you comment off the code in the get_next_buff that clear the > previous frame data? No. Git tree + my last patch. With my best regards, Dmitry. > On Wed, May 5, 2010 at 12:50 PM, Dmitri Belimov > wrote: > > Hi > > > > At this moment I can start mplayer and see green field with some > > junk without crash. Info from mplayer - received 497 frames, drop > > 69 incorrect frames. > > > > Compile without support DVB-T for our cards. > > > > Now try understand init process working drivers and diff with linux. > > > > P.S. Linux kernel is 2.6.33 > > > > With my best regards, Dmitry. > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
