[GIT PULL FOR 3.8-rc] s5p-fimc driver fixes
Mauro, the following are just two bug fixes for Exynos FIMC/MIPI-CSIS drivers. Please pull for 3.8. The following changes since commit d8658bca2e5696df2b6c69bc5538f8fe54e4a01e: [media] omap3isp: Replace cpu_is_omap3630() with ISP revision check (2012-11-28 10:54:46 -0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_s5p_fimc_fixes for you to fetch changes up to c3f9f35d39a15bbfc038fb53d143337a41cfc488: s5p-csis: Correct the event counters logging (2012-12-03 10:17:52 +0100) Sylwester Nawrocki (2): s5p-fimc: Fix horizontal/vertical image flip s5p-csis: Correct the event counters logging drivers/media/platform/s5p-fimc/fimc-reg.c |8 drivers/media/platform/s5p-fimc/mipi-csis.c |6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) -- Regards, Sylwester -- 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 v3] media: V4L2: add temporary clock helpers
Typical video devices like camera sensors require an external clock source.
Many such devices cannot even access their hardware registers without a
running clock. These clock sources should be controlled by their consumers.
This should be performed, using the generic clock framework. Unfortunately
so far only very few systems have been ported to that framework. This patch
adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
Platforms, adopting the clock API, should switch to using it. Eventually
this temporary API should be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3: (thanks for all the comments)
1. add and use a mutex to protect the enable counter instead of an atomic
variable
2. add a use-count
3. add const to dev_id
4. move allocations outside the mutex
5. allow rate reading and setting on disabled clock
6. rename the clock list head:-)
drivers/media/v4l2-core/Makefile |2 +-
drivers/media/v4l2-core/v4l2-clk.c | 176
include/media/v4l2-clk.h | 54 +++
3 files changed, 231 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
create mode 100644 include/media/v4l2-clk.h
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index c2d61d4..d065c01 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -5,7 +5,7 @@
tuner-objs := tuner-core.o
videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
- v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
+ v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
ifeq ($(CONFIG_COMPAT),y)
videodev-objs += v4l2-compat-ioctl32.o
endif
diff --git a/drivers/media/v4l2-core/v4l2-clk.c
b/drivers/media/v4l2-core/v4l2-clk.c
new file mode 100644
index 000..2225081
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -0,0 +1,176 @@
+/*
+ * V4L2 clock service
+ *
+ * Copyright (C) 2012, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/atomic.h
+#include linux/errno.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/string.h
+
+#include media/v4l2-clk.h
+#include media/v4l2-subdev.h
+
+static DEFINE_MUTEX(clk_lock);
+static LIST_HEAD(clk_list);
+
+static struct v4l2_clk *v4l2_clk_find(const char *dev_id, const char *id)
+{
+ struct v4l2_clk *clk;
+
+ list_for_each_entry(clk, clk_list, list) {
+ if (strcmp(dev_id, clk-dev_id))
+ continue;
+
+ if (!id || !clk-id || !strcmp(clk-id, id))
+ return clk;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+struct v4l2_clk *v4l2_clk_get(struct v4l2_subdev *sd, const char *id)
+{
+ struct v4l2_clk *clk;
+
+ mutex_lock(clk_lock);
+ clk = v4l2_clk_find(sd-name, id);
+
+ if (!IS_ERR(clk) !try_module_get(clk-ops-owner))
+ clk = ERR_PTR(-ENODEV);
+ mutex_unlock(clk_lock);
+
+ if (!IS_ERR(clk))
+ atomic_inc(clk-use_count);
+
+ return clk;
+}
+EXPORT_SYMBOL(v4l2_clk_get);
+
+void v4l2_clk_put(struct v4l2_clk *clk)
+{
+ if (!IS_ERR(clk)) {
+ atomic_dec(clk-use_count);
+ module_put(clk-ops-owner);
+ }
+}
+EXPORT_SYMBOL(v4l2_clk_put);
+
+int v4l2_clk_enable(struct v4l2_clk *clk)
+{
+ int ret;
+ mutex_lock(clk-lock);
+ if (++clk-enable == 1 clk-ops-enable) {
+ ret = clk-ops-enable(clk);
+ if (ret 0)
+ clk-enable--;
+ } else {
+ ret = 0;
+ }
+ mutex_unlock(clk-lock);
+ return ret;
+}
+EXPORT_SYMBOL(v4l2_clk_enable);
+
+void v4l2_clk_disable(struct v4l2_clk *clk)
+{
+ int enable;
+
+ mutex_lock(clk-lock);
+ enable = --clk-enable;
+ if (WARN(enable 0, Unbalanced %s() on %s:%s!\n, __func__,
+clk-dev_id, clk-id))
+ clk-enable++;
+ else if (!enable clk-ops-disable)
+ clk-ops-disable(clk);
+ mutex_unlock(clk-lock);
+}
+EXPORT_SYMBOL(v4l2_clk_disable);
+
+unsigned long v4l2_clk_get_rate(struct v4l2_clk *clk)
+{
+ if (!clk-ops-get_rate)
+ return -ENOSYS;
+
+ return clk-ops-get_rate(clk);
+}
+EXPORT_SYMBOL(v4l2_clk_get_rate);
+
+int v4l2_clk_set_rate(struct v4l2_clk *clk, unsigned long rate)
+{
+ if (!clk-ops-set_rate)
+ return -ENOSYS;
+
+ return clk-ops-set_rate(clk, rate);
+}
+EXPORT_SYMBOL(v4l2_clk_set_rate);
+
+struct v4l2_clk *v4l2_clk_register(const struct v4l2_clk_ops *ops,
+ const char *dev_id,
+ const char *id, void *priv)
Re: tda8290 regression fix
On 2012-11-15 21:43, Anders Thomson wrote:
On 2012-10-01 18:56, Anders Thomson wrote:
On 2012-09-23 23:06, Anders Thomson wrote:
Awfully sorry about this. After having had the familty sit in and check
the differences,
I must say that the patch does not fix the issue. This time around I
have x11grabs with
ffmpeg to show if you want.
I'll be away from the card until the end of the coming week. Then, I'll
bring out the multimeter...
So, I got the multimeter working over the weekend and pretty much no
results there. :-(
I tested vanilla 3.5.3, w/ my patch, w/ your tuner patch. All three
gave a (DC) reading of 0 to 30 mV (yes milli-). Given that the wiki page
you referred to spoke of a few volts, I guess this is just noise. Coming
to think of it, shouldn't any signal amplification done work on HF, so
I'd have to measure the AC on the carrier freq or something? This
multimeter is useless in the MHz range...
While at it, I created these 20 sec snippets:
http://pickup.famthomson.se/output-vanilla.avi
vanilla 3.5.3
http://pickup.famthomson.se/output-test3.avi
This patch:
# cat /TV_TEST3.diff
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index bc08f1d..98b482e 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -3291,7 +3291,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 1,
+ .tuner_config = 0,
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x00020,
.inputs = {{
http://pickup.famthomson.se/output-card.avi
This patch:
# cat /TV_CARD.diff
diff --git a/drivers/media/common/tuners/tda8290.c
b/drivers/media/common/tuners/tda8290.c
index 064d14c..498cc7b 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -635,7 +635,11 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
dvb_attach(tda827x_attach, fe, priv-tda827x_addr,
priv-i2c_props.adap,priv-cfg);
+ tuner_info(ANDERS: setting switch_addr. was 0x%02x, new
0x%02x\n,priv-cfg.switch_addr,priv-i2c_props.addr);
priv-cfg.switch_addr = priv-i2c_props.addr;
+ priv-cfg.switch_addr = 0xc2 / 2;
+ tuner_info(ANDERS: new 0x%02x\n,priv-cfg.switch_addr);
+
}
if (fe-ops.tuner_ops.init)
fe-ops.tuner_ops.init(fe);
Would looking again at the specifics on the 2.6.25-26 transition be of
any help? I expect some pain to go to such old kernel, but if I can add
some printks somewhere, maybe that could help?
Cheers,
-Anders
Hi Mauro,
Picking up this thread again. Did you have chance to look into this?
/Anders
Hi Mauro,
Any chance we can make progress on this one? As indicated, the patches
you've proposed do not work. I have no idea why mine does though
/Anders
--
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
[RFC PATCH] vb2: force output buffers to fault into memory
(repost after accidentally using HTML formatting) This needs a good review. The change is minor, but as I am not a mm expert, I'd like to get some more feedback on this. The dma-sg change has been successfully tested on our hardware, but I don't have any hardware to test the vmalloc change. Note that the 'write' attribute is still stored internally and used to tell whether set_page_dirty_lock() should be called during put_userptr. It is my understanding that that still makes sense, so I didn't change that. Regards, Hans --- start patch --- When calling get_user_pages for output buffers, the 'write' argument is set to 0 (since the DMA isn't writing to memory), This can cause unexpected results: If you calloc() buffer memory and do not fill that memory afterwards, then the kernel assigns most of that memory to one single physical 'zero' page. If you queue that buffer to the V4L2 driver, then it will call get_user_pages and store the results. Next you dequeue it, fill the buffer and queue it again. Now the V4L2 core code sees the same userptr and length and expects it to be the same buffer that it got before and it will reuse the results of the previous get_user_pages call. But that still points to zero pages, whereas userspace filled it up and so changed the buffer to use different pages. In other words, the pages the V4L2 core knows about are no longer correct. The solution is to always set 'write' to 1 as this will force the kernel to fault in proper pages. We do this for videobuf2-dma-sg.c and videobuf2-vmalloc.c, but not for videobuf2-dma-contig.c since the userptr there is already supposed to point to contiguous memory and shouldn't use the zero page at all. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf2-dma-sg.c |3 ++- drivers/media/v4l2-core/videobuf2-vmalloc.c |4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index 25c3b36..c29f159 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -143,7 +143,8 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, num_pages_from_user = get_user_pages(current, current-mm, vaddr PAGE_MASK, buf-sg_desc.num_pages, -write, +1, /* always set write to force + faulting all pages */ 1, /* force */ buf-pages, NULL); diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c b/drivers/media/v4l2-core/videobuf2-vmalloc.c index a47fd4f..c8d8519 100644 --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c @@ -107,7 +107,9 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr, /* current-mm-mmap_sem is taken by videobuf2 core */ n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK, buf-n_pages, -write, 1, /* force */ +1, /* always set write to force + faulting all pages */ +1, /* force */ buf-pages, NULL); if (n_pages != buf-n_pages) goto fail_get_user_pages; -- 1.7.10.4 -- 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 RFC 3/3] s5p-fimc: improved pipeline try format routine
Hi Andrzej,
On 11/23/2012 04:22 PM, Andrzej Hajda wrote:
Function support variable number of subdevs in pipe-line.
I'm will be applying this patch with description changed to:
Make the pipeline try format routine more generic to support any
number of subdevs in the pipeline, rather than hard coding it for
only a sensor, MIPI-CSIS and FIMC subdevs and the FIMC video node.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-capture.c | 100
+++-
1 file changed, 64 insertions(+), 36 deletions(-)
...
/**
* fimc_pipeline_try_format - negotiate and/or set formats at pipeline
*elements
@@ -809,65 +824,78 @@ static int fimc_pipeline_try_format(struct fimc_ctx
*ctx,
...
ffmt = fimc_find_format(NULL, mf-code != 0 ? mf-code : NULL,
FMT_FLAGS_CAM, i++);
- if (ffmt == NULL) {
- /*
- * Notify user-space if common pixel code for
- * host and sensor does not exist.
- */
+ if (ffmt == NULL)
return -EINVAL;
- }
+
And as we agreed, with this chunk removed from the patch. Since the comment
still stands.
--
Thank you!
Sylwester
--
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 v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator
Em 24-09-2012 09:44, Marek Szyprowski escreveu:
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it use the
DMA streaming interface (dma_map_single, dma_unmap_single). The
allocator allocates buffers and immediately map the memory for DMA
transfer. For each buffer prepare/finish it does a DMA synchronization.
Hmm.. the explanation didn't convince me, e. g.:
1) why is it needed;
2) why vb2-dma-config can't be patched to use dma_map_single
(eventually using a different vb2_io_modes bit?);
3) what are the usecases for it.
Could you please detail it? Without that, one that would be needing to
write a driver will have serious doubts about what would be the right
driver for its usage. Also, please document it at the driver itself.
Thanks!
Mauro
Signed-off-by: Federico Vaga federico.v...@gmail.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/Kconfig | 5 +
drivers/media/v4l2-core/Makefile | 1 +
drivers/media/v4l2-core/videobuf2-dma-streaming.c | 205 ++
include/media/videobuf2-dma-streaming.h | 32
4 file modificati, 243 inserzioni(+)
create mode 100644 drivers/media/v4l2-core/videobuf2-dma-streaming.c
create mode 100644 include/media/videobuf2-dma-streaming.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 0c54e19..60548a7 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -79,3 +79,8 @@ config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+
+config VIDEOBUF2_DMA_STREAMING
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index c2d61d4..0b2756f 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_DMA_STREAMING) += videobuf2-dma-streaming.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/v4l2-core/videobuf2-dma-streaming.c
b/drivers/media/v4l2-
core/videobuf2-dma-streaming.c
new file mode 100644
index 000..c839e05
--- /dev/null
+++ b/drivers/media/v4l2-core/videobuf2-dma-streaming.c
@@ -0,0 +1,205 @@
+/*
+ * videobuf2-dma-streaming.c - DMA streaming memory allocator for videobuf2
+ *
+ * Copyright (C) 2012 Federico Vaga federico.v...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/pagemap.h
+#include linux/dma-mapping.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-streaming.h
+#include media/videobuf2-memops.h
+
+struct vb2_streaming_conf {
+ struct device *dev;
+};
+struct vb2_streaming_buf {
+ struct vb2_streaming_conf *conf;
+ void*vaddr;
+
+ dma_addr_t dma_handle;
+
+ unsigned long size;
+ struct vm_area_struct *vma;
+
+ atomic_trefcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_dma_streaming_put(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(buf-refcount)) {
+ dma_unmap_single(buf-conf-dev, buf-dma_handle, buf-size,
+DMA_FROM_DEVICE);
+ free_pages_exact(buf-vaddr, buf-size);
+ kfree(buf);
+ }
+
+}
+
+static void *vb2_dma_streaming_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_streaming_conf *conf = alloc_ctx;
+ struct vb2_streaming_buf *buf;
+ int err;
+
+ buf = kzalloc(sizeof(struct vb2_streaming_buf), GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+ buf-vaddr = alloc_pages_exact(size, GFP_KERNEL | GFP_DMA);
+ if (!buf-vaddr) {
+ err = -ENOMEM;
+ goto out;
+ }
+ buf-dma_handle = dma_map_single(conf-dev, buf-vaddr, size,
+DMA_FROM_DEVICE);
+ err = dma_mapping_error(conf-dev, buf-dma_handle);
+ if (err) {
+ dev_err(conf-dev, dma_map_single failed\n);
+
+ free_pages_exact(buf-vaddr, size);
+ buf-vaddr = NULL;
+ goto out_pages;
+ }
+ buf-conf = conf;
[PATCH 2/2] au0828: break au0828_card_setup() down into smaller functions
Pull the analog frontend setup code out of au0828_card_setup into its
own seperate function, au0828_card_analog_fe_setup().
Signed-off-by: Michael Krufky mkru...@linuxtv.org
---
drivers/media/usb/au0828/au0828-cards.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 7b5b742..88e35df 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -185,14 +185,11 @@ static void hauppauge_eeprom(struct au0828_dev *dev, u8
*eeprom_data)
__func__, tv.model);
}
+void au0828_card_analog_fe_setup(struct au0828_dev *dev);
+
void au0828_card_setup(struct au0828_dev *dev)
{
static u8 eeprom[256];
-#ifdef CONFIG_VIDEO_AU0828_V4L2
- struct tuner_setup tun_setup;
- struct v4l2_subdev *sd;
- unsigned int mode_mask = T_ANALOG_TV;
-#endif
dprintk(1, %s()\n, __func__);
@@ -213,7 +210,16 @@ void au0828_card_setup(struct au0828_dev *dev)
break;
}
+ au0828_card_analog_fe_setup(dev);
+}
+
+void au0828_card_analog_fe_setup(struct au0828_dev *dev)
+{
#ifdef CONFIG_VIDEO_AU0828_V4L2
+ struct tuner_setup tun_setup;
+ struct v4l2_subdev *sd;
+ unsigned int mode_mask = T_ANALOG_TV;
+
if (AUVI_INPUT(0).type != AU0828_VMUX_UNDEFINED) {
/* Load the analog demodulator driver (note this would need to
be abstracted out if we ever need to support a different
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2
This patch removes the dependendency of VIDEO_AU0828 on VIDEO_V4L2 by
creating a new Kconfig option, VIDEO_AU0828_V4L2, which enables analog
video capture support and depends on VIDEO_V4L2 itself.
With VIDEO_AU0828_V4L2 disabled, the driver will only support digital
television and will not depend on the v4l2-core. With VIDEO_AU0828_V4L2
enabled, the driver will be built with the analog v4l2 support included.
By default, the VIDEO_AU0828_V4L2 option will be set to Y, so as to
preserve the original behavior.
Signed-off-by: Michael Krufky mkru...@linuxtv.org
---
drivers/media/usb/Kconfig |2 +-
drivers/media/usb/au0828/Kconfig| 17 ++---
drivers/media/usb/au0828/Makefile |6 +-
drivers/media/usb/au0828/au0828-cards.c |4
drivers/media/usb/au0828/au0828-core.c | 13 -
drivers/media/usb/au0828/au0828-i2c.c |4
drivers/media/usb/au0828/au0828.h |2 ++
7 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig
index 6746994..0a7d520 100644
--- a/drivers/media/usb/Kconfig
+++ b/drivers/media/usb/Kconfig
@@ -21,7 +21,6 @@ endif
if MEDIA_ANALOG_TV_SUPPORT
comment Analog TV USB devices
-source drivers/media/usb/au0828/Kconfig
source drivers/media/usb/pvrusb2/Kconfig
source drivers/media/usb/hdpvr/Kconfig
source drivers/media/usb/tlg2300/Kconfig
@@ -31,6 +30,7 @@ endif
if (MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT)
comment Analog/digital TV USB devices
+source drivers/media/usb/au0828/Kconfig
source drivers/media/usb/cx231xx/Kconfig
source drivers/media/usb/tm6000/Kconfig
endif
diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig
index 1766c0c..953a37c 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -1,17 +1,28 @@
config VIDEO_AU0828
tristate Auvitek AU0828 support
- depends on I2C INPUT DVB_CORE USB VIDEO_V4L2
+ depends on I2C INPUT DVB_CORE USB
select I2C_ALGOBIT
select VIDEO_TVEEPROM
select VIDEOBUF_VMALLOC
select DVB_AU8522_DTV if MEDIA_SUBDRV_AUTOSELECT
- select DVB_AU8522_V4L if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_TDA18271 if MEDIA_SUBDRV_AUTOSELECT
---help---
- This is a video4linux driver for Auvitek's USB device.
+ This is a hybrid analog/digital tv capture driver for
+ Auvitek's AU0828 USB device.
To compile this driver as a module, choose M here: the
module will be called au0828
+
+config VIDEO_AU0828_V4L2
+ bool Auvitek AU0828 v4l2 analog video support
+ depends on VIDEO_AU0828 VIDEO_V4L2
+ select DVB_AU8522_V4L if MEDIA_SUBDRV_AUTOSELECT
+ default y
+ ---help---
+ This is a video4linux driver for Auvitek's USB device.
+
+ Choose Y here to include support for v4l2 analog video
+ capture within the au0828 driver.
diff --git a/drivers/media/usb/au0828/Makefile
b/drivers/media/usb/au0828/Makefile
index 98cc20c..be3bdf6 100644
--- a/drivers/media/usb/au0828/Makefile
+++ b/drivers/media/usb/au0828/Makefile
@@ -1,4 +1,8 @@
-au0828-objs:= au0828-core.o au0828-i2c.o au0828-cards.o au0828-dvb.o
au0828-video.o au0828-vbi.o
+au0828-objs:= au0828-core.o au0828-i2c.o au0828-cards.o au0828-dvb.o
+
+ifeq ($(CONFIG_VIDEO_AU0828_V4L2),y)
+ au0828-objs += au0828-video.o au0828-vbi.o
+endif
obj-$(CONFIG_VIDEO_AU0828) += au0828.o
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index cf309d8..7b5b742 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -188,9 +188,11 @@ static void hauppauge_eeprom(struct au0828_dev *dev, u8
*eeprom_data)
void au0828_card_setup(struct au0828_dev *dev)
{
static u8 eeprom[256];
+#ifdef CONFIG_VIDEO_AU0828_V4L2
struct tuner_setup tun_setup;
struct v4l2_subdev *sd;
unsigned int mode_mask = T_ANALOG_TV;
+#endif
dprintk(1, %s()\n, __func__);
@@ -211,6 +213,7 @@ void au0828_card_setup(struct au0828_dev *dev)
break;
}
+#ifdef CONFIG_VIDEO_AU0828_V4L2
if (AUVI_INPUT(0).type != AU0828_VMUX_UNDEFINED) {
/* Load the analog demodulator driver (note this would need to
be abstracted out if we ever need to support a different
@@ -236,6 +239,7 @@ void au0828_card_setup(struct au0828_dev *dev)
v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_type_addr,
tun_setup);
}
+#endif
}
/*
diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index 745a80a..1e6f40e 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++
Re: [PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
Em 24-09-2012 07:58, Federico Vaga escreveu: This patch re-write the driver and use the videobuf2 interface instead of the old videobuf. Moreover, it uses also the control framework which allows the driver to inherit controls from its subdevice (ADV7180) Signed-off-by: Federico Vaga federico.v...@gmail.com Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com --- drivers/media/pci/sta2x11/Kconfig |2 +- drivers/media/pci/sta2x11/sta2x11_vip.c | 1238 ++- 2 file modificati, 407 inserzioni(+), 833 rimozioni(-) diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig index 6749f67..654339f 100644 --- a/drivers/media/pci/sta2x11/Kconfig +++ b/drivers/media/pci/sta2x11/Kconfig @@ -2,7 +2,7 @@ config STA2X11_VIP tristate STA2X11 VIP Video For Linux depends on STA2X11 select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT - select VIDEOBUF_DMA_CONTIG + select VIDEOBUF2_DMA_STREAMING depends on PCI VIDEO_V4L2 VIRT_TO_BUS help Say Y for support for STA2X11 VIP (Video Input Port) capture diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c b/drivers/media/pci/sta2x11/sta2x11_vip.c index 4c10205..b9ff926 100644 --- a/drivers/media/pci/sta2x11/sta2x11_vip.c +++ b/drivers/media/pci/sta2x11/sta2x11_vip.c @@ -1,6 +1,7 @@ /* * This is the driver for the STA2x11 Video Input Port. * + * Copyright (C) 2012 ST Microelectronics * Copyright (C) 2010 WindRiver Systems, Inc. * * This program is free software; you can redistribute it and/or modify it @@ -19,36 +20,30 @@ * The full GNU General Public License is included in this distribution in * the file called COPYING. * - * Author: Andreas Kies andreas.k...@windriver.com - * Vlad Lungu vlad.lu...@windriver.com Why are you dropping those authorship data? Ok, it is clear to me that most of the code there got rewritten, and, while IANAL, I think they still have some copyrights on it. So, if you're willing to do that, you need to get authors ack on such patch. ... MODULE_DESCRIPTION(STA2X11 Video Input Port driver); -MODULE_AUTHOR(Wind River); Same note applies here: we need Wind River's ack on that to drop it. +MODULE_AUTHOR(Federico Vaga federico.v...@gmail.com); MODULE_LICENSE(GPL v2); MODULE_SUPPORTED_DEVICE(sta2x11 video input); MODULE_VERSION(DRV_VERSION); -- 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 1/2] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2
On Tue, Dec 4, 2012 at 11:07 AM, Michael Krufky mkru...@linuxtv.org wrote: This patch removes the dependendency of VIDEO_AU0828 on VIDEO_V4L2 by creating a new Kconfig option, VIDEO_AU0828_V4L2, which enables analog video capture support and depends on VIDEO_V4L2 itself. With VIDEO_AU0828_V4L2 disabled, the driver will only support digital television and will not depend on the v4l2-core. With VIDEO_AU0828_V4L2 enabled, the driver will be built with the analog v4l2 support included. Hi Mike, This is generally good stuff. A couple of thoughts. It seems that this driver effectively takes the approach which is the exact reverse of all the other hybrid drivers - it mandates DVB with V4L as optional, whereas most of the other drivers mandate V4L with DVB is optional. Now I recognize that in this case it was done because of some specific business need -- however I have to wonder if the moving around of all the code to no longer be video vs. dvb specific could be leveraged to allow users to select either condition - to select DVB, V4L, or both. This seems like the direction things are going in -- we've restructured the tree based on bus interface type (pci/usb/etc) rather than v4l versus dvb. This might be an opportunity to define the model for how other hybrid devices could also be refactored to not have V4L or DVB if not needed. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2
On Tue, Dec 4, 2012 at 11:17 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, Dec 4, 2012 at 11:07 AM, Michael Krufky mkru...@linuxtv.org wrote: This patch removes the dependendency of VIDEO_AU0828 on VIDEO_V4L2 by creating a new Kconfig option, VIDEO_AU0828_V4L2, which enables analog video capture support and depends on VIDEO_V4L2 itself. With VIDEO_AU0828_V4L2 disabled, the driver will only support digital television and will not depend on the v4l2-core. With VIDEO_AU0828_V4L2 enabled, the driver will be built with the analog v4l2 support included. Hi Mike, This is generally good stuff. A couple of thoughts. It seems that this driver effectively takes the approach which is the exact reverse of all the other hybrid drivers - it mandates DVB with V4L as optional, whereas most of the other drivers mandate V4L with DVB is optional. Now I recognize that in this case it was done because of some specific business need -- however I have to wonder if the moving around of all the code to no longer be video vs. dvb specific could be leveraged to allow users to select either condition - to select DVB, V4L, or both. This seems like the direction things are going in -- we've restructured the tree based on bus interface type (pci/usb/etc) rather than v4l versus dvb. This might be an opportunity to define the model for how other hybrid devices could also be refactored to not have V4L or DVB if not needed. Thanks for your comments, Devin. I agree with you that it would be nice to be able to choose to disable DVB just like how we can disable V4L, but the reason why I did this to V4L first was not simply due to the business need -- I did this because of how easy it was to do. The driver was originally developed as a DVB-only driver, and later analog support was added to it (by you ;-) ). As a result, conditionalizing the analog support was rather easy. Doing the same for DVB would probably not be very difficult either, but I also believe in small patches and gradual changes. These patches allow us to build the au0828 driver (and its dependencies) without the need for the v4l-core. This is especially helpful when backporting digital support to older kernels without the need to muck through the v4l2 api changes. Do you have any issues with these two patches as-is? Any suggestions? If not, is it OK with you if I request that Mauro merge this for v3.9 ? Cheers, Mike Krufky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2
On Tue, Dec 4, 2012 at 11:25 AM, Michael Krufky mkru...@linuxtv.org wrote: Do you have any issues with these two patches as-is? Any suggestions? If not, is it OK with you if I request that Mauro merge this for v3.9 ? I have no specific issues with the patch as-is. Reviewed-by: Devin Heitmueller dheitmuel...@kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] linux-firmware: cx23885: update to Version 2.06.139
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/03/2012 10:07 PM, Ben Hutchings wrote: On Mon, 2012-12-03 at 11:13 -0700, Tim Gardner wrote: Ben - what is your policy on extracting firmware from Windows drivers? snip I'm not sure how you can say they are the same files, as you're proposing to change the contents. The copyright on the current files belongs to the chipset vendor, Conexant, and Hauppuage *presumably* used firmware supplied by Conexant, but either of them might have chosen a different licence for the versions in this driver package. I guess that is the root of the issue. In light of the licensing uncertainty I think you should just drop this pull request. Tim Gardner (1): cx23885: update to Version 2.06.139 v4l-cx23885-avcore-01.fw | Bin 16382 - 16382 bytes v4l-cx23885-enc.fw | Bin 16382 - 376836 bytes 2 files changed, 0 insertions(+), 0 deletions(-) How odd, these two files are currently identical to each other... Ben. Indeed they are. The comment in the bug report [0] indicates that those files should not be identical. [0] https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/569615/comments/4 rtg - -- Tim Gardner tim.gard...@canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJQvh9lAAoJED12yEX6FEfKYD8P/ih3NovJAZqndS8ljG/X7Pcw 7pgQNM0WWiiwjNxcxQK+s+w/XV1QJGztLgXDduUEb3jD8nNH2qvAGXVgBKWZNSqQ alSF6yqvRUq8G2h6CJc6/T9MVmhaYm1GkgXRVFViLFyvjh9wc6xxD/O5SA3Fr0Q2 J0Js4/vExIoFd8ps+9cB4+AzDqWmiEGk5FBseNLwO2zrDyzziO7tXH6K3W34n1EW ztVOnkFbrvVBuf/QOQFBbt06ziKINwPsyZkCyUHCWs7WXmWLLH1rvrH2CSGvQkXY S5fk/H1j5LRCellURpAbs9x50OWdShOQs05mSpd4eZmD1lvFqjMCCYWHn4AR2fvk yXi71uendvfVFfFHlN3kWHnCLICLJUa8urMRDSts3XRUFXZDijeJVWpJZJXK5m+W 40NIkDOQVvVHWxL+W1bCiM36uE0f+9klsqfs0nWB1xERol9peaoqJhoW1VyzHEmK 7QSt1+nezFuURfaSktG2W/WsRZuo6RI9ElOWrOVGrmnA3PoYun8KlanGyGiS+ezu /b2l/yxPAlanHXcAtpCcV7h+sLL9k7z5rIUZDuseHazAw14jATGu7LLpac7nvPCB cuYvKUeVOSPi/fkC5A+pSWMDznjr92bgTf71tlzzGTNDIq/MQCwpotxJUfOXr3Oh 5dZzEgczjDDdYMniC6rl =egal -END PGP SIGNATURE- -- 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 PULL] linux-firmware: cx23885: update to Version 2.06.139
Em 04-12-2012 03:07, Ben Hutchings escreveu: On Mon, 2012-12-03 at 11:13 -0700, Tim Gardner wrote: Ben - what is your policy on extracting firmware from Windows drivers? I suppose the policy should be that the driver's licence must allow extracting and then distributing the result. Which I wouldn't expect ever to be the case, in practice. Your commit message refers to the Hauppuage driver package at http://steventoth.net/linux/hvr1800/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip. I didn't find any licence text, other than 'All rights reserved', in either that or the currently distributed version of the same driver http://www.wintvcd.co.uk/drivers/HVR-12x0-14x0-17x0-33x0-44x0_1_48_29272_SIGNED.zip. It seems like it ought to be OK, and they _are_ the same files that are covered under the license in WHENCE. I'm not sure how you can say they are the same files, as you're proposing to change the contents. The copyright on the current files belongs to the chipset vendor, Conexant, and Hauppuage *presumably* used firmware supplied by Conexant, but either of them might have chosen a different licence for the versions in this driver package. We shouldn't be replacing the firmwares that Conexant explicitly gave us the rights to re-distribute by something else extracted from the Windows drivers without redistribution rights. Also, AFAIKT, with regards to the firmwares used on ivtv, there is a license variant that Hauppauge gave to some distros in the past, after getting Conexant's agreement for that. The terms used there explicitly forbids redistribution. So, if any of the existing firmware doesn't work, we should ask Conexant (c/c) to send us a firmware that works, under the same terms they gave us in the past, e. g. with redistribution rights. Regards, 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
[GIT PULL] s5p-fimc driver updates for Exynos4x12 SoC support
Hi Mauro, This series is mainly prerequisite patches for camera devices (FIMC, FIMC-LITE, MIPI-CSIS, FIMC-IS) support on Exynos4x12 (two- and quad-core) SoCs. Exynos4412 is a processor found on Origen 4 Quad dev board for example. It would have been good to have this series in 3.8, however if it is already not reachable then please pull for 3.9. The following changes since commit df5450d51945b4a1a506200e11267626a6d324e3: Merge tag 'v3.7-rc8' into staging/for_v3.8 (2012-12-04 10:46:21 -0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_s5p_fimc for you to fetch changes up to c78a1a3584a7a2b89e84e57382abec9153a477fe: s5p-fimc: Improved pipeline try format routine (2012-12-04 16:47:27 +0100) Andrzej Hajda (1): s5p-fimc: Add support for sensors with multiple pads Sylwester Nawrocki (10): V4L: DocBook: Add V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code fimc-lite: Register dump function cleanup s5p-fimc: Clean up capture enable/disable helpers s5p-fimc: Add variant data structure for Exynos4x12 s5p-csis: Add support for raw Bayer pixel formats s5p-csis: Enable only data lanes that are actively used s5p-csis: Add registers logging for debugging s5p-fimc: Add sensor group ids for fimc-is fimc-lite: Add ISP FIFO output support s5p-fimc: Improved pipeline try format routine Documentation/DocBook/media/v4l/subdev-formats.xml | 718 ++-- Documentation/DocBook/media_api.tmpl |1 + drivers/media/platform/s5p-fimc/fimc-capture.c | 105 ++- drivers/media/platform/s5p-fimc/fimc-core.c| 90 ++- drivers/media/platform/s5p-fimc/fimc-core.h|8 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.c|6 +- drivers/media/platform/s5p-fimc/fimc-lite.c| 146 +++- drivers/media/platform/s5p-fimc/fimc-lite.h|7 +- drivers/media/platform/s5p-fimc/fimc-m2m.c |2 +- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 26 +- drivers/media/platform/s5p-fimc/fimc-mdevice.h | 12 +- drivers/media/platform/s5p-fimc/fimc-reg.c | 40 +- drivers/media/platform/s5p-fimc/fimc-reg.h |4 +- drivers/media/platform/s5p-fimc/mipi-csis.c| 52 +- include/uapi/linux/v4l2-mediabus.h |3 +- 15 files changed, 548 insertions(+), 672 deletions(-) --- Regards, Sylwester -- 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] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2 | git://linuxtv.org/mkrufky/hauppauge voyager-digital
On Tue, Dec 4, 2012 at 11:29 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, Dec 4, 2012 at 11:25 AM, Michael Krufky mkru...@linuxtv.org wrote: Do you have any issues with these two patches as-is? Any suggestions? If not, is it OK with you if I request that Mauro merge this for v3.9 ? I have no specific issues with the patch as-is. Reviewed-by: Devin Heitmueller dheitmuel...@kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Thank you, Devin. Mauro, please merge: The following changes since commit 72567f3cfafe31c1612efe52e2893e960cc8dd00: au0828: update model matrix entries for 72261, 72271 72281 (2012-11-28 09:46:24 -0500) are available in the git repository at: git://linuxtv.org/mkrufky/hauppauge voyager-digital for you to fetch changes up to c67f6580bfa7922572a883437413f6480db05ef2: au0828: break au0828_card_setup() down into smaller functions (2012-12-04 10:46:38 -0500) Michael Krufky (2): au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2 au0828: break au0828_card_setup() down into smaller functions drivers/media/usb/Kconfig |2 +- drivers/media/usb/au0828/Kconfig| 17 ++--- drivers/media/usb/au0828/Makefile |6 +- drivers/media/usb/au0828/au0828-cards.c | 16 +--- drivers/media/usb/au0828/au0828-core.c | 13 - drivers/media/usb/au0828/au0828-i2c.c |4 drivers/media/usb/au0828/au0828.h |2 ++ 7 files changed, 51 insertions(+), 9 deletions(-) Cheers, Mike Krufky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption
Em Mon, 29 Oct 2012 14:11 + Simon Farnsworth simon.farnswo...@onelan.co.uk escreveu: On Monday 29 October 2012 09:32:27 Andy Walls wrote: On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote: It will affect other drivers as well; the basic cause is that modern chips can enter a package deep sleep state that affects both CPU speed and latency to start of DMA. On older systems, this couldn't happen - the Northbridge kept running at all times, and DMA latencies were low. However, on the Intel Sandybridge system I'm testing with, the maximum wake latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't hold onto data for that long, and overflows, resulting in the corruption I'm seeing. The pm QoS request fixes this for me, by telling the PM subsystem that the SAA7134 cannot cope with a long latency on the first write of a DMA transfer. Now, some media bridges (like the ones driven by the cx18 driver) can cope with very high latency before the beginning of a DMA burst. Andy Walls has worked on the cx18 driver to cope in this situation, so it doesn't fail even with the 109 microsecond DMA latency we have on Sandybridge. Well if brdige wake-up DMA latency is the problem, it is alos the case that the CX23418 has a *lot* of on board memory with which to collect video and compress it. (And lets face it, the CX23418 is an SoC with two ARM cores and a lot of dedicated external memory, as opposed to the SAA7134 with 1 kB of FIFO.) That hardware helps quite a bit, if the PCI bus is slow to wake up. I found a SAA7134 sheet for you: http://www.nxp.com/documents/data_sheet/SAA7134HL.pdf Section 6.4.3 has a short description of the behaviour when the FIFO overflows. That's a good description of what I'm seeing, so fits with the idea that it's FIFO underflow. But this sheet (close enough): http://www.nxp.com/documents/data_sheet/SAA7133HL.pdf Has much nicer examples of the programmed levels of the FIFO in section 6.4.3. That 1 kB is for everything: raw VBI, Y, U, V, MPEG, and Audio. So you're lucky if one full line of video fits in the FIFO. And that datasheet suggests that my 31 usec request is too high; in the fastidious configuration, I'd need a latency of 22 usec, not 31. Does anyone have register-level documentation for the SAA7134, to confirm the maximum tolerated latency with the FIFO configuration Linux uses? Others, like the SAA7134, just don't have that much buffering, and we need to ask the pm core to cope with it. I suspect that most old drivers will need updating if anyone wants to use them with modern systems; either they'll have an architecture like the cx18 series, and the type of work Andy has done will fix the problem, or they'll behave like the saa7134, and need a pm_qos request to ensure that the CPU package (and thus memory controller) stay awake. Unless the chip has a lot of internal memory and processing resources, I suspect a pm_qos solution is needed to ensure the PCI bus responds in time. This is a system level issue though. Having the drivers decide what QoS they need in the absences of total system requirements, is the right thing for the home user. It might not be very friendly for a professional solution where someone is trying to tune the use of the system IO bandwidth and CPU resources. The ivtv driver and cx18 driver unconditionally bumping up their PCI latency timer to 64 cycles minimum always bugged me: drivers shouldn't be deciding QoS in a vaccuum. But, then again, user complaints went away and the 64 PCI cycles seemed to be a minimum QoS that everyone needed. Also both drivers have a ivtv/cx18_pci_latency module option to override the behaviour anyway. So, one trick that the pm_qos request infrastructure gives us is that I only request reduced latency when we are actually streaming. It's up to the pm core to determine what that means - e.g. keep CPU awake, program chipset registers, ignore the request completely. The other part of this is that I'm flagging my QoS requirements; if the wakeup latency is higher than I'm requesting, I'll fail - that is clearly wrong. On the other hand, if you have reasons to want lower wakeup latencies, the core will combine all requests (both userspace and kernelspace), and choose the minimum. If you're sophisticated enough to accept the problems involved in not waking up in time to service DMA requests, you're probably also up to the task of changing the kernel slightly to not request lower latencies. Simon, If I understood your above comments well, you'll be submitting us a version 2 of this patch changing the latency to a value closer to 22 usec, after testing it. So, I'll mark this patch as changes-requested and I'll wait for your next one. Cheers, Mauro -- To unsubscribe from this
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Dec 4 19:00:23 CET 2012 git hash:16427faf28674451a7a0485ab0a929402f355ffd gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: ERRORS linux-3.5-i686: ERRORS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: ERRORS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: em28xx: msi Digivox ATSC board id [0db0:8810]
Am 04.12.2012 03:58, schrieb Devin Heitmueller:
On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik matt...@pyther.net wrote:
I would try running lsusb -v and send the output. Make sure that
it's not expecting to use bulk mode for DVB (which would require
driver changes to support).
Devin
Here is the output of lsusb -v
http://pyther.net/a/digivox_atsc/patch2/lsusb.txt
Hmmm, it's isoc, so that should be ok. Maybe the 3305 TS
configuration is mismatched (serial vs. parallel). I don't recall off
the top of my head, but I think em2875 is pretty much always in serial
mode, so check the lgdt3305 config block passed in the dvb_attach()
call and see if it's the same.
I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
but LGDT3305_TPCLK_FALLING_EDGE is used instead of
LGDT3305_TPCLK_RISING_EDGE.
OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
Matthew, could you please test V3 of the patch ? It is written against
the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git).
You could also already test the remote control key map (e.g. with evtest)
Regards,
Frank
Devin
From 7f7aa989a339f9510db53662042c39551b40b0df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Frank=20Sch=C3=A4fer?= fschaefer@googlemail.com
Date: Tue, 4 Dec 2012 22:03:47 +0100
Subject: [PATCH] Experimental patch for the 'MSI DIGIVOX ATSC' V3
---
drivers/media/usb/em28xx/em28xx-cards.c | 30
drivers/media/usb/em28xx/em28xx-dvb.c | 38 +++
drivers/media/usb/em28xx/em28xx.h |1 +
3 Dateien geändert, 69 Zeilen hinzugefügt(+)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index 619bffb..ec3b29b 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -393,6 +393,21 @@ static struct em28xx_reg_seq pctv_520e[] = {
{ -1, -1, -1, -1},
};
+/* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+ * GPIO_0 - ??? (related to eeprom reading ?)
+ * GPIO_6 - ??? (TDA18271C2 or/and LGDT3305 reset ?)
+ * GPIO_7 - ??? (wakeup or stream enable ?)
+ */
+static struct em28xx_reg_seq msi_digivox_atsc[] = {
+ {EM2874_R80_GPIO, 0xff, 0xff, 50}, /* GPIO_0=1 */
+ {0x0d,0xff, 0xff, 0},
+ {EM2874_R80_GPIO, 0xfe, 0xff, 0}, /* GPIO_0=0 */
+ {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
+ {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
+ {EM2874_R80_GPIO, 0x7e, 0xff, 20}, /* GPIO_7=0 */
+ { -1, -1, -1, -1},
+};
+
/*
* Board definitions
*/
@@ -1988,6 +2003,19 @@ struct em28xx_board em28xx_boards[] = {
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+ * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
+ [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
+ .name = MSI DIGIVOX ATSC,
+ .dvb_gpio = msi_digivox_atsc,
+ .has_dvb = 1,
+ .tuner_type = TUNER_ABSENT,
+ .ir_codes = RC_MAP_MSI_DIGIVOX_III, /* just a guess from looking at the picture */
+ .xclk = EM28XX_XCLK_FREQUENCY_12MHZ, /* TODO */
+ .i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
+EM28XX_I2C_CLK_WAIT_ENABLE |
+EM28XX_I2C_FREQ_100_KHZ,
+ },
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -2145,6 +2173,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2884_BOARD_PCTV_510E },
{ USB_DEVICE(0x2013, 0x0251),
.driver_info = EM2884_BOARD_PCTV_520E },
+ { USB_DEVICE(0x0db0, 0x8810),
+ .driver_info = EM2874_BOARD_MSI_DIGIVOX_ATSC },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..b4855c8 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -263,6 +263,18 @@ static struct lgdt3305_config em2870_lgdt3304_dev = {
.qam_if_khz = 4000,
};
+static struct lgdt3305_config em2874_lgdt3305_dev = {
+ .i2c_addr = 0x0e,
+ .demod_chip = LGDT3305,
+ .spectral_inversion = 1,
+ .rf_agc_loop= 0,
+ .mpeg_mode = LGDT3305_MPEG_PARALLEL,
+ .tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE,
+ .tpvalid_polarity = LGDT3305_TP_VALID_HIGH,
+ .vsb_if_khz = 3250, /* not confirmed with a USB log */
+ .qam_if_khz = 4000,
+};
+
static struct s921_config sharp_isdbt = {
.demod_address = 0x30 1
};
@@ -713,6 +725,14 @@ static struct tda18271_config em28xx_cxd2820r_tda18271_config = {
.gate = TDA18271_GATE_DIGITAL,
};
+static struct tda18271_config em28xx_lgdt3305_tda18271_config = {
+ .std_map = kworld_a340_std_map, /* TODO / EXPERIMENTAL */
+ .gate = TDA18271_GATE_DIGITAL,
+ .output_opt = TDA18271_OUTPUT_LT_OFF,
+/* .rf_cal_on_startup = 1, */ /* needed ??? */
+/* .delay_cal = 1, */ /* needed ??? */
+};
+
static const struct tda10071_config em28xx_tda10071_config = {
.i2c_address = 0x55, /* (0xaa 1)
Re: [PATCH RFC 3/3] s5p-fimc: improved pipeline try format routine
Hi Andrzej,
On Fri, Nov 23, 2012 at 04:22:30PM +0100, Andrzej Hajda wrote:
Function support variable number of subdevs in pipe-line.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-capture.c | 100
+++-
1 file changed, 64 insertions(+), 36 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 3acbea3..39c4555 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -794,6 +794,21 @@ static int fimc_cap_enum_fmt_mplane(struct file *file,
void *priv,
return 0;
}
+static struct media_entity *fimc_pipeline_get_head(struct media_entity *me)
+{
+ struct media_pad *pad = me-pads[0];
+
+ while (!(pad-flags MEDIA_PAD_FL_SOURCE)) {
+ pad = media_entity_remote_source(pad);
+ if (!pad)
+ break;
Isn't it an error if a sink pad of the entity isn't connected?
media_entity_remote_source(pad) returns NULL if the link is disabled. I'm
just wondering if this is possible.
+ me = pad-entity;
+ pad = me-pads[0];
+ }
+
+ return me;
+}
+
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
On Tuesday 04 December 2012 14:15:15 Mauro Carvalho Chehab wrote: Em 24-09-2012 07:58, Federico Vaga escreveu: This patch re-write the driver and use the videobuf2 interface instead of the old videobuf. Moreover, it uses also the control framework which allows the driver to inherit controls from its subdevice (ADV7180) Signed-off-by: Federico Vaga federico.v...@gmail.com Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com [..] /* * This is the driver for the STA2x11 Video Input Port. * + * Copyright (C) 2012 ST Microelectronics * Copyright (C) 2010 WindRiver Systems, Inc. * * This program is free software; you can redistribute it and/or modify it @@ -19,36 +20,30 @@ * The full GNU General Public License is included in this distribution in * the file called COPYING. * - * Author: Andreas Kies andreas.k...@windriver.com - * Vlad Lungu vlad.lu...@windriver.com Why are you dropping those authorship data? Ok, it is clear to me that most of the code there got rewritten, and, while IANAL, I think they still have some copyrights on it. So, if you're willing to do that, you need to get authors ack on such patch. I re-write the driver, and also the first version of the driver has many modification made by me, many bug fix, style review, remove useless code. The first time I didn't add myself as author because the logic of the driver did not change. This time, plus the old change I think there is nothing of the original driver because I rewrite it from the hardware manual. Practically, It is a new driver for the same device. Anyway I will try to contact the original authors for the acked-by. MODULE_DESCRIPTION(STA2X11 Video Input Port driver); -MODULE_AUTHOR(Wind River); Same note applies here: we need Wind River's ack on that to drop it. I will try also for this. But I think that this is not a windriver driver because I re-wrote it from the hardware manual. I used the old driver because I thought that it was better than propose a patch that remove the old driver and add my driver. I did not remove the 2010 Copyright from windriver, because they did the job, but this work was paid by ST (copyright 2012) and made completely by me. Is my thinking wrong? Just a question for the future so I avoid to redo the same error. If I re- wrote most of a driver I cannot change the authorship automatically without the acked-by of the previous author. If I ask to the previous author and he does not give me the acked-by (or he is unreachable, he change email address), then the driver is written by me but the author is someone else? Right? So, it is better if I propose a patch which remove a driver and a patch which add my driver? Thank you -- Federico Vaga -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/04/2012 04:06 PM, Frank Schäfer wrote: I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL, but LGDT3305_TPCLK_FALLING_EDGE is used instead of LGDT3305_TPCLK_RISING_EDGE. OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL... Matthew, could you please test V3 of the patch ? It is written against the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git). You could also already test the remote control key map (e.g. with evtest) Regards, Frank Version 3 has the same behavior has v2. It seems I can tune a channel, but trying to watch it fails. There is no data being set to /dev/dvb/adapter0/dvr0 Tune channel [root@tux ~]# azap -r -c /home/pyther/channels.conf ION LIF [root@tux ~]# dvbdate dvbdate: Unable to get time from multiplex. I got further on a channel scan but then encountered some errors (no channels detected): http://pyther.net/a/digivox_atsc/patch3/scan.txt http://pyther.net/a/digivox_atsc/patch3/dmesg_after_scan.txt dmesg: http://pyther.net/a/digivox_atsc/patch3/dmesg.txt azap: http://pyther.net/a/digivox_atsc/patch3/azap.txt dvbtraffic: http://pyther.net/a/digivox_atsc/patch3/dvbtraffic.txt Matthew -- 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: [PATCHv15 0/7] of: add display helper
Hello Steffen, Any update on version 16 ? Best Wishes, Leela Krishna Amudala. On Mon, Nov 26, 2012 at 2:37 PM, Steffen Trumtrar s.trumt...@pengutronix.de wrote: Hi! Changes since v14: - fix const struct * warning (reported by: Leela Krishna Amudala l.kris...@samsung.com) - return -EINVAL when htotal or vtotal are zero - remove unreachable code in of_get_display_timings - include headers in .c files and not implicit in .h - sort includes alphabetically - fix lower/uppercase in binding documentation - rebase onto v3.7-rc7 Changes since v13: - fix const struct * warning (reported by: Laurent Pinchart laurent.pinch...@ideasonboard.com) - prevent division by zero in fb_videomode_from_videomode Changes since v12: - rename struct display_timing to via_display_timing in via subsystem - fix refreshrate calculation - fix const struct * warnings (reported by: Manjunathappa, Prakash prakash...@ti.com) - some CodingStyle fixes - rewrite parts of commit messages and display-timings.txt - let display_timing_get_value get all values instead of just typical Changes since v11: - make pointers const where applicable - add reviewed-by Laurent Pinchart Changes since v10: - fix function name (drm_)display_mode_from_videomode - add acked-by, reviewed-by, tested-by Changes since v9: - don't leak memory when previous timings were correct - CodingStyle fixes - move blank lines around Changes since v8: - fix memory leaks - change API to be more consistent (foo_from_bar(struct bar, struct foo)) - include headers were necessary - misc minor bufixe Changes since v7: - move of_xxx to drivers/video - remove non-binding documentation from display-timings.txt - squash display_timings and videomode in one patch - misc minor fixes Changes since v6: - get rid of some empty lines etc. - move functions to their subsystems - split of_ from non-of_ functions - add at least some kerneldoc to some functions Changes since v5: - removed all display stuff and just describe timings Changes since v4: - refactored functions Changes since v3: - print error messages - free alloced memory - general cleanup Changes since v2: - use hardware-near property-names - provide a videomode structure - allow ranges for all properties (min,typ,max) - functions to get display_mode or fb_videomode Steffen Trumtrar (7): viafb: rename display_timing to via_display_timing video: add display_timing and videomode video: add of helper for display timings/videomode fbmon: add videomode helpers fbmon: add of_videomode helpers drm_modes: add videomode helpers drm_modes: add of_videomode helpers .../devicetree/bindings/video/display-timing.txt | 107 ++ drivers/gpu/drm/drm_modes.c| 70 +++ drivers/video/Kconfig | 21 ++ drivers/video/Makefile |4 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 93 + drivers/video/of_display_timing.c | 219 drivers/video/of_videomode.c | 54 + drivers/video/via/hw.c |6 +- drivers/video/via/hw.h |2 +- drivers/video/via/lcd.c|2 +- drivers/video/via/share.h |2 +- drivers/video/via/via_modesetting.c|8 +- drivers/video/via/via_modesetting.h|6 +- drivers/video/videomode.c | 44 include/drm/drmP.h | 13 ++ include/linux/display_timing.h | 104 ++ include/linux/fb.h | 12 ++ include/linux/of_display_timing.h | 20 ++ include/linux/of_videomode.h | 18 ++ include/linux/videomode.h | 54 + 21 files changed, 870 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/display_timing.h create mode 100644 include/linux/of_display_timing.h create mode 100644 include/linux/of_videomode.h create mode 100644 include/linux/videomode.h --
