Re: [PATCH] media/video: adding __init/__exit macros to various drivers
On Tuesday 29 September 2009 02:19:00 Peter Huewe wrote: From: Peter Huewe peterhu...@gmx.de Trivial patch which adds the __init/__exit macros to the module_init/ module_exit functions of the following drivers in media video: drivers/media/video/ivtv/ivtv-driver.c drivers/media/video/cx18/cx18-driver.c drivers/media/video/davinci/dm355_ccdc.c drivers/media/video/davinci/dm644x_ccdc.c drivers/media/video/saa7164/saa7164-core.c drivers/media/video/saa7134/saa7134-core.c drivers/media/video/cx23885/cx23885-core.c For drivers/media/video/davinci/dm355_ccdc.c and drivers/media/video/davinci/dm644x_ccdc.c, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Please have a look at the small patch and either pull it through your tree, or please ack' it so Jiri can pull it through the trivial tree. linux version v2.6.32-rc1 - linus git tree, Di 29. Sep 01:10:18 CEST 2009 Signed-off-by: Peter Huewe peterhu...@gmx.de -- Laurent Pinchart -- 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
Re: [2.6.31] ir-kbd-i2c oops.
On Tuesday 29 September 2009 16:16:29 Jean Delvare wrote:
On Wed, 16 Sep 2009 10:03:32 +0200, Paweł Sikora wrote:
On Wednesday 16 September 2009 08:57:01 Jean Delvare wrote:
Hi Pawel,
I think this would be fixed by the following patch:
http://patchwork.kernel.org/patch/45707/
still oopses. this time i've attached full dmesg.
Any news on this? Do you have a refined list of kernels which have the
bug and kernels which do not?
afaics in the 2.6.2{7,8}, the remote sends some noises to pc.
effect: random characters on terminal and unusable login prompt.
now in the 2.6.31, the kernel module oopses during udev loading.
so i've renamed the .ko to prevent loading.
Tried 2.6.32-rc1? Tried the v4l-dvb repository?
no.
I am also skeptical about the +0x64/0x1a52, ir_input_init() is a rather
small function and I fail to see how it could be 6738 bytes in binary size.
i've attached asm dump of ir-common.ko
i found the '41 c7 80 cc ...' code in dump at adress 0x83e.
ir-common.ko: file format elf64-x86-64
Disassembly of section .text:
ir_extract_bits:
0: 31 c0 xor%eax,%eax
2: ba 01 00 00 00 mov$0x1,%edx
7: eb 09 jmp12 ir_extract_bits+0x12
9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
10: d1 ef shr%edi
12: 40 f6 c6 01 test $0x1,%sil
16: 74 0d je 25 ir_extract_bits+0x25
18: 89 c1 mov%eax,%ecx
1a: 09 d1 or %edx,%ecx
1c: 40 f6 c7 01 test $0x1,%dil
20: 0f 45 c1cmovne %ecx,%eax
23: 01 d2 add%edx,%edx
25: d1 ee shr%esi
27: 75 e7 jne10 ir_extract_bits+0x10
29: f3 c3 repz retq
2b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
0030 ir_decode_pulsedistance:
30: 41 55 push %r13
32: c1 e6 05shl$0x5,%esi
35: 85 f6 test %esi,%esi
37: 41 54 push %r12
39: 55 push %rbp
3a: 53 push %rbx
3b: 89 cb mov%ecx,%ebx
3d: 7e 58 jle97 ir_decode_pulsedistance+0x67
3f: 31 c0 xor%eax,%eax
41: 45 31 c0xor%r8d,%r8d
44: 41 bb 1f 00 00 00 mov$0x1f,%r11d
4a: 41 ba 01 00 00 00 mov$0x1,%r10d
50: eb 12 jmp64 ir_decode_pulsedistance+0x34
52: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
58: 41 83 c0 01 add$0x1,%r8d
5c: 83 c0 01add$0x1,%eax
5f: 41 39 f0cmp%esi,%r8d
62: 7d 33 jge97 ir_decode_pulsedistance+0x67
64: 44 89 c1mov%r8d,%ecx
67: 45 89 c1mov%r8d,%r9d
6a: 44 89 ddmov%r11d,%ebp
6d: 83 e1 1fand$0x1f,%ecx
70: 41 c1 f9 05 sar$0x5,%r9d
74: 45 89 d5mov%r10d,%r13d
77: 29 cd sub%ecx,%ebp
79: 4d 63 c9movslq %r9d,%r9
7c: 89 e9 mov%ebp,%ecx
7e: 41 d3 e5shl%cl,%r13d
81: 46 85 2c 8f test %r13d,(%rdi,%r9,4)
85: 75 d1 jne58 ir_decode_pulsedistance+0x28
87: 83 f8 1ccmp$0x1c,%eax
8a: 7f 1c jg a8 ir_decode_pulsedistance+0x78
8c: 41 83 c0 01 add$0x1,%r8d
90: 31 c0 xor%eax,%eax
92: 41 39 f0cmp%esi,%r8d
95: 7c cd jl 64 ir_decode_pulsedistance+0x34
97: b8 ff ff ff ff mov$0x,%eax
9c: 5b pop%rbx
9d: 5d pop%rbp
9e: 41 5c pop%r12
a0: 41 5d pop%r13
a2: c3 retq
a3: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
a8: 41 39 f0cmp%esi,%r8d
ab: 7d ea jge97 ir_decode_pulsedistance+0x67
ad: 31 c0 xor%eax,%eax
af: 41 bb 1f 00 00 00 mov$0x1f,%r11d
b5: 41 ba 01 00 00 00 mov$0x1,%r10d
bb: eb 26 jmpe3 ir_decode_pulsedistance+0xb3
bd: 0f 1f 00nopl (%rax)
c0: 44 89 c1mov%r8d,%ecx
c3: 45 89 c1mov%r8d,%r9d
c6: 44 89 ddmov%r11d,%ebp
c9: 83 e1 1fand$0x1f,%ecx
cc: 41 c1 f9 05 sar$0x5,%r9d
d0: 45 89 d5mov%r10d,%r13d
d3: 29 cd sub%ecx,%ebp
d5: 4d 63 c9movslq %r9d,%r9
d8: 89 e9
Re: [2.6.31] ir-kbd-i2c oops.
Hi Pawel,
I am removing the linux-i2c list from Cc, because it seems clear that
your problem is related to specific media drivers and not the i2c
subsystem.
On Wed, 30 Sep 2009 10:16:15 +0200, Paweł Sikora wrote:
On Tuesday 29 September 2009 16:16:29 Jean Delvare wrote:
On Wed, 16 Sep 2009 10:03:32 +0200, Paweł Sikora wrote:
On Wednesday 16 September 2009 08:57:01 Jean Delvare wrote:
Hi Pawel,
I think this would be fixed by the following patch:
http://patchwork.kernel.org/patch/45707/
still oopses. this time i've attached full dmesg.
Any news on this? Do you have a refined list of kernels which have the
bug and kernels which do not?
afaics in the 2.6.2{7,8}, the remote sends some noises to pc.
effect: random characters on terminal and unusable login prompt.
now in the 2.6.31, the kernel module oopses during udev loading.
so i've renamed the .ko to prevent loading.
This is contradictory with your initial statement: afaics the
2.6.28.10 is also affected. It would be good to have real data points,
otherwise investigation will be very difficult...
It would be great if you could test kernel 2.6.30 and report whether it
oopses or not. The big ir-kbd-i2c changes went into kernel 2.6.31, so
my bet is that 2.6.30 should not oops, but I'd rather be certain of
this, otherwise we might keep searching in the wrong direction.
Tried 2.6.32-rc1? Tried the v4l-dvb repository?
no.
I am also skeptical about the +0x64/0x1a52, ir_input_init() is a rather
small function and I fail to see how it could be 6738 bytes in binary size.
i've attached asm dump of ir-common.ko
i found the '41 c7 80 cc ...' code in dump at adress 0x83e.
Not sure why you look at address 0x83e? The stack trace says +0x64. As
function ir_input_init() starts at 0x800, the oops address would be
0x864, which is:
864:f0 0f ab 31 lock bts %esi,(%rcx)
If my disassembler skills are still worth anything, this corresponds to
the set_bit instruction in:
for (i = 0; i IR_KEYTAB_SIZE; i++)
set_bit(ir-ir_codes[i], dev-keybit);
in the source code. This suggests that ir-ir_codes is smaller than
expected (sounds unlikely as this array is included in struct
ir_input_state) or dev-keybit isn't large enough (sounds unlikely as
well, it should be large enough to contain 0x300 bits while ir keycodes
are all below 0x100.) So most probably something went wrong before and
we're only noticing now.
Are you running distribution kernels or self-compiled ones? Any local
patches applied?
Would you be able to apply debug patches and rebuild your kernel?
At this point, all I can offer is instrumenting ir_probe() and
ir_input_init() with log messages to see exactly what code paths are
taken and what parameters are passed around.
--
Jean Delvare
--
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
Re: [2.6.31] ir-kbd-i2c oops.
On Wednesday 30 September 2009 12:57:37 Jean Delvare wrote: Are you running distribution kernels or self-compiled ones? Any local patches applied? Would you be able to apply debug patches and rebuild your kernel? yes, i'm using patched (vserver,grsec) modular kernel from pld-linux but i'm able to boot custom git build and do the bisect if necessary. -- 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
arm tree in broken state (was Re: What's inside the pxa tree for this merge window)
I discarded them _because_ Eric handled them, which is what I said in the comments when I discarded them. Ok, I did do my best to get patches in the right order in the mainline, but it all failed. AFAICS, v4l and sh are already in the mainline with a _wrongly_ resolved mefge conflict, which, most likely, breaks the sh_mobile_ceu_camera.c driver, and the three PXA platforms, patches for which should have been applied before both those trees and still haven't been applied are broken until the patches do get in and the later those patches get applied the longer the interval with the broken for them bisection is going to be. Meanwhile I have to consider that we have several bug fixes outstanding, and since I can't send Linus a pull request every day (max once a week) I have to be very careful about when I send stuff. So I only get _two_ opportunities during a merge window to send a pull request. Well, you should certainly try to keep your tree unbroken, but when it breaks, fixing it asap should be a priority. I don't know where you got the 'once a week' rule, but it seems stupid. I'm going to wait until tomorrow before sending my final pull for this window, which is the penultimate day before the window closes. Don't blame me for these delays - it's not my choice to impose such delays. I'd really like to fix those broken platforms right now. I just can't do so without causing additional delays for other issues. Blame Linus for imposing the max one pull a week rule on me. Do you have maillist reference? Not even Linus should slow down development like that. If Linus really insists on that, perhaps possible solution would be to make subarch maintainers send pull requests for simple fixes directly to Linus? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: arm tree in broken state (was Re: What's inside the pxa tree for this merge window)
Hi Pavel On Wed, 30 Sep 2009, Pavel Machek wrote: I discarded them _because_ Eric handled them, which is what I said in the comments when I discarded them. Ok, I did do my best to get patches in the right order in the mainline, but it all failed. AFAICS, v4l and sh are already in the mainline with a _wrongly_ resolved mefge conflict, which, most likely, breaks the sh_mobile_ceu_camera.c driver, and the three PXA platforms, patches for which should have been applied before both those trees and still haven't been applied are broken until the patches do get in and the later those patches get applied the longer the interval with the broken for them bisection is going to be. Meanwhile I have to consider that we have several bug fixes outstanding, and since I can't send Linus a pull request every day (max once a week) I have to be very careful about when I send stuff. So I only get _two_ opportunities during a merge window to send a pull request. Well, you should certainly try to keep your tree unbroken, but when it breaks, fixing it asap should be a priority. I don't know where you got the 'once a week' rule, but it seems stupid. I'm going to wait until tomorrow before sending my final pull for this window, which is the penultimate day before the window closes. Don't blame me for these delays - it's not my choice to impose such delays. I'd really like to fix those broken platforms right now. I just can't do so without causing additional delays for other issues. Blame Linus for imposing the max one pull a week rule on me. Do you have maillist reference? Not even Linus should slow down development like that. If Linus really insists on that, perhaps possible solution would be to make subarch maintainers send pull requests for simple fixes directly to Linus? Thanks for your concern, but the patches are long in mainline, no reason to worry any more. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: [2.6.31] ir-kbd-i2c oops.
On Wed, 30 Sep 2009 13:52:27 +0200, Paweł Sikora wrote:
On Wednesday 30 September 2009 12:57:37 Jean Delvare wrote:
Are you running distribution kernels or self-compiled ones?
Any local patches applied?
Would you be able to apply debug patches and rebuild your kernel?
yes, i'm using patched (vserver,grsec) modular kernel from pld-linux
but i'm able to boot custom git build and do the bisect if necessary.
OK, then it would be great if you could try the patch below on top of
kernel 2.6.31, and report everything that gets logged before the oops.
Of course, if you can also bisect to find out which exact change causes
the oops, that would be very helpful.
---
drivers/media/common/ir-functions.c |8 +++-
drivers/media/video/ir-kbd-i2c.c|6 ++
2 files changed, 13 insertions(+), 1 deletion(-)
--- linux-2.6.31.orig/drivers/media/common/ir-functions.c 2009-06-10
05:05:27.0 +0200
+++ linux-2.6.31/drivers/media/common/ir-functions.c2009-09-30
14:15:10.0 +0200
@@ -62,6 +62,9 @@ void ir_input_init(struct input_dev *dev
{
int i;
+ pr_info(%s: dev=%p, ir=%p, ir_type=%d, ir_codes=%p\n,
+ __func__, dev, ir, ir_type, ir_codes);
+
ir-ir_type = ir_type;
if (ir_codes)
memcpy(ir-ir_codes, ir_codes, sizeof(ir-ir_codes));
@@ -69,8 +72,11 @@ void ir_input_init(struct input_dev *dev
dev-keycode = ir-ir_codes;
dev-keycodesize = sizeof(IR_KEYTAB_TYPE);
dev-keycodemax = IR_KEYTAB_SIZE;
- for (i = 0; i IR_KEYTAB_SIZE; i++)
+ for (i = 0; i IR_KEYTAB_SIZE; i++) {
+ pr_info(%s: [i=%d] Setting bit %u of dev-keybit\n,
+ __func__, i, ir-ir_codes[i]);
set_bit(ir-ir_codes[i], dev-keybit);
+ }
clear_bit(0, dev-keybit);
set_bit(EV_KEY, dev-evbit);
--- linux-2.6.31.orig/drivers/media/video/ir-kbd-i2c.c 2009-09-10
10:08:22.0 +0200
+++ linux-2.6.31/drivers/media/video/ir-kbd-i2c.c 2009-09-30
14:17:37.0 +0200
@@ -317,6 +317,7 @@ static int ir_probe(struct i2c_client *c
ir-input = input_dev;
i2c_set_clientdata(client, ir);
+ pr_info(%s: addr=0x%02hx\n, __func__, addr);
switch(addr) {
case 0x64:
name= Pixelview;
@@ -385,6 +386,9 @@ static int ir_probe(struct i2c_client *c
goto err_out_free;
}
+ pr_info(%s: [before override] ir_codes=%p, name=%s, get_key=%p\n,
+ __func__, ir_codes, name, ir-get_key);
+
/* Let the caller override settings */
if (client-dev.platform_data) {
const struct IR_i2c_init_data *init_data =
@@ -393,6 +397,8 @@ static int ir_probe(struct i2c_client *c
ir_codes = init_data-ir_codes;
name = init_data-name;
ir-get_key = init_data-get_key;
+ pr_info(%s: [after override] ir_codes=%p, name=%s,
get_key=%p\n,
+ __func__, ir_codes, name, ir-get_key);
}
/* Make sure we are all setup before going on */
--
Jean Delvare
--
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
RE: [PATCH] media/video: adding __init/__exit macros to various drivers
For drivers/media/video/davinci/dm355_ccdc.c and drivers/media/video/davinci/dm644x_ccdc.c, Acked-by: Muralidharan Karicheri m-kariche...@ti.com Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, September 30, 2009 4:03 AM To: Peter Huewe Cc: Jiri Kosina; kernel-janit...@vger.kernel.org; Hans Verkuil; Andy Walls; Mauro Carvalho Chehab; Steven Toth; Michael Krufky; Karicheri, Muralidharan; Martin Dauskardt; Beholder Intl. Ltd. Dmitry Belimov; ivtv- de...@ivtvdriver.org; linux-media@vger.kernel.org; linux- ker...@vger.kernel.org Subject: Re: [PATCH] media/video: adding __init/__exit macros to various drivers On Tuesday 29 September 2009 02:19:00 Peter Huewe wrote: From: Peter Huewe peterhu...@gmx.de Trivial patch which adds the __init/__exit macros to the module_init/ module_exit functions of the following drivers in media video: drivers/media/video/ivtv/ivtv-driver.c drivers/media/video/cx18/cx18-driver.c drivers/media/video/davinci/dm355_ccdc.c drivers/media/video/davinci/dm644x_ccdc.c drivers/media/video/saa7164/saa7164-core.c drivers/media/video/saa7134/saa7134-core.c drivers/media/video/cx23885/cx23885-core.c For drivers/media/video/davinci/dm355_ccdc.c and drivers/media/video/davinci/dm644x_ccdc.c, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Please have a look at the small patch and either pull it through your tree, or please ack' it so Jiri can pull it through the trivial tree. linux version v2.6.32-rc1 - linus git tree, Di 29. Sep 01:10:18 CEST 2009 Signed-off-by: Peter Huewe peterhu...@gmx.de -- Laurent Pinchart -- 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
Re: record DVB-S2 stream into file
Kaffeine 0.8.8 supports DVB-S2 and you can record a whole TS by setting a channel with videoPid=0 and audioPid=8192. Hope this helps. Thanks, but I need command line tool. Is it possible use kaffeine without XORG? I thing no. But many thanks, it is solution but i forget wrote that I need command line tool. in first console you can run szap-s2 which support s2 api in second console you can run dvbstream dvbstream -o 8192 dump.ts I hope it will help Goga -- 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
Re: dvbstream and S2 API (was - record DVB-S2 stream into file)
Hello, is there any plans to implement in dvbstream the s2 api support ? Goga I would like to record DVB-S2 complete stream into file. For DVB-S I can use dvbstream tool. But on this time it not support DVB_S2. Do somebody have patch or another tip how to save stream into file. Jiri PS: I don't need only one program/service but complete stream with all PIDs. http://vger.kernel.org/vger-lists.html#linux-media -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Wed Sep 30 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13044:6b7617d4a0be gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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
Re: [PATCH] media/video: adding __init/__exit macros to various drivers
On 9/30/09 9:26 AM, Karicheri, Muralidharan wrote: drivers/media/video/saa7164/saa7164-core.c drivers/media/video/cx23885/cx23885-core.c Acked-By: Steven Toth st...@kernellabs.com -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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
Re: [2.6.31] ir-kbd-i2c oops.
On Wed, 2009-09-30 at 12:57 +0200, Jean Delvare wrote:
Hi Pawel,
I am removing the linux-i2c list from Cc, because it seems clear that
your problem is related to specific media drivers and not the i2c
subsystem.
On Wed, 30 Sep 2009 10:16:15 +0200, Paweł Sikora wrote:
On Tuesday 29 September 2009 16:16:29 Jean Delvare wrote:
On Wed, 16 Sep 2009 10:03:32 +0200, Paweł Sikora wrote:
On Wednesday 16 September 2009 08:57:01 Jean Delvare wrote:
Hi Pawel,
I think this would be fixed by the following patch:
http://patchwork.kernel.org/patch/45707/
still oopses. this time i've attached full dmesg.
Any news on this? Do you have a refined list of kernels which have the
bug and kernels which do not?
afaics in the 2.6.2{7,8}, the remote sends some noises to pc.
effect: random characters on terminal and unusable login prompt.
now in the 2.6.31, the kernel module oopses during udev loading.
so i've renamed the .ko to prevent loading.
i've attached asm dump of ir-common.ko
i found the '41 c7 80 cc ...' code in dump at adress 0x83e.
Not sure why you look at address 0x83e? The stack trace says +0x64. As
function ir_input_init() starts at 0x800, the oops address would be
0x864, which is:
864: f0 0f ab 31 lock bts %esi,(%rcx)
If my disassembler skills are still worth anything, this corresponds to
the set_bit instruction in:
for (i = 0; i IR_KEYTAB_SIZE; i++)
set_bit(ir-ir_codes[i], dev-keybit);
in the source code. This suggests that ir-ir_codes is smaller than
expected (sounds unlikely as this array is included in struct
ir_input_state) or dev-keybit isn't large enough (sounds unlikely as
well, it should be large enough to contain 0x300 bits while ir keycodes
are all below 0x100.) So most probably something went wrong before and
we're only noticing now.
Jean,
You should be aware that the type of ir_codes changed recently from
IR_KEYTAB_TYPE
to
struct ir_scancode_table *
I'm not sure if it is the problem here, but it may be prudent to check
that there's no mismatch between the module and the structure
definitions being pulled in via #include (maybe by stopping gcc after
the preprocessing with -E ).
Regards,
Andy
Are you running distribution kernels or self-compiled ones? Any local
patches applied?
Would you be able to apply debug patches and rebuild your kernel?
At this point, all I can offer is instrumenting ir_probe() and
ir_input_init() with log messages to see exactly what code paths are
taken and what parameters are passed around.
--
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
Re: [PATCH] V4L/DVB:uvcvideo:fix uvc_alloc_urb_buffers()
Hi,
On Sunday 27 September 2009 10:30:34 tom.leim...@gmail.com wrote:
From: Ming Lei tom.leim...@gmail.com
This patch sets stream-urb_size as psize*npackets
before calling uvc_alloc_urb_buffers, which may fix
a possible failure of usb_buffer_free in case usb_buffer_alloc
returns NULL. The patch is based on the ideas below:
1,If usb_buffer_alloc can't allocate a buffer sucessfully,
uvc_free_urb_buffers will be called to free the allocated
buffers, and stream-urb_size is required to be passed to
usb_buffer_free;
2,uvc_free_urb_buffers can reset stream-urb_size.
This patch is against linux-v2.6.31-next-20090926.
Good catch, thanks.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
I've applied the patch to my tree and I'll send a pull request.
---
drivers/media/video/uvc/uvc_video.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c index f960e8e..31dba66 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -768,9 +768,10 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
*stream,
/* Retry allocations until one succeed. */
for (; npackets 1; npackets /= 2) {
+ stream-urb_size = psize * npackets;
for (i = 0; i UVC_URBS; ++i) {
stream-urb_buffer[i] = usb_buffer_alloc(
- stream-dev-udev, psize * npackets,
+ stream-dev-udev, stream-urb_size,
gfp_flags | __GFP_NOWARN, stream-urb_dma[i]);
if (!stream-urb_buffer[i]) {
uvc_free_urb_buffers(stream);
@@ -779,7 +780,6 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
*stream, }
if (i == UVC_URBS) {
- stream-urb_size = psize * npackets;
return npackets;
}
}
--
Regards,
Laurent Pinchart
--
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
Re: [PATCH 6/9] drivers/media/video/uvc: Use %pUr to print UUIDs
Hi Joe,
thanks for the patch. A few comments below.
On Tuesday 29 September 2009 07:01:08 Joe Perches wrote:
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/video/uvc/uvc_ctrl.c | 69
--
drivers/media/video/uvc/uvc_driver.c |7 +--
drivers/media/video/uvc/uvcvideo.h | 10 -
3 files changed, 35 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index c3225a5..2959e46 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1093,8 +1093,8 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
if (!found) {
uvc_trace(UVC_TRACE_CONTROL,
- Control UVC_GUID_FORMAT /%u not found.\n,
- UVC_GUID_ARGS(entity-extension.guidExtensionCode),
+ Control %pUr/%u not found.\n,
+ entity-extension.guidExtensionCode,
xctrl-selector);
Could you try to cut long statements in as few lines as possible ? This one
would become
uvc_trace(UVC_TRACE_CONTROL, Control %pUr/%u not found.\n,
entity-extension.guidExtensionCode, xctrl-selector);
There are a few others that should be changed as well. If you prefer I can
apply the patch through my tree (after the printk patch goes in of course)
and handle that myself.
[snip]
flags = info-flags;
if (((flags UVC_CONTROL_GET_CUR) !(inf (1 0))) ||
((flags UVC_CONTROL_SET_CUR) !(inf (1 1 {
- uvc_trace(UVC_TRACE_CONTROL, Control
- UVC_GUID_FORMAT /%u flags don't match
- supported operations.\n,
- UVC_GUID_ARGS(info-entity), info-selector);
+ uvc_trace(UVC_TRACE_CONTROL,
+ Control %pUr/%u flags don't match supported
operations.\n,
+ info-entity, info-selector);
This doesn't fit the 80 columns limit. Please run checkpatch.pl on your patches.
[snip]
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c index 8756be5..647d0a2 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -328,11 +328,10 @@ static int uvc_parse_format(struct uvc_device *dev,
sizeof format-name);
format-fcc = fmtdesc-fcc;
} else {
- uvc_printk(KERN_INFO, Unknown video format
- UVC_GUID_FORMAT \n,
- UVC_GUID_ARGS(buffer[5]));
+ uvc_printk(KERN_INFO, Unknown video format %pUr\n,
+buffer[5]);
snprintf(format-name, sizeof format-name,
- UVC_GUID_FORMAT, UVC_GUID_ARGS(buffer[5]));
+ %pUr, Buffer[5]);
Should be buffer[5], not Buffer[5]. You haven't compiled the patch, have
you ? :-)
--
Regards,
Laurent Pinchart
--
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
Re: [PATCH 6/9] drivers/media/video/uvc: Use %pUr to print UUIDs
On Thu, 2009-10-01 at 02:20 +0200, Laurent Pinchart wrote:
flags = info-flags;
if (((flags UVC_CONTROL_GET_CUR) !(inf (1 0))) ||
((flags UVC_CONTROL_SET_CUR) !(inf (1 1 {
- uvc_trace(UVC_TRACE_CONTROL, Control
- UVC_GUID_FORMAT /%u flags don't match
- supported operations.\n,
- UVC_GUID_ARGS(info-entity), info-selector);
+ uvc_trace(UVC_TRACE_CONTROL,
+ Control %pUr/%u flags don't match supported
operations.\n,
+ info-entity, info-selector);
This doesn't fit the 80 columns limit. Please run checkpatch.pl on your
patches.
Intentional. Strings shouldn't be broken across lines unnecessarily.
snprintf(format-name, sizeof format-name,
- UVC_GUID_FORMAT, UVC_GUID_ARGS(buffer[5]));
+%pUr, Buffer[5]);
Should be buffer[5], not Buffer[5]. You haven't compiled the patch, have
you ? :-)
Unintentional. Did compile allyesconfig.
cheers, Joe
--
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
[PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes3
Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes3 for the following: xc5000: add FM radio support xc5000: make the definition of the FM input part of the xc5000 config struct em28xx: Add support for new variant of KWorld 2800d em28xx: fix support for Terratec Cinergy T XS (005e) dib0700: fixed xc2028 firmware loading kernel oops saa7134: add support for the digital side of the Behold X7 saa7134: use the #define for the xc5000 radio_input field em28xx: remove not validated status from Terratec Cinergy T XS (005e) Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
[PATCH 1/2] dvb-usb-friio: return the correct DTV_DELIVERY_SYSTEM
From: Akihiro Tsukada ts...@yahoo.co.jp
This patch makes the driver return the correct DTV_DELIVERY_SYSTEM.
The driver previously returned SYS_UNDEFINED for DTV_DELIVERY_SYSTEM property,
as it lacked any driver specific S2API support.
Priority: normal
Signed-off-by: Akihiro Tsukada ts...@yahoo.co.jp
---
friio-fe.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/linux/drivers/media/dvb/dvb-usb/friio-fe.c
b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
--- a/linux/drivers/media/dvb/dvb-usb/friio-fe.c
+++ b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
@@ -286,6 +286,27 @@ static int jdvbt90502_get_tune_settings(
return 0;
}
+/* filter out un-supported properties to notify users */
+static int jdvbt90502_set_property(struct dvb_frontend *fe,
+ struct dtv_property *tvp)
+{
+ int r = 0;
+
+ switch (tvp-cmd) {
+ case DTV_DELIVERY_SYSTEM:
+ if (tvp-u.data != SYS_ISDBT)
+ r = -EINVAL;
+ break;
+ case DTV_CLEAR:
+ case DTV_TUNE:
+ case DTV_FREQUENCY:
+ break;
+ default:
+ r = -EINVAL;
+ }
+ return r;
+}
+
static int jdvbt90502_get_frontend(struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
@@ -314,6 +335,9 @@ static int jdvbt90502_set_frontend(struc
deb_fe(%s: Freq:%d\n, __func__, p-frequency);
+ /* for recovery from DTV_CLEAN */
+ fe-dtv_property_cache.delivery_system = SYS_ISDBT;
+
ret = jdvbt90502_pll_set_freq(state, p-frequency);
if (ret) {
deb_fe(%s:ret == %d\n, __func__, ret);
@@ -394,6 +418,7 @@ static int jdvbt90502_init(struct dvb_fr
if (ret != 1)
goto error;
}
+ fe-dtv_property_cache.delivery_system = SYS_ISDBT;
msleep(100);
return 0;
@@ -471,6 +496,8 @@ static struct dvb_frontend_ops jdvbt9050
.sleep = jdvbt90502_sleep,
.write = _jdvbt90502_write,
+ .set_property = jdvbt90502_set_property,
+
.set_frontend = jdvbt90502_set_frontend,
.get_frontend = jdvbt90502_get_frontend,
.get_tune_settings = jdvbt90502_get_tune_settings,
--
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/
--
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
[PATCH 2/2] dvb-usb-friio: cleaning up unnecessary functions
From: Akihiro Tsukada ts...@yahoo.co.jp
This patch removes some fe-ops.X() functions which do nothing more useful than
the default.
Priority: normal
Signed-off-by: Akihiro Tsukada ts...@yahoo.co.jp
---
friio-fe.c | 38 --
1 file changed, 38 deletions(-)
diff --git a/linux/drivers/media/dvb/dvb-usb/friio-fe.c
b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
--- a/linux/drivers/media/dvb/dvb-usb/friio-fe.c
+++ b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
@@ -232,12 +232,6 @@ static int jdvbt90502_read_status(struct
return 0;
}
-static int jdvbt90502_read_ber(struct dvb_frontend *fe, u32 *ber)
-{
- *ber = 0;
- return 0;
-}
-
static int jdvbt90502_read_signal_strength(struct dvb_frontend *fe,
u16 *strength)
{
@@ -264,27 +258,6 @@ static int jdvbt90502_read_signal_streng
return 0;
}
-static int jdvbt90502_read_snr(struct dvb_frontend *fe, u16 *snr)
-{
- *snr = 0x0101;
- return 0;
-}
-
-static int jdvbt90502_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
-{
- *ucblocks = 0;
- return 0;
-}
-
-static int jdvbt90502_get_tune_settings(struct dvb_frontend *fe,
- struct dvb_frontend_tune_settings *fs)
-{
- fs-min_delay_ms = 500;
- fs-step_size = 0;
- fs-max_drift = 0;
-
- return 0;
-}
/* filter out un-supported properties to notify users */
static int jdvbt90502_set_property(struct dvb_frontend *fe,
@@ -347,12 +320,6 @@ static int jdvbt90502_set_frontend(struc
return 0;
}
-static int jdvbt90502_sleep(struct dvb_frontend *fe)
-{
- deb_fe(%s called.\n, __func__);
- return 0;
-}
-
/**
* (reg, val) commad list to initialize this module.
@@ -493,18 +460,13 @@ static struct dvb_frontend_ops jdvbt9050
.release = jdvbt90502_release,
.init = jdvbt90502_init,
- .sleep = jdvbt90502_sleep,
.write = _jdvbt90502_write,
.set_property = jdvbt90502_set_property,
.set_frontend = jdvbt90502_set_frontend,
.get_frontend = jdvbt90502_get_frontend,
- .get_tune_settings = jdvbt90502_get_tune_settings,
.read_status = jdvbt90502_read_status,
- .read_ber = jdvbt90502_read_ber,
.read_signal_strength = jdvbt90502_read_signal_strength,
- .read_snr = jdvbt90502_read_snr,
- .read_ucblocks = jdvbt90502_read_ucblocks,
};
--
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/
--
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
