On Wednesday 31 March 2010 16:41:51 Dean A. wrote:
# HG changeset patch
# User Dean Anderson d...@sensoray.com
# Date 1270046291 25200
# Node ID c72bdc8732abc0cf7bc376babfd06b2d999bdcf4
# Parent 2ab296deae938864b06b29cc224eb4b670ae3aa9
s2255drv: removal of BKL
From: Dean Anderson
-Original Message-
From: Pawel Osciak [mailto:p.osc...@samsung.com]
Sent: Monday, March 29, 2010 1:07 PM
To: linux-media@vger.kernel.org
Cc: p.osc...@samsung.com; m.szyprow...@samsung.com;
kyungmin.p...@samsung.com; Hiremath, Vaibhav
Subject: [PATCH v3 0/2] Mem-to-mem device
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/v4l2-mem2mem.c | 40 ++-
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/v4l2-mem2mem.c
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/mem2mem_testdev.c | 58 ++--
1 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/media/video/mem2mem_testdev.c
On Tuesday 30 March 2010 14:39:12 Wolfram Sang wrote:
Hans,
But this just feels like an i2c core thing to me. After remove() is called
the core should just set the client data to NULL. If there are drivers that
rely on the current behavior, then those drivers should be reviewed first as
Here is my review...
On Monday 29 March 2010 09:36:46 Pawel Osciak wrote:
A mem-to-mem device is a device that uses memory buffers passed by
userspace applications for both their source and destination data. This
is different from existing drivers, which utilize memory buffers for either
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Thursday, April 01, 2010 2:37 PM
To: Pawel Osciak
Cc: linux-media@vger.kernel.org; m.szyprow...@samsung.com;
kyungmin.p...@samsung.com; Hiremath, Vaibhav
Subject: Re: [PATCH v3 1/2] v4l: Add memory-to-memory
Hi Hans,
On Thursday 01 April 2010 10:01:10 Hans Verkuil wrote:
Hi all,
I just read on LWN that the core kernel guys are putting more effort into
removing the BKL. We are still using it in our own drivers, mostly V4L.
I added a BKL column to my driver list:
The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
Jonathan Corbet (1):
V4L/DVB: ov7670: silence some compiler warnings
are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo
Laurent Pinchart (5):
uvcvideo: Add
Hi,
thanks for the patch, one comment below:
Vaibhav Hiremath (hvaib...@ti.com) wrote:
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/v4l2-mem2mem.c | 40 ++-
1 files changed, 16 insertions(+), 24 deletions(-)
[...]
@@ -319,10 +317,9
From: Vaibhav Hiremath hvaib...@ti.com
The previous patch submission had a dependancy on ti-media directory patch,
and since we were not having any conclusion on that patch, I have created
omap directory (device specific name) and moved V4L2 driver
(as of now applicable to OMAP2/3 devices) to
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/devices.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index
Hi again,
Vaibhav Hiremath hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/mem2mem_testdev.c | 58 ++--
1 files changed, 25 insertions(+), 33 deletions(-)
diff --git
-Original Message-
From: Pawel Osciak [mailto:p.osc...@samsung.com]
Sent: Thursday, April 01, 2010 3:39 PM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org; Marek Szyprowski; kyungmin.p...@samsung.com
Subject: RE: [PATCH 2/2] mem2mem_testdev: Code cleanup
Hi again,
On Thursday 01 April 2010 11:23:30 Laurent Pinchart wrote:
Hi Hans,
On Thursday 01 April 2010 10:01:10 Hans Verkuil wrote:
Hi all,
I just read on LWN that the core kernel guys are putting more effort into
removing the BKL. We are still using it in our own drivers, mostly V4L.
I
On Tue, Mar 30, 2010 at 04:06:11PM +0200, Rodolfo Giometti wrote:
On Tue, Feb 23, 2010 at 12:19:13AM +0100, Richard Röjfors wrote:
We use it as a subdev to a driver not yet committed from us. So I think
you should extend it, not move it.
Finally I got something functional... but I'm
The attached patch rewrites the keyup/keydown logic in
drivers/media/IR/ir-keytable.c.
(applies to http://git.linuxtv.org/mchehab/ir.git)
All knowledge of keystates etc is now internal to ir-keytable.c
and not scattered around ir-raw-event.c and ir-nec-decoder.c (where
it doesn't belong).
In
Hans Verkuil wrote:
On the DVB side there seem to be only two sources that use the BKL:
linux/drivers/media/dvb/bt8xx/dst_ca.c: lock_kernel();
linux/drivers/media/dvb/bt8xx/dst_ca.c: unlock_kernel();
This is from an incomplete conversion from .ioctl to .unlocked_ioctl (no
conversion really,
Hi Hans,
On Thursday 01 April 2010 13:11:51 Hans Verkuil wrote:
On Thursday 01 April 2010 11:23:30 Laurent Pinchart wrote:
On Thursday 01 April 2010 10:01:10 Hans Verkuil wrote:
Hi all,
I just read on LWN that the core kernel guys are putting more effort
into removing the BKL. We
On Thursday 01 April 2010 13:57:13 Stefan Richter wrote:
Hans Verkuil wrote:
I just read on LWN that the core kernel guys are putting more effort into
removing the BKL. We are still using it in our own drivers, mostly V4L.
I added a BKL column to my driver list:
Stefan Richter wrote:
linux/drivers/media/dvb/dvb-core/dvbdev.c: lock_kernel();
linux/drivers/media/dvb/dvb-core/dvbdev.c: unlock_kernel();
linux/drivers/media/dvb/dvb-core/dvbdev.c: unlock_kernel();
This is from when the BKL was pushed down into drivers' open()
Hans Verkuil wrote:
I just read on LWN that the core kernel guys are putting more effort into
removing the BKL. We are still using it in our own drivers, mostly V4L.
I added a BKL column to my driver list:
http://www.linuxtv.org/wiki/index.php/V4L_framework_progress#Bridge_Drivers
If
Hi Hans,
thank you for the review. My comments below.
Hans Verkuil [mailto:hverk...@xs4all.nl] wrote:
Here is my review...
[...]
+/**
+ * v4l2_m2m_next_src_buf() - return next source buffer from the list of
ready
+ * buffers
+ */
+inline void *v4l2_m2m_next_src_buf(struct v4l2_m2m_ctx
Pawel Osciak [mailto:p.osc...@samsung.com] wrote:
+unsigned int v4l2_m2m_poll(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
+ struct poll_table_struct *wait)
+{
+ struct videobuf_queue *dst_q;
+ struct videobuf_buffer *vb = NULL;
+ unsigned int rc = 0;
+
+
On Thursday 01 April 2010 16:12:50 Mauro Carvalho Chehab wrote:
Laurent Pinchart wrote:
Hi Hans,
On Thursday 01 April 2010 13:11:51 Hans Verkuil wrote:
On Thursday 01 April 2010 11:23:30 Laurent Pinchart wrote:
On Thursday 01 April 2010 10:01:10 Hans Verkuil wrote:
Hi all,
I just
Hello,
we would like to propose a change to how videobuf handles the process
of waking up buffers, to allow returning them to userspace in a different
order than FIFO, if a driver (device) so requires.
Currently, when poll() or dqbuf() is called, videobuf takes the first
(i.e. first qbuf()-ed)
On Thursday 01 April 2010 17:02:01 Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
What to do if we have multiple device nodes? E.g. video0 and vbi0? Should we
allow access to video0 when vbi0 is not yet registered? Or should we block
access until all video nodes are registered?
It
It's possible that we wanted to resize to a smaller size but we didn't
have enough memory to create the new table. We need to test for that
here so we don't try to lock twice and dead lock. Also we free the
oldkeymap on that path and that would be bad.
Signed-off-by: Dan Carpenter
Muralidharan Karicheri wrote:
Mauro,
When I had last replied to your email, I didn't check if the patch is
actually applied to your v4l_for_linux branch of fixes.git tree. But
Today I checked and I can't find the patch merged to this tree as you
had mentioned..
So if you haven't merged
Mauro,
Thanks a lot for your support.
Do you plan to merge my pull request for 2.6.35 anytime soon?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Mauro Carvalho Chehab
Karicheri, Muralidharan wrote:
Mauro,
Thanks a lot for your support.
Do you plan to merge my pull request for 2.6.35 anytime soon?
It were already merged locally. I'm running a compilation of the
tree with the merged patches. If all compile ok, your pull request
(and others) will be at
Hans Verkuil wrote:
Hi all,
I just read on LWN that the core kernel guys are putting more effort into
removing the BKL. We are still using it in our own drivers, mostly V4L.
I added a BKL column to my driver list:
Laurent Pinchart wrote:
One typical problem that I see is that some drivers register too soon: they
first register, then initialize some things. I've seen (and fixed) some
race conditions due to that. Just moving the register to the end solves
this issue.
That's right, devices should not
Hans Verkuil wrote:
What to do if we have multiple device nodes? E.g. video0 and vbi0? Should we
allow access to video0 when vbi0 is not yet registered? Or should we block
access until all video nodes are registered?
It will depend on the driver implementation, but, as new udev
Laurent Pinchart wrote:
Hi Hans,
On Thursday 01 April 2010 13:11:51 Hans Verkuil wrote:
On Thursday 01 April 2010 11:23:30 Laurent Pinchart wrote:
On Thursday 01 April 2010 10:01:10 Hans Verkuil wrote:
Hi all,
I just read on LWN that the core kernel guys are putting more effort
into
Hi!
Do you mean the dmesg output ?
A full dmesg is included in this address :
http://pastebin.com/8XU619Uk
Not in all suspend/hibernate the problem comes, only in some of them
and this included dmesg output is just after a non working case of
webcam fault.
I also have found this in
On Thu, Apr 1, 2010 at 11:02 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
I remember I had to do it on em28xx:
This is the init code for it:
...
mutex_init(dev-lock);
mutex_lock(dev-lock);
em28xx_init_dev(dev, udev, interface, nr);
...
Pavel Machek pa...@ucw.cz writes:
Do you mean the dmesg output ?
A full dmesg is included in this address :
http://pastebin.com/8XU619Uk
Not in all suspend/hibernate the problem comes, only in some of them
and this included dmesg output is just after a non working case of
webcam
Devin Heitmueller wrote:
On Thu, Apr 1, 2010 at 11:02 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
I remember I had to do it on em28xx:
This is the init code for it:
...
mutex_init(dev-lock);
mutex_lock(dev-lock);
em28xx_init_dev(dev, udev, interface,
I made a quick implementation which is available here:
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
It's pretty easy to use and it also gives you a very simple way to block
access to the video device nodes until all have been allocated by simply
taking the serialization lock and holding
drivers/media/video/saa7134/saa7134-input.c: In function
‘saa7134_raw_decode_irq’:
drivers/media/video/saa7134/saa7134-input.c:957: warning: unused variable
‘oldpulse’
drivers/media/video/saa7134/saa7134-input.c:957: warning: unused variable
‘count’
Signed-off-by: Mauro Carvalho Chehab
This series of 15 patches improves support for IR, as discussed at the
What are the goals for the architecture of an in-kernel IR system?
thread.
It basically adds a raw decoder layer at ir-core, allowing decoders to plug
into IR core, and preparing for the addition of a lirc_dev driver that will
With the help of raw_register/raw_unregister, adds a sysfs group
associated with the decoder, inside the corresponding irrcv node.
Writing 1 to nec_decoder/enabled enables the decoder, while
writing 0 disables it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git
Some decoders and a lirc_dev interface may need some other operations to work.
For example: IR device register/unregister and ir_keydown events may need to
be tracked.
As some operations can occur in interrupt time, and a lock is needed to prevent
un-registering a decode while decoding a key, the
Instead of hardcoding the protocols into ir-core, add a register interface
for the IR protocol decoders, and convert ir-nec-decoder into a client of
ir-core.
With this approach, it is possible to dynamically load the needed IR protocols,
and to add a RAW IR interface module, registered as one IR
At raw_decode mode, the key is processed after the end of a timer. The
previous code resets the timer every time something is received at the IR
port. While this works fine with IR's that don't implement repeat, like
Avermedia RM-JX IR, it keeps waiting until keydown, on IR's that implement
NEC
Especially when IR needs to do polling, it generates lots of wakeups per
second. This makes no sense, if the input event device is closed.
Adds a callback handler to the IR hardware driver, to allow registering
an open/close ops.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index d7e73de..8187928 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@
Several devices use a high number of bits for scancodes. One important
group is the Remote Controllers. Some new protocols like RC-6 define a
scancode space of 64 bits.
The current EVIO[CS]GKEYCODE ioctls allow replace the scancode/keycode
translation tables, but it is limited to up to 32 bits
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/IR/ir-keymaps.c b/drivers/media/IR/ir-keymaps.c
index dfc777b..55e7acd 100644
--- a/drivers/media/IR/ir-keymaps.c
+++ b/drivers/media/IR/ir-keymaps.c
@@ -122,55 +122,57 @@ static struct ir_scancode
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index bbddf2f..ee6b36d 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -92,7 +92,7 @@ static ssize_t store_protocol(struct device *d,
IR is an alias for Infrared Remote, while RC is an alias for Remote
Controller.
While currently all implementations are with Infrared Remote Controller,
this subsystem is not meant to be used only by IR type of RC's. So,
as discussed on both linux-media and linux-input, the better is to
rename
Adds a method to pass IR raw pulse/code events into ir-core. This is
needed in order to support LIRC. It also helps to move common code
from the drivers into the core.
In order to allow testing, it implements a simple NEC protocol decoder
at ir-nec-decoder.c file. The logic is about the same used
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx88/cx88-input.c
b/drivers/media/video/cx88/cx88-input.c
index 8f1b846..a7214d0 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -39,6 +39,10 @@ struct
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 2d9ba84..ab60730 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -364,7 +364,7 @@ static int ir_setkeycode(struct
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/IR/ir-nec-decoder.c
b/drivers/media/IR/ir-nec-decoder.c
index 16360eb..a58c717 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -30,37 +30,35 @@
#define MIN_BIT0_TIME
Hans,
Hans Verkuil wrote:
I made a quick implementation which is available here:
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
It's pretty easy to use and it also gives you a very simple way to block
access to the video device nodes until all have been allocated by simply
taking
On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
If you take a look at em28xx-dvb, it is not lock-protected. If the bug is due
to the async load, we'll need to add the same locking at *alsa and *dvb
parts of em28xx.
Yes, that is correct. The problem effects both
Devin Heitmueller wrote:
On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
If you take a look at em28xx-dvb, it is not lock-protected. If the bug is due
to the async load, we'll need to add the same locking at *alsa and *dvb
parts of em28xx.
Yes, that is
On Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
If the i2c lock was toggled to digital mode, then it means that the i2c
code is being in use simultaneously by analog and digital mode. It also
means that an i2c IR device, or alsa will have troubles also. So, we
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:Thu Apr 1 19:00:20 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 14536:a539e5b68945
git master:
On Thursday 01 April 2010 20:24:12 Mauro Carvalho Chehab wrote:
Hans,
Hans Verkuil wrote:
I made a quick implementation which is available here:
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
It's pretty easy to use and it also gives you a very simple way to block
access
On Thursday 01 April 2010 20:29:52 Devin Heitmueller wrote:
On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
If you take a look at em28xx-dvb, it is not lock-protected. If the bug is
due
to the async load, we'll need to add the same locking at *alsa and *dvb
Devin Heitmueller wrote:
On Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
If the i2c lock was toggled to digital mode, then it means that the i2c
code is being in use simultaneously by analog and digital mode. It also
means that an i2c IR device, or alsa will
On Thursday 01 April 2010 20:56:19 Devin Heitmueller wrote:
On Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
If the i2c lock was toggled to digital mode, then it means that the i2c
code is being in use simultaneously by analog and digital mode. It also
means
Hans Verkuil wrote:
On Thursday 01 April 2010 20:29:52 Devin Heitmueller wrote:
On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
If you take a look at em28xx-dvb, it is not lock-protected. If the bug is
due
to the async load, we'll need to add the same locking
On Thu, Apr 1, 2010 at 5:16 PM, Mauro Carvalho Chehab mche...@redhat.com
What was the reason behind the asynchronous loading? In general it simplifies
things a lot if you load modules up front.
The reason is to avoid a dead lock: driver A depends on symbols on B (the
other driver init code)
Hans Verkuil wrote:
Maybe a better alternative would be to pass to the V4L2 core, optionally,
some lock,
used internally on the driver. This approach will still be pedantic, as all
ioctls will
keep being serialized, but at least the driver will need to explicitly
handle the lock,
and the
On Thu, Apr 1, 2010 at 5:07 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Most i2c locks typically are only held for the duration of a single
i2c transaction. What you are proposing would likely result in just
about every function having to explicitly lock/unlock, which just
seems bound
Hi!
- Original Nachricht
Von: Mauro Carvalho Chehab mche...@redhat.com
An: Devin Heitmueller dheitmuel...@kernellabs.com
Datum: 02.04.2010 01:10
Betreff: Re: V4L-DVB drivers and BKL
Devin Heitmueller wrote:
On Thu, Apr 1, 2010 at 5:07 PM, Mauro Carvalho Chehab
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe. Prevents further
key xxx not in .data bug-reports. Although some attributes could probably be
converted to static ones, this is left for people having hardware to test.
Found by this semantic patch:
@ init @
type T;
identifier A;
@@
On Thu, Apr 1, 2010 at 1:56 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
This series of 15 patches improves support for IR, as discussed at the
What are the goals for the architecture of an in-kernel IR system?
thread.
It basically adds a raw decoder layer at ir-core, allowing decoders
72 matches
Mail list logo
