Re: [GIT PATCHES FOR 2.6.35] videobuf refactoring
Hans Verkuil wrote:
The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
Jonathan Corbet (1):
V4L/DVB: ov7670: silence some compiler warnings
are available in the git repository at:
git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf
Hans Verkuil (8):
v4l videobuf: remove unused mmap callback.
v4l videobuf: remove mmap_free callback
v4l videobuf: remove unused is_mmapped field
v4l videobuf: use struct videobuf_buffer * instead of void * for
videobuf_alloc
v4l videobuf: rename .vmalloc to .vaddr
v4l videobuf: rename videobuf_queue_to_vmalloc to
videobuf_queue_to_vaddr
v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper
v4l videobuf: move video_copy_to_user and copy_stream to core.
drivers/media/video/videobuf-core.c | 95 +++-
drivers/media/video/videobuf-dma-contig.c | 109 +++
drivers/media/video/videobuf-dma-sg.c | 139
-
drivers/media/video/videobuf-dvb.c|2 +-
drivers/media/video/videobuf-vmalloc.c| 104 ++
include/media/videobuf-core.h | 29 ++-
6 files changed, 137 insertions(+), 341 deletions(-)
Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi.
The tests were done with userptr, mmap and read().
There is a lot more that needs to be done, but this is a good start.
I got this error when testing the patches with a saa7134 card:
[ 9171.989707] ===
[ 9171.992696] [ INFO: possible circular locking dependency detected ]
[ 9171.992696] 2.6.33 #3
[ 9171.992696] ---
[ 9171.992696] xawtv/13330 is trying to acquire lock:
[ 9171.992696] (mm-mmap_sem){++}, at: [f80f6c50]
videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]
[ 9171.992696] but task is already holding lock:
[ 9171.992696] (q-vb_lock){+.+.+.}, at: [f80ed8bf]
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] which lock already depends on the new lock.
[ 9171.992696]
[ 9171.992696]
[ 9171.992696] the existing dependency chain (in reverse order) is:
[ 9171.992696]
[ 9171.992696] - #1 (q-vb_lock){+.+.+.}:
[ 9171.992696][c1078b3d] __lock_acquire+0xd1d/0x1220
[ 9171.992696][c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696][c1499f6c] __mutex_lock_common+0x4c/0x370
[ 9171.992696][c149a36f] mutex_lock_nested+0x3f/0x50
[ 9171.992696][f80ec3c9] videobuf_mmap_mapper+0x39/0xf0
[videobuf_core]
[ 9171.992696][f83ce5e9] video_mmap+0x29/0x40 [saa7134]
[ 9171.992696][f82df23b] v4l2_mmap+0x3b/0x40 [videodev]
[ 9171.992696][c10ee292] mmap_region+0x342/0x480
[ 9171.992696][c10ee62f] do_mmap_pgoff+0x25f/0x300
[ 9171.992696][c10ee869] sys_mmap_pgoff+0x199/0x1c0
[ 9171.992696][c1002fff] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] - #0 (mm-mmap_sem){++}:
[ 9171.992696][c1078ddf] __lock_acquire+0xfbf/0x1220
[ 9171.992696][c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696][c149a6ee] down_read+0x4e/0x60
[ 9171.992696][f80f6c50] videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696][f80f71c4] __videobuf_iolock+0xc4/0x110
[videobuf_dma_sg]
[ 9171.992696][f80ec343] videobuf_iolock+0x33/0x80 [videobuf_core]
[ 9171.992696][f83cded6] buffer_prepare+0x1d6/0x230 [saa7134]
[ 9171.992696][f80ed9f6] videobuf_read_one+0x176/0x340 [videobuf_core]
[ 9171.992696][f83ce7cb] video_read+0x8b/0xc0 [saa7134]
[ 9171.992696][f82df08d] v4l2_read+0x5d/0x70 [videodev]
[ 9171.992696][c1107b3f] vfs_read+0x9f/0x190
[ 9171.992696][c1108052] sys_read+0x42/0x70
[ 9171.992696][c1002fff] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] other info that might help us debug this:
[ 9171.992696]
[ 9171.992696] 1 lock held by xawtv/13330:
[ 9171.992696] #0: (q-vb_lock){+.+.+.}, at: [f80ed8bf]
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] stack backtrace:
[ 9171.992696] Pid: 13330, comm: xawtv Tainted: G C 2.6.33 #3
[ 9171.992696] Call Trace:
[ 9171.992696] [c1498793] ? printk+0x1d/0x22
[ 9171.992696] [c1076cb2] print_circular_bug+0xc2/0xd0
[ 9171.992696] [c1078ddf] __lock_acquire+0xfbf/0x1220
[ 9171.992696] [c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696] [f80f6c50] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [c149a6ee] down_read+0x4e/0x60
[ 9171.992696] [f80f6c50] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [f80f6c50] videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696] [f80f71c4] __videobuf_iolock+0xc4/0x110 [videobuf_dma_sg]
[ 9171.992696] [f80f6a22] ? videobuf_dma_free+0x62/0xb0 [videobuf_dma_sg]
[ 9171.992696] [c107787b] ?
Re: [GIT PATCHES FOR 2.6.35] videobuf refactoring
On Friday 23 April 2010 08:08:01 Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
Jonathan Corbet (1):
V4L/DVB: ov7670: silence some compiler warnings
are available in the git repository at:
git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf
Hans Verkuil (8):
v4l videobuf: remove unused mmap callback.
v4l videobuf: remove mmap_free callback
v4l videobuf: remove unused is_mmapped field
v4l videobuf: use struct videobuf_buffer * instead of void * for
videobuf_alloc
v4l videobuf: rename .vmalloc to .vaddr
v4l videobuf: rename videobuf_queue_to_vmalloc to
videobuf_queue_to_vaddr
v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper
v4l videobuf: move video_copy_to_user and copy_stream to core.
drivers/media/video/videobuf-core.c | 95 +++-
drivers/media/video/videobuf-dma-contig.c | 109 +++
drivers/media/video/videobuf-dma-sg.c | 139
-
drivers/media/video/videobuf-dvb.c|2 +-
drivers/media/video/videobuf-vmalloc.c| 104 ++
include/media/videobuf-core.h | 29 ++-
6 files changed, 137 insertions(+), 341 deletions(-)
Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi.
The tests were done with userptr, mmap and read().
There is a lot more that needs to be done, but this is a good start.
I got this error when testing the patches with a saa7134 card:
[ 9171.989707] ===
[ 9171.992696] [ INFO: possible circular locking dependency detected ]
[ 9171.992696] 2.6.33 #3
[ 9171.992696] ---
[ 9171.992696] xawtv/13330 is trying to acquire lock:
[ 9171.992696] (mm-mmap_sem){++}, at: [f80f6c50]
videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]
[ 9171.992696] but task is already holding lock:
[ 9171.992696] (q-vb_lock){+.+.+.}, at: [f80ed8bf]
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] which lock already depends on the new lock.
[ 9171.992696]
[ 9171.992696]
[ 9171.992696] the existing dependency chain (in reverse order) is:
[ 9171.992696]
[ 9171.992696] - #1 (q-vb_lock){+.+.+.}:
[ 9171.992696][c1078b3d] __lock_acquire+0xd1d/0x1220
[ 9171.992696][c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696][c1499f6c] __mutex_lock_common+0x4c/0x370
[ 9171.992696][c149a36f] mutex_lock_nested+0x3f/0x50
[ 9171.992696][f80ec3c9] videobuf_mmap_mapper+0x39/0xf0
[videobuf_core]
[ 9171.992696][f83ce5e9] video_mmap+0x29/0x40 [saa7134]
[ 9171.992696][f82df23b] v4l2_mmap+0x3b/0x40 [videodev]
[ 9171.992696][c10ee292] mmap_region+0x342/0x480
[ 9171.992696][c10ee62f] do_mmap_pgoff+0x25f/0x300
[ 9171.992696][c10ee869] sys_mmap_pgoff+0x199/0x1c0
[ 9171.992696][c1002fff] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] - #0 (mm-mmap_sem){++}:
[ 9171.992696][c1078ddf] __lock_acquire+0xfbf/0x1220
[ 9171.992696][c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696][c149a6ee] down_read+0x4e/0x60
[ 9171.992696][f80f6c50] videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696][f80f71c4] __videobuf_iolock+0xc4/0x110
[videobuf_dma_sg]
[ 9171.992696][f80ec343] videobuf_iolock+0x33/0x80 [videobuf_core]
[ 9171.992696][f83cded6] buffer_prepare+0x1d6/0x230 [saa7134]
[ 9171.992696][f80ed9f6] videobuf_read_one+0x176/0x340
[videobuf_core]
[ 9171.992696][f83ce7cb] video_read+0x8b/0xc0 [saa7134]
[ 9171.992696][f82df08d] v4l2_read+0x5d/0x70 [videodev]
[ 9171.992696][c1107b3f] vfs_read+0x9f/0x190
[ 9171.992696][c1108052] sys_read+0x42/0x70
[ 9171.992696][c1002fff] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] other info that might help us debug this:
[ 9171.992696]
[ 9171.992696] 1 lock held by xawtv/13330:
[ 9171.992696] #0: (q-vb_lock){+.+.+.}, at: [f80ed8bf]
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] stack backtrace:
[ 9171.992696] Pid: 13330, comm: xawtv Tainted: G C 2.6.33 #3
[ 9171.992696] Call Trace:
[ 9171.992696] [c1498793] ? printk+0x1d/0x22
[ 9171.992696] [c1076cb2] print_circular_bug+0xc2/0xd0
[ 9171.992696] [c1078ddf] __lock_acquire+0xfbf/0x1220
[ 9171.992696] [c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696] [f80f6c50] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [c149a6ee] down_read+0x4e/0x60
[ 9171.992696] [f80f6c50] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [f80f6c50] videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[
RE: [GIT PATCHES FOR 2.6.35] videobuf refactoring
Mauro Carvalho Chehab mche...@redhat.com wrote:
Hans Verkuil wrote:
The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
Jonathan Corbet (1):
V4L/DVB: ov7670: silence some compiler warnings
are available in the git repository at:
git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf
Hans Verkuil (8):
v4l videobuf: remove unused mmap callback.
v4l videobuf: remove mmap_free callback
v4l videobuf: remove unused is_mmapped field
v4l videobuf: use struct videobuf_buffer * instead of void * for
videobuf_alloc
v4l videobuf: rename .vmalloc to .vaddr
v4l videobuf: rename videobuf_queue_to_vmalloc to
videobuf_queue_to_vaddr
v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper
v4l videobuf: move video_copy_to_user and copy_stream to core.
drivers/media/video/videobuf-core.c | 95 +++-
drivers/media/video/videobuf-dma-contig.c | 109 +++
drivers/media/video/videobuf-dma-sg.c | 139
-
drivers/media/video/videobuf-dvb.c|2 +-
drivers/media/video/videobuf-vmalloc.c| 104 ++
include/media/videobuf-core.h | 29 ++-
6 files changed, 137 insertions(+), 341 deletions(-)
Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi.
The tests were done with userptr, mmap and read().
There is a lot more that needs to be done, but this is a good start.
I got this error when testing the patches with a saa7134 card:
[ 9171.989707] ===
[ 9171.992696] [ INFO: possible circular locking dependency detected ]
[ 9171.992696] 2.6.33 #3
[ 9171.992696] ---
[ 9171.992696] xawtv/13330 is trying to acquire lock:
[ 9171.992696] (mm-mmap_sem){++}, at: [f80f6c50]
videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]
[ 9171.992696] but task is already holding lock:
[ 9171.992696] (q-vb_lock){+.+.+.}, at: [f80ed8bf]
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] which lock already depends on the new lock.
[ 9171.992696]
[ 9171.992696]
[ 9171.992696] the existing dependency chain (in reverse order) is:
[ 9171.992696]
[ 9171.992696] - #1 (q-vb_lock){+.+.+.}:
[ 9171.992696][c1078b3d] __lock_acquire+0xd1d/0x1220
[ 9171.992696][c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696][c1499f6c] __mutex_lock_common+0x4c/0x370
[ 9171.992696][c149a36f] mutex_lock_nested+0x3f/0x50
[ 9171.992696][f80ec3c9] videobuf_mmap_mapper+0x39/0xf0
[videobuf_core]
[ 9171.992696][f83ce5e9] video_mmap+0x29/0x40 [saa7134]
[ 9171.992696][f82df23b] v4l2_mmap+0x3b/0x40 [videodev]
[ 9171.992696][c10ee292] mmap_region+0x342/0x480
[ 9171.992696][c10ee62f] do_mmap_pgoff+0x25f/0x300
[ 9171.992696][c10ee869] sys_mmap_pgoff+0x199/0x1c0
[ 9171.992696][c1002fff] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] - #0 (mm-mmap_sem){++}:
[ 9171.992696][c1078ddf] __lock_acquire+0xfbf/0x1220
[ 9171.992696][c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696][c149a6ee] down_read+0x4e/0x60
[ 9171.992696][f80f6c50] videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696][f80f71c4] __videobuf_iolock+0xc4/0x110
[videobuf_dma_sg]
[ 9171.992696][f80ec343] videobuf_iolock+0x33/0x80 [videobuf_core]
[ 9171.992696][f83cded6] buffer_prepare+0x1d6/0x230 [saa7134]
[ 9171.992696][f80ed9f6] videobuf_read_one+0x176/0x340
[videobuf_core]
[ 9171.992696][f83ce7cb] video_read+0x8b/0xc0 [saa7134]
[ 9171.992696][f82df08d] v4l2_read+0x5d/0x70 [videodev]
[ 9171.992696][c1107b3f] vfs_read+0x9f/0x190
[ 9171.992696][c1108052] sys_read+0x42/0x70
[ 9171.992696][c1002fff] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] other info that might help us debug this:
[ 9171.992696]
[ 9171.992696] 1 lock held by xawtv/13330:
[ 9171.992696] #0: (q-vb_lock){+.+.+.}, at: [f80ed8bf]
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] stack backtrace:
[ 9171.992696] Pid: 13330, comm: xawtv Tainted: G C 2.6.33 #3
[ 9171.992696] Call Trace:
[ 9171.992696] [c1498793] ? printk+0x1d/0x22
[ 9171.992696] [c1076cb2] print_circular_bug+0xc2/0xd0
[ 9171.992696] [c1078ddf] __lock_acquire+0xfbf/0x1220
[ 9171.992696] [c10790cd] lock_acquire+0x8d/0x100
[ 9171.992696] [f80f6c50] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [c149a6ee] down_read+0x4e/0x60
[ 9171.992696] [f80f6c50] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [f80f6c50] videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696] [f80f71c4] __videobuf_iolock+0xc4/0x110 [videobuf_dma_sg]
[ 9171.992696] [f80f6a22] ? videobuf_dma_free+0x62/0xb0
Re: DViCo Dual Fusion Express (cx23885) remote control issue
On 4/22/2010 5:29 PM, Daniel O'Connor wrote: On Fri, 23 Apr 2010, Timothy D. Lenz wrote: On 4/22/2010 6:11 AM, Daniel O'Connor wrote: On Thu, 15 Apr 2010, Daniel O'Connor wrote: I haven't delved much further yet (planning to printf my way through the probe routines) as I am a Linux kernel noob (plenty of FreeBSD experience though!). I found that it is intermittent with no pattern I can determine. When it doesn't work the probe routine is not called, but I am not sure how i2c_register_driver decides to call the probe routine. Does anyone have an idea what the cause could be? Or at least somewhere to start looking :) A patch was posted that was suposed to be merged that fixed the ir problem, at least for me. Though my problem was not intermittent. The patch worked for me. Now if I could just get both tuners to keep working Hmm do you have a subject line or message ID I can search for? I haven't found any problems with tuners not working although I don't often fire them both up at once. [PATCH] FusionHDTV: Use quick reads for I2C IR device probing -- 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: Fw: PROBLEM: linux server halts while restarting VLC
Hello, The issue happens if VLC process hasn't been unloaded before executing another instance. In this case killall command did not work as supposed. Hope this helps. We have a video camera which is connected to a capture card in a linux server (CentOS 5.4). VLC takes video data from the capture card, streams it and writes to a file. A cron job checking the file's size and rotates it when it comes to a configured limit. After file was rotated, VLC process is restarted. [...] -- Best regards, Alexander -- 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 v5 1/2] v4l: Add memory-to-memory device helper framework for videobuf.
A mem-to-mem device is a device that uses memory buffers passed by
userspace applications for both their source and destination data. This
is different from existing drivers, which utilize memory buffers for either
input or output, but not both.
In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type.
Examples of such devices would be: image 'resizers', 'rotators',
'colorspace converters', etc.
This patch adds a separate Kconfig sub-menu for mem-to-mem devices as well.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/Kconfig| 14 +
drivers/media/video/Makefile |2 +
drivers/media/video/v4l2-mem2mem.c | 633
include/media/v4l2-mem2mem.h | 201
4 files changed, 850 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/v4l2-mem2mem.c
create mode 100644 include/media/v4l2-mem2mem.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f8fc865..5fd041e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -45,6 +45,10 @@ config VIDEO_TUNER
tristate
depends on MEDIA_TUNER
+config V4L2_MEM2MEM_DEV
+ tristate
+ depends on VIDEOBUF_GEN
+
#
# Multimedia Video device configuration
#
@@ -1107,3 +,13 @@ config USB_S2255
endif # V4L_USB_DRIVERS
endif # VIDEO_CAPTURE_DRIVERS
+
+menuconfig V4L_MEM2MEM_DRIVERS
+ bool Memory-to-memory multimedia devices
+ depends on VIDEO_V4L2
+ default n
+ ---help---
+ Say Y here to enable selecting drivers for V4L devices that
+ use system memory for both source and destination buffers, as opposed
+ to capture and output drivers, which use memory buffers for just
+ one of those.
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b88b617..e974680 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -117,6 +117,8 @@ obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o
obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
+obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+
obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
diff --git a/drivers/media/video/v4l2-mem2mem.c
b/drivers/media/video/v4l2-mem2mem.c
new file mode 100644
index 000..f45f940
--- /dev/null
+++ b/drivers/media/video/v4l2-mem2mem.c
@@ -0,0 +1,633 @@
+/*
+ * Memory-to-memory device framework for Video for Linux 2 and videobuf.
+ *
+ * Helper functions for devices that use videobuf buffers for both their
+ * source and destination.
+ *
+ * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * Pawel Osciak, p.osc...@samsung.com
+ * Marek Szyprowski, m.szyprow...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include linux/module.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include media/videobuf-core.h
+#include media/v4l2-mem2mem.h
+
+MODULE_DESCRIPTION(Mem to mem device framework for videobuf);
+MODULE_AUTHOR(Pawel Osciak, p.osc...@samsung.com);
+MODULE_LICENSE(GPL);
+
+static bool debug;
+module_param(debug, bool, 0644);
+
+#define dprintk(fmt, arg...) \
+ do {\
+ if (debug) \
+ printk(KERN_DEBUG %s: fmt, __func__, ## arg);\
+ } while (0)
+
+
+/* Instance is already queued on the job_queue */
+#define TRANS_QUEUED (1 0)
+/* Instance is currently running in hardware */
+#define TRANS_RUNNING (1 1)
+
+
+/* Offset base for buffers on the destination queue - used to distinguish
+ * between source and destination buffers when mmapping - they receive the same
+ * offsets but for different queues */
+#define DST_QUEUE_OFF_BASE (1 30)
+
+
+/**
+ * struct v4l2_m2m_dev - per-device context
+ * @curr_ctx: currently running instance
+ * @job_queue: instances queued to run
+ * @job_spinlock: protects job_queue
+ * @m2m_ops: driver callbacks
+ */
+struct v4l2_m2m_dev {
+ struct v4l2_m2m_ctx *curr_ctx;
+
+ struct list_headjob_queue;
+ spinlock_t job_spinlock;
+
+ struct v4l2_m2m_ops *m2m_ops;
+};
+
+static struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx *m2m_ctx,
+ enum v4l2_buf_type type)
+{
+ switch (type) {
+ case
[PATCH v5 2/2] v4l: Add a mem-to-mem videobuf framework test device.
This is a virtual device driver for testing the memory-to-memory framework.
This virtual device uses in-memory buffers for both its source and destination.
It is capable of multi-instance, multi-buffer-per-transaction operation
(via the mem2mem framework).
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/Kconfig | 14 +
drivers/media/video/Makefile |1 +
drivers/media/video/mem2mem_testdev.c | 1049 +
3 files changed, 1064 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mem2mem_testdev.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 5fd041e..9a306a6 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1121,3 +1121,17 @@ menuconfig V4L_MEM2MEM_DRIVERS
use system memory for both source and destination buffers, as opposed
to capture and output drivers, which use memory buffers for just
one of those.
+
+if V4L_MEM2MEM_DRIVERS
+
+config VIDEO_MEM2MEM_TESTDEV
+ tristate Virtual test device for mem2mem framework
+ depends on VIDEO_DEV VIDEO_V4L2
+ select VIDEOBUF_VMALLOC
+ select V4L2_MEM2MEM_DEV
+ default n
+ ---help---
+ This is a virtual test device for the memory-to-memory driver
+ framework.
+
+endif # V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index e974680..2fa3c13 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
+obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
new file mode 100644
index 000..75497fa
--- /dev/null
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -0,0 +1,1049 @@
+/*
+ * A virtual v4l2-mem2mem example device.
+ *
+ * This is a virtual device driver for testing mem-to-mem videobuf framework.
+ * It simulates a device that uses memory buffers for both source and
+ * destination, processes the data and issues an irq (simulated by a timer).
+ * The device is capable of multi-instance, multi-buffer-per-transaction
+ * operation (via the mem2mem framework).
+ *
+ * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * Pawel Osciak, p.osc...@samsung.com
+ * Marek Szyprowski, m.szyprow...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+#include linux/module.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/version.h
+#include linux/timer.h
+#include linux/sched.h
+
+#include linux/platform_device.h
+#include media/v4l2-mem2mem.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf-vmalloc.h
+
+#define MEM2MEM_TEST_MODULE_NAME mem2mem-testdev
+
+MODULE_DESCRIPTION(Virtual device for mem2mem framework testing);
+MODULE_AUTHOR(Pawel Osciak, p.osc...@samsung.com);
+MODULE_LICENSE(GPL);
+
+
+#define MIN_W 32
+#define MIN_H 32
+#define MAX_W 640
+#define MAX_H 480
+#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */
+
+/* Flags that indicate a format can be used for capture/output */
+#define MEM2MEM_CAPTURE(1 0)
+#define MEM2MEM_OUTPUT (1 1)
+
+#define MEM2MEM_NAME m2m-testdev
+
+/* Per queue */
+#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
+/* In bytes, per queue */
+#define MEM2MEM_VID_MEM_LIMIT (16 * 1024 * 1024)
+
+/* Default transaction time in msec */
+#define MEM2MEM_DEF_TRANSTIME 1000
+/* Default number of buffers per transaction */
+#define MEM2MEM_DEF_TRANSLEN 1
+#define MEM2MEM_COLOR_STEP (0xff 4)
+#define MEM2MEM_NUM_TILES 8
+
+#define dprintk(dev, fmt, arg...) \
+ v4l2_dbg(1, 1, dev-v4l2_dev, %s: fmt, __func__, ## arg)
+
+
+void m2mtest_dev_release(struct device *dev)
+{}
+
+static struct platform_device m2mtest_pdev = {
+ .name = MEM2MEM_NAME,
+ .dev.release= m2mtest_dev_release,
+};
+
+struct m2mtest_fmt {
+ char*name;
+ u32 fourcc;
+ int depth;
+ /* Types the format can be used for */
+ u32 types;
+};
+
+static struct m2mtest_fmt formats[] = {
+ {
+ .name = RGB565 (BE),
+ .fourcc = V4L2_PIX_FMT_RGB565X, /* rggg gggb */
+ .depth = 16,
+ /* Both capture and output format */
+
[PATCH v5 0/2] Mem-to-mem device framework
Hello, this is the fifth and final version of the mem-to-mem device framework. I have added Vaibhav's Reviewed-by and Tested-by with his permission (thank you). Changes in v5: - one additional empty line - an opening brace moved one line above Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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] Mem-to-mem framework
Hello Mauro, could you please pull the final version of mem-to-mem framework? Relevant patchwork entries: https://patchwork.kernel.org/patch/94646/ https://patchwork.kernel.org/patch/94647/ Thank you. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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 0/3] Driver for TI WL1273 FM radio.
On Tuesday 20 April 2010 17:20:04 Matti J. Aaltonen wrote: Hi. This is the initial version of my driver for Texas Instruments WL1273 FM receiver transmitter. The driver is divided into three parts: the MFD core which handles the communication with the chip and also keeps the chip state, ASoC codec takes care of the digital audio part and the V4L2 control part with some private IOCTLs. This is my first up-streaming effort so all comments are welcome. OK, I did a quick review and the main things that you need to look at are the RDS receiver API as defined in the spec (http://www.linuxtv.org/downloads/v4l-dvb-apis/ch04s11.html) and the FM and RDS transmitter controls: http://www.linuxtv.org/downloads/v4l-dvb-apis/ch01s09.html#fm-tx-controls. Any private controls that you think you need should be discussed first. We may need to standardize them. The other thing you have to do in the V4L2 driver is to use struct v4l2_device. See also Documentation/video4linux/v4l2-framework.txt. I also noticed some FM and RDS things in the alsa driver. It is not clear to me why these are there since this is pretty much V4L2 specific. Regarding hardcoding regions: isn't this more for the application? Are there any legal requirements for region handling? Most radio tuners just accept the whole frequency range that they support and leave it to the application to restrict it if needed depending on the region. Those disabled controls like bass, treble etc. should be removed. Workarounds for plainly broken applications is not something we want in our drivers. Instead make a patch for that app and send it to the maintainer. If it is unmaintained, then let us know: we can move unmaintained but frequently used apps to our own repository. Regards, Hans Cheers, Matti Matti J. Aaltonen (3): MFD: WL1273 FM Radio: MFD driver for the FM radio. ASoC: WL1273 FM Radio: Digital audio codec. V4L2: WL1273 FM Radio: Controls for the FM radio. drivers/media/radio/Kconfig| 15 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-wl1273.c | 805 drivers/mfd/Kconfig|6 + drivers/mfd/Makefile |2 + drivers/mfd/wl1273-core.c | 1825 include/linux/mfd/wl1273-core.h| 265 ++ sound/soc/codecs/Kconfig |6 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/wl1273.c | 708 ++ sound/soc/codecs/wl1273.h | 49 + 11 files changed, 3684 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-wl1273.c create mode 100644 drivers/mfd/wl1273-core.c create mode 100644 include/linux/mfd/wl1273-core.h create mode 100644 sound/soc/codecs/wl1273.c create mode 100644 sound/soc/codecs/wl1273.h -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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 0/3] Driver for TI WL1273 FM radio.
Hello Hans, thank you for the comments. On Fri, 2010-04-23 at 11:16 +0200, ext Hans Verkuil wrote: On Tuesday 20 April 2010 17:20:04 Matti J. Aaltonen wrote: Hi. This is the initial version of my driver for Texas Instruments WL1273 FM receiver transmitter. The driver is divided into three parts: the MFD core which handles the communication with the chip and also keeps the chip state, ASoC codec takes care of the digital audio part and the V4L2 control part with some private IOCTLs. This is my first up-streaming effort so all comments are welcome. OK, I did a quick review and the main things that you need to look at are the RDS receiver API as defined in the spec (http://www.linuxtv.org/downloads/v4l-dvb-apis/ch04s11.html) and the FM and RDS transmitter controls: http://www.linuxtv.org/downloads/v4l-dvb-apis/ch01s09.html#fm-tx-controls. OK, I'll do that. Any private controls that you think you need should be discussed first. We may need to standardize them. OK, I didn't realize that. But it makes sense, so let's discuss... The other thing you have to do in the V4L2 driver is to use struct v4l2_device. See also Documentation/video4linux/v4l2-framework.txt. OK. I also noticed some FM and RDS things in the alsa driver. It is not clear to me why these are there since this is pretty much V4L2 specific. Yes, I kind of new that those controls weren't a good idea. But I implemented those when I didn't know better. Ande I left them there to see if they would get accepted. But I'll remove them as the functionality is duplicated in the V4L2 module. Regarding hardcoding regions: isn't this more for the application? Are there any legal requirements for region handling? I thought about that a lot. And I know that the regions are a policy thing that doesn't belong into the driver/kernel. But those two regions are directly supported by the hardware so I thought that it would be OK make them available. Most radio tuners just accept the whole frequency range that they support and leave it to the application to restrict it if needed depending on the region. I understand... see above... Those disabled controls like bass, treble etc. should be removed. Workarounds for plainly broken applications is not something we want in our drivers. Instead make a patch for that app and send it to the maintainer. If it is unmaintained, then let us know: we can move unmaintained but frequently used apps to our own repository. Fine... I did that just to copy the functionality of some existing driver when I started. B.R. Matti Regards, Hans Cheers, Matti Matti J. Aaltonen (3): MFD: WL1273 FM Radio: MFD driver for the FM radio. ASoC: WL1273 FM Radio: Digital audio codec. V4L2: WL1273 FM Radio: Controls for the FM radio. drivers/media/radio/Kconfig| 15 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-wl1273.c | 805 drivers/mfd/Kconfig|6 + drivers/mfd/Makefile |2 + drivers/mfd/wl1273-core.c | 1825 include/linux/mfd/wl1273-core.h| 265 ++ sound/soc/codecs/Kconfig |6 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/wl1273.c | 708 ++ sound/soc/codecs/wl1273.h | 49 + 11 files changed, 3684 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-wl1273.c create mode 100644 drivers/mfd/wl1273-core.c create mode 100644 include/linux/mfd/wl1273-core.h create mode 100644 sound/soc/codecs/wl1273.c create mode 100644 sound/soc/codecs/wl1273.h -- 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 -- 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
Ticket #5744: Initial tuning to an analogue station fault
Hi, Apologies for the nube ignorance/vagueness but I'm seeking a bugfix to (I believe) the cx8800 module, related to an issue I experienced in MythTV (http://svn.mythtv.org/trac/ticket/5744). The MythTV devs are reluctant to incorporate the patch attached to the bug since they believe it is a workaround for an upstream V4L issue. Hence my mail to this list. The following is a mail written to Gerd Knorr (who I believe to be the the author of the cx8800 driver/module), seeking assistance with this bugfix. At the foot of the email trail is a brief description of what is believed to be the issue (written by Daniel Kristjansson). Having found various statements suggesting Gerd is no longer involved with V4L, I though I'd repost here. NB. I've yet to receive confirmation that it is actually the cx8800 module (and not some dependency of the cx8800 module) that requires fixing. All I know is that MythTV reports that it is using the cx8800 driver. FYI, I'm picking up the V4L modules from kernel v2.6.32.11-99. My system is running x86_64 Fedora 12. My video capture card is a Hauppague HVR-4000 Any help anyone can give would be greatly appreciated. Mike --- Gerd, Apologies for the direct email, but I'm trying to track down the person responsible for, I believe, the V4L cx8800 driver/module. I'm attempting to find a resolution for http://svn.mythtv.org/trac/ticket/5744, an issue which has wasted several hours of my time recently as I've struggled to get live TV in Myth working on my HVR-4000 card. As the ticket describes, the MythTV devs are unwilling to integrate this patch as they see it as a workaround for a V4L driver bug (briefly described below by Daniel Kristjansson). Are you the correct person to implement a fix for the cx8800 driver? NB. As you can doubtless tell from this and previous mails, I'm operating well out of my depth here. I'm just trying to get an issue solved that has cost me time and will probably cost others time in the months/years to come. If you can help in any way to move this issue closer to resolution, I'd be very grateful. If you need any information, logs etc. from me, just let me know what I need to do and I'll do my best to provide you with the information you need. Obviously, if you're not the correct recipient of this mail, I'd appreciate you passing it onto to whoever you believe to be the correct recipient. Best regards, Mike -Original Message- From: Mike Parker [mailto:michael.par...@st.com] Sent: Thursday, April 22, 2010 1:35 PM To: 'Daniel Kristjansson' Cc: 'Janne' Subject: RE: Ticket #5744: Initial tuning to an analogue station fault snip It looks like the problem is that the driver is not allowing multiple open calls to it's file handle. It should be allowing opens for ioctl's even if it only allows one open for reading. The driver probably has the name of the person who maintains the driver in it's source files in the copyright notice. Try e-mailing that person. We work with many drivers so we don't want to add special code to interface with each one's quirks unless it's on a limited time basis. When we add a workaround we need the driver name and the version the problem is fixed in. We write the hack so it is only used for those older drivers and remove the workaround after one to two years. -- Daniel Thanks for getting back to me. First off, I understand and agree with your position re. the inclusion of workarounds. Excuse my ignorance (I'm a relative newbie to Linux) but which driver are we talking about? Myth BE log reports that it's using the cx8800 driver, which I assume references the common v4l_common(?) module/driver via the dependency tree illustrated in the output of 'lsmod'. Is this even roughly correct? Am I correct in thinking, therefore, that the driver that requires a bugfix is the cx8800 driver? i.e. the driver specific to the hardware on the HVR-4000 card? Also, when we talk about driver, are we really talking about the kernel module (*.ko, IIRC)? Looking at the copyright notice in one of the cx88 src files, it looks as if Gerd Knorr kra...@bytesex.org is the contact I'm looking for. Best regards, 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: Help needed in understanding v4l2_device_call_all
Bee Hock Goh wrote:
Mauro,
Thanks.
Previously, I have done some limited test and it seem that
xc2028_signal seem to be getting the correct registered value for the
detected a signal locked.
With the i2c reads working perfectly, it should be already providing the
signal strength with the current code. Dmitri submitted an interesting
patch that it is probably improving the i2c code. It is a worthy trial.
Since I am now able to get video working(though somewhat limited since
it still crashed if i change channel from mythtv), i will be spending
more time to look getting a lock on the signal.
There are still troubles on video. I tested yesterday, and it still crashing.
Tested on a tm6010 device. Unfortunately, some patch broke support for my
10moons device: it is now failing when reading the firmware. Probably, the
GPIO code is wrong.
Is line 139,140,155,156 needed? Its slowing down the loading of
firmware and it working for me with the additional register setting.
138 if (addr == dev-tuner_addr 1) {
139 tm6000_set_reg(dev, 0x32, 0,0);
140 tm6000_set_reg(dev, 0x33, 0,0);
On my tests with HVR-950H, it makes no difference. Probably, Dmitri approach
should be enough, but it won't solve the slow down, as it adds some delay
on i2c operations.
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: [PATCH] tm6000 fix i2c
I am still able to watch tv after applying the patch but the return
code is bad and is causing unnecessary reloading of the same
firmwares.
[ 2482.599040] usb 1-1: firmware: requesting tm6000-xc3028.fw
[ 2482.607229] xc2028 2-0061: Loading 77 firmware images from
tm6000-xc3028.fw, type: xc2028 firmware, ver 2.4
[ 2482.788089] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2503.620069] (0), id 00ff:
[ 2503.620078] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2504.380061] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2504.520063] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2504.536064] xc2028 2-0061: Unable to read tuner registers.
[ 2504.776079] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2525.556048] (0), id 00ff:
[ 2525.556057] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2526.312058] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2526.452061] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2526.468050] xc2028 2-0061: Unable to read tuner registers.
[ 2527.648076] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2548.460067] (0), id 00ff:
[ 2548.460076] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2549.216070] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2549.356064] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2549.372065] xc2028 2-0061: Unable to read tuner registers.
[ 2549.612052] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2570.609041] (0), id 00ff:
[ 2570.609049] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2571.397034] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2571.537025] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2571.553024] xc2028 2-0061: Unable to read tuner registers.
[ 2572.553103] Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load status: 0)
[ 2572.561090] tm6000: open called (dev=video0)
[ 2573.081022] Original value=96
[ 2573.093037] tm6000: VIDIOC_QUERYCAP
[ 2573.149565] tm6000: open called (dev=video0)
On Fri, Apr 23, 2010 at 8:48 AM, Dmitri Belimov d.beli...@gmail.com wrote:
Hi
Rework I2C for read word from connected devices, now it works well.
Add new functions for read/write blocks.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c Fri Apr 23 04:23:03 2010 +1000
@@ -24,6 +24,7 @@
#include linux/kernel.h
#include linux/usb.h
#include linux/i2c.h
+#include linux/delay.h
#include compat.h
#include tm6000.h
@@ -45,11 +46,39 @@
printk(KERN_DEBUG %s at %s: fmt, \
dev-name, __FUNCTION__ , ##args); } while (0)
+static void tm6000_i2c_reset(struct tm6000_core *dev)
+{
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 0);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 1);
+ msleep(15);
+}
+
static int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr,
__u8 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, buf, len);
+ int rc;
+ unsigned int tsleep;
+
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = ((len * 200) + 200 + 1000) / 1000;
+ msleep(tsleep);
+
+ /* release mutex */
+ return rc;
}
/* Generic read - doesn't work fine with 16bit registers */
@@ -59,22 +88,30 @@
int rc;
u8 b[2];
- if ((dev-caps.has_zl10353) (dev-demod_addr 1 == addr) (reg
% 2 == 0)) {
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ if ((dev-caps.has_zl10353) (dev-demod_addr 1 == addr)
+ (reg % 2 == 0)) {
/*
* Workaround an I2C bug when reading from zl10353
*/
reg -= 1;
len += 1;
- rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR
| USB_RECIP_DEVICE,
-
Please ignore this message
Please ignore this message. I've been trying to send a patch to this list since yesterday without success. This message is just to validate my mailing list subscription. -rm -- 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
Xawtv version 3.96
For those that haven't notice yet, we're fixing some bugs at xawtv 3. Probably, we won't be adding new features on it, but we want to keep it on a sane state, in order to allow people to use it as a reference application on driver development. I've just committed a few patches I wrote yesterday that backports some of the Fedora 12 patches to xawtv, and fixed a few bugs on it. As result, after having all dependencies installed, xawtv should compile fine with a recent distro (tested here with Fedora 12 and RHEL 5). The version was increased to 3.96. As usual, all commit messages are sent to linuxtv-commits mailing list. So, people that are interested on tracking what's happening can subscribe to the list. Cheers, Mauro. Mensagem original Assunto: [git:xawtv3/master] Increase version to 3.96 Data: Fri, 23 Apr 2010 14:47:57 +0200 De: Mauro Carvalho Chehab mche...@redhat.com Responder a: linux-media@vger.kernel.org Para: linuxtv-comm...@linuxtv.org This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/xawtv3.git tree: Subject: Increase version to 3.96 Author: Mauro Carvalho Chehab mche...@redhat.com Date:Fri Apr 23 09:37:43 2010 -0300 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Changes| 10 ++ xawtv.spec |2 +- 2 files changed, 11 insertions(+), 1 deletions(-) --- http://git.linuxtv.org/xawtv3.git?a=commitdiff;h=091c0a39d56419253cc501a121c81655c94296e7 diff --git a/Changes b/Changes index fa941ff..916c373 100644 --- a/Changes +++ b/Changes @@ -1,4 +1,14 @@ +3.96 + + * misc minor fixes collected at Fedora 12. + * Fix requement of /dev/vbi instead of /dev/vbi0 on scantv. + * Fix compilation with Xorg and remove the --x_libraries parameter from + the configure script (as, on Xorg, X11 libraries are at /usr/lib). + * Now, providing that all build dependencies are satisfied, just typing + make after the download is enough to generate/run configure and build + the tools. + 3.95 diff --git a/xawtv.spec b/xawtv.spec index d390d1b..77b4098 100644 --- a/xawtv.spec +++ b/xawtv.spec @@ -1,7 +1,7 @@ Name: xawtv Group:Applications/Multimedia Autoreqprov: on -Version: 3.95 +Version: 3.96 Release: 0 License: GPL Summary: v4l applications ___ linuxtv-commits mailing list linuxtv-comm...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits -- 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
Xawtv sparc 64bit fix
Hi,
Here is an old patch of mine which I tried to submit in 2006 but never
got it. I didn't really know who was xawtv's maintainer at that time.
The calculation to compute the 64bit alignement in struct-dump.c is
plain wrong. The alignment has to be computed with a structure
containing a char and then a 64bit integer and then substract the
pointer of the 64bit int to the one of the char.
This fix v4l-info doing a Bus Error on sparc with structs containing
64 bit integer following a non 64bit field aligned on a 8 byte boundary
like v4l2_standard.
Signed-off-by: Guy Martin gms...@tuxicoman.be
Regards,
Guydiff --git a/structs/struct-dump.c b/structs/struct-dump.c
index 0ee7fc8..ba1dc6f 100644
--- a/structs/struct-dump.c
+++ b/structs/struct-dump.c
@@ -43,7 +43,9 @@ int print_struct(FILE *fp, struct struct_desc *desc, void *data,
int16_t s16;
uint8_t u8;
int8_t s8;
- int al = sizeof(long)-1; /* struct + union + 64bit alignment */
+ struct al64_t { char c; uint64_t t; } al64_t;
+ int al = sizeof(long)-1; /* struct + union */
+ int al64 = (unsigned)al64_t.t - (unsigned)al64_t.c - 1; /* 64 bit alignement */
void *p;
unsigned int i,j,first;
@@ -149,7 +151,7 @@ int print_struct(FILE *fp, struct struct_desc *desc, void *data,
ptr += 4;
break;
case BITS64:
- ptr = (void*)(((intptr_t)ptr + al) ~al);
+ ptr = (void*)(((intptr_t)ptr + al64) ~al64);
u64 = *((uint64_t*)ptr);
first = 1;
fprintf(fp,0x% PRIx64 [,u64);
@@ -166,13 +168,13 @@ int print_struct(FILE *fp, struct struct_desc *desc, void *data,
break;
case UINT64:
- ptr = (void*)(((intptr_t)ptr + al) ~al);
+ ptr = (void*)(((intptr_t)ptr + al64) ~al64);
u64 = *((uint64_t*)ptr);
fprintf(fp,% PRIu64,u64);
ptr += 8;
break;
case SINT64:
- ptr = (void*)(((intptr_t)ptr + al) ~al);
+ ptr = (void*)(((intptr_t)ptr + al64) ~al64);
s64 = *((int64_t*)ptr);
fprintf(fp,% PRId64,s64);
ptr += 8;
Re: [PATCH] tm6000 fix i2c
Am 23.04.2010 02:48, schrieb Dmitri Belimov:
Hi
Rework I2C for read word from connected devices, now it works well.
Add new functions for read/write blocks.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 05 22:56:43
2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c Fri Apr 23 04:23:03
2010 +1000
@@ -24,6 +24,7 @@
#include linux/kernel.h
#include linux/usb.h
#include linux/i2c.h
+#include linux/delay.h
#include compat.h
#include tm6000.h
@@ -45,11 +46,39 @@
printk(KERN_DEBUG %s at %s: fmt, \
dev-name, __FUNCTION__ , ##args); } while (0)
+static void tm6000_i2c_reset(struct tm6000_core *dev)
+{
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 0);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 1);
+ msleep(15);
+}
+
static int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr,
__u8 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, buf, len);
+ int rc;
+ unsigned int tsleep;
+
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = ((len * 200) + 200 + 1000) / 1000;
+ msleep(tsleep);
+
+ /* release mutex */
+ return rc;
}
/* Generic read - doesn't work fine with 16bit registers */
@@ -59,22 +88,30 @@
int rc;
u8 b[2];
- if ((dev-caps.has_zl10353) (dev-demod_addr 1 == addr) (reg %
2 == 0)) {
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ if ((dev-caps.has_zl10353) (dev-demod_addr 1 == addr)
+ (reg % 2 == 0)) {
/*
* Workaround an I2C bug when reading from zl10353
*/
reg -= 1;
len += 1;
- rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, b, len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, b, len);
*buf = b[1];
} else {
- rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, buf,
len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
}
+ /* release mutex */
return rc;
}
@@ -85,8 +122,106 @@
static int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char
addr,
__u16 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+ int rc;
+ unsigned char ureg;
+
+ if (!buf || len != 2)
+ return -1;
+
+ /* capture mutex */
+ ureg = reg 0xFF;
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | (reg 0xFF00), 0, ureg, 1);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ msleep(1400 / 1000);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
+ reg, 0, buf, len);
+
not all can this request (chip revision 0xf3 and 0xf4 can it)
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* release mutex */
+ return rc;
+}
+
+static int tm6000_i2c_read_sequence(struct tm6000_core *dev, unsigned char
addr,
+ __u16 reg, char *buf, int len)
+{
+ int rc;
+
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
+ reg, 0, buf, len);
ditto
+ /* release mutex */
+ return rc;
+}
+
+static int tm6000_i2c_write_sequence(struct tm6000_core *dev,
+ unsigned
Re: Help needed in understanding v4l2_device_call_all
Am 23.04.2010 04:20, schrieb Bee Hock Goh:
Mauro,
Thanks.
Previously, I have done some limited test and it seem that
xc2028_signal seem to be getting the correct registered value for the
detected a signal locked.
Since I am now able to get video working(though somewhat limited since
it still crashed if i change channel from mythtv), i will be spending
more time to look getting a lock on the signal.
Is line 139,140,155,156 needed? Its slowing down the loading of
firmware and it working for me with the additional register setting.
138 if (addr == dev-tuner_addr 1) {
139 tm6000_set_reg(dev, 0x32, 0,0);
140 tm6000_set_reg(dev, 0x33, 0,0);
use tm6010
141 }
142 if (i2c_debug = 2)
143 for (byte = 0; byte msgs[i].len; byte++)
144 printk( %02x, msgs[i].buf[byte]);
145 } else {
146 /* write bytes */
147 if (i2c_debug = 2)
148 for (byte = 0; byte msgs[i].len; byte++)
149 printk( %02x, msgs[i].buf[byte]);
150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
151 msgs[i].buf + 1, msgs[i].len - 1);
152
153 if (addr == dev-tuner_addr 1) {
154 tm6000_set_reg(dev, 0x32, 0,0);
155 tm6000_set_reg(dev, 0x33, 0,0);
use tm6010
On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Bee Hock Goh wrote:
Hi,
I am trying to understand how the subdev function are triggered when I
use v4l2_device_call_all(dev-v4l2_dev, 0, tuner, g_tuner,t) on
tm600-video.
It calls tuner-core.c code, with g_tuner command. tuner-core
checks what's the used tuner and, in the case of tm6000, calls the
corresponding
function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
The function basically does some sanity checks, and some common tuner code,
but
the actual implementation is handled by some callbacks that the driver needs
to
define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
get_status for it:
fe_tuner_ops-get_status(t-fe, tuner_status);
You will find a good example of how to implement such code at tuner-simple
simple_get_status() function.
In the case of tuner-xc2028, we never found a way for it to properly report
the
status of the tuner lock. That's why this function is not implemented on the
driver.
How am i able to link the callback from the tuner_xc2028 function?
The callback is used by tuner-xc2028 when it detects the need of changing the
firmware (or when the firmware is not loaded yet, or when you select a
standard
that it is not supported by the current firmware).
Basically, xc2028 driver will use the callback that was set previously via:
v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_config, xc2028_cfg);
Please help me to understand or directly me to any documentation that
I can read up?
thanks,
Hock.
--
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
--
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
--
Stefan Ringel stefan.rin...@arcor.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: Help needed in understanding v4l2_device_call_all
So do you mean its required for tm6010 to set the registers?
On Fri, Apr 23, 2010 at 11:23 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
Am 23.04.2010 04:20, schrieb Bee Hock Goh:
Mauro,
Thanks.
Previously, I have done some limited test and it seem that
xc2028_signal seem to be getting the correct registered value for the
detected a signal locked.
Since I am now able to get video working(though somewhat limited since
it still crashed if i change channel from mythtv), i will be spending
more time to look getting a lock on the signal.
Is line 139,140,155,156 needed? Its slowing down the loading of
firmware and it working for me with the additional register setting.
138 if (addr == dev-tuner_addr 1) {
139 tm6000_set_reg(dev, 0x32, 0,0);
140 tm6000_set_reg(dev, 0x33, 0,0);
use tm6010
141 }
142 if (i2c_debug = 2)
143 for (byte = 0; byte msgs[i].len; byte++)
144 printk( %02x, msgs[i].buf[byte]);
145 } else {
146 /* write bytes */
147 if (i2c_debug = 2)
148 for (byte = 0; byte msgs[i].len; byte++)
149 printk( %02x, msgs[i].buf[byte]);
150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
151 msgs[i].buf + 1, msgs[i].len - 1);
152
153 if (addr == dev-tuner_addr 1) {
154 tm6000_set_reg(dev, 0x32, 0,0);
155 tm6000_set_reg(dev, 0x33, 0,0);
use tm6010
On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Bee Hock Goh wrote:
Hi,
I am trying to understand how the subdev function are triggered when I
use v4l2_device_call_all(dev-v4l2_dev, 0, tuner, g_tuner,t) on
tm600-video.
It calls tuner-core.c code, with g_tuner command. tuner-core
checks what's the used tuner and, in the case of tm6000, calls the
corresponding
function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
The function basically does some sanity checks, and some common tuner code,
but
the actual implementation is handled by some callbacks that the driver
needs to
define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
get_status for it:
fe_tuner_ops-get_status(t-fe, tuner_status);
You will find a good example of how to implement such code at tuner-simple
simple_get_status() function.
In the case of tuner-xc2028, we never found a way for it to properly report
the
status of the tuner lock. That's why this function is not implemented on
the driver.
How am i able to link the callback from the tuner_xc2028 function?
The callback is used by tuner-xc2028 when it detects the need of changing
the
firmware (or when the firmware is not loaded yet, or when you select a
standard
that it is not supported by the current firmware).
Basically, xc2028 driver will use the callback that was set previously via:
v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_config,
xc2028_cfg);
Please help me to understand or directly me to any documentation that
I can read up?
thanks,
Hock.
--
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
--
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
--
Stefan Ringel stefan.rin...@arcor.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: Help needed in understanding v4l2_device_call_all
Am 23.04.2010 17:28, schrieb Bee Hock Goh:
So do you mean its required for tm6010 to set the registers?
that is not a register, please see you in lastest git, that this request
a command is (send start and send stop!).
On Fri, Apr 23, 2010 at 11:23 PM, Stefan Ringel stefan.rin...@arcor.de
wrote:
Am 23.04.2010 04:20, schrieb Bee Hock Goh:
Mauro,
Thanks.
Previously, I have done some limited test and it seem that
xc2028_signal seem to be getting the correct registered value for the
detected a signal locked.
Since I am now able to get video working(though somewhat limited since
it still crashed if i change channel from mythtv), i will be spending
more time to look getting a lock on the signal.
Is line 139,140,155,156 needed? Its slowing down the loading of
firmware and it working for me with the additional register setting.
138 if (addr == dev-tuner_addr 1) {
139 tm6000_set_reg(dev, 0x32, 0,0);
140 tm6000_set_reg(dev, 0x33, 0,0);
use tm6010
141 }
142 if (i2c_debug = 2)
143 for (byte = 0; byte msgs[i].len; byte++)
144 printk( %02x, msgs[i].buf[byte]);
145 } else {
146 /* write bytes */
147 if (i2c_debug = 2)
148 for (byte = 0; byte msgs[i].len; byte++)
149 printk( %02x, msgs[i].buf[byte]);
150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
151 msgs[i].buf + 1, msgs[i].len - 1);
152
153 if (addr == dev-tuner_addr 1) {
154 tm6000_set_reg(dev, 0x32, 0,0);
155 tm6000_set_reg(dev, 0x33, 0,0);
use tm6010
On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Bee Hock Goh wrote:
Hi,
I am trying to understand how the subdev function are triggered when I
use v4l2_device_call_all(dev-v4l2_dev, 0, tuner, g_tuner,t) on
tm600-video.
It calls tuner-core.c code, with g_tuner command. tuner-core
checks what's the used tuner and, in the case of tm6000, calls the
corresponding
function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
The function basically does some sanity checks, and some common tuner
code, but
the actual implementation is handled by some callbacks that the driver
needs to
define (get_afc, get_status, is_stereo, has_signal). In general, drivers
use
get_status for it:
fe_tuner_ops-get_status(t-fe, tuner_status);
You will find a good example of how to implement such code at tuner-simple
simple_get_status() function.
In the case of tuner-xc2028, we never found a way for it to properly
report the
status of the tuner lock. That's why this function is not implemented on
the driver.
How am i able to link the callback from the tuner_xc2028 function?
The callback is used by tuner-xc2028 when it detects the need of changing
the
firmware (or when the firmware is not loaded yet, or when you select a
standard
that it is not supported by the current firmware).
Basically, xc2028 driver will use the callback that was set previously via:
v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_config,
xc2028_cfg);
Please help me to understand or directly me to any documentation that
I can read up?
thanks,
Hock.
--
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
--
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
--
Stefan Ringel stefan.rin...@arcor.de
--
Stefan Ringel stefan.rin...@arcor.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
[PATCH] tm6000: renaming firmware
From: Stefan Ringel stefan.rin...@arcor.de renaming tm6000-xc3028.fw to xc3028-v24.fw Signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000-cards.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index f795a3e..d5edc78 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -533,7 +533,7 @@ static void tm6000_config_tuner (struct tm6000_core *dev) if (dev-dev_type == TM6010) ctl.fname = xc3028-v27.fw; else - ctl.fname = tm6000-xc3028.fw; + ctl.fname = xc3028-v24.fw; } printk(KERN_INFO Setting firmware parameters for xc2028\n); -- 1.6.6.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
Re: Please ignore this message
Ricardo Maraschini wrote: Please ignore this message. I've been trying to send a patch to this list since yesterday without success. This message is just to validate my mailing list subscription. You don't need to be subscribed to be able to sending patches, but you need to be sure that you don't have any html attachments on your email, as vger will simply discard anything that it might contain a spam (including html emails). -- 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: Please ignore this message
Hi Mauro, On Fri, Apr 23, 2010 at 2:14 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: You don't need to be subscribed to be able to sending patches, but you need to be sure that you don't have any html attachments on your email, as vger will simply discard anything that it might contain a spam (including html emails). Sorry to make you loose your time. Shame on me... Now I discovered that Majordomo didn't forward the e-mail I sent to my account, only to the other list members... Due to my fault, the patch I sent arrived two times[1] [2] according to patchwork. -rm [1] https://patchwork.kernel.org/patch/94156/ [2] https://patchwork.kernel.org/patch/93688/ -- 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: WARNINGS
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:Fri Apr 23 19:00:18 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14592:b438301e588f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1f96716187774be265c59a713fb570810e3a15c7 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-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK 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-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK 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: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, 2010-04-23 at 14:06 -0400, Jon Smirl wrote: On Fri, Apr 23, 2010 at 1:40 PM, Jarod Wilson ja...@wilsonet.com wrote: So now that I'm more or less done with porting the imon driver, I think I'm ready to start tackling the mceusb driver. But I'm debating on what approach to take with respect to lirc support. It sort of feels like we should have lirc_dev ported as an ir decoder driver/plugin before starting to port mceusb to ir-core, so that we can maintain lirc compat and transmit support. Alternatively, I could port mceusb without lirc support for now, leaving it to only use in-kernel decoding and have no transmit support for the moment, then re-add lirc support. I'm thinking that porting lirc_dev as, say, ir-lirc-decoder first is probably the way to go though. Anyone else want to share their thoughts on this? I'd take whatever you think is the simplest path. It is more likely that initial testers will want to work with the new in-kernel system than the compatibility layer to LIRC. Existing users that are happy with the current LIRC should just keep on using it. Jarod, Not that my commit rate has been 0 LOC lately, but I'd like to see lirc_dev, just to get transmit worked out for the CX23888 chip and cx23885 driver. I think this device will bring to light some assumptions LIRC currently makes about transmit that don't apply to the CX23888 (i.e. LIRC having to perform the pulse timing). The cx23888-ir implementation has a kfifo for holding outgoing pulse data and the hardware itself has an 8 pulse measurement deep fifo. But I'd recommend whatever helps you get more productive work done first. I've had no time for linux lately. 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
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote: So now that I'm more or less done with porting the imon driver, I think I'm ready to start tackling the mceusb driver. But I'm debating on what approach to take with respect to lirc support. It sort of feels like we should have lirc_dev ported as an ir decoder driver/plugin before starting to port mceusb to ir-core, so that we can maintain lirc compat and transmit support. Alternatively, I could port mceusb without lirc support for now, leaving it to only use in-kernel decoding and have no transmit support for the moment, then re-add lirc support. I'm thinking that porting lirc_dev as, say, ir-lirc-decoder first is probably the way to go though. Anyone else want to share their thoughts on this? I think it would make sense to start with a mce driver without the TX and lirc bits first. Adding lirc rx support can be done as a separate raw decoder later (so its scope is outside the mce driver anyway) and TX support is not implemented in ir-core yet and we haven't had any discussion yet on which form it should take. (Actually, while sharing thoughts... Should drivers/media/IR become drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become rc-keytable.c and so on?) It will happen...and on a related note, I still think rc-core should in the end expose an API where drivers create rc devices and the input device(s) are kept as an internal detail in rc-core rather than the way it works now (where drivers create input devices and use ir-core to create a kind of addon device). But that change is about as disruptive as the ir-core - rc-core change, so it can also wait to a more convenient time. -- David Härdeman -- 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 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: Not that my commit rate has been 0 LOC lately, but I'd like to see lirc_dev, just to get transmit worked out for the CX23888 chip and cx23885 driver. I think this device will bring to light some assumptions LIRC currently makes about transmit that don't apply to the CX23888 (i.e. LIRC having to perform the pulse timing). The cx23888-ir implementation has a kfifo for holding outgoing pulse data and the hardware itself has an 8 pulse measurement deep fifo. I think we're eventually going to want to let rc-core create a chardev per rc device to allow for things like reading out scancodes (when creating keymaps for new and unknown remotes), raw timings (for debugging in-kernel decoders and writing new ones), possibly also ioctl's (for e.g. setting all RX parameters in one go or to create/destroy additional keymaps, though I'm sure some will want all of that to go through sysfs). That same chardev could also be used to implement TX, once a suitable interface has been fleshed out. The end result might not look exactly like lirc... -- David Härdeman -- 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
