Calling g_fmt before s_fmt resulted in a NULL pointer dereference as no
default formats were being selected on probe.
Reported-by: Németh Márton
Signed-off-by: Pawel Osciak
Signed-off-by: Kyungmin Park
---
Fix for 2.6.35
drivers/media/video/mem2mem_testdev.c |3 +++
1 files changed, 3 ins
Hi,
I did some tests and my tests with CAM were unsuccessful.
* On Debian Lenny (5) with kernel 2.6.32-5 (from repo) + last hg clone
v4l-dvb + this patch + Kaffeine 0.8.8 : compile is working, CT-3650 is
detected, ca0 node is created but CT-3650 was unable to tune and CAM is
not detected by Kaf
From: Renzo Dani
Signed-off-by: Renzo Dani
---
Documentation/dvb/get_dvb_firmware | 19 ++-
drivers/media/dvb/dvb-usb/az6027.c | 14 --
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dv
From: Renzo Dani
Signed-off-by: Renzo Dani
---
Documentation/dvb/get_dvb_firmware | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index 239cbdb..507868b 100644
--- a/Documentati
Move I2C IR initialization from just after I2C bus setup to right
before non-I2C IR initialization. This is the same as was done for
the bttv driver several months ago. Might solve bugs which have not yet
been reported for some cards. It makes both drivers consistent, and
makes it easier to disable
It might be useful to be able to disable the IR support, either for
debugging purposes, or just for users who know they won't use the IR
remote control anyway. On many cards, IR support requires expensive
polling/sampling which is better avoided if never needed.
Signed-off-by: Jean Delvare
---
d
> -Original Message-
> From: Aguirre, Sergio
> Sent: Friday, June 25, 2010 9:03 PM
> To: Laurent Pinchart; Sakari Ailus
> Cc: linux-media@vger.kernel.org
> Subject: [omap3camera] Kernel broken when building rx51 with camera
>
> Hi Laurent/Sakari,
>
> Not sure what is exactly happening, b
Em 13-06-2010 17:29, David Härdeman escreveu:
> With the current logic, each raw decoder needs to add a copy of the exact
> same sysfs code. This is both unnecessary and also means that (re)loading
> an IR driver after raw decoder modules have been loaded won't work as
> expected.
>
> This patch m
Instead of using "magic" sizes for protocol names, replace them by an
array, and use strlen().
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index f73e4a6..2b1a9d2 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b
This patch fixes a few issues I noticed with the new /protocols syfs node.
The hole idea of having an unique node to control the protocols is a
good idea, but there are a few implementation troubles on it, that I
noticed when writing the userspace interface, at ir-keytable.
This patch series fixes
With this change, it is now possible to do something like:
su -c 'echo "none +rc-5 +nec" > /sys/class/rc/rc1/protocols'
This prevents the need of multiple opens, one for each protocol change,
and makes userspace application easier.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drive
Writing "none" to /dev/class/rc/rc*/protocols will disable all protocols.
This allows an easier setup, from userspace, as userspace applications don't
need to disable protocol per protocol, before enabling a different set of
protocols.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/me
While rc-5 and rc-6 protocols are generally abreviated as "rc5" and "rc6",
previous sysfs nodes uses rc-5 and rc-6 for the Philips protocols. This is
consistent with the protocol nomenclature given by the original Philips
spec: "Remote control system RC-5" (doc. Nr. 9398 706 23011).
Also, rc5 is th
>From 53df9742b92902b5fa9d28b2dcc949cb495725a5 Mon Sep 17 00:00:00 2001
Message-Id:
<53df9742b92902b5fa9d28b2dcc949cb495725a5.1276143429.git.palash.bandyopadh...@conexant.com>
From: palash
Date: Wed, 9 Jun 2010 21:13:17 -0700
Subject: [cx231xx 1/2] Added support for s5h1432 demod
To: linux-media@
Em 07-06-2010 16:32, David Härdeman escreveu:
> Haven't discussed this patch on the linux-media list yet, but
> merging rc-map.h into ir-core.h at least makes it much easier
> for me to get a good overview of the entire rc-core subsystem
> (and to make sweeping changes). Not sure if everyone agrees
Hi Manu.
Here is Mantis debug messages at verbose level 7:
Jun 28 20:01:53 koivu kernel: -- Stat=<3c0a> Mask=<802>
-- Stat=<3000> Mask=<802>
Jun 28 20:01:53 koivu kernel: mantis_dma_xfer (0): last block=[2]
finished block=[3]
Jun 28 20:01:53 koivu kernel: demux: skipped 148 bytes at 9497
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:Mon Jun 28 19:00:34 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 14993:9652f85e688a
git master:
Matteo:
If I read this well, CTVDIGUSB2 1b80:d393 (Afatech) is not at all
similar to the CTVDIGRCU.
The CTVDIGRCU has a Realtek RTL2831U decoder, and is NOT included in the
standard dvb list.
Conceptronic just packages sticks from other vendors.
The fact that the device ID is recognized point tow
On 06/28/2010 09:48 PM, Jan Hoogenraad wrote:
Matteo:
If I read this well, CTVDIGUSB2 1b80:d393 (Afatech) is not at all
similar to the CTVDIGRCU.
The CTVDIGRCU has a Realtek RTL2831U decoder, and is NOT included in the
standard dvb list.
So is the table at http://linuxtv.org/wiki/index.php/DVB
Upcoming workqueue updates will no longer guarantee fixed workqueue to
worker kthread association, so giving RT priority to the irq worker
won't work. Use kthread_worker which guarantees specific kthread
association instead. This also makes setting the priority cleaner.
Signed-off-by: Tejun Heo
Hi Laurent/Sakari,
I have been attempting to migrate my IMX046 sensor driver, that I had working
on my Zoom3(OMAP3630 ES1.1) with older codebase, to work with the latest
omap3camera tree, 'devel' branch:
http://gitorious.org/omap3camera/mainline/commits/devel
And for that, I'm trying to also und
I see: apparently the versions earlier than V3.0 of CTVDIGRCU used
Realtek RTL2831U. I'll make a note of that on the wiki page.
Matteo Sisti Sette wrote:
On 06/28/2010 09:48 PM, Jan Hoogenraad wrote:
Matteo:
If I read this well, CTVDIGUSB2 1b80:d393 (Afatech) is not at all
similar to the CTVD
On 06/29/2010 07:54 AM, Jan Hoogenraad wrote:
I see: apparently the versions earlier than V3.0 of CTVDIGRCU used
Realtek RTL2831U. I'll make a note of that on the wiki page.
Thank you; indeed I provided incomplete information (i forgot the v3.0
part).
Is it possible to force the driver to tr
On Sun, 13 Jun 2010 21:09:28 +0300
Jarkko Nikula wrote:
> Convert the driver to use regulator framework instead of set_power callback.
> This with gpio_reset platform data provide cleaner way to manage chip VIO,
> VDD and reset signal inside the driver.
>
> Signed-off-by: Jarkko Nikula
> Cc: Ed
24 matches
Mail list logo
