* 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 th
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
Hi Michael
2011/12/5 Michael Krufky :
> On Mon, Dec 5, 2011 at 9:28 AM, HoP wrote:
>> Hi
>>
>> 2011/12/5 Florian Fainelli :
>>> Hello,
>>>
>>>
>>> On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Cox:
>
> On Thu, 1 Dec 2011 15:58:41 +0100
> HoP wrote:
>
>
> 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 i
On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pieri 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 anything.
Ok, g
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
wrote:
> On Fri, Dec 2, 2011 at 2:41 PM, Fredrik Lingvall
> wrote:
>> The HVR 930C device has three connectors/i
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
wro
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
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann 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 problem I ev
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 dmab
On Mon, Dec 05, 2011 at 04:11:46PM -0600, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter 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 the rec
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 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, don't loo
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter 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 wrote:
>> > In the patch 2, you have a section about migration that mentions that
>> > it is possible to export a buffer that can be
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann 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
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 brac
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 detecti
> 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
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann 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 user drive
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 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 A
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 o
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann 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 about t
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 ma
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 Ringel
Signed-off-by: Stefan Ringe
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 Ringel
Signed-off-by: Stefan Ringel
Your commit message needs more details.
On Mon, Dec 5, 2011 at 1:46 PM, Devin Heitmueller
wrote:
> On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab
> 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
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 Liakhovetski
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 func
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.
>
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 d
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 (GCC
On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab
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 initiali
On 05-12-2011 16:23, Devin Heitmueller wrote:
On Sun, Nov 20, 2011 at 9:56 AM, Mauro Carvalho Chehab
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/com
On Sun, Nov 20, 2011 at 9:56 AM, Mauro Carvalho Chehab
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
> @@ -1004,6 +1004,8
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 Ringel
Signed-off-by: Stefan Ringel
Your commit message needs more details. Why do you think this is a bugfix?
Also this commit
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 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
> > su
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 nee
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 Meyer
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
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 d
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
* Mauro Carvalho Chehab wrote:
> On 05-12-2011 05:21, Thierry Reding wrote:
> >* linu...@stefanringel.de wrote:
> >>From: Stefan Ringel
> >>
> >>Signed-off-by: Stefan Ringel
> >
> >Your commit message needs more details. Why do you think this is a bugfix?
> >Also this commit seems to effectively re
On Mon, December 5, 2011 7:18 am, Andy Walls wrote:
> Yan Seiner 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 stack probl
On Mon, Dec 5, 2011 at 9:28 AM, HoP wrote:
> Hi
>
> 2011/12/5 Florian Fainelli :
>> Hello,
>>
>>
>> On 12/03/11 01:37, HoP wrote:
>>>
>>> Hi Alan.
>>>
>>> 2011/12/3 Alan Cox:
On Thu, 1 Dec 2011 15:58:41 +0100
HoP wrote:
> Hi,
>
> let me ask you some details of your
Yan Seiner 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
>videobuf_vmalloc
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 Liakhovetski
> 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 t
Yan Seiner 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 acc
Hi
2011/12/5 Florian Fainelli :
> Hello,
>
>
> On 12/03/11 01:37, HoP wrote:
>>
>> Hi Alan.
>>
>> 2011/12/3 Alan Cox:
>>>
>>> On Thu, 1 Dec 2011 15:58:41 +0100
>>> HoP wrote:
>>>
Hi,
let me ask you some details of your interesting idea (how to
achieve the same functionality as
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 is
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 f
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
videobu
On 05-12-2011 05:21, Thierry Reding wrote:
* linu...@stefanringel.de wrote:
From: Stefan Ringel
Signed-off-by: Stefan Ringel
Your commit message needs more details. Why do you think this is a bugfix?
Also this commit seems to effectively revert (and then partially reimplement)
a patch that I
Hello,
On 12/03/11 01:37, HoP wrote:
Hi Alan.
2011/12/3 Alan Cox:
On Thu, 1 Dec 2011 15:58:41 +0100
HoP wrote:
Hi,
let me ask you some details of your interesting idea (how to
achieve the same functionality as with vtunerc driver):
[...]
The driver, as proposed, is not really a driver,
Signed-off-by: Peter Korsgaard
---
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
--- a/drivers/media/video/s5p
Hi Konrad,
On Fri, Dec 2, 2011 at 10:41 PM, Konrad Rzeszutek Wilk
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.
>>
>>
>> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
>> [2]: http://lwn.net
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 'r
59 matches
Mail list logo
