RE: [PATCH 1/7] v4l: videobuf: rename videobuf_alloc to videobuf_alloc_vb
Mauro: in case you decide to merge this patch and the following one, please add Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com after my sign-off. Thanks! Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Subject: [PATCH 1/7] v4l: videobuf: rename videobuf_alloc to videobuf_alloc_vb From: Pawel Osciak p.osc...@samsung.com These functions allocate videobuf_buffer structures only. Renaming in order to prevent confusion with functions allocating actual video buffer memory. Signed-off-by: Pawel Osciak p.osc...@samsung.com Rename the functions in videobuf-core.h videobuf-dma-sg.c as well. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/videobuf-core.c | 14 +++--- drivers/media/video/videobuf-dma-contig.c |4 ++-- drivers/media/video/videobuf-dma-sg.c |6 +++--- drivers/media/video/videobuf-vmalloc.c|4 ++-- include/media/videobuf-core.h |4 ++-- 5 files changed, 16 insertions(+), 16 deletions(-) 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: [GIT PATCHES FOR 2.6.35] More _fmt to _mbus_fmt conversions
On Monday 10 May 2010 08:42:29 Hans Verkuil wrote: On Sunday 09 May 2010 15:30:24 Hans Verkuil wrote: The following changes since commit 08b8618ac4dbcd05ec1886853b1d865798d26e1d: Devin Heitmueller (1): V4L/DVB: ngene: Add lgdt3303 and mt2131 deps to Kconfig are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git mbus1 Tested with ivtv, cx18, saa7134-empress and pvrusb2. This is the first patch series of driver conversions. These are all pretty trivial and basically just replace enum/try/g/s_fmt with enum/try/g/s_mbus_fmt. There will be two or three more patch series but some need to be reviewed first. The goal is to get rid of enum/try/g/s_fmt in the video ops. It's the wrong API at that level and as long as it is in the video ops people will misuse it. Now that I received the Ack from Guennadi I've also added this patch to the pull request: v4l2-subdev.h: fix enum_mbus_fmt prototype Guennadi: I've changed unsigned to unsigned int. And with Vaibhav's ack I've added those patches as well: tvp514x: do NOT change the std as a side effect tvp514x: make std_list const tvp514x: there is only one supported format, so simplify the code tvp514x: add missing newlines tvp514x: remove obsolete fmt_list tvp514x: simplify try/g/s_fmt handling Regards, Hans Hans Verkuil (21): V4L2 Spec: Improve the VIDIOC_QUERY_DV_PRESET description saa7115: add s_mbus_fmt op cx25840: add support for s_mbus_fmt saa717x: add support for s_mbus_fmt ivtv: convert to use s_mbus_fmt cx18: add s_mbus_fmt support cx18: remove old g/s_fmt from the cx18_av subdev saa7127: remove obsolete g_fmt support saa717x: remove obsolete s_fmt op v4l2-mediabus.h: add two helper functions saa6752hs: add g/s_mbus_fmt support saa7134: convert to use the new mbus API pvrusb2: convert to s_mbus_fmt cx23885: convert to s_mbus_fmt cx231xx: convert to s_mbus_fmt cx24850: remove obsolete g/s_fmt ops saa7115: remove obsolete g/s_fmt ops v4l2-mediabus.h: added V4L2_MBUS_FMT_SGRBG8_1X8 mt9v011: add enum/try/s_mbus_fmt support tvp5150: remove obsolete g/s_fmt ops au8522_decoder: g/s_fmt doesn't do anything: remove. .../DocBook/v4l/vidioc-query-dv-preset.xml |6 +- drivers/media/dvb/frontends/au8522_decoder.c | 26 drivers/media/video/cx18/cx18-av-core.c| 125 +--- drivers/media/video/cx18/cx18-controls.c | 11 +- drivers/media/video/cx18/cx18-ioctl.c |8 +- drivers/media/video/cx231xx/cx231xx-video.c|5 +- drivers/media/video/cx23885/cx23885-video.c|5 +- drivers/media/video/cx25840/cx25840-core.c | 99 +++- drivers/media/video/ivtv/ivtv-controls.c | 10 +- drivers/media/video/ivtv/ivtv-ioctl.c |6 +- drivers/media/video/mt9v011.c | 37 +++--- drivers/media/video/pvrusb2/pvrusb2-hdw.c | 12 +- drivers/media/video/saa7115.c | 19 +-- drivers/media/video/saa7127.c |8 -- drivers/media/video/saa7134/saa6752hs.c| 46 --- drivers/media/video/saa7134/saa7134-empress.c |9 +- drivers/media/video/saa717x.c | 38 --- drivers/media/video/tvp5150.c | 20 --- include/media/v4l2-mediabus.h | 21 19 files changed, 233 insertions(+), 278 deletions(-) -- 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
[PULL] http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan-ci_init-fix
Mauro, Please pull follwing fix: http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan-ci_init-fix Fix kernel Oops when number of NetUP Dual DVB-S2-CI cards more than DVB_MAX_ADAPTERS limit Thanks. -- Abylai Ospan aos...@netup.ru NetUP Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/7] v4l: videobuf: Remove videobuf_mapping start and end fields
Hi,
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
The fields are assigned but never used, remove them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf-dma-contig.c |2 --
drivers/media/video/videobuf-dma-sg.c |2 --
drivers/media/video/videobuf-vmalloc.c|2 --
include/media/videobuf-core.h |2 --
4 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index d87ed21..c5d2552 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -279,8 +279,6 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
*q,
return -ENOMEM;
buf-map = map;
- map-start = vma-vm_start;
- map-end = vma-vm_end;
map-q = q;
buf-baddr = vma-vm_start;
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 8924e51..2d64040 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -608,8 +608,6 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
*q,
}
map-count= 1;
- map-start= vma-vm_start;
- map-end = vma-vm_end;
map-q= q;
vma-vm_ops = videobuf_vm_ops;
vma-vm_flags |= VM_DONTEXPAND | VM_RESERVED;
diff --git a/drivers/media/video/videobuf-vmalloc.c
b/drivers/media/video/videobuf-vmalloc.c
index cf5be6b..f0d7cb8 100644
--- a/drivers/media/video/videobuf-vmalloc.c
+++ b/drivers/media/video/videobuf-vmalloc.c
@@ -245,8 +245,6 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
*q,
return -ENOMEM;
buf-map = map;
- map-start = vma-vm_start;
- map-end = vma-vm_end;
map-q = q;
buf-baddr = vma-vm_start;
diff --git a/include/media/videobuf-core.h b/include/media/videobuf-core.h
index a157cd1..f2c41ce 100644
--- a/include/media/videobuf-core.h
+++ b/include/media/videobuf-core.h
@@ -54,8 +54,6 @@ struct videobuf_queue;
struct videobuf_mapping {
unsigned int count;
- unsigned long start;
- unsigned long end;
struct videobuf_queue *q;
};
--
1.6.4.4
ack, I see no reason to keep them either.
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 7/7] v4l: videobuf: Rename vmalloc fields to vaddr
Hi,
Laurent Pinchart laurent.pinch...@ideasonboard.com
The videobuf_dmabuf and videobuf_vmalloc_memory fields have a vmalloc
field to store the kernel virtual address of vmalloc'ed buffers. Rename
the field to vaddr.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/cx88/cx88-alsa.c |2 +-
drivers/media/video/saa7134/saa7134-alsa.c |2 +-
drivers/media/video/videobuf-dma-sg.c | 18
drivers/media/video/videobuf-vmalloc.c | 30 ++
--
drivers/staging/cx25821/cx25821-alsa.c |2 +-
include/media/videobuf-dma-sg.h|2 +-
include/media/videobuf-vmalloc.h |2 +-
7 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/cx88/cx88-alsa.c
b/drivers/media/video/cx88/cx88-alsa.c
index ebeb9a6..771406f 100644
--- a/drivers/media/video/cx88/cx88-alsa.c
+++ b/drivers/media/video/cx88/cx88-alsa.c
@@ -425,7 +425,7 @@ static int snd_cx88_hw_params(struct snd_pcm_substream *
substream,
chip-buf = buf;
chip-dma_risc = dma;
- substream-runtime-dma_area = chip-dma_risc-vmalloc;
+ substream-runtime-dma_area = chip-dma_risc-vaddr;
substream-runtime-dma_bytes = chip-dma_size;
substream-runtime-dma_addr = 0;
return 0;
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index 5bca2ab..68b7e8d 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -669,7 +669,7 @@ static int snd_card_saa7134_hw_params(struct
snd_pcm_substream * substream,
byte, but it doesn't work. So I allocate the DMA using the
V4L functions, and force ALSA to use that as the DMA area */
- substream-runtime-dma_area = dev-dmasound.dma.vmalloc;
+ substream-runtime-dma_area = dev-dmasound.dma.vaddr;
substream-runtime-dma_bytes = dev-dmasound.bufsize;
substream-runtime-dma_addr = 0;
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 2d64040..06f9a9c 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -211,17 +211,17 @@ int videobuf_dma_init_kernel(struct videobuf_dmabuf
*dma, int direction,
dprintk(1, init kernel [%d pages]\n, nr_pages);
dma-direction = direction;
- dma-vmalloc = vmalloc_32(nr_pages PAGE_SHIFT);
- if (NULL == dma-vmalloc) {
+ dma-vaddr = vmalloc_32(nr_pages PAGE_SHIFT);
+ if (NULL == dma-vaddr) {
dprintk(1, vmalloc_32(%d pages) failed\n, nr_pages);
return -ENOMEM;
}
dprintk(1, vmalloc is at addr 0x%08lx, size=%d\n,
- (unsigned long)dma-vmalloc,
+ (unsigned long)dma-vaddr,
nr_pages PAGE_SHIFT);
- memset(dma-vmalloc, 0, nr_pages PAGE_SHIFT);
+ memset(dma-vaddr, 0, nr_pages PAGE_SHIFT);
dma-nr_pages = nr_pages;
return 0;
@@ -254,8 +254,8 @@ int videobuf_dma_map(struct device *dev, struct
videobuf_dmabuf *dma)
dma-sglist = videobuf_pages_to_sg(dma-pages, dma-nr_pages,
dma-offset);
}
- if (dma-vmalloc) {
- dma-sglist = videobuf_vmalloc_to_sg(dma-vmalloc,
+ if (dma-vaddr) {
+ dma-sglist = videobuf_vmalloc_to_sg(dma-vaddr,
dma-nr_pages);
}
if (dma-bus_addr) {
@@ -319,8 +319,8 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
dma-pages = NULL;
}
- vfree(dma-vmalloc);
- dma-vmalloc = NULL;
+ vfree(dma-vaddr);
+ dma-vaddr = NULL;
if (dma-bus_addr)
dma-bus_addr = 0;
@@ -444,7 +444,7 @@ static void *__videobuf_to_vaddr(struct videobuf_buffer
*buf)
MAGIC_CHECK(mem-magic, MAGIC_SG_MEM);
- return mem-dma.vmalloc;
+ return mem-dma.vaddr;
}
static int __videobuf_iolock(struct videobuf_queue *q,
diff --git a/drivers/media/video/videobuf-vmalloc.c
b/drivers/media/video/videobuf-vmalloc.c
index f0d7cb8..ea08b5d 100644
--- a/drivers/media/video/videobuf-vmalloc.c
+++ b/drivers/media/video/videobuf-vmalloc.c
@@ -102,10 +102,10 @@ static void videobuf_vm_close(struct vm_area_struct
*vma)
called with IRQ's disabled
*/
dprintk(1, %s: buf[%d] freeing (%p)\n,
- __func__, i, mem-vmalloc);
+ __func__, i, mem-vaddr);
- vfree(mem-vmalloc);
- mem-vmalloc = NULL;
+ vfree(mem-vaddr);
+ mem-vaddr = NULL;
}
q-bufs[i]-map = NULL;
@@ -170,7 +170,7
Re: Remote control at Zolid Hybrid TV Tuner
Hi Sander, Am Samstag, den 08.05.2010, 16:12 +0200 schrieb Sander Pientka: Hi Hermann, I am going to revive this old thread, I completely forgot about it and I still want to solve this problem. Yes, with the IR transmitter not plugged in, the gpio is reported as 0 by dmesg. I am aware there is a picture of the backside missing on the wiki, I will try to make one a.s.a.p. NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c. Besides, dmesg outputs a section of error messages I don't understand: [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 1585.548229] tda18271_toggle_output: error -5 on line 47 [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 1585.720129] tda18271_init: error -5 on line 826 [ 1585.720136] tda18271_tune: error -5 on line 904 [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041 [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1, i2c_transfer returned: -5 [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1, i2c_transfer returned: -5 [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1, i2c_transfer returned: -5 [ 1586.629458] tda18271_channel_configuration: error -5 on line 160 [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041 Do you have any idea about the origin of these errors? Do you think they affect the IR functionality? you are still welcome with such delayed reports. But I don't have any influence anymore, how such are treated. For the tda18271 stuff, you must be on latest and Michael Krufky should take it on. For to be on latest, I also can't give any advice anymore. For the IR/remote stuff, try with Mauro and all others working through. Cheers, Hermann -- Sander Pientka 2010/2/17 hermann pitton hermann-pit...@arcor.de: Hi, Am Mittwoch, den 17.02.2010, 17:38 +0100 schrieb Sander Pientka: Thanks for your answer. If I understand you correctly, I should disattach the IR receiver, which is a cable with a diode at the end? It is plugged in to a port like the green one for audio. did you remove the copy to the list by will? Then I will not complain about top posting here ;) I think we have only a photo of the frontside of that card. One line from the IR input connector vanishes to the backside. If on the backside is not a dedicated IR controller chip, gpio18 might be in use for the remote. This gpio is capable of triggering IRQs and is also connected to the clock. On recent Asus saa713x cards it is used for some RC5 protocol derived from those IRQs, gpio18 is the up/down button and the only changing gpio pin concerning the remote. That pin goes low, if the receiver is not plugged on the Asus cards. Mauro recently added also support for NEC IR protocol also on that gpio. You should be able to track rc5 and nec support from the mercurial/cvs interface or from the lists. Maybe it gets you started. Cheers, Hermann 2010/2/17 hermann pitton hermann-pit...@arcor.de: Hi Sander, Am Dienstag, den 16.02.2010, 20:16 +0100 schrieb Sander Pientka: Hi, my Zolid Hybrid TV Tuner has been working like a charm for over two months now. The remote control is not working though, which is a showstopper. I don't have experience with remote controls in any kind, I've heard of LIRC but I would rather choose a more elegant solution, for instance evdev in X11. It's wiki page: http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner gpio init of your board is reported as 0x24. So gpio18/0x4 is high. Assuming the IR receiver is plugged during that, unplug it on next boot and see if gpio init is now only 0x20. 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: [PATCH 03/15] [RFC] Documentation: add v4l2-controls.txt documenting the new controls API.
Hi Hans, Hans Verkuil wrote: [clip] Should't v4l2_ctrl_new_std take a control type as well ? The type is set automatically as that is determined by the control ID. What about hardware for which the boundaries are only known at runtime, or could depend on the values of other controls ? I'm thinking about UVC devices for instance, the boundaries, step and default values need to be retrieved from the hardware. I currently do that at runtime when the control is queried for the first time and cache the values, as doing it during initialization (probe function) crashes a few webcams. That doesn't seem to be possible with the control framework. It is possible to add controls to an existing control handler at runtime. It is also possible to change boundaries at runtime: you just change the relevant values in v4l2_ctrl. There is no function for that, it's enough to call v4l2_ctrl_lock(), change the values and call unlock(). I could make a function that does this, but UVC is the only driver that I know of that might need this. It won't be for long. Think of the sensor drivers, for example. The maximum exposure time (often expressed in lines) is dependent on the active sensor area (lines) plus vertical blanking. I'd assume the active area to be selected in other ways than using controls, however. The vertical blanking, though, also affects the frame rate, and thus available exposure time. Not quite sure whether the user should be left to touch the vertical blanking directly. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: [PATCH 7/7] v4l: videobuf: Rename vmalloc fields to vaddr
On Tue, May 11, 2010 at 9:36 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
The videobuf_dmabuf and videobuf_vmalloc_memory fields have a vmalloc
field to store the kernel virtual address of vmalloc'ed buffers. Rename
the field to vaddr.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/cx88/cx88-alsa.c | 2 +-
drivers/media/video/saa7134/saa7134-alsa.c | 2 +-
drivers/media/video/videobuf-dma-sg.c | 18
drivers/media/video/videobuf-vmalloc.c | 30
++--
drivers/staging/cx25821/cx25821-alsa.c | 2 +-
include/media/videobuf-dma-sg.h | 2 +-
include/media/videobuf-vmalloc.h | 2 +-
7 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/cx88/cx88-alsa.c
b/drivers/media/video/cx88/cx88-alsa.c
index ebeb9a6..771406f 100644
--- a/drivers/media/video/cx88/cx88-alsa.c
+++ b/drivers/media/video/cx88/cx88-alsa.c
@@ -425,7 +425,7 @@ static int snd_cx88_hw_params(struct snd_pcm_substream *
substream,
chip-buf = buf;
chip-dma_risc = dma;
- substream-runtime-dma_area = chip-dma_risc-vmalloc;
+ substream-runtime-dma_area = chip-dma_risc-vaddr;
substream-runtime-dma_bytes = chip-dma_size;
substream-runtime-dma_addr = 0;
return 0;
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index 5bca2ab..68b7e8d 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -669,7 +669,7 @@ static int snd_card_saa7134_hw_params(struct
snd_pcm_substream * substream,
byte, but it doesn't work. So I allocate the DMA using the
V4L functions, and force ALSA to use that as the DMA area */
- substream-runtime-dma_area = dev-dmasound.dma.vmalloc;
+ substream-runtime-dma_area = dev-dmasound.dma.vaddr;
substream-runtime-dma_bytes = dev-dmasound.bufsize;
substream-runtime-dma_addr = 0;
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 2d64040..06f9a9c 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -211,17 +211,17 @@ int videobuf_dma_init_kernel(struct videobuf_dmabuf
*dma, int direction,
dprintk(1, init kernel [%d pages]\n, nr_pages);
dma-direction = direction;
- dma-vmalloc = vmalloc_32(nr_pages PAGE_SHIFT);
- if (NULL == dma-vmalloc) {
+ dma-vaddr = vmalloc_32(nr_pages PAGE_SHIFT);
+ if (NULL == dma-vaddr) {
dprintk(1, vmalloc_32(%d pages) failed\n, nr_pages);
return -ENOMEM;
}
dprintk(1, vmalloc is at addr 0x%08lx, size=%d\n,
- (unsigned long)dma-vmalloc,
+ (unsigned long)dma-vaddr,
nr_pages PAGE_SHIFT);
- memset(dma-vmalloc, 0, nr_pages PAGE_SHIFT);
+ memset(dma-vaddr, 0, nr_pages PAGE_SHIFT);
dma-nr_pages = nr_pages;
return 0;
@@ -254,8 +254,8 @@ int videobuf_dma_map(struct device *dev, struct
videobuf_dmabuf *dma)
dma-sglist = videobuf_pages_to_sg(dma-pages, dma-nr_pages,
dma-offset);
}
- if (dma-vmalloc) {
- dma-sglist = videobuf_vmalloc_to_sg(dma-vmalloc,
+ if (dma-vaddr) {
+ dma-sglist = videobuf_vmalloc_to_sg(dma-vaddr,
dma-nr_pages);
}
if (dma-bus_addr) {
@@ -319,8 +319,8 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
dma-pages = NULL;
}
- vfree(dma-vmalloc);
- dma-vmalloc = NULL;
+ vfree(dma-vaddr);
+ dma-vaddr = NULL;
if (dma-bus_addr)
dma-bus_addr = 0;
@@ -444,7 +444,7 @@ static void *__videobuf_to_vaddr(struct videobuf_buffer
*buf)
MAGIC_CHECK(mem-magic, MAGIC_SG_MEM);
- return mem-dma.vmalloc;
+ return mem-dma.vaddr;
}
static int __videobuf_iolock(struct videobuf_queue *q,
diff --git a/drivers/media/video/videobuf-vmalloc.c
b/drivers/media/video/videobuf-vmalloc.c
index f0d7cb8..ea08b5d 100644
--- a/drivers/media/video/videobuf-vmalloc.c
+++ b/drivers/media/video/videobuf-vmalloc.c
@@ -102,10 +102,10 @@ static void videobuf_vm_close(struct vm_area_struct
*vma)
called with IRQ's disabled
*/
dprintk(1, %s: buf[%d] freeing (%p)\n,
- __func__, i, mem-vmalloc);
+ __func__, i, mem-vaddr);
- vfree(mem-vmalloc);
- mem-vmalloc = NULL;
+
[PATCH] [budget] Wrong code on init failure
In frontend_init you can read:
if (budget-dvb_frontend) {
ctl = dvb_attach(stv6110x_attach,
budget-dvb_frontend,
tt1600_stv6110x_config,
budget-i2c_adap);
tt1600_stv090x_config.tuner_init = ctl-tuner_init;
[...]
} else {
dvb_frontend_detach(budget-dvb_frontend);
budget-dvb_frontend = NULL;
}
But if we are in else, budget-dvb_frontend is already NULL...
I guess the else part could better apply to a test on ctl before using
it
---
drivers/media/dvb/ttpci/budget.c | 39 +++--
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index 9fdf26c..14adf27 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -627,25 +627,26 @@ static void frontend_init(struct budget *budget)
tt1600_stv6110x_config,
budget-i2c_adap);
- tt1600_stv090x_config.tuner_init =
ctl-tuner_init;
- tt1600_stv090x_config.tuner_set_mode =
ctl-tuner_set_mode;
- tt1600_stv090x_config.tuner_set_frequency =
ctl-tuner_set_frequency;
- tt1600_stv090x_config.tuner_get_frequency =
ctl-tuner_get_frequency;
- tt1600_stv090x_config.tuner_set_bandwidth =
ctl-tuner_set_bandwidth;
- tt1600_stv090x_config.tuner_get_bandwidth =
ctl-tuner_get_bandwidth;
- tt1600_stv090x_config.tuner_set_bbgain=
ctl-tuner_set_bbgain;
- tt1600_stv090x_config.tuner_get_bbgain=
ctl-tuner_get_bbgain;
- tt1600_stv090x_config.tuner_set_refclk=
ctl-tuner_set_refclk;
- tt1600_stv090x_config.tuner_get_status=
ctl-tuner_get_status;
-
- dvb_attach(isl6423_attach,
- budget-dvb_frontend,
- budget-i2c_adap,
- tt1600_isl6423_config);
-
- } else {
- dvb_frontend_detach(budget-dvb_frontend);
- budget-dvb_frontend = NULL;
+ if (ctl) {
+ tt1600_stv090x_config.tuner_init
= ctl-tuner_init;
+ tt1600_stv090x_config.tuner_set_mode
= ctl-tuner_set_mode;
+
tt1600_stv090x_config.tuner_set_frequency = ctl-tuner_set_frequency;
+
tt1600_stv090x_config.tuner_get_frequency = ctl-tuner_get_frequency;
+
tt1600_stv090x_config.tuner_set_bandwidth = ctl-tuner_set_bandwidth;
+
tt1600_stv090x_config.tuner_get_bandwidth = ctl-tuner_get_bandwidth;
+ tt1600_stv090x_config.tuner_set_bbgain
= ctl-tuner_set_bbgain;
+ tt1600_stv090x_config.tuner_get_bbgain
= ctl-tuner_get_bbgain;
+ tt1600_stv090x_config.tuner_set_refclk
= ctl-tuner_set_refclk;
+ tt1600_stv090x_config.tuner_get_status
= ctl-tuner_get_status;
+
+ dvb_attach(isl6423_attach,
+ budget-dvb_frontend,
+ budget-i2c_adap,
+ tt1600_isl6423_config);
+ } else {
+
dvb_frontend_detach(budget-dvb_frontend);
+ budget-dvb_frontend = NULL;
+ }
}
}
break;
--
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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed May 12 19:00:27 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14787:8c2b24dbe205 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 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: ERRORS linux-2.6.33-armv5: OK linux-2.6.34-rc7-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc7-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc7-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc7-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: OK linux-2.6.34-rc7-i686: ERRORS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: OK linux-2.6.34-rc7-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: OK linux-2.6.34-rc7-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: OK linux-2.6.34-rc7-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: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: OK linux-2.6.34-rc7-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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
[PATCH] checkstack fixes for drivers/media/dvb
When compiling 2.6.34-rc7 I see the following warnings
drivers/media/dvb/frontends/dib3000mc.c: In function
'dib3000mc_i2c_enumeration':
drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2224
bytes is larger than 2048 bytes
drivers/media/dvb/frontends/dib7000p.c: In function 'dib7000p_i2c_enumeration':
drivers/media/dvb/frontends/dib7000p.c:1346: warning: the frame size of 2304
bytes is larger than 2048 bytes
because the dib*_state structs are large and they are alloc'd on the stack.
This patch moves the structures off the stack.
I also noticed that the cxusb driver doesn't check the return value from
dib7000p_i2c_enumeration().
Signed-off-by: Prarit Bhargava pra...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/cxusb.c
b/drivers/media/dvb/dvb-usb/cxusb.c
index 960376d..8141b10 100644
--- a/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/drivers/media/dvb/dvb-usb/cxusb.c
@@ -1025,8 +1025,11 @@ static int cxusb_dualdig4_rev2_frontend_attach(struct
dvb_usb_adapter *adap)
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
- dib7000p_i2c_enumeration(adap-dev-i2c_adap, 1, 18,
-cxusb_dualdig4_rev2_config);
+ if (dib7000p_i2c_enumeration(adap-dev-i2c_adap, 1, 18,
+cxusb_dualdig4_rev2_config)) {
+ printk(KERN_WARNING Unable to enumerate dib7000p\n);
+ return -ENODEV;
+ }
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap, 0x80,
cxusb_dualdig4_rev2_config);
diff --git a/drivers/media/dvb/frontends/dib3000mc.c
b/drivers/media/dvb/frontends/dib3000mc.c
index 40a0998..6a178f1 100644
--- a/drivers/media/dvb/frontends/dib3000mc.c
+++ b/drivers/media/dvb/frontends/dib3000mc.c
@@ -814,42 +814,52 @@ EXPORT_SYMBOL(dib3000mc_set_config);
int dib3000mc_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8
default_addr, struct dib3000mc_config cfg[])
{
- struct dib3000mc_state st = { .i2c_adap = i2c };
+ struct dib3000mc_state *st;
int k;
u8 new_addr;
-
static u8 DIB3000MC_I2C_ADDRESS[] = {20,22,24,26};
+ st = kzalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+ st-i2c_adap = i2c;
+
for (k = no_of_demods-1; k = 0; k--) {
- st.cfg = cfg[k];
+ st-cfg = cfg[k];
/* designated i2c address */
- new_addr = DIB3000MC_I2C_ADDRESS[k];
- st.i2c_addr = new_addr;
- if (dib3000mc_identify(st) != 0) {
- st.i2c_addr = default_addr;
- if (dib3000mc_identify(st) != 0) {
- dprintk(-E- DiB3000P/MC #%d: not
identified\n, k);
+ new_addr = DIB3000MC_I2C_ADDRESS[k];
+ st-i2c_addr = new_addr;
+ if (dib3000mc_identify(st) != 0) {
+ st-i2c_addr = default_addr;
+ if (dib3000mc_identify(st) != 0) {
+ dprintk(-E- DiB3000P/MC #%d: not
+identified\n, k);
+ kfree(st);
return -ENODEV;
}
}
- dib3000mc_set_output_mode(st, OUTMODE_MPEG2_PAR_CONT_CLK);
+ dib3000mc_set_output_mode(st, OUTMODE_MPEG2_PAR_CONT_CLK);
- // set new i2c address and force divstr (Bit 1) to value 0 (Bit
0)
- dib3000mc_write_word(st, 1024, (new_addr 3) | 0x1);
- st.i2c_addr = new_addr;
+ /* set new i2c address and force divstr (Bit 1) to
+* value 0 (Bit 0)
+*/
+ dib3000mc_write_word(st, 1024, (new_addr 3) | 0x1);
+ st-i2c_addr = new_addr;
}
for (k = 0; k no_of_demods; k++) {
- st.cfg = cfg[k];
- st.i2c_addr = DIB3000MC_I2C_ADDRESS[k];
+ st-cfg = cfg[k];
+ st-i2c_addr = DIB3000MC_I2C_ADDRESS[k];
- dib3000mc_write_word(st, 1024, st.i2c_addr 3);
+ dib3000mc_write_word(st, 1024, st-i2c_addr 3);
/* turn off data output */
- dib3000mc_set_output_mode(st, OUTMODE_HIGH_Z);
+ dib3000mc_set_output_mode(st, OUTMODE_HIGH_Z);
}
+
+ kfree(st);
return 0;
}
EXPORT_SYMBOL(dib3000mc_i2c_enumeration);
diff --git a/drivers/media/dvb/frontends/dib7000p.c
b/drivers/media/dvb/frontends/dib7000p.c
index 85468a4..08ea982 100644
--- a/drivers/media/dvb/frontends/dib7000p.c
+++ b/drivers/media/dvb/frontends/dib7000p.c
@@ -1322,48 +1322,59 @@ int dib7000p_pid_filter(struct dvb_frontend *fe, u8 id,
u16 pid, u8 onoff)
}
EXPORT_SYMBOL(dib7000p_pid_filter);
-int dib7000p_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8
default_addr, struct dib7000p_config cfg[])
Re: Remote control at Zolid Hybrid TV Tuner
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better approach
is to start using raw_decode mode. I've enabled it only for Avermedia M135A,
since this is the board I'm using at the IR refactoring tests, but the same
approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For
GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1),
and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the
most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the wiki
page. Feel
free to improve it, if needed.
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
zvbi-atsc-cc accurate time-stamping
Hi Everyone, I have Hauppauge HVR-1850 cards working in digital mode. I need separate recordings of the video/audio file (mpeg2) and the closed captioning (plain text). I can capture a plain mpeg stream by issing this in one console: * azap -r KOCE-HD And this in a second console: * cat /dev/dvb/adapter0/dvr0 test-cat3.mpeg I tested this file and it plays fine. To generate the closed captioning, I feed this file into zvbi-atsc-cc: * zvbi-atsc-cc --atsc -c KCAL-HD -T test-cat3.mpeg KCAL-HD being the the channel in my channels.conf that I captured from. The problem: I need accurate time stamps. Normally, I add the time stamps during capture, so they match reality. If I get the closed captioning from a file, the information is still in the file (I just need to set the start time), but how do I get that information out? Our system relies on the time stamps in the closed captioning to cue the video, so they need to be accurate. One-second accuracy is adequate, so if I can get the STT information from the PSIP info, that would be good enough. I'm using an off-air signal, so these are ATSC 8VSB channels: LA18.8:49700:8VSB:161:164:8 KBEH-DT:53300:8VSB:49:52:1 KCET-HD:55700:8VSB:49:52:1 A typical closed captioning file should end up looking like this: 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:02 % Communication Studies Archive, UCLA % 87e70c70-5614-11df-b2f7-00e0815fe826 % Video length 0:59:54.024 % Christiane Amanpour 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:12 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:22 A HIGH STAKES INVESTIGATION IS STARTED AFTER A CAR BOMB IS 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:32 FOUND IN NEW YORK'S TIMES SQUARE. WHO WANTED TO ATTACK THE CROSSROADS OF THE WORLD AND WHY. PRESIDENT OBAMA HEADS TO THE GULF COAST FOR A FIRSTHAND LOOK 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:42 AT DESPERATE EFFORTS TO MAINTAIN AN OIL SPILL. -- in other words, a time stamp every ten seconds, which is then used by our search engine to link to the video. The header (%) is added afterward. Ideally for us, then, I would get the STT stamp at ten-second intervals inserted into the closed captioning file. Are there command-line Linux tools for reading PSIP? (There are also other possible uses of PSIP. xds information is too unreliable and inconsistent for us to use, but if PSIP is reliable, I'd like to use it to verify that I'm getting the recording I intended to get (channel and program name). I could potentially use this information to crop the video to the exact program -- but it would have to be reliable enough to be automated, I don't have staff to do anything manual with individual recordings.) Alternatively, Devin Heitmueller advises that there is also the PTS (presentation timestamp), which should be pretty easy to modify zlib-atsc-cc to show. Since the PTS can be used to synchronize the video to the CC info is it possible to make a small modification to zvbi-atsc-cc to log the CC info with the PTS, and then write a really simple utility to seek to a given PTS and play the video? Could someone help me out with accurate timestamps in relation to PSIP info and PTS? Warm wishes, Sonny -- 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/3] mx25: add support for the CSI device
On Thu, 6 May 2010, Baruch Siach wrote:
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
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/mx25.h |2 ++
4 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx25/clock.c b/arch/arm/mach-mx25/clock.c
index 1550149..7a98d18 100644
--- a/arch/arm/mach-mx25/clock.c
+++ b/arch/arm/mach-mx25/clock.c
@@ -129,6 +129,11 @@ static unsigned long get_rate_lcdc(struct clk *clk)
return get_rate_per(7);
}
+static unsigned long get_rate_csi(struct clk *clk)
+{
+ return get_rate_per(0);
+}
+
static unsigned long get_rate_otg(struct clk *clk)
{
return 4800; /* FIXME */
@@ -174,6 +179,8 @@ DEFINE_CLOCK(cspi3_clk, 0, CCM_CGCR1, 7, get_rate_ipg,
NULL, NULL);
DEFINE_CLOCK(fec_ahb_clk, 0, CCM_CGCR0, 23, NULL, NULL, NULL);
DEFINE_CLOCK(lcdc_ahb_clk, 0, CCM_CGCR0, 24, NULL,NULL, NULL);
DEFINE_CLOCK(lcdc_per_clk, 0, CCM_CGCR0, 7, NULL,NULL, lcdc_ahb_clk);
+DEFINE_CLOCK(csi_ahb_clk, 0, CCM_CGCR0, 18, get_rate_csi, NULL, NULL);
+DEFINE_CLOCK(csi_per_clk, 0, CCM_CGCR0, 0, get_rate_csi, NULL, csi_ahb_clk);
DEFINE_CLOCK(uart1_clk, 0, CCM_CGCR2, 14, get_rate_uart, NULL,
uart_per_clk);
DEFINE_CLOCK(uart2_clk, 0, CCM_CGCR2, 15, get_rate_uart, NULL,
uart_per_clk);
DEFINE_CLOCK(uart3_clk, 0, CCM_CGCR2, 16, get_rate_uart, NULL,
uart_per_clk);
@@ -191,6 +198,7 @@ DEFINE_CLOCK(i2c_clk, 0, CCM_CGCR0, 6,
get_rate_i2c, NULL, NULL);
DEFINE_CLOCK(fec_clk, 0, CCM_CGCR1, 15, get_rate_ipg, NULL,
fec_ahb_clk);
DEFINE_CLOCK(dryice_clk, 0, CCM_CGCR1, 8, get_rate_ipg, NULL, NULL);
DEFINE_CLOCK(lcdc_clk,0, CCM_CGCR1, 29, get_rate_lcdc, NULL,
lcdc_per_clk);
+DEFINE_CLOCK(csi_clk,0, CCM_CGCR1, 4, get_rate_csi, NULL,
csi_per_clk);
#define _REGISTER_CLOCK(d, n, c) \
{ \
@@ -225,6 +233,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK(fec.0, NULL, fec_clk)
_REGISTER_CLOCK(imxdi_rtc.0, NULL, dryice_clk)
_REGISTER_CLOCK(imx-fb.0, NULL, lcdc_clk)
+ _REGISTER_CLOCK(mx2-camera.0, NULL, csi_clk)
};
int __init mx25_clocks_init(void)
@@ -239,8 +248,9 @@ int __init mx25_clocks_init(void)
__raw_writel((0xf 16) | (3 26), CRM_BASE + CCM_CGCR1);
__raw_writel((1 5), CRM_BASE + CCM_CGCR2);
- /* Clock source for lcdc is upll */
- __raw_writel(__raw_readl(CRM_BASE+0x64) | (1 7), CRM_BASE + 0x64);
+ /* Clock source for lcdc and csi is upll */
+ __raw_writel(__raw_readl(CRM_BASE+0x64) | (1 7) | (1 0),
+ CRM_BASE + 0x64);
mxc_timer_init(gpt_clk, MX25_IO_ADDRESS(MX25_GPT1_BASE_ADDR), 54);
diff --git a/arch/arm/mach-mx25/devices.c b/arch/arm/mach-mx25/devices.c
index 3f4b8a0..bc6d189 100644
--- a/arch/arm/mach-mx25/devices.c
+++ b/arch/arm/mach-mx25/devices.c
@@ -500,3 +500,25 @@ struct platform_device mx25_fb_device = {
.coherent_dma_mask = 0x,
},
};
+
+static struct resource mx25_csi_resources[] = {
+ {
+ .start = MX25_CSI_BASE_ADDR,
+ .end= MX25_CSI_BASE_ADDR + 0xfff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MX25_INT_CSI,
+ .flags = IORESOURCE_IRQ
Please, also specify .end (= .start).
+ },
+};
+
+struct platform_device mx25_csi_device = {
+ .name = mx2-camera,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mx25_csi_resources),
+ .resource = mx25_csi_resources,
+ .dev= {
+ .coherent_dma_mask = 0x,
+ },
+};
diff --git a/arch/arm/mach-mx25/devices.h b/arch/arm/mach-mx25/devices.h
index 39560e1..1e80ac2 100644
--- a/arch/arm/mach-mx25/devices.h
+++ b/arch/arm/mach-mx25/devices.h
@@ -21,3 +21,4 @@ extern struct platform_device mx25_fec_device;
extern struct platform_device mxc_nand_device;
extern struct platform_device mx25_rtc_device;
extern struct platform_device mx25_fb_device;
+extern struct platform_device mx25_csi_device;
diff --git a/arch/arm/plat-mxc/include/mach/mx25.h
b/arch/arm/plat-mxc/include/mach/mx25.h
index 4eb6e33..5e6a8b5 100644
--- a/arch/arm/plat-mxc/include/mach/mx25.h
+++ b/arch/arm/plat-mxc/include/mach/mx25.h
@@ -34,11 +34,13 @@
#define MX25_NFC_BASE_ADDR 0xbb00
#define MX25_DRYICE_BASE_ADDR0x53ffc000
#define MX25_LCDC_BASE_ADDR 0x53fbc000
+#define MX25_CSI_BASE_ADDR 0x53ff8000
#define MX25_INT_DRYICE 25
#define MX25_INT_FEC 57
#define MX25_INT_NANDFC 33
#define MX25_INT_LCDC39
+#define MX25_INT_CSI 17
#if defined(IMX_NEEDS_DEPRECATED_SYMBOLS)
#define UART1_BASE_ADDR MX25_UART1_BASE_ADDR
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/ngene2
Hello Devin/Mauro, On Fri, May 7, 2010 at 11:52 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Devin Heitmueller wrote: Hello, Please PULL from http://kernellabs.com/hg/~dheitmueller/ngene2 for the following: Hi Devin, As agreed via IRC with you and stoth, I'm applying all patches, except for the ones that are currently creating unused files at the building system. Let's apply them after you have added some code running there. ngene: properly support boards where channel 0 isn't a TS input ngene: add initial support for digital side of Avermedia m780 ngene: split out i2c code into a separate file Committed. ngene: split out card specific code into a separate file ngene: split out DVB audio/video into a separate file Not merged: it just creates a file with currently unused code. ngene: move more card-specific code to ngene-cards.c This patch were folded with ngene: split out card specific code into a separate file. ngene: split out eeprom functions int a separate file ngene: move a few more DVB a/v related functions Not merged: they just create a file with currently unused code. ngene: start separating out DVB functions into separate file Committed, with a few trivial conflict resolving changes, caused by not merging the 3 previous patches. ngene: Add lgdt3303 and mt2131 deps to Kconfig Committed. I've stored locally the rebased diffs for the non-applied patches. So, on your next ngene pull, you won't need to rebase against my git. It should also be noticed that I needed to apply one patch before your series, in order to fix those compilation errors: drivers/media/dvb/ngene/ngene-cards.c:42:20: error: mt2131.h: Arquivo ou diretório não encontrado drivers/media/dvb/ngene/ngene-cards.c:111: error: variable ‘m780_tunerconfig’ has initializer but incomplete type drivers/media/dvb/ngene/ngene-cards.c:113: warning: excess elements in struct initializer drivers/media/dvb/ngene/ngene-cards.c:113: warning: (near initialization for ‘m780_tunerconfig’) drivers/media/dvb/ngene/ngene-cards.c: In function ‘demod_attach_lg330x’: drivers/media/dvb/ngene/ngene-cards.c:126: error: ‘mt2131_attach’ undeclared (first use in this function) drivers/media/dvb/ngene/ngene-cards.c:126: error: (Each undeclared identifier is reported only once drivers/media/dvb/ngene/ngene-cards.c:126: error: for each function it appears in.) drivers/media/dvb/ngene/ngene-cards.c:126: warning: type defaults to ‘int’ in declaration of ‘__a’ drivers/media/dvb/ngene/ngene-cards.c:126: warning: type defaults to ‘int’ in declaration of ‘type name’ drivers/media/dvb/ngene/ngene-cards.c:126: warning: type defaults to ‘int’ in declaration of ‘type name’ drivers/media/dvb/ngene/ngene-cards.c:126: error: called object ‘__a’ is not a function The fix were to just add the proper tuner include directory: --- a/drivers/media/dvb/ngene/Makefile +++ b/drivers/media/dvb/ngene/Makefile @@ -8,4 +8,4 @@ obj-$(CONFIG_DVB_NGENE) += ngene.o EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/ EXTRA_CFLAGS += -Idrivers/media/dvb/frontends/ - +EXTRA_CFLAGS += -Idrivers/media/common/tuners/ Douglas, It seems to me that the better option is if you just pull from ngene2 tree at hg. This will produce a small diff between -git and -hg, but, as according with Devin, they'll send soon an update on ngene driver adding some working code for eeprom and ngene-av, it should probably be ok for you to handle this difference for a couple weeks, especially since it won't produce any runtime difference. Of course, it is up to you to decide, as you're the maintainer of the backport tree ;) I have merged all patches from http://kernellabs.com/hg/~dheitmueller/ngene2. Cheers, Douglas -- 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] checkstack fixes for drivers/media/dvb
Prarit Bhargava wrote:
When compiling 2.6.34-rc7 I see the following warnings
drivers/media/dvb/frontends/dib3000mc.c: In function
'dib3000mc_i2c_enumeration':
drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2224
bytes is larger than 2048 bytes
drivers/media/dvb/frontends/dib7000p.c: In function
'dib7000p_i2c_enumeration':
drivers/media/dvb/frontends/dib7000p.c:1346: warning: the frame size of 2304
bytes is larger than 2048 bytes
because the dib*_state structs are large and they are alloc'd on the stack.
This patch moves the structures off the stack.
Hi Prarit,
Thanks for the patch, but I've received two patches to fix the same thing some
time ago.
Unfortunately, it took a long time to be merged, since I was waiting for the
driver
maintainer's ack. It is at those changesets:
http://git.linuxtv.org/v4l-dvb.git?a=commit;h=65483f7e5f3e169ea038de26068395231dd3b13b
http://git.linuxtv.org/v4l-dvb.git?a=commit;h=370c0cb185d4fccfb2c66fbe94b48579d4c5fa1c
I also noticed that the cxusb driver doesn't check the return value from
dib7000p_i2c_enumeration().
Randy's patch also added a test for it, but without the warning printk. It may
be a good
idea to have that warning. So, please be free to send it as a separate patch if
you also
think so.
Signed-off-by: Prarit Bhargava pra...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/cxusb.c
b/drivers/media/dvb/dvb-usb/cxusb.c
index 960376d..8141b10 100644
--- a/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/drivers/media/dvb/dvb-usb/cxusb.c
@@ -1025,8 +1025,11 @@ static int cxusb_dualdig4_rev2_frontend_attach(struct
dvb_usb_adapter *adap)
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
- dib7000p_i2c_enumeration(adap-dev-i2c_adap, 1, 18,
- cxusb_dualdig4_rev2_config);
+ if (dib7000p_i2c_enumeration(adap-dev-i2c_adap, 1, 18,
+ cxusb_dualdig4_rev2_config)) {
+ printk(KERN_WARNING Unable to enumerate dib7000p\n);
+ return -ENODEV;
+ }
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap, 0x80,
cxusb_dualdig4_rev2_config);
diff --git a/drivers/media/dvb/frontends/dib3000mc.c
b/drivers/media/dvb/frontends/dib3000mc.c
index 40a0998..6a178f1 100644
--- a/drivers/media/dvb/frontends/dib3000mc.c
+++ b/drivers/media/dvb/frontends/dib3000mc.c
@@ -814,42 +814,52 @@ EXPORT_SYMBOL(dib3000mc_set_config);
int dib3000mc_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8
default_addr, struct dib3000mc_config cfg[])
{
- struct dib3000mc_state st = { .i2c_adap = i2c };
+ struct dib3000mc_state *st;
int k;
u8 new_addr;
-
static u8 DIB3000MC_I2C_ADDRESS[] = {20,22,24,26};
+ st = kzalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+ st-i2c_adap = i2c;
+
for (k = no_of_demods-1; k = 0; k--) {
- st.cfg = cfg[k];
+ st-cfg = cfg[k];
/* designated i2c address */
- new_addr = DIB3000MC_I2C_ADDRESS[k];
- st.i2c_addr = new_addr;
- if (dib3000mc_identify(st) != 0) {
- st.i2c_addr = default_addr;
- if (dib3000mc_identify(st) != 0) {
- dprintk(-E- DiB3000P/MC #%d: not
identified\n, k);
+ new_addr = DIB3000MC_I2C_ADDRESS[k];
+ st-i2c_addr = new_addr;
+ if (dib3000mc_identify(st) != 0) {
+ st-i2c_addr = default_addr;
+ if (dib3000mc_identify(st) != 0) {
+ dprintk(-E- DiB3000P/MC #%d: not
+ identified\n, k);
+ kfree(st);
return -ENODEV;
}
}
- dib3000mc_set_output_mode(st, OUTMODE_MPEG2_PAR_CONT_CLK);
+ dib3000mc_set_output_mode(st, OUTMODE_MPEG2_PAR_CONT_CLK);
- // set new i2c address and force divstr (Bit 1) to value 0 (Bit
0)
- dib3000mc_write_word(st, 1024, (new_addr 3) | 0x1);
- st.i2c_addr = new_addr;
+ /* set new i2c address and force divstr (Bit 1) to
+ * value 0 (Bit 0)
+ */
+ dib3000mc_write_word(st, 1024, (new_addr 3) | 0x1);
+ st-i2c_addr = new_addr;
}
for (k = 0; k no_of_demods; k++) {
- st.cfg = cfg[k];
- st.i2c_addr = DIB3000MC_I2C_ADDRESS[k];
+ st-cfg = cfg[k];
+ st-i2c_addr = DIB3000MC_I2C_ADDRESS[k];
- dib3000mc_write_word(st, 1024, st.i2c_addr 3);
+ dib3000mc_write_word(st, 1024, st-i2c_addr 3);
/* turn off data output */
- dib3000mc_set_output_mode(st, OUTMODE_HIGH_Z);
+
Stuck Digittrade DVB-T stick (dvb_usb_af9015)
Hi, i have problems with my Digittrade (www.digittrade.de) dvb-t stick. I'm trying at first to sum up my researches and observings (since im researching now two weeks for this problem) and will then enumerate my system parameter. This problem is very annoying so I hope you can help me. Perhaps there is workaround for instance reseting the stick somehow (see *Observings and Researches).* *Observings and Researches:* * im using a mythtv box that runs 24 hours a day. The box uses EItScan to retrieve the EPG data. * every now and then there is a file recorded that is empty. It seems that dvb-t stick doesnt tune correctly. There is however no error reported by mythtv. I have then found on some forums that the problem might be triggered by channels that cannot be received very well being scanned by the mythtv EITScanner. It is assumed that the driver or firmware stucks then somehow. * when this happens (stuck device) only a reboot or unplugging the stick helps. Reloading all dvb modules helps nothing. So the problem might be the firmware? * sometimes the device gets itself out of this state * some days ago this happened again. The usb stick came in this state. No Live Tv was possible and no recordings could be made. I decided to wait and see what happens. Two days later the device was still stuck in this state and I observed that this had an impact on the entire system: The responsivness was very bad. I pressed a button on the USB keyboard and the reaction appeard one or two seconds later on the screen. I tried this also via a ssh connection. It was the same. Then I examined the logs. I think that the first show that couldnt be recorded was on 11th May. Thats the day the I2C read failed reg log messages started. ## /var/log/kern.log: May 9 15:38:36 debian kernel: usb 8-2: new high speed USB device using ehci_hcd and address 9 May 9 15:38:36 debian kernel: af9015_usb_probe: interface:0 May 9 15:38:36 debian kernel: af9015_read_config: IR mode:1 May 9 15:38:36 debian kernel: af9015_read_config: TS mode:0 May 9 15:38:36 debian kernel: af9015_read_config: [0] xtal:2 set adc_clock:28000 May 9 15:38:36 debian kernel: af9015_read_config: [0] IF1:36125 May 9 15:38:36 debian kernel: af9015_read_config: [0] MT2060 IF1:1220 May 9 15:38:36 debian kernel: af9015_read_config: [0] tuner id:130 May 9 15:38:36 debian kernel: af9015_identify_state: reply:01 May 9 15:38:36 debian kernel: dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to load a firmware May 9 15:38:36 debian kernel: usb 8-2: firmware: requesting dvb-usb-af9015.fw May 9 15:38:36 debian kernel: dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' May 9 15:38:36 debian kernel: af9015_download_firmware: May 9 15:38:36 debian kernel: dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. May 9 15:38:36 debian kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. May 9 15:38:36 debian kernel: DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) May 9 15:38:36 debian kernel: af9015_af9013_frontend_attach: init I2C May 9 15:38:36 debian kernel: af9015_i2c_init: May 9 15:38:36 debian kernel: 00: 2c 21 97 0b 00 00 00 00 a4 15 16 90 00 02 01 02 May 9 15:38:36 debian kernel: 10: 00 80 00 fa fa 10 40 ef 01 30 31 30 31 30 35 30 May 9 15:38:36 debian kernel: 20: 36 30 39 30 30 30 30 31 ff ff ff ff ff ff ff ff May 9 15:38:36 debian kernel: 30: 00 00 3a 01 00 08 02 00 1d 8d c4 04 82 ff ff ff May 9 15:38:36 debian kernel: 40: ff ff ff ff ff 08 02 00 1d 8d c4 04 82 ff ff ff May 9 15:38:36 debian kernel: 50: ff ff ff ff ff 24 00 00 04 03 09 04 10 03 41 00 May 9 15:38:37 debian kernel: 60: 66 00 61 00 74 00 65 00 63 00 68 00 0c 03 44 00 May 9 15:38:37 debian kernel: 70: 56 00 42 00 2d 00 54 00 20 03 30 00 31 00 30 00 May 9 15:38:37 debian kernel: 80: 31 00 30 00 31 00 30 00 31 00 30 00 36 00 30 00 May 9 15:38:37 debian kernel: 90: 30 00 30 00 30 00 31 00 00 ff ff ff ff ff ff ff May 9 15:38:37 debian kernel: a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff May 9 15:38:37 debian kernel: b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff May 9 15:38:37 debian kernel: c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff May 9 15:38:37 debian kernel: d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff May 9 15:38:37 debian kernel: e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff May 9 15:38:37 debian kernel: f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff May 9 15:38:37 debian kernel: af9013: firmware version:4.95.0 May 9 15:38:37 debian kernel: DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... May 9 15:38:37 debian kernel: af9015_tuner_attach: May 9 15:38:37 debian kernel: MT2060: successfully identified (IF1 = 1220) May 9 15:38:37 debian kernel: input: IR-receiver inside an USB DVB receiver as /class/input/input62 May 9 15:38:37
Bug in AMDs V4L2 driver lxv4l2?
Hi everyone,
I am using an AMD Geode webcam with a V4L driver (lxv4l2). For the userspace
I've implemented a V4L
binding with memory mapping of the frames. After sucessfull receiving frames it
lasts about two or
three minutes and then either the timestamp of the frame is not changing
anymore or a kernel oops
happens. I am not quite sure whether this is caused by my userspace test
program (fw_singapore)
or whether this is a bug within AMDs driver code ...
Thanks for help.
Cheers,
Daniel
Here the causing driver function within AMDs lx.c (and below the dmesg output):
Nevertheless, I noticed that this function is also a potential deadlock
candidate since
spin_lock_irqsave(io-lock, flags); is called an the else return 0; does
not release the lock.
/** lx_capt_resume2 - queue capture buffers to vip */
int
lx_capt_resume2(VidDevice *dp,io_queue *io)
{
io_buf *op, *ep;
int eidx, oidx, vip_buffers;
int task = dp-capt_vip_task;
int task_buffers = vip_task_data[task].task_buffers;
VIPINPUTBUFFER *vip_inpbfr = dp-vip_inpbfr;
unsigned long flags;
struct list_head *lp;
io_buf *bp1;
dp-capt_stalled = 1;
task = dp-capt_vip_task;
task_buffers = vip_task_data[task].task_buffers;
if( dp-capt_addr_is_set == 0 ) {
op = dp-capt_toggle == capt_toggle_odd ? dp-capt_elch : dp-capt_onxt;
if( op == NULL ) {
if( list_empty(io-rd_qbuf) != 0 )
{
// there are no more buffers into the input list for grabbing images,
// so requeue first output buffer into input list
spin_lock_irqsave(io-lock, flags);
lp = io-rd_dqbuf;
if( ! list_empty(lp) ) {
bp1 = list_entry(lp-next,io_buf,bfrq); // get the struct for
this entry / list_entry ( ptr, type, member) struct list_head pointer/ type of
the struct this is embedded in/
name of the list_struct within the struct.
list_del_init(bp1-bfrq);//deletes entry from
list and reinitialize it
}
else return 0;
lp = io-rd_qbuf;
list_move_tail(bp1-bfrq,lp);
bp1-sequence = io-sequence++;
bp1-flags = ~V4L2_BUF_FLAG_DONE;
bp1-flags |= V4L2_BUF_FLAG_QUEUED;
if( dp-capt_stalled != 0 )
{
DMSG(3, v4l_qbfr : capt != 0 dp-capt_stalled !=
0\n);
//v4l_capt_unstall(dp);
}
spin_unlock_irqrestore(io-lock,flags);
//return 0;
}
op = list_entry(io-rd_qbuf.next,io_buf,bfrq);
list_del_init(op-bfrq);
}
if( dp-capt_toggle == capt_toggle_both ||
dp-capt_toggle == capt_toggle_odd ) {
if( (ep=dp-capt_enxt) == NULL ) {
if( list_empty(io-rd_qbuf) != 0 ) {
list_add(op-bfrq,io-rd_qbuf);
return 0;
}
ep = list_entry(io-rd_qbuf.next,io_buf,bfrq);
list_del_init(ep-bfrq);
}
}
else
{
ep = op;
}
dp-capt_onxt = op; oidx = op-index;
dp-capt_enxt = ep; eidx = ep-index;
}
else
{
oidx = eidx = 0;
}
if( oidx != eidx ) {
vip_inpbfr-current_buffer = eidx;
vip_buffers = vip_task_data[task].vip_even_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
vip_inpbfr-current_buffer = oidx;
vip_buffers = vip_task_data[task].vip_odd_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
}
else {
vip_inpbfr-current_buffer = oidx;
vip_buffers = vip_task_data[task].vip_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
}
dp-capt_stalled = 0;
++dp-capt_sequence;
++dp-capt_jiffy_sequence;
return 1;
}
dmesg and uname:
n...@purzel [1] [~]$ uname -a
Linux purzel 2.6.29.6-rt24-aldebaran-rt #1 PREEMPT RT Fri Feb 12 17:51:46 CET
2010 i586 GNU/Linux
[ 17.877211] AMD Linux LX video2linux/2 driver 3.2.0100
[ 17.893218] Found Geode LX VIP at IRQ 11
[ 17.910414] OmniVision ov7670 sensor driver, at your service (v 2.00)
[ 17.939093] ov7670/1: driver attached: adapter id: 10002
[ 17.955545] Trying to detect OmniVision 7670/7672 I2C adapters
[ 19.847126] ov7670_init returned 0
[ 19.847139] Phase 1
[ 19.849429] Phase 2
[ 19.849440] Phase 3
[ 19.851728] Phase 4
[ 19.851739] Phase 5
[ 19.854054] Phase 6
[ 19.854064] Phase 7
[ 19.856357] Phase 8
[ 19.856367] Phase 9
[ 19.856377] OmniVision 7670/7671 I2C Found
[ 19.868799] ov7670/1: driver attached: adapter id: 0
[ 20.324975] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[ 22.963201] spurious 8259A interrupt: IRQ7.
[ 74.863542] warning: `vsftpd' uses 32-bit capabilities (legacy support in
use)
[ 565.626822] BUG: unable to handle kernel paging request at 0519e544
[ 565.627024] IP: [cf4bc988] vip_toggle_video_offsets+0x29/0x106 [cimarron]
[ 565.627024] *pde =
[ 565.627024] Oops: [#1] PREEMPT
[
Re: [PATCH] checkstack fixes for drivers/media/dvb
On 05/12/2010 04:39 PM, Mauro Carvalho Chehab wrote: Prarit Bhargava wrote: When compiling 2.6.34-rc7 I see the following warnings drivers/media/dvb/frontends/dib3000mc.c: In function 'dib3000mc_i2c_enumeration': drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2224 bytes is larger than 2048 bytes drivers/media/dvb/frontends/dib7000p.c: In function 'dib7000p_i2c_enumeration': drivers/media/dvb/frontends/dib7000p.c:1346: warning: the frame size of 2304 bytes is larger than 2048 bytes because the dib*_state structs are large and they are alloc'd on the stack. This patch moves the structures off the stack. Hi Prarit, Thanks for the patch, but I've received two patches to fix the same thing some time ago. Unfortunately, it took a long time to be merged, since I was waiting for the driver maintainer's ack. It is at those changesets: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=65483f7e5f3e169ea038de26068395231dd3b13b http://git.linuxtv.org/v4l-dvb.git?a=commit;h=370c0cb185d4fccfb2c66fbe94b48579d4c5fa1c Oops! Sorry about that Mauro :( -- I didn't realize there was another git tree to check. Just curious -- is the one listed in MAINTAINERS still active? I also noticed that the cxusb driver doesn't check the return value from dib7000p_i2c_enumeration(). Randy's patch also added a test for it, but without the warning printk. It may be a good idea to have that warning. So, please be free to send it as a separate patch if you also think so. Sure I'll do that shortly (after checking out the above tree ;) ). P. -- 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] Add notification to cxusb_dualdig4_rev2_frontend_attach() error handling
Add a notification to the dib7000p_i2c_enumeration() failure path in
cxusb_dualdig4_rev2_frontend_attach().
Signed-off-by: Prarit Bhargava pra...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/cxusb.c
b/drivers/media/dvb/dvb-usb/cxusb.c
index 320ce88..8965601 100644
--- a/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/drivers/media/dvb/dvb-usb/cxusb.c
@@ -1025,8 +1025,10 @@ static int cxusb_dualdig4_rev2_frontend_attach(struct
dvb_usb_adapter *adap)
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);
if (dib7000p_i2c_enumeration(adap-dev-i2c_adap, 1, 18,
-cxusb_dualdig4_rev2_config) 0)
+cxusb_dualdig4_rev2_config) 0) {
+ printk(KERN_WARNING Unable to enumerate dib7000p\n);
return -ENODEV;
+ }
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap, 0x80,
cxusb_dualdig4_rev2_config);
--
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: Bug in AMDs V4L2 driver lxv4l2?
Daniel Borkmann wrote:
Hi everyone,
I am using an AMD Geode webcam with a V4L driver (lxv4l2). For the userspace
I've implemented a V4L
binding with memory mapping of the frames. After sucessfull receiving frames
it lasts about two or
three minutes and then either the timestamp of the frame is not changing
anymore or a kernel oops
happens. I am not quite sure whether this is caused by my userspace test
program (fw_singapore)
or whether this is a bug within AMDs driver code ...
If you're getting an OOPS, for sure there's a bug at the driver. That's said,
unfortunately, we
can't help you on it, since AMD has never submitted this driver for our review.
Thanks for help.
Cheers,
Daniel
Here the causing driver function within AMDs lx.c (and below the dmesg
output):
Nevertheless, I noticed that this function is also a potential deadlock
candidate since
spin_lock_irqsave(io-lock, flags); is called an the else return 0; does
not release the lock.
/** lx_capt_resume2 - queue capture buffers to vip */
int
lx_capt_resume2(VidDevice *dp,io_queue *io)
{
io_buf *op, *ep;
int eidx, oidx, vip_buffers;
int task = dp-capt_vip_task;
int task_buffers = vip_task_data[task].task_buffers;
VIPINPUTBUFFER *vip_inpbfr = dp-vip_inpbfr;
unsigned long flags;
struct list_head *lp;
io_buf *bp1;
dp-capt_stalled = 1;
task = dp-capt_vip_task;
task_buffers = vip_task_data[task].task_buffers;
if( dp-capt_addr_is_set == 0 ) {
op = dp-capt_toggle == capt_toggle_odd ? dp-capt_elch : dp-capt_onxt;
if( op == NULL ) {
if( list_empty(io-rd_qbuf) != 0 )
{
// there are no more buffers into the input list for grabbing
images,
// so requeue first output buffer into input list
spin_lock_irqsave(io-lock, flags);
lp = io-rd_dqbuf;
if( ! list_empty(lp) ) {
bp1 = list_entry(lp-next,io_buf,bfrq); // get the struct for
this entry / list_entry ( ptr, type, member) struct list_head pointer/ type
of the struct this is embedded in/
name of the list_struct within the struct.
list_del_init(bp1-bfrq);//deletes entry from
list and reinitialize it
}
else return 0;
lp = io-rd_qbuf;
list_move_tail(bp1-bfrq,lp);
bp1-sequence = io-sequence++;
bp1-flags = ~V4L2_BUF_FLAG_DONE;
bp1-flags |= V4L2_BUF_FLAG_QUEUED;
if( dp-capt_stalled != 0 )
{
DMSG(3, v4l_qbfr : capt != 0 dp-capt_stalled !=
0\n);
//v4l_capt_unstall(dp);
}
spin_unlock_irqrestore(io-lock,flags);
//return 0;
}
op = list_entry(io-rd_qbuf.next,io_buf,bfrq);
list_del_init(op-bfrq);
}
if( dp-capt_toggle == capt_toggle_both ||
dp-capt_toggle == capt_toggle_odd ) {
if( (ep=dp-capt_enxt) == NULL ) {
if( list_empty(io-rd_qbuf) != 0 ) {
list_add(op-bfrq,io-rd_qbuf);
return 0;
}
ep = list_entry(io-rd_qbuf.next,io_buf,bfrq);
list_del_init(ep-bfrq);
}
}
else
{
ep = op;
}
dp-capt_onxt = op; oidx = op-index;
dp-capt_enxt = ep; eidx = ep-index;
}
else
{
oidx = eidx = 0;
}
if( oidx != eidx ) {
vip_inpbfr-current_buffer = eidx;
vip_buffers = vip_task_data[task].vip_even_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
vip_inpbfr-current_buffer = oidx;
vip_buffers = vip_task_data[task].vip_odd_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
}
else {
vip_inpbfr-current_buffer = oidx;
vip_buffers = vip_task_data[task].vip_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
}
dp-capt_stalled = 0;
++dp-capt_sequence;
++dp-capt_jiffy_sequence;
return 1;
}
dmesg and uname:
n...@purzel [1] [~]$ uname -a
Linux purzel 2.6.29.6-rt24-aldebaran-rt #1 PREEMPT RT Fri Feb 12 17:51:46 CET
2010 i586 GNU/Linux
[ 17.877211] AMD Linux LX video2linux/2 driver 3.2.0100
[ 17.893218] Found Geode LX VIP at IRQ 11
[ 17.910414] OmniVision ov7670 sensor driver, at your service (v 2.00)
[ 17.939093] ov7670/1: driver attached: adapter id: 10002
[ 17.955545] Trying to detect OmniVision 7670/7672 I2C adapters
[ 19.847126] ov7670_init returned 0
[ 19.847139] Phase 1
[ 19.849429] Phase 2
[ 19.849440] Phase 3
[ 19.851728] Phase 4
[ 19.851739] Phase 5
[ 19.854054] Phase 6
[ 19.854064] Phase 7
[ 19.856357] Phase 8
[ 19.856367] Phase 9
[ 19.856377] OmniVision 7670/7671 I2C Found
[ 19.868799] ov7670/1: driver attached: adapter id: 0
[ 20.324975] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[ 22.963201]
Re: Bug in AMDs V4L2 driver lxv4l2?
Mauro Carvalho Chehab wrote:
Daniel Borkmann wrote:
Hi everyone,
I am using an AMD Geode webcam with a V4L driver (lxv4l2). For the userspace
I've implemented a V4L
binding with memory mapping of the frames. After sucessfull receiving frames
it lasts about two or
three minutes and then either the timestamp of the frame is not changing
anymore or a kernel oops
happens. I am not quite sure whether this is caused by my userspace test
program (fw_singapore)
or whether this is a bug within AMDs driver code ...
If you're getting an OOPS, for sure there's a bug at the driver. That's said,
unfortunately, we
can't help you on it, since AMD has never submitted this driver for our
review.
Okay, but for now this helps. I'm currently debugging this whole mess, since
(as far as I've seen)
they have their own HAL-like mechanism called cimarron that also provides the
vip_toggle_video_offsets
function that is causing the Oops and on my first view they do not even check
the buffer pointer
against NULL, so it could be possible that some deprecated structs point
somewhere in the space which
causes a bad paging request. If I rememer correctly, they didn't get into the
mainline because of
cimarron ...
Thanks!
Daniel
Thanks for help.
Cheers,
Daniel
Here the causing driver function within AMDs lx.c (and below the dmesg
output):
Nevertheless, I noticed that this function is also a potential deadlock
candidate since
spin_lock_irqsave(io-lock, flags); is called an the else return 0;
does not release the lock.
/** lx_capt_resume2 - queue capture buffers to vip */
int
lx_capt_resume2(VidDevice *dp,io_queue *io)
{
io_buf *op, *ep;
int eidx, oidx, vip_buffers;
int task = dp-capt_vip_task;
int task_buffers = vip_task_data[task].task_buffers;
VIPINPUTBUFFER *vip_inpbfr = dp-vip_inpbfr;
unsigned long flags;
struct list_head *lp;
io_buf *bp1;
dp-capt_stalled = 1;
task = dp-capt_vip_task;
task_buffers = vip_task_data[task].task_buffers;
if( dp-capt_addr_is_set == 0 ) {
op = dp-capt_toggle == capt_toggle_odd ? dp-capt_elch :
dp-capt_onxt;
if( op == NULL ) {
if( list_empty(io-rd_qbuf) != 0 )
{
// there are no more buffers into the input list for grabbing
images,
// so requeue first output buffer into input list
spin_lock_irqsave(io-lock, flags);
lp = io-rd_dqbuf;
if( ! list_empty(lp) ) {
bp1 = list_entry(lp-next,io_buf,bfrq); // get the struct for
this entry / list_entry ( ptr, type, member) struct list_head pointer/ type
of the struct this is embedded in/
name of the list_struct within the struct.
list_del_init(bp1-bfrq);//deletes entry from
list and reinitialize it
}
else return 0;
lp = io-rd_qbuf;
list_move_tail(bp1-bfrq,lp);
bp1-sequence = io-sequence++;
bp1-flags = ~V4L2_BUF_FLAG_DONE;
bp1-flags |= V4L2_BUF_FLAG_QUEUED;
if( dp-capt_stalled != 0 )
{
DMSG(3, v4l_qbfr : capt != 0 dp-capt_stalled !=
0\n);
//v4l_capt_unstall(dp);
}
spin_unlock_irqrestore(io-lock,flags);
//return 0;
}
op = list_entry(io-rd_qbuf.next,io_buf,bfrq);
list_del_init(op-bfrq);
}
if( dp-capt_toggle == capt_toggle_both ||
dp-capt_toggle == capt_toggle_odd ) {
if( (ep=dp-capt_enxt) == NULL ) {
if( list_empty(io-rd_qbuf) != 0 ) {
list_add(op-bfrq,io-rd_qbuf);
return 0;
}
ep = list_entry(io-rd_qbuf.next,io_buf,bfrq);
list_del_init(ep-bfrq);
}
}
else
{
ep = op;
}
dp-capt_onxt = op; oidx = op-index;
dp-capt_enxt = ep; eidx = ep-index;
}
else
{
oidx = eidx = 0;
}
if( oidx != eidx ) {
vip_inpbfr-current_buffer = eidx;
vip_buffers = vip_task_data[task].vip_even_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
vip_inpbfr-current_buffer = oidx;
vip_buffers = vip_task_data[task].vip_odd_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
}
else {
vip_inpbfr-current_buffer = oidx;
vip_buffers = vip_task_data[task].vip_buffers;
vip_toggle_video_offsets(vip_buffers,vip_inpbfr);
}
dp-capt_stalled = 0;
++dp-capt_sequence;
++dp-capt_jiffy_sequence;
return 1;
}
dmesg and uname:
n...@purzel [1] [~]$ uname -a
Linux purzel 2.6.29.6-rt24-aldebaran-rt #1 PREEMPT RT Fri Feb 12 17:51:46
CET 2010 i586 GNU/Linux
[ 17.877211] AMD Linux LX video2linux/2 driver 3.2.0100
[ 17.893218] Found Geode LX VIP at IRQ 11
[ 17.910414] OmniVision ov7670 sensor driver, at your service (v 2.00)
[ 17.939093]
Re: Remote control at Zolid Hybrid TV Tuner
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better approach
is to start using raw_decode mode. I've enabled it only for Avermedia M135A,
since this is the board I'm using at the IR refactoring tests, but the same
approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For
GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of
the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the wiki
page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
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
Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia M135A,
since this is the board I'm using at the IR refactoring tests, but the same
approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For
GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of
the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the wiki
page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
As the backport is manual, some delay is expected at the backport tree. Also,
backports are made at the best efforts basis. So, nobody can warrant that the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
Developers are encouraged to use git for development, but patches and pull
requests against the backport tree are accepted.
Long answer:
===
As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests not
handled yet, mercurial tree will be soon out of sync. I'll try to merge most of
the
pending stuff during this weekend.
The main
Re: [PATCH 1/3] mx2_camera: Add soc_camera support for i.MX25/i.MX27
Hi Guennadi,
On Wed, May 12, 2010 at 09:02:29PM +0200, Guennadi Liakhovetski wrote:
Thanks for eventually mainlining this driver! A couple of comments below.
Sascha, would be great, if you could get it tested on imx27 with and without
emma. BTW, if you say, that you use emma to avoid using the standard DMA
controller, why would anyone want not to use emma? Resource conflict? There
is also a question for you down in the comments, please, skim over.
Thank you very much for your detailed review and informative comments. I'll
fix the problems that you've found, and post up updated patch after getting
Sascha comments on the mx27 specific code.
baruch
On Thu, 6 May 2010, Baruch Siach wrote:
This is the soc_camera support developed by Sascha Hauer for the i.MX27.
Alan
Carvalho de Assis modified the original driver to get it working on more
recent
kernels. I modified it further to add support for i.MX25. This driver has
only
been tested on the i.MX25 platform.
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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
