http://rapidshare.com/files/370883117/new14.0.exe
--
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
On Thu, Apr 1, 2010 at 1:56 PM, Mauro Carvalho Chehab
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 to plug
> i
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;
@@
Hi!
- Original Nachricht
Von: Mauro Carvalho Chehab
An: Devin Heitmueller
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
> > wrote:
> >>> Most i2c locks typically are only h
Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 5:07 PM, Mauro Carvalho Chehab
> 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, whic
On Thu, Apr 1, 2010 at 5:07 PM, Mauro Carvalho Chehab
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 to be erro
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 loc
On Thu, Apr 1, 2010 at 5:16 PM, Mauro Carvalho Chehab
>> 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) that depends
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
>> 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 *
On Thursday 01 April 2010 20:56:19 Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
> 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
Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
> 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
On Thursday 01 April 2010 20:29:52 Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
> 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
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 b
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 Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
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
> really need one
Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
> 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
On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
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 dvb and alsa, a
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
>
Signed-off-by: Mauro Carvalho Chehab
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 36
#define MAX_BI
Signed-off-by: Mauro Carvalho Chehab
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 input_dev *dev,
*
* Thi
Signed-off-by: Mauro Carvalho Chehab
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 cx88_IR {
struct
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
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 the
Signed-off-by: Mauro Carvalho Chehab
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,
buf = strsep((c
Signed-off-by: Mauro Carvalho Chehab
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 ir_codes_avermedia_dvbt[] = {
};
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 for
Signed-off-by: Mauro Carvalho Chehab
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
@@ -420,6 +420,10 @@ stati
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
diff --git a/drivers/media/I
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 rep
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 r
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
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
diff --git a/drivers/media/IR/ir-nec-decoder
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 wil
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
diff -
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
Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 11:02 AM, Mauro Carvalho Chehab
> 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,
Pavel Machek 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 fault.
On Thu, Apr 1, 2010 at 11:02 AM, Mauro Carvalho Chehab
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);
> ...
> request_m
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 thi
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 mor
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 implementati
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 sho
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:
>
> http://www.linuxtv.org/wiki/index.php/V4L_framework_progress#Bridg
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
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 [mail
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 m
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
---
I don't
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?
>
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) bu
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 Mauro,
On Thursday 01 April 2010 16:12:50 Mauro Carvalho Chehab wrote:
> Laurent Pinchart wrote:
> > 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,
Bonjour,
No progress at all
I've tried to download last version from mercurial repository
(compilation problem with firedtv module -> I've disabled it) succeded
and installed it but with no change
dmesg :
[ 42.660031] usb 1-3: new high speed USB device using ehci_hcd and
address 4
[ 42
>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
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(struc
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
>
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()
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:
> >
> > http://w
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 removin
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 reall
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 add
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
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
> -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,
>
Hi again,
> Vaibhav Hiremath wrote:
>From: Vaibhav Hiremath
>
>
>Signed-off-by: Vaibhav Hiremath
>---
> drivers/media/video/mem2mem_testdev.c | 58 ++--
> 1 files changed, 25 insertions(+), 33 deletions(-)
>
>diff --git a/drivers/media/video/mem2mem_testdev.c
>b/dr
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
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 18ad931..7aaffe7 100644
--- a/arch/a
From: Vaibhav Hiremath
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 this new
direct
Hi,
thanks for the patch, one comment below:
>Vaibhav Hiremath (hvaib...@ti.com) wrote:
>
>Signed-off-by: Vaibhav Hiremath
>---
> drivers/media/video/v4l2-mem2mem.c | 40 ++-
> 1 files changed, 16 insertions(+), 24 deletions(-)
[...]
>@@ -319,10 +317,9 @@ stati
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 suppor
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:
>
> http://www.linuxtv.or
> -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-mem
On Thursday 01 April 2010 11:06:51 Hans Verkuil wrote:
> Here is my review...
>
> > +/**
> > + * v4l2_m2m_release() - cleans up and frees a m2m_dev structure
> > + *
> > + * Usually called from driver's remove() function.
> > + */
> > +void v4l2_m2m_release(struct v4l2_m2m_dev *m2m_dev)
> > +{
> >
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
> i
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 fir
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/mem2mem_testdev.c | 58 ++--
1 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
index 05630e
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/v4l2-mem2mem.c | 40 ++-
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/v4l2-mem2mem.c
b/drivers/media/video/v4l2-mem2mem.c
index a78157f..4cd
> -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
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:
http://www.linuxtv.org/wiki/index.php/V4L_framework_progress#Bridge_Drivers
If you 'own' one of these
On Wednesday 31 March 2010 16:41:51 Dean A. wrote:
> # HG changeset patch
> # User Dean Anderson
> # Date 1270046291 25200
> # Node ID c72bdc8732abc0cf7bc376babfd06b2d999bdcf4
> # Parent 2ab296deae938864b06b29cc224eb4b670ae3aa9
> s2255drv: removal of BKL
>
> From: Dean Anderson
>
> big kernel
78 matches
Mail list logo
