mem2mem_testdev: BUG: unable to handle kernel NULL pointer dereference
Hi,
I tried the mem2mem_testdev driver from Linux kernel 2.6.35-rc3 together
with the test environment from http://v4l-test.sourceforge.net . I found
that the VIDIOC_G_FMT ioctl may result in a NULL pointer dereference in
kernel. I derived a simple test case which I also attached.
Steps to reproduce:
$ su
# modprobe mem2mem-testdev
# exit
$ gcc -Wall -Wextra -O2 test_mem2mem.c -o test_mem2mem
$ ./test_mem2mem
I investigated the problem a little bit and found that the expression
q_data->fmt->fourcc in function vidioc_g_fmt() may cause this behaviour.
Regards,
Márton Németh
/*
* Simple test case for VIDIOC_G_FMT. Derived from
* v4l-test, http://v4l-test.sourceforge.net
*
* Writen by Márton Németh
* 20 Jun 2010
* Released under GPL.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
int f;
int ret;
int ret_get, errno_get;
struct v4l2_format format;
f = open("/dev/video0", O_RDWR);
if (f < 0) {
perror("Cannot open /dev/video0");
return 1;
}
memset(&format, 0xff, sizeof(format));
format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
printf("Calling VIDIOC_G_FMT ioctl...\n");
fflush(stdout);
ret_get = ioctl(f, VIDIOC_G_FMT, &format);
errno_get = errno;
printf("VIDIOC_G_FMT: ret=%i, errno=%i\n", ret_get, errno_get);
ret = close(f);
f = 0;
if (ret < 0) {
perror("Cannot close");
return 1;
}
return 0;
}
[0.00] Linux version 2.6.35-rc3 (nma...@europa) (gcc version 4.4.4
(Debian 4.4.4-5) ) #2 PREEMPT Sat Jun 19 14:34:39 CEST 2010
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 0009f800 (usable)
[0.00] BIOS-e820: 0009f800 - 000a (reserved)
[0.00] BIOS-e820: 000d8000 - 0010 (reserved)
[0.00] BIOS-e820: 0010 - 3bf7 (usable)
[0.00] BIOS-e820: 3bf7 - 3bf7a000 (ACPI data)
[0.00] BIOS-e820: 3bf7a000 - 3bf8 (ACPI NVS)
[0.00] BIOS-e820: 3bf8 - 4000 (reserved)
[0.00] BIOS-e820: fffe - 0001 (reserved)
[0.00] Notice: NX (Execute Disable) protection cannot be enabled:
non-PAE kernel!
[0.00] DMI present.
[0.00] e820 update range: - 1000 (usable)
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] last_pfn = 0x3bf70 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00] 0-9 write-back
[0.00] A-B uncachable
[0.00] C-D3FFF write-protect
[0.00] D4000-D7FFF uncachable
[0.00] D8000-DBFFF write-protect
[0.00] DC000-D write-back
[0.00] E-E3FFF uncachable
[0.00] E4000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00] 0 base 00 mask FFC000 write-back
[0.00] 1 base 003C00 mask FFFC00 uncachable
[0.00] 2 base 00E000 mask FFF000 write-combining
[0.00] 3 disabled
[0.00] 4 disabled
[0.00] 5 disabled
[0.00] 6 disabled
[0.00] 7 disabled
[0.00] initial memory mapped : 0 - 0100
[0.00] found SMP MP-table at [c00f6870] f6870
[0.00] init_memory_mapping: -377fe000
[0.00] 00 - 40 page 4k
[0.00] 40 - 003740 page 2M
[0.00] 003740 - 00377fe000 page 4k
[0.00] kernel direct mapping tables up to 377fe000 @ 7000-c000
[0.00] ACPI: RSDP 000f68d0 00014 (v00 PTLTD )
[0.00] ACPI: RSDT 3bf7600b 00030 (v01 PTLTDRSDT 0604 LTP
)
[0.00] ACPI: FACP 3bf79e87 00074 (v01 AMDK8 PTLTW0604 PTL_
000F4240)
[0.00] ACPI: DSDT 3bf7603b 03E4C (v01 VIA PTL_ACPI 0604 MSFT
010E)
[0.00] ACPI: FACS 3bf7afc0 00040
[0.00] ACPI: SSDT 3bf79efb 000B5 (v01 PTLTD POWERNOW 0604 LTP
0001)
[0.00] ACPI: APIC 3bf79fb0 00050 (v01 PTLTD ? APIC 0604 LTP
)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] 71MB HIGHMEM available.
[0.00] 887MB LOWMEM available.
[0.00] mapped low ram: 0 - 377fe000
[0.00] low ram: 0 - 377fe000
[0.00] Zone PFN ranges:
[0.00] DMA 0x0001 -> 0x1000
[0.00] Normal 0x1000 -> 0x000377fe
[0.00] HighMem 0x000377fe -> 0x0003bf70
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00] 0: 0x0001 -> 0x009f
[0.00] 0: 0x0100 -> 0x0003bf70
[0.00] On node 0 totalpages: 245518
[0.00] free_area_init_node: node 0, pgdat c04afb00, node_mem_map
c1001020
Re: Laptop failing to suspend when WinTV-HVR950 installed.
Am Dienstag, den 22.06.2010, 04:19 +0200 schrieb hermann pitton: > Hi David, > > Am Montag, den 21.06.2010, 20:19 -0500 schrieb David Hagood: > > I have a 100% repeatable failure for my laptop runing Lucid 64 bit to > > suspend when my WinTV-HVR950 is installed, and a 100% success rate on it > > suspending when the device is not installed. > > > > If I put the device in, remove the device, and suspend (e.g. by closing > > the lid) it will suspend. There are no processes opening the device (as > > confirmed by lsof | grep dvb). > > > > Additionally, most of the time the failure to suspend occurs, the > > machine becomes unresponsive, and I have to hard power off to get it > > back. > > > > Has anybody else seen this? > > just as a hint. > > You need some cloud of users, that somebody sticks in. > > I still have cases, where a single user claims on the wiki, all Asus > stuff is rubbish, but he still is exactly the only one failing after > years. To stop joking, well noticed from you. The dvb subsystem never had any way to suspend and recover reliable. Cheers, Hermann -- 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://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-em28xx-isoc/
Hello, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-em28xx-isoc for the following: * Make em28xx s_ctrl not always return error * Fix case where fields were not at the correct start location. This addresses two bugs found in the em28xx driver (one with video rendering and one with the s_ctrl ioctl always returning an error). Thanks to Eugeniy Meshcheryakov for bringing the field rendering issue to my attention. 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
[PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950qvbi
Hello, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950qvbi for the following: * Add closed captioning support for the HVR-950q Thanks go out to GetWellNetwork Inc. for sponsoring this work. 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
Re: About Viewcast Osprey 450e
On Mon, Jun 21, 2010 at 11:04:19PM -0400, Devin Heitmueller wrote: > On Mon, Jun 21, 2010 at 10:37 PM, wrote: > > Is there any chance this card will be supported by V4L in the future (or > > is it already) ? > > KernelLabs has written a driver for both the 240e and 450e (in > cooperation with ViewCast) and it is currently in testing (with plans > to be merged upstream). Keep an eye on the KernelLabs blog for more > info. > > http://www.kernellabs.com/blog/ Thanks so much for this ! bye Jerome Alet -- 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: About Viewcast Osprey 450e
On Mon, Jun 21, 2010 at 10:37 PM, wrote: > Is there any chance this card will be supported by V4L in the future (or > is it already) ? KernelLabs has written a driver for both the 240e and 450e (in cooperation with ViewCast) and it is currently in testing (with plans to be merged upstream). Keep an eye on the KernelLabs blog for more info. http://www.kernellabs.com/blog/ Cheers, 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
About Viewcast Osprey 450e
Hi there, Over the years I've used successfully several products from Viewcast to do video capture, most notably Osprey 100, 210, 230 and 440, as part of the Boxtream Free Software project (http://boxtream.unice.fr) The 440 is a 4-inputs video capture card based on BT878, and it works flawlessly for my needs. Now when building an instance of Boxtream based on a motherboard with PCI express bus, I've simply thought that the Osprey 450e was identical to the 440 but with a PCI express slot, and purchased one without asking first... Unfortunately I was wrong, this card is based on a different chip than the 440, and it doesn't seem to be supported. Here's the output of lspci -vv : 07:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 Subsystem: Viewcast COM Device 0032 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 08:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 Subsystem: Viewcast COM Device 0032 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- The commercial specs are available from : http://www.viewcast.com/products/osprey-cards/osprey-450e Is there any chance this card will be supported by V4L in the future (or is it already) ? I'm not a kernel developper, but I'm more than willing to help and/or test if I can be useful. Thanks in advance for any help Jerome Alet -- 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: Laptop failing to suspend when WinTV-HVR950 installed.
Hi David, Am Montag, den 21.06.2010, 20:19 -0500 schrieb David Hagood: > I have a 100% repeatable failure for my laptop runing Lucid 64 bit to > suspend when my WinTV-HVR950 is installed, and a 100% success rate on it > suspending when the device is not installed. > > If I put the device in, remove the device, and suspend (e.g. by closing > the lid) it will suspend. There are no processes opening the device (as > confirmed by lsof | grep dvb). > > Additionally, most of the time the failure to suspend occurs, the > machine becomes unresponsive, and I have to hard power off to get it > back. > > Has anybody else seen this? just as a hint. You need some cloud of users, that somebody sticks in. I still have cases, where a single user claims on the wiki, all Asus stuff is rubbish, but he still is exactly the only one failing after years. I don't deny, that it might fail for him. Cheers, Hermann -- 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: [PULL] http://kernellabs.com/hg/~mkrufky/lgdt3304-5
Em 19-06-2010 12:58, Michael Krufky escreveu: > Mauro, > > These are the changes from Jarod Wilson to add support for the > lgdt3304 to the lgdt3305 module, and add support for kworld 340u and > ub435-q to em28xx-dvb. > > I apologize to Jarod for the delay in sending this merge request. > > Please pull from: > > http://kernellabs.com/hg/~mkrufky/lgdt3304-5 > > for the following: > > - dvb: add lgdt3304 support to lgdt3305 driver >From the patch comments: There's a currently-unused lgdt3304 demod driver, which leaves a lot to be desired as far as functionality. The 3304 is unsurprisingly quite similar to the 3305, and empirical testing yeilds far better results and more complete functionality by merging 3304 support into the 3305 driver. (For example, the current lgdt3304 driver lacks support for signal strength, snr, ucblocks, etc., which we get w/the lgdt3305). For the moment, not dropping the lgdt3304 driver, and its still up to a given device's config setup to choose which demod driver to use, but I'd suggest dropping the 3304 driver entirely. If lgdt3305 driver got superseded, just send me a patch dropping it. Jarod/Michael, Please send me a patch removing the legacy driver. Anyway, I'm applying it. > - lgdt3305: remove pointless function, lgdt3304_sleep > - lgdt3305: fix (disabled) lgdt3304 FE_HAS_SIGNAL hack for the DT3304, only > - lgdt3305: update lgdt3305.h header to match the header in lgdt3305.c > - lgdt3305: re-write lgdt3304 ifbw hack in lgdt3305_rfagc_loop with FIXME > - lgdt3305: consolidate init functions > - lgdt3305: FIXME: verify & document the LGDT3304 registers > - lgdt3305: Jarod Wilson gets the credit for LGDT3304 support > - lgdt3305: update copyright date and MODULE_VERSION > - lgdt3305: enable FE_HAS_SIGNAL hack for the lgdt3304 in QAM mode > - merge: ~mkrufky/lgdt3304 > - dvb: add support for kworld 340u and ub435-q to em28xx-dvb > > Documentation/video4linux/CARDLIST.em28xx |1 > drivers/media/dvb/frontends/lgdt3305.c| 684 +++--- > drivers/media/dvb/frontends/lgdt3305.h| 20 > drivers/media/video/em28xx/em28xx-cards.c | 28 > drivers/media/video/em28xx/em28xx-dvb.c | 33 > drivers/media/video/em28xx/em28xx.h |1 > 6 files changed, 578 insertions(+), 189 deletions(-) > > Thanks, > > Mike -- 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: [GIT PATCHES FOR 2.6.36] gspca for_2.6.36
Em 05-06-2010 08:33, Jean-Francois Moine escreveu: > Hi Mauro, > > The following changes apply to the 'master' branch. > > The following changes since commit ad8456361fa19068cf49b50a4f98e41b73c08e76: > > Merge branch 'upstream-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev (2010-06-03 > 15:48:15 -0700) > > are available in the git repository at: > > git://linuxtv.org/jfrancois/gspca.git for_2.6.36 > > Jean-François Moine (15): > gspca - JPEG subdrivers: Don't allocate the JPEG header. > gspca - stk014: Change the min and default values of the JPEG quality. > gspca - zc3xx: Change the max and default JPEG qualities. > gspca - zc3xx: Don't change the registers 7 and 8 for sensor pas202b. > gspca - zc3xx: Add back the brightness control. > gspca: Remove/move useless inclusions of slab.h. This patch doesn't seem right. The addition of slab.h were done in order to allow the removal of the header from some core files. I'm not sure if all the upstream changes got applied to 2.6.35, but it seems prudent to wait for a while before just removing the headers, especially since the slab.h dependency may be different on non-Intel architectures. I'm applying the remaining patches. If you think that this patch is correct, please re-send it to both LMML and LKML, c/c the authors of the slab.h removal, in order to get their acks, or, otherwise, please re-submit it for 2.6.37 window. > gspca - t613: Cleanup and clarify the source. > gspca - t613: Change the gamma table. > gspca - t613: Remove the RGB gains setting from sensor_polling. > gspca - t613: Simplify the scan of isoc packets. > gspca - t613: Adjust light frequency values per sensor. > gspca - t613: Change the gain mechanism. > gspca - sq930x: New subdriver. > gspca - main: Function gspca_dev_probe2 added. > gspca - spca1528: New subdriver. > > Documentation/video4linux/gspca.txt|7 + > drivers/media/video/gspca/Kconfig | 18 + > drivers/media/video/gspca/Makefile |4 + > drivers/media/video/gspca/conex.c |8 +- > drivers/media/video/gspca/gspca.c | 46 +- > drivers/media/video/gspca/gspca.h |6 +- > drivers/media/video/gspca/jeilinj.c|6 +- > drivers/media/video/gspca/m5602/m5602_bridge.h |1 + > drivers/media/video/gspca/m5602/m5602_s5k83a.c |1 - > drivers/media/video/gspca/mars.c | 13 +- > drivers/media/video/gspca/ov519.c |7 +- > drivers/media/video/gspca/sn9c20x.c| 18 +- > drivers/media/video/gspca/sonixj.c |1 - > drivers/media/video/gspca/spca1528.c | 607 + > drivers/media/video/gspca/spca500.c| 13 +- > drivers/media/video/gspca/sq930x.c | 1140 > > drivers/media/video/gspca/stk014.c | 17 +- > drivers/media/video/gspca/stv06xx/stv06xx.h|1 + > drivers/media/video/gspca/sunplus.c| 13 +- > drivers/media/video/gspca/t613.c | 405 + > drivers/media/video/gspca/w996Xcf.c| 16 +- > drivers/media/video/gspca/zc3xx.c | 90 ++- > 22 files changed, 2109 insertions(+), 329 deletions(-) > create mode 100644 drivers/media/video/gspca/spca1528.c > create mode 100644 drivers/media/video/gspca/sq930x.c > > Thanks. > -- 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
Laptop failing to suspend when WinTV-HVR950 installed.
I have a 100% repeatable failure for my laptop runing Lucid 64 bit to suspend when my WinTV-HVR950 is installed, and a 100% success rate on it suspending when the device is not installed. If I put the device in, remove the device, and suspend (e.g. by closing the lid) it will suspend. There are no processes opening the device (as confirmed by lsof | grep dvb). Additionally, most of the time the failure to suspend occurs, the machine becomes unresponsive, and I have to hard power off to get it back. Has anybody else seen this? -- 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: [GIT PATCHES FOR 2.6.35] forget gspca for_2.6.35
Em 11-06-2010 07:32, Jean-Francois Moine escreveu: > Hi Mauro, > > Please forget about the previous pull request: it seems that people > better like to have a monotonic time instead of the real wall time in > the video buffer timestamp. Yes. We should patch the other drivers to also use ktime, and update the specs. Cheers, Mauro. > > Thanks. > -- 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:Mon Jun 21 19:00:08 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
[PULL] http://kernellabs.com/hg/~mkrufky/af9005
Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/af9005 for: - af9005: use generic_bulk_ctrl_endpoint_response af9005.c | 55 +++ 1 file changed, 7 insertions(+), 48 deletions(-) Regards, Mike Krufky -- 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] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable
21.06.2010 19:51, Bjørn Mork wrote: VDR User writes: Instead of copy&paste patches from Manu's tree, maybe it's better to just wait for him to push all the changes into v4l. I'm Manu sorry about trying to put patches directly into v4-dvb, if those should go onto your branch first. So, what Manu do you think about my DMA patch or other patches I sent into linux-media mailing list this weekend? Is it okay to generate one interrupt once per 16k bytes, or are the interrupts too rare? At least VDR reads the DVB stream rarely, so I think that it is enough if the DVB card has always something to be delivered when VDR or MythTV asks more data, so if the number of DMA transfer IRQs is twice than the number of times VDR or MythTV asks more data per second, then the context switches are in balance. Understandable DMA RISC programming should be easier to maintain, and it removes the initial garbage from the stream too. How about the tasklet enable/disable patch I wrote? What needs to be done for these patches to be accepted? Best regards, Marko -- 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] af9005: use generic_bulk_ctrl_endpoint_response
On Mon, Jun 21, 2010 at 2:22 PM, Luca Olivetti wrote: > Al 21/06/10 17:45, En/na Michael Krufky ha escrit: >> >> On Mon, Jun 21, 2010 at 2:59 AM, Luca Olivetti wrote: >>> >>> En/na Michael Krufky ha escrit: Could somebody please test this patch and confirm that it doesn't break the af9005 support? This patch removes the af9005_usb_generic_rw function and uses the dvb_usb_generic_rw function instead, using generic_bulk_ctrl_endpoint_response to differentiate between the read pipe and the write pipe. >>> >>> Unfortunately I cannot test it (my device is broken)[*]. >>> At the time I wrote my own rw function because I didn't find a way to >>> send >>> on a bulk endpoint and receiving on another one (i.e. I didn't know about >>> generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or they >>> weren't available at the time). >>> >>> [*]Actually the tuner is broken, but the usb is working fine, so maybe I >>> can >>> give it a try. >> >> >> Luca, >> >> That's OK -- I only added this "generic_bulk_ctrl_endpoint_response" >> feature 4 months ago -- your driver predates that. I am pushing this >> patch to reduce the size of the kernel while using your driver to >> demonstrate how to use the new feature. I am already using it in an >> out of tree driver that I plan to merge within the next few months or >> so, but its always nice to optimize code that already exists with >> small cleanups like this. >> >> You don't need the tuner in order to prove the patch -- if you can >> simply confirm that you are able to both read and write successfully, >> that would be enough to prove the patch. After testing, please >> provide an ack in this thread so that I may include that with my pull >> request. > > I cloned your hg tree and had to modify a couple of #if otherwise it > wouldn't compile (it choked on dvb_class->nodename and dvb_class->devnode), > after that it built fine and apparently the usb communication still works: > > usb 8-2: new full speed USB device using uhci_hcd and address 2 > usb 8-2: New USB device found, idVendor=15a4, idProduct=9020 > usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 8-2: Product: DVBT > usb 8-2: Manufacturer: Afatech > usb 8-2: configuration #1 chosen from 1 choice > dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in cold state, will try to > load a firmware > usb 8-2: firmware: requesting af9005.fw > dvb-usb: downloading firmware from file 'af9005.fw' > dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in warm state. > dvb-usb: will use the device's hardware PID filter (table count: 32). > DVB: registering new adapter (Afatech DVB-T USB1.1 stick) > DVB: registering adapter 0 frontend 0 (AF9005 USB DVB-T)... > input: IR-receiver inside an USB DVB receiver as > /devices/pci:00/:00:1d.2/usb8/8-2/input/input12 > dvb-usb: schedule remote query interval to 200 msecs. > dvb-usb: Afatech DVB-T USB1.1 stick successfully initialized and connected. > MT2060: successfully identified (IF1 = 1224) > > Acked-by: Luca Olivetti > > Bye > -- > Luca Thank you, Luca -- I'll add your ack now and send off a pull request. Cheers,. Mike Krufky -- 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] soc_camera_platform: add set_fmt callback
On Mon, 21 Jun 2010, Baruch Siach wrote:
> This allows the platform camera to arrange a change in the capture format.
Sorry, no. I don't like this. This driver is a very primitive piece of
code, allowing you to bootstrap a camera in a most simple static way. We
even were considering removing it from the kernel, because there's only
one user currently in the mainline and, unfortunately, it is not very well
maintained. So, you can use this driver as it is in the kernel now,
bug-fixes are welcome. But if it isn't enough for you, this means you need
a proper driver.
Thanks
Guennadi
>
> Signed-off-by: Baruch Siach
> ---
> drivers/media/video/soc_camera_platform.c |3 +++
> include/media/soc_camera_platform.h |2 ++
> 2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/soc_camera_platform.c
> b/drivers/media/video/soc_camera_platform.c
> index 248c986..208fd42 100644
> --- a/drivers/media/video/soc_camera_platform.c
> +++ b/drivers/media/video/soc_camera_platform.c
> @@ -61,6 +61,9 @@ static int soc_camera_platform_try_fmt(struct v4l2_subdev
> *sd,
> {
> struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
>
> + if (p->try_fmt)
> + return p->try_fmt(p, mf);
> +
> mf->width = p->format.width;
> mf->height = p->format.height;
> mf->code= p->format.code;
> diff --git a/include/media/soc_camera_platform.h
> b/include/media/soc_camera_platform.h
> index 0ecefe2..0558ffc 100644
> --- a/include/media/soc_camera_platform.h
> +++ b/include/media/soc_camera_platform.h
> @@ -22,6 +22,8 @@ struct soc_camera_platform_info {
> struct v4l2_mbus_framefmt format;
> unsigned long bus_param;
> struct device *dev;
> + int (*try_fmt)(struct soc_camera_platform_info *info,
> + struct v4l2_mbus_framefmt *mf);
> int (*set_capture)(struct soc_camera_platform_info *info, int enable);
> };
>
> --
> 1.7.1
>
> --
> 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
>
---
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: [PATCH] af9005: use generic_bulk_ctrl_endpoint_response
Al 21/06/10 17:45, En/na Michael Krufky ha escrit: On Mon, Jun 21, 2010 at 2:59 AM, Luca Olivetti wrote: En/na Michael Krufky ha escrit: Could somebody please test this patch and confirm that it doesn't break the af9005 support? This patch removes the af9005_usb_generic_rw function and uses the dvb_usb_generic_rw function instead, using generic_bulk_ctrl_endpoint_response to differentiate between the read pipe and the write pipe. Unfortunately I cannot test it (my device is broken)[*]. At the time I wrote my own rw function because I didn't find a way to send on a bulk endpoint and receiving on another one (i.e. I didn't know about generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or they weren't available at the time). [*]Actually the tuner is broken, but the usb is working fine, so maybe I can give it a try. Luca, That's OK -- I only added this "generic_bulk_ctrl_endpoint_response" feature 4 months ago -- your driver predates that. I am pushing this patch to reduce the size of the kernel while using your driver to demonstrate how to use the new feature. I am already using it in an out of tree driver that I plan to merge within the next few months or so, but its always nice to optimize code that already exists with small cleanups like this. You don't need the tuner in order to prove the patch -- if you can simply confirm that you are able to both read and write successfully, that would be enough to prove the patch. After testing, please provide an ack in this thread so that I may include that with my pull request. I cloned your hg tree and had to modify a couple of #if otherwise it wouldn't compile (it choked on dvb_class->nodename and dvb_class->devnode), after that it built fine and apparently the usb communication still works: usb 8-2: new full speed USB device using uhci_hcd and address 2 usb 8-2: New USB device found, idVendor=15a4, idProduct=9020 usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 8-2: Product: DVBT usb 8-2: Manufacturer: Afatech usb 8-2: configuration #1 chosen from 1 choice dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in cold state, will try to load a firmware usb 8-2: firmware: requesting af9005.fw dvb-usb: downloading firmware from file 'af9005.fw' dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 32). DVB: registering new adapter (Afatech DVB-T USB1.1 stick) DVB: registering adapter 0 frontend 0 (AF9005 USB DVB-T)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.2/usb8/8-2/input/input12 dvb-usb: schedule remote query interval to 200 msecs. dvb-usb: Afatech DVB-T USB1.1 stick successfully initialized and connected. MT2060: successfully identified (IF1 = 1224) Acked-by: Luca Olivetti Bye -- Luca -- 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] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable
VDR User writes: > Instead of copy&paste patches from Manu's tree, maybe it's better to > just wait for him to push all the changes into v4l. I certainly agree that having him push all the changes would be much better. And nothing would please me more than seeing this happen. But I do *not* agree that "just wait" is better. We have waited for 4 months. It did not work. Why do you think that waiting more will work better? > There have been > many bug fixes & improvements Manu has done that haven't been pushed > into v4l yet I guess there is. I only know of the two now 4 months old bug fixes in http://jusst.de/hg/mantis-v4l-dvb but there can of course be much more happening without me knowing. There could be other trees. But without pointers (we have a perfectly good MAINTAINERS for this), it's very hard to find such things. In fact, I do have some problems getting oriented in the V4L/DVB world. There seem to be a number of dead development trees scattered all around. But I guess that's to be expected, since there have been major reorganisations lately. To the better, IMHO. I'm looking forward to having Linus' kernel track the V4L/DVB development more closely, and not having to replace a whole subsystem every time I want to test a new driver. > and I think it's better to sync the entire driver instead > of cherry picking patches here & there. Yes. And I did hesitate to do this. But this one patch is really wanted to make the driver fully functional (users do expect PCI drivers to autoload nowadays). It could have been in 2.6.34. As it looks now, it won't make 2.6.35... Why wait? What's the point of collecting a large number (or small number for that sake) of patches in some development tree only very few developers even know exists? Push them upstream as soon as possible. The initial driver development is of course something else. I appreciate the need to develop something working before pushing it. But simple fixes like this one? Just push it. Bjørn -- 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 8/8 v2]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/21/2010 05:34 AM, Mauro Carvalho Chehab wrote: Em Mon, 14 Jun 2010 22:48:34 -0700 "Justin P. Mattock" escreveu: Resend due to a whitespace issue I created by mistake. The below patch fixes a warning message create by gcc 4.6.0 It seems OK for me, but you shouldn't be sending it to be applied at reiserfs-devel ML. Instead, it should be sent to linux-media ML, and applied via my tree. I should of used get_maintainer.pl to find the correct list to send this too(instead I just looked into the MAINTAINERS file). I'll resend. CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock Reviewed-By: Mauro Carvalho Chehab --- drivers/media/common/tuners/tuner-simple.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..84900fa 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,11 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe->tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv->tun; - /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD Justin P. Mattock -- 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 8/8 v2]tuners:tuner-simple Fix warning: variable 'tun' set but not used
Resend due to a whitespace issue I created by mistake. The below patch fixes a warning message create by gcc 4.6.0 CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock Reviewed-By: Mauro Carvalho Chehab --- drivers/media/common/tuners/tuner-simple.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..84900fa 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,11 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe->tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv->tun; - /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD -- 1.7.1.rc1.21.gf3bd6 -- 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] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable
2010/6/21 Bjørn Mork : > Thanks to Ozan ?a?layan for pointing it out > > From: Manu Abraham > > Signed-off-by: Manu Abraham > [bj...@mork.no: imported from > http://jusst.de/hg/mantis-v4l-dvb/raw-rev/3731f71ed6bf] > Signed-off-by: Bjørn Mork > Cc: sta...@kernel.org > --- > This patch is so obviously correct that I do not know how to write it > differently. > > It is copied from the mercurial repostory at > http://jusst.de/hg/mantis-v4l-dvb/ > where it has been resting for more than 4 months. I certainly hope everyone is > OK with me just forwarding it like this... My only agenda is a fully > functional > mantis driver in the kernel. Instead of copy&paste patches from Manu's tree, maybe it's better to just wait for him to push all the changes into v4l. There have been many bug fixes & improvements Manu has done that haven't been pushed into v4l yet and I think it's better to sync the entire driver instead of cherry picking patches here & there. -Derek -- 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: How to use aux input on ATI TV Wonder 600 USB?
On Mon, Jun 21, 2010 at 11:48 AM, Steve Freitas wrote: >> Yes, it's fully supported. But bear in mind it's an analog input, so >> you need to use a V4L application as opposed to something designed for >> DVB. Once you use an analog app (such as tvtime), just toggle over to >> input 1 for composite or input 2 for S-Video (input zero is the analog >> tuner input). > > That was just the help I needed. Thanks! Would it be appropriate for me > to add that input number information to the wiki page[1]? I'm not sure how much value it would provide. Pretty much all the applications show an input description next to the number (for example, with tvtime you actually see "Tuner", "Composite", and "S-Video" as the options). The driver shows you the mapping if you run v4l2-ctl --list-inputs. But feel free to update the Wiki if you think it helps. Cheers, 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
Re: How to use aux input on ATI TV Wonder 600 USB?
On Mon, 2010-06-21 at 11:22 -0400, Devin Heitmueller wrote: > On Mon, Jun 21, 2010 at 11:09 AM, Steve Freitas wrote: > > Hi all, > > > > I have an ATI TV Wonder 600 USB and have successfully used it for its > > DVB features, thanks to the work of many of you on this list. However, > > this device also has an auxiliary s-video/composite input[1] which I'd > > like to use in VLC, and I can't figure out how. Is there any capability > > in the driver to switch to that? > > Yes, it's fully supported. But bear in mind it's an analog input, so > you need to use a V4L application as opposed to something designed for > DVB. Once you use an analog app (such as tvtime), just toggle over to > input 1 for composite or input 2 for S-Video (input zero is the analog > tuner input). That was just the help I needed. Thanks! Would it be appropriate for me to add that input number information to the wiki page[1]? Steve [1] http://www.linuxtv.org/wiki/index.php/ATI/AMD_TV_Wonder_HD_600_USB -- 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] af9005: use generic_bulk_ctrl_endpoint_response
On Mon, Jun 21, 2010 at 2:59 AM, Luca Olivetti wrote: > En/na Michael Krufky ha escrit: >> >> Could somebody please test this patch and confirm that it doesn't >> break the af9005 support? >> >> This patch removes the af9005_usb_generic_rw function and uses the >> dvb_usb_generic_rw function instead, using >> generic_bulk_ctrl_endpoint_response to differentiate between the read >> pipe and the write pipe. > > Unfortunately I cannot test it (my device is broken)[*]. > At the time I wrote my own rw function because I didn't find a way to send > on a bulk endpoint and receiving on another one (i.e. I didn't know about > generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or they > weren't available at the time). > > [*]Actually the tuner is broken, but the usb is working fine, so maybe I can > give it a try. Luca, That's OK -- I only added this "generic_bulk_ctrl_endpoint_response" feature 4 months ago -- your driver predates that. I am pushing this patch to reduce the size of the kernel while using your driver to demonstrate how to use the new feature. I am already using it in an out of tree driver that I plan to merge within the next few months or so, but its always nice to optimize code that already exists with small cleanups like this. You don't need the tuner in order to prove the patch -- if you can simply confirm that you are able to both read and write successfully, that would be enough to prove the patch. After testing, please provide an ack in this thread so that I may include that with my pull request. Thanks & regards, Mike Krufky -- 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: How to use aux input on ATI TV Wonder 600 USB?
On Mon, Jun 21, 2010 at 11:09 AM, Steve Freitas wrote: > Hi all, > > I have an ATI TV Wonder 600 USB and have successfully used it for its > DVB features, thanks to the work of many of you on this list. However, > this device also has an auxiliary s-video/composite input[1] which I'd > like to use in VLC, and I can't figure out how. Is there any capability > in the driver to switch to that? > > I'm using kernel 2.6.32 on Debian, with firmware xc3028L-v36.fw. The > device's USB id is 0438:b002. > > I'm happy to provide any other logs or info requested and appreciate any > help I can get. Yes, it's fully supported. But bear in mind it's an analog input, so you need to use a V4L application as opposed to something designed for DVB. Once you use an analog app (such as tvtime), just toggle over to input 1 for composite or input 2 for S-Video (input zero is the analog tuner input). Cheers, 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
How to use aux input on ATI TV Wonder 600 USB?
Hi all, I have an ATI TV Wonder 600 USB and have successfully used it for its DVB features, thanks to the work of many of you on this list. However, this device also has an auxiliary s-video/composite input[1] which I'd like to use in VLC, and I can't figure out how. Is there any capability in the driver to switch to that? I'm using kernel 2.6.32 on Debian, with firmware xc3028L-v36.fw. The device's USB id is 0438:b002. I'm happy to provide any other logs or info requested and appreciate any help I can get. Thanks! Steve [1] http://www.linuxtv.org/wiki/index.php/ATI/AMD_TV_Wonder_HD_600_USB -- 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
page allocation failures with Hauppauge 950Q
[ resend due to subscription complications. apologies if this winds up becoming a duplicate. ] Hi there. I have a Hauppauge HVR 950Q. I am mostly successful with it, but lately I have been seeing a lot of these: usb 1-4: new high speed USB device using ehci_hcd and address 9 usb 1-4: configuration #1 chosen from 1 choice au0828 driver loaded au0828: i2c bus registered tveeprom 5-0050: Hauppauge model 72001, rev B3F0, serial# 6922999 tveeprom 5-0050: MAC address is 00-0D-FE-69-A2-F7 tveeprom 5-0050: tuner model is Xceive XC5000 (idx 150, type 76) tveeprom 5-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) tveeprom 5-0050: audio processor is AU8522 (idx 44) tveeprom 5-0050: decoder processor is AU8522 (idx 42) tveeprom 5-0050: has no radio, has IR receiver, has no IR transmitter hauppauge_eeprom: hauppauge eeprom: model=72001 au8522 5-0047: creating new instance au8522_decoder creating new instance... tuner 5-0061: chip found @ 0xc2 (au0828) xc5000 5-0061: creating new instance xc5000: Successfully identified at address 0x61 xc5000: Firmware has not been loaded previously au8522 5-0047: attaching existing instance xc5000 5-0061: attaching existing instance xc5000: Successfully identified at address 0x61 xc5000: Firmware has not been loaded previously DVB: registering new adapter (au0828) DVB: registering adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)... Registered device AU0828 [Hauppauge HVR950Q] usbcore: registered new interface driver au0828 xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... usb 1-4: firmware: requesting dvb-fe-xc5000-1.6.114.fw xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... mythbackend: page allocation failure. order:4, mode:0xc0d0 Pid: 15154, comm: mythbackend Tainted: P 2.6.32-22-generic #36-Ubuntu Call Trace: [] ? printk+0x1d/0x23 [] __alloc_pages_slowpath+0x46e/0x4a0 [] __alloc_pages_nodemask+0x13a/0x170 [] __get_free_pages+0x1c/0x30 [] start_urb_transfer+0x7f/0x1e0 [au0828] [] au0828_dvb_start_feed+0xc3/0xe0 [au0828] [] ? dmx_ts_feed_set+0x104/0x130 [dvb_core] [] dmx_ts_feed_start_filtering+0x58/0xe0 [dvb_core] [] dvb_dmxdev_start_feed+0xab/0x110 [dvb_core] [] dvb_dmxdev_filter_start+0x2a1/0x380 [dvb_core] [] ? chrdev_open+0xf5/0x200 [] dvb_demux_do_ioctl+0x4a7/0x550 [dvb_core] [] ? __dentry_open+0x1af/0x290 [] dvb_usercopy+0x96/0x140 [dvb_core] [] ? dvb_demux_do_ioctl+0x0/0x550 [dvb_core] [] ? mem_cgroup_update_mapped_file_stat+0x35/0x90 [] dvb_demux_ioctl+0x1f/0x30 [dvb_core] [] ? dvb_demux_do_ioctl+0x0/0x550 [dvb_core] [] vfs_ioctl+0x7b/0x90 [] do_vfs_ioctl+0x79/0x310 [] sys_ioctl+0x67/0x80 [] ? sys_open+0x2e/0x40 [] syscall_call+0x7/0xb Mem-Info: DMA per-cpu: CPU0: hi:0, btch: 1 usd: 0 CPU1: hi:0, btch: 1 usd: 0 Normal per-cpu: CPU0: hi: 186, btch: 31 usd: 0 CPU1: hi: 186, btch: 31 usd: 0 HighMem per-cpu: CPU0: hi: 186, btch: 31 usd: 2 CPU1: hi: 186, btch: 31 usd: 0 active_anon:238741 inactive_anon:92054 isolated_anon:88 active_file:46091 inactive_file:47629 isolated_file:65 unevictable:35 dirty:18690 writeback:500 unstable:207 free:233580 slab_reclaimable:13718 slab_unreclaimable:10001 mapped:19061 shmem:3609 pagetables:4972 bounce:0 DMA free:3508kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:1904kB inactive_file:2024kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB mlocked:0kB dirty:96kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:44kB slab_unreclaimable:616kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 865 2777 2777 Normal free:410632kB min:3728kB low:4660kB high:5592kB active_anon:59376kB inactive_anon:61132kB active_file:80984kB inactive_file:84656kB unevictable:0kB isolated(anon):220kB isolated(file):236kB present:885944kB mlocked:0kB dirty:46268kB writeback:292kB mapped:5692kB shmem:348kB slab_reclaimable:54828kB slab_unreclaimable:39388kB kernel_stack:4856kB pagetables:1084kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 15295 15295 HighMem free:520180kB min:512kB low:2572kB high:4632kB active_anon:895588kB inactive_anon:307084kB active_file:101476kB inactive_file:103836kB unevictable:140kB isolated(anon):132kB isolated(file):24kB present:1957776kB mlocked:136kB dirty:28396kB writeback:1708kB mapped:70552kB shmem:14088kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:18804kB unstable:828kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 5*4kB 30*8kB 15*16kB 30*32kB 24*64kB 2*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3508kB Normal: 5376*4kB 27467*8kB 10527*16kB 26*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 410632kB HighMem: 2277*4kB 45032*8kB 9358*16kB 28*32kB 3*64k
Re: [PATCH 8/8 v2]tuners:tuner-simple Fix warning: variable 'tun' set but not used
Em Mon, 14 Jun 2010 22:48:34 -0700 "Justin P. Mattock" escreveu: > Resend due to a whitespace issue I created by mistake. > The below patch fixes a warning message create by gcc 4.6.0 It seems OK for me, but you shouldn't be sending it to be applied at reiserfs-devel ML. Instead, it should be sent to linux-media ML, and applied via my tree. > > CC [M] drivers/media/common/tuners/tuner-simple.o > drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': > drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' > set but not used > > Signed-off-by: Justin P. Mattock > Reviewed-By: Mauro Carvalho Chehab > > --- > drivers/media/common/tuners/tuner-simple.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/common/tuners/tuner-simple.c > b/drivers/media/common/tuners/tuner-simple.c > index 8abbcc5..84900fa 100644 > --- a/drivers/media/common/tuners/tuner-simple.c > +++ b/drivers/media/common/tuners/tuner-simple.c > @@ -545,14 +545,11 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, > struct tuner_simple_priv *priv = fe->tuner_priv; > u8 config, cb; > u16 div; > - struct tunertype *tun; > u8 buffer[4]; > int rc, IFPCoff, i; > enum param_type desired_type; > struct tuner_params *t_params; > > - tun = priv->tun; > - > /* IFPCoff = Video Intermediate Frequency - Vif: > 940 =16*58.75 NTSC/J (Japan) > 732 =16*45.75 M/N STD -- Cheers, Mauro -- 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: WinTV-NOVA HD-S2 unable to load firmware since register 0x20 is allways 0
Hello, Am Sonntag, 20. Juni 2010 schrieb Andreas Stempfhuber: > Hello, > > I bought a brandnew Hauppauge WinTV-NOVA HD-S2 which does not load the > firmware since the value of register 0x20 is allways 0x00. After changing > the cx24116 driver to not check register 0x20, the firmware is loaded and > the card works as expected (DVB-S, audio and remote control). [...] I did a few additional tests and there seems to be only an issue with brandnew cards which have never before got a firmware uploaded. As on my card register 0x20 allways returned 0 with different kernel and driver versions and several reboots. After forcing a firmware upload by modifying the driver to not check the state of register 0x20, the issue no longer exists. If I now reboot or power cycle the PC, register 0x20 returns values unequal 0 and the original driver works as expected. It seems to me that relying on register 0x20 for firmware uploads is not stable as a brandnew card may return 0 until it got the first firmware uploaded. Regards, Andreas -- -- 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 3/4] ir-core: move decoding state to ir_raw_event_ctrl
On Sun, 2010-06-20 at 23:51 -0400, Jarod Wilson wrote: > On Sun, Jun 20, 2010 at 8:47 PM, Andy Walls wrote: > As for the building your own kernel thing... I've been doing my work > mainly on a pair of x86_64 systems, one a ThinkPad T61 running Fedora > 13, and the other an HP xw4400 workstation running RHEL6. In both > cases, I copied a distro kernel's, config file out of /boot/, and then > ran make oldconfig over it and build straight from what's in my tree, > which works well enough on both setups. I pulled the config out of the kernel*.src.rpm after 'rpmbuild -bp' (I only saw the configs in /boot after doing that :P ), and then ran 'make oldconfig'. The first time around I forgot to do a modules_install and the ext[234] modules weren't in the initramfs. That made it hard for the kernel to read the /boot and / filesystems. ;) After fixing that idiocy, it now hangs in early boot - just a blinking cursor. I'm speculating it is a problem with support for my old-ish ATI Radeon Xpress 200 video chipset with a vanilla kernel. I'll work it out eventually. > > I'll have time on Thursday night to try again. > > No rush yet, we've got a while before the merge window still. > Christoph (Bartelmus) helped me out with a bunch of ioctl > documentation this weekend, so I've got that to add to the tree, then > I think I'll be prepared to resubmit the lirc bits. I'll shoot for > doing that next weekend, and hopefully, that'll give you a chance to > try 'em out before then and provide any necessary feedback/fixes/etc. > (Not that we can't also just fix things up as needed post-merge). I'm > still up in the air as to what I should work on next... So many lirc > drivers left to port still... Maybe zilog, maybe streamzap... Maybe > the MCE IR keyboard... I've got a PVR-150 and HVR-1600 both with the Zilog Z8's on them. If I ever get my act together, I'll at least be able to test that and integrate any changes into the ivtv & cx18 drivers. I've recently seen users having trouble on IRC, BTW. Regards, Andy -- 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] Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable
Thanks to Ozan ?a?layan for pointing it out
From: Manu Abraham
Signed-off-by: Manu Abraham
[bj...@mork.no: imported from
http://jusst.de/hg/mantis-v4l-dvb/raw-rev/3731f71ed6bf]
Signed-off-by: Bjørn Mork
Cc: sta...@kernel.org
---
This patch is so obviously correct that I do not know how to write it
differently.
It is copied from the mercurial repostory at http://jusst.de/hg/mantis-v4l-dvb/
where it has been resting for more than 4 months. I certainly hope everyone is
OK with me just forwarding it like this... My only agenda is a fully functional
mantis driver in the kernel.
This patch does nothing but add all the relevant device id's for these two
drivers, so
I consider it material for stable as well.
Bjørn
drivers/media/dvb/mantis/hopper_cards.c |2 ++
drivers/media/dvb/mantis/mantis_cards.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/mantis/hopper_cards.c
b/drivers/media/dvb/mantis/hopper_cards.c
index d073c61..1bf03ac 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -250,6 +250,8 @@ static struct pci_device_id hopper_pci_table[] = {
{ }
};
+MODULE_DEVICE_TABLE(pci, hopper_pci_table);
+
static struct pci_driver hopper_pci_driver = {
.name = DRIVER_NAME,
.id_table = hopper_pci_table,
diff --git a/drivers/media/dvb/mantis/mantis_cards.c
b/drivers/media/dvb/mantis/mantis_cards.c
index 16f1708..64970cf 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -280,6 +280,8 @@ static struct pci_device_id mantis_pci_table[] = {
{ }
};
+MODULE_DEVICE_TABLE(pci, mantis_pci_table);
+
static struct pci_driver mantis_pci_driver = {
.name = DRIVER_NAME,
.id_table = mantis_pci_table,
--
1.7.1
--
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
Switzerland, Geneva DVB-T scan update
Hi all, For the Switzerland, Geneva region, a new mux has been launched in May 2010 for the local TV station. Therefore this is now different from the ch-All DVB-T file. Attached is a new file for ch-Geneva containing the SFN frequency for the main mux and this new mux. I expect another update may appear in August if/when the French DVB-T mux start broadcasting in this region. Regards, Thomas # Switzerland, Geneva region # Created from http://www.broadcast.ch/portal.aspx?pid=705 # http://www.broadcast.ch/data_program_dvbt.aspx # and w_scan for the new mux # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 57800 8MHz 5/6 NONE QAM16 8k 1/4 NONE T 70600 8MHz 1/2 NONE QAM16 8k 1/4 NONE
Re: PROBLEM: 2.6.34-rc7 kernel panics "BUG: unable to handle kernel NULL pointer dereference at (null)" while channel scan runnin
On 06/18/2010 04:30 PM, David Ellingsworth wrote: > On Sun, Jun 13, 2010 at 11:28 AM, Silamael wrote: >> Hello! >> >> In the meanwhile i tried several different kernel versions: >> - 2.6.26 (as included in Debian Lenny): crash >> - 2.6.32-3 (as in Debian Squeeze): crash >> - 2.6.32-5 (updated version in Debian Squeeze): crash >> - 2.6.34: crash >> >> In every kernel version I've tested, the crashdump looks the same. Each >> time there's an NULL pointer given to saa7146_buffer_next(). >> >> Would be nice if someone could give me some hints. I'm not sure whether >> it's a broken driver or it's due to broken hardware or some other issues. >> >> Thanks a lot! >> > > Matthias, > > While I don't doubt there's probably a bug in this driver, you haven't > provided nearly enough information to correct it. Please resubmit with > the full backtrace provided by the kernel at the time of the crash. > Without this information, it's hard to gauge the exact cause of the > error and thus no one will attempt to fix it. > > Regards, > > David Ellingsworth Hello everyone, This weekend i tried some other Nexus-S card. Same problem again. Has anyone perhaps some hint, what could be wrong with my system if it's not the driver? Is it some problem with interrupt sharing? Some ACPI issues? Thanks a lot! Greetings, Matthias -- 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: [PATCHv4 0/3] Driver for the i.MX2x CMOS Sensor Interface
Hi Baruch, > > Baruch Siach (3): > mx2_camera: Add soc_camera support for i.MX25/i.MX27 > mx27: add support for the CSI device > mx25: add support for the CSI device applied 2/3 and 3/3 for 2.6.36. Sascha > > arch/arm/mach-mx2/clock_imx27.c |2 +- > arch/arm/mach-mx2/devices.c | 31 + > arch/arm/mach-mx2/devices.h |1 + > arch/arm/mach-mx25/clock.c | 14 +- > arch/arm/mach-mx25/devices.c | 22 + > arch/arm/mach-mx25/devices.h |1 + > arch/arm/plat-mxc/include/mach/memory.h |4 +- > arch/arm/plat-mxc/include/mach/mx25.h|2 + > arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 + > drivers/media/video/Kconfig | 13 + > drivers/media/video/Makefile |1 + > drivers/media/video/mx2_camera.c | 1493 > ++ > 12 files changed, 1625 insertions(+), 5 deletions(-) > create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h > create mode 100644 drivers/media/video/mx2_camera.c > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] af9005: use generic_bulk_ctrl_endpoint_response
En/na Michael Krufky ha escrit: Could somebody please test this patch and confirm that it doesn't break the af9005 support? This patch removes the af9005_usb_generic_rw function and uses the dvb_usb_generic_rw function instead, using generic_bulk_ctrl_endpoint_response to differentiate between the read pipe and the write pipe. Unfortunately I cannot test it (my device is broken)[*]. At the time I wrote my own rw function because I didn't find a way to send on a bulk endpoint and receiving on another one (i.e. I didn't know about generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or they weren't available at the time). [*]Actually the tuner is broken, but the usb is working fine, so maybe I can give it a try. Bye -- Luca -- 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
