The following changes since commit 36d36b884c745c507d9b3f60eb42925749f7d758:
[media] tm6000: Warning cleanup (2011-11-28 21:58:54 -0200)
are available in the git repository at:
git://linuxtv.org/jfrancois/gspca.git for_v3.3
Jean-François Moine (6):
gspca: Remove the useless variable
Hi Konrad,
On Fri, Dec 2, 2011 at 10:41 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
snip
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
drivers/media/video/s5p-mfc/s5p_mfc_enc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
index 1e8cdb7..dff9dc7 100644
---
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011 15:58:41 +0100
HoPjpetr...@gmail.com wrote:
Hi,
let me ask you some details of your interesting idea (how to
achieve the same functionality as with vtunerc driver):
[...]
The
On 05-12-2011 05:21, Thierry Reding wrote:
* linu...@stefanringel.de wrote:
From: Stefan Ringellinu...@stefanringel.de
Signed-off-by: Stefan Ringellinu...@stefanringel.de
Your commit message needs more details. Why do you think this is a bugfix?
Also this commit seems to effectively revert
I'm still seeing a kernel oops on use.
Module Size Used byNot tainted
cx231xx 124608 0
cx2341x13552 1 cx231xx
cx2584035568 1
rc_core12640 1 cx231xx
videobuf_vmalloc3168 1 cx231xx
Yan Seiner wrote:
I'm still seeing a kernel oops on use.
One more minor point:
Before the kernel oops, I have /dev/video0. After the oops, I have
/dev/video0 and /dev/video1 - probably related to the ehci crash.
--
Few people are capable of expressing with equanimity opinions which differ
On 02-12-2011 22:08, 'Sakari Ailus' wrote:
Hi Mauro,
On Fri, Dec 02, 2011 at 03:07:44PM -0200, Mauro Carvalho Chehab wrote:
I'm not fully certain it is always possible to find out the largest stream
resolution. I'd like an answer from someone knowing more about video codecs
than I do.
That
Hi
2011/12/5 Florian Fainelli f.faine...@gmail.com:
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011 15:58:41 +0100
HoPjpetr...@gmail.com wrote:
Hi,
let me ask you some details of your interesting idea (how to
achieve
Yan Seiner y...@seiner.com wrote:
Yan Seiner wrote:
Andy Walls wrote:
On Sun, 2011-12-04 at 18:01 -0800, Yan Seiner wrote:
I am experiencing a kernel oops when trying to use a Hauppage USB
Live 2 frame grabber. The oops is below.
The system is a SOC 260Mhz Broadcom BCM47XX access point
You know - I'm a bit confused. Somebody are pointing on double
data copying (userspace networked daemon - kernel - application)
issue and another one warn me to not start network connection
from the kernel. But if it works for NFS or CIFS then it should not
be so weaky, isn't it?
And then
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support any 64-bit systems, but such platforms can be added in the
and in any case compiler warnings should be avoided.
Signed-off-by: Guennadi
Yan Seiner y...@seiner.com wrote:
I'm still seeing a kernel oops on use.
Module Size Used byNot tainted
cx231xx 124608 0
cx2341x13552 1 cx231xx
cx2584035568 1
rc_core12640 1 cx231xx
On Mon, Dec 5, 2011 at 9:28 AM, HoP jpetr...@gmail.com wrote:
Hi
2011/12/5 Florian Fainelli f.faine...@gmail.com:
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011 15:58:41 +0100
HoPjpetr...@gmail.com wrote:
Hi,
let me
On Mon, December 5, 2011 7:18 am, Andy Walls wrote:
Yan Seiner y...@seiner.com wrote:
ehci_hcd :00:02.2: fatal error
ehci_hcd :00:02.2: HC died; cleaning up
ehci_hcd :00:02.2: force halt; handshake c0350024 4000 4000
Well, you probably have figured out you have a USB
* Mauro Carvalho Chehab wrote:
On 05-12-2011 05:21, Thierry Reding wrote:
* linu...@stefanringel.de wrote:
From: Stefan Ringellinu...@stefanringel.de
Signed-off-by: Stefan Ringellinu...@stefanringel.de
Your commit message needs more details. Why do you think this is a bugfix?
Also this
hi all,
I'm a linux-media user who for many years used an fm radio card.
After recent kernel updates, fm no longer works. I frankly, don't
know enough to determine where the problem lies--whether it's hardware
or out of date drivers or unmaintained code.
FM Radio seems to join the dustbins of
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have about things I spotted.
Do you have prototype exporter and consumer
On Monday 05 of December 2011 at 16:15:28, Guennadi Liakhovetski wrote:
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support any 64-bit systems, but such platforms can be added in the
and in any
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas
On 05-12-2011 12:28, HoP wrote:
And here is a new hack.
I'm really tired from all those hack, crap, pigback ... wordings.
What exactly vtuner aproach does so hackish (other then exposing
DVB internals, what is every time made if virtualization support is developing)?
The code itself no need
On Monday 05 of December 2011 at 18:23:44, Janusz Krzysztofik wrote:
On Monday 05 of December 2011 at 16:15:28, Guennadi Liakhovetski wrote:
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support
On 05-12-2011 13:40, Zhu, Mingcheng wrote:
Hi Mauro and Hans,
For our MSM chipset family we will have multiple capture device drivers. There
are two directory layout approaches as:
Tree type directory structure:
* /video/msm/camera: for camera driver
* /video/msm/wfd: for our wfd driver
On 05-12-2011 13:38, Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
On 05-12-2011 05:21, Thierry Reding wrote:
* linu...@stefanringel.de wrote:
From: Stefan Ringellinu...@stefanringel.de
Signed-off-by: Stefan Ringellinu...@stefanringel.de
Your commit message needs more details. Why
On Sun, Nov 20, 2011 at 9:56 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index ecd1f95..048f489 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@
On 05-12-2011 16:23, Devin Heitmueller wrote:
On Sun, Nov 20, 2011 at 9:56 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index ecd1f95..048f489 100644
--- a/drivers/media/common/tuners/xc5000.c
+++
On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
What's up with this change? Is this a bugfix for some race condition?
Why is it jammed into a patch for some particular product?
It seems like a change such as this could significantly change the
timing of tuner
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Mon Dec 5 19:00:18 CET 2011
git hash:2a887d27708a4f9f3b5ad8258f9e19a150b58f03
gcc version: i686-linux-gcc
On Mon, Dec 05, 2011 at 05:18:48PM +, Arnd Bergmann wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
+ /* allow allocator to take care of cache ops */
+ void (*sync_sg_for_cpu) (struct dma_buf *, struct device *);
+ void (*sync_sg_for_device)(struct dma_buf *, struct device
On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
The only way to solve this that I can think of right now is to
mandate that the mappings are all coherent (i.e. noncachable
on noncoherent architectures like ARM). If you do that, you no
longer need the sync_sg_for_* calls.
Woops,
The V4L2_CID_FLASH_HW_STROBE_MODE mode control is intended
for devices that are source of an external flash strobe for flash
devices. This part seems to be missing in current Flash control
class, i.e. a means for configuring devices that are not camera
flash drivers but involve a flash related
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support any 64-bit systems, but such platforms can be added in the
and in any case compiler warnings should be avoided.
Signed-off-by: Guennadi
On Mon, Dec 5, 2011 at 1:46 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
What's up with this change? Is this a bugfix for some race condition?
Why is it jammed into a patch for some particular
Am 05.12.2011 19:21, schrieb Mauro Carvalho Chehab:
On 05-12-2011 13:38, Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
On 05-12-2011 05:21, Thierry Reding wrote:
* linu...@stefanringel.de wrote:
From: Stefan Ringellinu...@stefanringel.de
Signed-off-by: Stefan
On 05-12-2011 18:02, Stefan Ringel wrote:
Am 05.12.2011 19:21, schrieb Mauro Carvalho Chehab:
On 05-12-2011 13:38, Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
On 05-12-2011 05:21, Thierry Reding wrote:
* linu...@stefanringel.de wrote:
From: Stefan Ringellinu...@stefanringel.de
On 05.12.2011 18:39, Mauro Carvalho Chehab wrote:
On 05-12-2011 12:28, HoP wrote:
And here is a new hack.
I'm really tired from all those hack, crap, pigback ... wordings.
What exactly vtuner aproach does so hackish (other then exposing
DVB internals, what is every time made if
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have
The USB case is quite different because your latency is very tightly
bounded, your dead device state is rigidly defined, and your loss of
device is accurately and immediately signalled.
Quite different.
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of
On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
The only way to solve this that I can think of right now is to
mandate that the mappings are all coherent (i.e. noncachable
on noncoherent architectures like ARM). If
On 05.12.2011 21:55, Alan Cox wrote:
The USB case is quite different because your latency is very tightly
bounded, your dead device state is rigidly defined, and your loss of
device is accurately and immediately signalled.
Quite different.
How can usbip work if networking and usb are so
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
In the patch 2, you have a section about migration that mentions that
it is possible to export a buffer that can be migrated after it
is already mapped into one
How can usbip work if networking and usb are so different and what's so
different between vtunerc and usbip, that made it possible to put usbip
into drivers/staging?
Where usbip seems to have remained for a long time without actually being
made useful or correct enough to progress. Meanwhile
Hi Ming,
(I've pruned the Cc list, leaving just the mailing lists)
On 12/02/2011 04:02 PM, Ming Lei wrote:
This patch introduces one driver for face detection purpose.
The driver is responsible for all v4l2 stuff, buffer management
and other general things, and doesn't touch face detection
On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
...
Thanks a lot for this excellent overview. I think at least for the first
version of dmabuf we should drop the sync_* interfaces and simply require
users to bracket
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
In the patch 2, you have a section about migration that mentions that
it is possible to export a
On 12/02/2011 04:02 PM, Ming Lei wrote:
This patch introduces two new IOCTLs and related data
structure defination which will be used by the coming
face detection video device.
The two IOCTLs and related data structure are used by
user space application to retrieve the results of face
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann a...@arndb.de wrote:
https://github.com/robclark/kernel-omap4/commits/dmabuf
Ok, thanks. I think it would be good to post these for reference
in v3, with a clear indication that they are not being submitted
for discussion/inclusion yet.
btw,
On Mon, Dec 05, 2011 at 04:11:46PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
I sort of preferred having the DMABUF shim because that lets you pass
a buffer around userspace without
On Mon, Dec 05, 2011 at 11:04:09PM +0100, Arnd Bergmann wrote:
On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
...
Thanks a lot for this excellent overview. I think at least for the first
version of dmabuf we
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
I sort of preferred having the DMABUF shim because that lets you pass
a buffer around userspace without the receiving code knowing about a
device specific API. But the
Hi Sylwester,
Thanks for the RFC.
On Mon, Dec 05, 2011 at 08:56:46PM +0100, Sylwester Nawrocki wrote:
The V4L2_CID_FLASH_HW_STROBE_MODE mode control is intended
for devices that are source of an external flash strobe for flash
devices. This part seems to be missing in current Flash control
Sorry, I think I applied follow patch on my tree while I developed
the driver trying to fix tuner initialization.
http://patchwork.linuxtv.org/patch/6617/
I forgot to remove from my tree after I see that don't solve anything.
Regards
Eddi
On Mon, Dec 5, 2011 at 9:01 PM, Devin Heitmueller
try using scan from dvb-apps and not w_scan.
Actually It seems to me w_scan isn't compatible with this driver due
some missing lock.
On Fri, Dec 2, 2011 at 8:45 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Fri, Dec 2, 2011 at 2:41 PM, Fredrik Lingvall
fredrik.lingv...@gmail.com
On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pieri e...@depieri.net wrote:
Sorry, I think I applied follow patch on my tree while I developed
the driver trying to fix tuner initialization.
http://patchwork.linuxtv.org/patch/6617/
I forgot to remove from my tree after I see that don't solve
I doubt that scan or w_scan would support it. Even if it supports, that
would mean that,
for each ioctl that would be sent to the remote server, the error code would
take 480 ms
to return. Try to calculate how many time w_scan would work with that. The
calculus is easy:
see how many ioctl's
Hi Michael
2011/12/5 Michael Krufky mkru...@linuxtv.org:
On Mon, Dec 5, 2011 at 9:28 AM, HoP jpetr...@gmail.com wrote:
Hi
2011/12/5 Florian Fainelli f.faine...@gmail.com:
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk:
On Thu, 1 Dec 2011
On Monday 05 of December 2011 at 21:01:13, Guennadi Liakhovetski wrote:
On 64-bit platforms assigning a pointer to a 32-bit variable causes a
compiler warning and cannot actually work. Soc-camera currently doesn't
support any 64-bit systems, but such platforms can be added in the
and in any
* Mauro Carvalho Chehab wrote:
That means that all we need is to get rid of TM6000_QUIRK_NO_USB_DELAY.
I've just reviewed my patches again and it seems that no-USB-delay quirk
patch was only partially applied. The actual location where it was introduced
was in tm6000_read_write_usb() to allow
59 matches
Mail list logo
