Re: [PATCH] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG
Hi Guennadi, On Thu, Apr 07, 2011 at 10:50:43AM +0200, Uwe Kleine-König wrote: Since commit 379fa5d ([media] V4L: mx3_camera: convert to videobuf2) mx3_camera uses videobuf2, but that commit didn't upgrade the select resulting in the following build failure: drivers/built-in.o: In function `mx3_camera_init_videobuf': clkdev.c:(.text+0x86580): undefined reference to `vb2_dma_contig_memops' drivers/built-in.o: In function `mx3_camera_probe': clkdev.c:(.devinit.text+0x3548): undefined reference to `vb2_dma_contig_init_ctx' clkdev.c:(.devinit.text+0x3578): undefined reference to `vb2_dma_contig_cleanup_ctx' drivers/built-in.o: In function `mx3_camera_remove': clkdev.c:(.devexit.text+0x674): undefined reference to `vb2_dma_contig_cleanup_ctx' make[2]: *** [.tmp_vmlinux1] Error 1 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- I guess the only problem with this is -ENOTIME on your side? does someone has a hint how to fix gcc not to believe the undefined references to be in clkdev.c? I got a hint that might be related to ccache. Didn't look into it yet, though. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG
On Mon, 18 Apr 2011, Uwe Kleine-König wrote: Hi Guennadi, On Thu, Apr 07, 2011 at 10:50:43AM +0200, Uwe Kleine-König wrote: Since commit 379fa5d ([media] V4L: mx3_camera: convert to videobuf2) mx3_camera uses videobuf2, but that commit didn't upgrade the select resulting in the following build failure: drivers/built-in.o: In function `mx3_camera_init_videobuf': clkdev.c:(.text+0x86580): undefined reference to `vb2_dma_contig_memops' drivers/built-in.o: In function `mx3_camera_probe': clkdev.c:(.devinit.text+0x3548): undefined reference to `vb2_dma_contig_init_ctx' clkdev.c:(.devinit.text+0x3578): undefined reference to `vb2_dma_contig_cleanup_ctx' drivers/built-in.o: In function `mx3_camera_remove': clkdev.c:(.devexit.text+0x674): undefined reference to `vb2_dma_contig_cleanup_ctx' make[2]: *** [.tmp_vmlinux1] Error 1 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- I guess the only problem with this is -ENOTIME on your side? It's been pushed upstream almost 2 weeks ago: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31352 Thanks Guennadi does someone has a hint how to fix gcc not to believe the undefined references to be in clkdev.c? I got a hint that might be related to ccache. Didn't look into it yet, though. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG
Uwe, On Mon, Apr 18, 2011 at 10:14:56AM +0200, Guennadi Liakhovetski wrote: It's been pushed upstream almost 2 weeks ago: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31352 As our autobuilder does still trigger, I assume that the configs have to be refreshed and it may be an issue on our side. Can you take care of that? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG
On Mon, Apr 18, 2011 at 10:20:49AM +0200, Robert Schwebel wrote: Uwe, On Mon, Apr 18, 2011 at 10:14:56AM +0200, Guennadi Liakhovetski wrote: It's been pushed upstream almost 2 weeks ago: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31352 As our autobuilder does still trigger, I assume that the configs have to be refreshed and it may be an issue on our side. Can you take care of that? Just take a look at what's in mainline: config VIDEO_MX3 tristate i.MX3x Camera Sensor Interface driver depends on VIDEO_DEV MX3_IPU SOC_CAMERA select VIDEOBUF_DMA_CONTIG select MX3_VIDEO ---help--- This is a v4l2 driver for the i.MX3x Camera Sensor Interface and you'll see that it hasn't made it there yet. If I search for 'linuxtv.org' in the history post 2.6.39-rc2, there's no sign of it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG
Hi Robert, On Mon, Apr 18, 2011 at 10:20:49AM +0200, Robert Schwebel wrote: On Mon, Apr 18, 2011 at 10:14:56AM +0200, Guennadi Liakhovetski wrote: It's been pushed upstream almost 2 weeks ago: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31352 As our autobuilder does still trigger, I assume that the configs have to be refreshed and it may be an issue on our side. Can you take care of that? The problem is not our config, but that the change didn't hit next (next-20110418) yet. git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (master) (which I guess is the tree targeted by Guennadi's pull request) is currently at 78fca1b9 (Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6) which doesn't contain Guennadi's pull request. Also the other branches in Mauro's repo don't contain it, in fact the repository is fully merged into Linus tree. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v3 0/7] Samsung IOMMU videobuf2 allocator and s5p-fimc update
Hello, This is a third version of the Samsung IOMMU driver (see patch #2) and videobuf2 allocator for IOMMU mapped memory (see patch #4) as well as FIMC driver update. This update brings some minor bugfixes to Samsung IOMMU (SYSMMU) driver and support for pages larger than 4KiB in videobuf2-dma-iommu allocator. The main change from the first version of the Samsung IOMMU patches is a complete rewrite of the IOMMU driver API. As suggested by Arnd Bergmann we decided to drop the custom interface and use the kernel wide, common iommu API defined in linux/include/iommu.h. This way the videobuf2 iommu allocator become much more generic framework and it is no longer tied to any particular iommu implementation. This patch series introduces new type of videbuf2 memory allocator - vb2-dma-iommu. This allocator can be used on the platforms that support linux/include/iommu.h style IOMMU driver. An IOMMU driver for Samsung EXYNOS4 (called SYSMMU) platform is also included. The allocator and IOMMU driver is then used by s5p-fimc driver. To make it possible some additional changes are required. Mainly the platform support for s5p-fimc for EXYNOS4 machines need to be defined. The proposed solution has been tested on Universal C210 board (Samsung S5PC210/EXYNOS4 based). This IOMMU allocator has no dependences on any external subsystems. We also ported s5p-mfc and s5p-tv drivers to this allocator, they will be posted in separate patch series. This will enable to get them working on mainline Linux kernel for EXYNOS4 platform. Support for S5PV210/S5PC110 platform still depends on CMA allocator that needs more discussion on memory management mailing list and further development. The patches with updated s5p-mfc and s5p-tv drivers will follow. To get FIMC module working on EXYNOS4 platform on UniversalC210 board we also added support for power domains and power gating. This patch series contains a collection of patches for various platform subsystems. Here is a detailed list: [PATCH 1/7] ARM: EXYNOS4: power domains: fixes and code cleanup - adds support for block gating in Samsung power domain driver and performs some cleanup [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver - a complete rewrite of sysmmu driver for Samsung platform, now uses linux/include/iommu.h api (key patch in this series) [PATCH 3/7] v4l: videobuf2: dma-sg: move some generic functions to memops - a little cleanup and preparations for the dma-iommu allocator [PATCH 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator - introduces new memory allocator for videobuf2 for drivers that support iommu dma memory mappings (key patch in this series) [PATCH 5/7] v4l: s5p-fimc: add pm_runtime support - adds support for pm_runtime in s5p-fimc driver [PATCH 6/7] v4l: s5p-fimc: Add support for vb2-dma-iommu allocator - adds support for the newly introduces videbuf2-s5p-iommu allocator on EXYNOS4 platform [PATCH 7/7] ARM: EXYNOS4: enable FIMC on Universal_C210 - adds all required machine definitions to get FIMC modules working on Universal C210 boards Changelog: V3: - minor bugfixes in SYSMMU driver - added complete support for 64KiB and 1MiB pages to videobuf2-dma-iommu allocator V2: http://68.183.106.108/lists/arm-kernel/msg120636.html - custom SYSMMU interface has been dropped in favour of linux/include/iommu.h and rewritten SYSMMU driver again - added support to SYSMMU for mapping pages larger than 4Kb - dropped ARM shared mode - videobuf2-s5p-iommu allocator has been renamed to videobuf2-dma-iommu, because it has no dependenco on any Samsung platform specific API, the allocator still uses only 4Kb pages, but this will be changed in the next version - dropped FIMC platform patch that have been merged mainline - rebased all patches onto Linux kernel v2.6.39-rc1 V1: http://www.spinics.net/lists/linux-media/msg29751.html Best regards -- Marek Szyprowski Samsung Poland RD Center Complete patch summary: Andrzej Pietrasiewicz (3): ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver v4l: videobuf2: dma-sg: move some generic functions to memops v4l: videobuf2: add IOMMU based DMA memory allocator Marek Szyprowski (3): v4l: s5p-fimc: add pm_runtime support v4l: s5p-fimc: Add support for vb2-dma-iommu allocator ARM: EXYNOS4: enable FIMC on Universal_C210 Tomasz Stanislawski (1): ARM: EXYNOS4: power domains: fixes and code cleanup arch/arm/mach-exynos4/Kconfig |6 + arch/arm/mach-exynos4/clock.c | 68 +- arch/arm/mach-exynos4/dev-pd.c | 93 ++- arch/arm/mach-exynos4/dev-sysmmu.c | 615 - arch/arm/mach-exynos4/include/mach/irqs.h | 35 +- arch/arm/mach-exynos4/include/mach/regs-clock.h |7 + arch/arm/mach-exynos4/include/mach/sysmmu.h | 46 - arch/arm/mach-exynos4/mach-universal_c210.c | 22 + arch/arm/plat-s5p/Kconfig | 20 +-
[PATCH 7/7] ARM: EXYNOS4: enable FIMC on Universal_C210
This patch adds definitions to enable support for s5p-fimc driver
together with required power domains and sysmmu controller on Universal
C210 board.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos4/Kconfig |6 ++
arch/arm/mach-exynos4/mach-universal_c210.c | 22 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index e849f67..544a594 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -148,12 +148,18 @@ config MACH_ARMLEX4210
config MACH_UNIVERSAL_C210
bool Mobile UNIVERSAL_C210 Board
select CPU_EXYNOS4210
+ select S5P_DEV_FIMC0
+ select S5P_DEV_FIMC1
+ select S5P_DEV_FIMC2
+ select S5P_DEV_FIMC3
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC2
select S3C_DEV_HSMMC3
select S3C_DEV_I2C1
select S3C_DEV_I2C5
select S5P_DEV_ONENAND
+ select EXYNOS4_DEV_PD
+ select EXYNOS4_DEV_SYSMMU
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_I2C5
select EXYNOS4_SETUP_SDHCI
diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
b/arch/arm/mach-exynos4/mach-universal_c210.c
index 97d329f..7ff2f5f 100644
--- a/arch/arm/mach-exynos4/mach-universal_c210.c
+++ b/arch/arm/mach-exynos4/mach-universal_c210.c
@@ -27,9 +27,12 @@
#include plat/cpu.h
#include plat/devs.h
#include plat/iic.h
+#include plat/pd.h
#include plat/sdhci.h
+#include plat/sysmmu.h
#include mach/map.h
+#include mach/regs-clock.h
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define UNIVERSAL_UCON_DEFAULT (S3C2410_UCON_TXILEVEL |\
@@ -613,6 +616,15 @@ static struct platform_device *universal_devices[]
__initdata = {
s3c_device_hsmmc2,
s3c_device_hsmmc3,
s3c_device_i2c5,
+ s5p_device_fimc0,
+ s5p_device_fimc1,
+ s5p_device_fimc2,
+ s5p_device_fimc3,
+ exynos4_device_pd[PD_CAM],
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC0],
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC1],
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC2],
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC3],
/* Universal Devices */
universal_gpio_keys,
@@ -638,6 +650,16 @@ static void __init universal_machine_init(void)
/* Last */
platform_add_devices(universal_devices, ARRAY_SIZE(universal_devices));
+
+ s5p_device_fimc0.dev.parent = exynos4_device_pd[PD_CAM].dev;
+ s5p_device_fimc1.dev.parent = exynos4_device_pd[PD_CAM].dev;
+ s5p_device_fimc2.dev.parent = exynos4_device_pd[PD_CAM].dev;
+ s5p_device_fimc3.dev.parent = exynos4_device_pd[PD_CAM].dev;
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC0].dev.parent =
exynos4_device_pd[PD_CAM].dev;
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC1].dev.parent =
exynos4_device_pd[PD_CAM].dev;
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC2].dev.parent =
exynos4_device_pd[PD_CAM].dev;
+ exynos4_device_sysmmu[S5P_SYSMMU_FIMC3].dev.parent =
exynos4_device_pd[PD_CAM].dev;
+
}
MACHINE_START(UNIVERSAL_C210, UNIVERSAL_C210)
--
1.7.1.569.g6f426
--
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 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch adds new videobuf2 memory allocator dedicated to devices that
supports IOMMU DMA mappings. A device with IOMMU module and a driver
with include/iommu.h compatible interface is required. This allocator
aquires memory with standard alloc_page() call and doesn't suffer from
memory fragmentation issues. The allocator support following page sizes:
4KiB, 64KiB, 1MiB and 16MiB to reduce iommu translation overhead.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/Kconfig |8 +-
drivers/media/video/Makefile |1 +
drivers/media/video/videobuf2-dma-iommu.c | 762 +
include/media/videobuf2-dma-iommu.h | 48 ++
4 files changed, 818 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/videobuf2-dma-iommu.c
create mode 100644 include/media/videobuf2-dma-iommu.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4498b94..40d7bcc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -60,12 +60,18 @@ config VIDEOBUF2_VMALLOC
select VIDEOBUF2_MEMOPS
tristate
-
config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
tristate
+
+config VIDEOBUF2_DMA_IOMMU
+ select GENERIC_ALLOCATOR
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
+
#
# Multimedia Video device configuration
#
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..04136f6 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -118,6 +118,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_IOMMU) += videobuf2-dma-iommu.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
diff --git a/drivers/media/video/videobuf2-dma-iommu.c
b/drivers/media/video/videobuf2-dma-iommu.c
new file mode 100644
index 000..7ccb51a
--- /dev/null
+++ b/drivers/media/video/videobuf2-dma-iommu.c
@@ -0,0 +1,762 @@
+/*
+ * videobuf2-dma-iommu.c - IOMMU based memory allocator for videobuf2
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * Author: Andrzej Pietrasiewicz andrze...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/mm.h
+#include linux/scatterlist.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/vmalloc.h
+#include linux/genalloc.h
+#include linux/device.h
+#include linux/iommu.h
+#include asm/cacheflush.h
+#include asm/page.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+#include media/videobuf2-dma-iommu.h
+
+/*
+ * 17: single piece of memory (one bitmap entry) equals 128k,
+ * so by default the genalloc's bitmap occupies 4kB (one page
+ * for a number of architectures)
+ */
+#define VB2_DMA_IOMMU_PIECE_ORDER 17
+
+/* -1: use default node id to allocate gen_pool/gen_pool_chunk structure from
*/
+#define VB2_DMA_IOMMU_NODE_ID -1
+
+/*
+ * starting address of the virtual address space of the client device
+ * must not be zero
+ */
+#define VB2_DMA_IOMMU_MEM_BASE 0x3000
+
+/* size of the virtual address space of the client device */
+#define VB2_DMA_IOMMU_MEM_SIZE 0x4000
+
+struct vb2_dma_iommu_alloc_ctx {
+ struct device *dev;
+ struct gen_pool *pool;
+ unsigned intorder;
+ struct iommu_domain *domain;
+};
+
+struct vb2_dma_iommu_desc {
+ unsigned long size;
+ unsigned intnum_pages;
+ struct page **pages;
+ unsigned long *pg_map;
+ boolcontig;
+};
+
+struct vb2_dma_iommu_buf {
+ unsigned long drv_addr;
+ unsigned long vaddr;
+
+ struct vb2_dma_iommu_desc info;
+ int offset;
+ atomic_trefcount;
+ int write;
+ struct vm_area_struct *vma;
+
+ struct vb2_vmarea_handler handler;
+
+ struct vb2_dma_iommu_alloc_ctx *ctx;
+};
+
+#define pages_4k(size) \
+ (((size) + PAGE_SIZE - 1) PAGE_SHIFT)
+
+#define pages_order(size, order) \
+ ((pages_4k(size) (order)) 0xF)
+
+#define for_each_compound_page(bitmap, size, idx) \
+ for ((idx) =
[PATCH 3/7] v4l: videobuf2: dma-sg: move some generic functions to memops
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch moves some generic code to videobuf2-memops. This code will
be later used by the iommu allocator. This patch adds also vma locking
in user pointer mode.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-dma-sg.c | 37 +--
drivers/media/video/videobuf2-memops.c | 76
include/media/videobuf2-memops.h |5 ++
3 files changed, 93 insertions(+), 25 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-sg.c
b/drivers/media/video/videobuf2-dma-sg.c
index b2d9485..240abaa 100644
--- a/drivers/media/video/videobuf2-dma-sg.c
+++ b/drivers/media/video/videobuf2-dma-sg.c
@@ -29,6 +29,7 @@ struct vb2_dma_sg_buf {
struct vb2_dma_sg_desc sg_desc;
atomic_trefcount;
struct vb2_vmarea_handler handler;
+ struct vm_area_struct *vma;
};
static void vb2_dma_sg_put(void *buf_priv);
@@ -150,15 +151,9 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
if (!buf-pages)
goto userptr_fail_pages_array_alloc;
- down_read(current-mm-mmap_sem);
- num_pages_from_user = get_user_pages(current, current-mm,
-vaddr PAGE_MASK,
-buf-sg_desc.num_pages,
-write,
-1, /* force */
-buf-pages,
-NULL);
- up_read(current-mm-mmap_sem);
+ num_pages_from_user = vb2_get_user_pages(vaddr, buf-sg_desc.num_pages,
+buf-pages, write, buf-vma);
+
if (num_pages_from_user != buf-sg_desc.num_pages)
goto userptr_fail_get_user_pages;
@@ -177,6 +172,8 @@ userptr_fail_get_user_pages:
num_pages_from_user, buf-sg_desc.num_pages);
while (--num_pages_from_user = 0)
put_page(buf-pages[num_pages_from_user]);
+ if (buf-vma)
+ vb2_put_vma(buf-vma);
kfree(buf-pages);
userptr_fail_pages_array_alloc:
@@ -200,6 +197,8 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
__func__, buf-sg_desc.num_pages);
if (buf-vaddr)
vm_unmap_ram(buf-vaddr, buf-sg_desc.num_pages);
+ if (buf-vma)
+ vb2_put_vma(buf-vma);
while (--i = 0) {
if (buf-write)
set_page_dirty_lock(buf-pages[i]);
@@ -236,28 +235,16 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv)
static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dma_sg_buf *buf = buf_priv;
- unsigned long uaddr = vma-vm_start;
- unsigned long usize = vma-vm_end - vma-vm_start;
- int i = 0;
+ int ret;
if (!buf) {
printk(KERN_ERR No memory to map\n);
return -EINVAL;
}
- do {
- int ret;
-
- ret = vm_insert_page(vma, uaddr, buf-pages[i++]);
- if (ret) {
- printk(KERN_ERR Remapping memory, error: %d\n, ret);
- return ret;
- }
-
- uaddr += PAGE_SIZE;
- usize -= PAGE_SIZE;
- } while (usize 0);
-
+ ret = vb2_insert_pages(vma, buf-pages);
+ if (ret)
+ return ret;
/*
* Use common vm_area operations to track buffer refcount.
diff --git a/drivers/media/video/videobuf2-memops.c
b/drivers/media/video/videobuf2-memops.c
index 5370a3a..9d44473 100644
--- a/drivers/media/video/videobuf2-memops.c
+++ b/drivers/media/video/videobuf2-memops.c
@@ -185,6 +185,82 @@ int vb2_mmap_pfn_range(struct vm_area_struct *vma,
unsigned long paddr,
EXPORT_SYMBOL_GPL(vb2_mmap_pfn_range);
/**
+ * vb2_get_user_pages() - pin user pages
+ * @vaddr: virtual address from which to start
+ * @num_pages: number of pages to pin
+ * @pages: table of pointers to struct pages to pin
+ * @write: if 0, the pages must not be written to
+ * @vma: output parameter, copy of the vma or NULL
+ * if get_user_pages fails
+ *
+ * This function just forwards invocation to get_user_pages, but eases using
+ * the latter in videobuf2 allocators.
+ */
+int vb2_get_user_pages(unsigned long vaddr, unsigned int num_pages,
+ struct page **pages, int write, struct vm_area_struct
**vma)
+{
+ struct vm_area_struct *found_vma;
+ struct mm_struct *mm = current-mm;
+ int ret = -EFAULT;
+
+ down_read(current-mm-mmap_sem);
+
+ found_vma = find_vma(mm, vaddr);
+
[PATCH 5/7] v4l: s5p-fimc: add pm_runtime support
This patch adds basic support for pm_runtime to s5p-fimc driver. PM
runtime support is required to enable the driver on S5PV310 series with
power domain driver enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |5 +
drivers/media/video/s5p-fimc/fimc-core.c| 14 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 95f8b4e1..f697ed1 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include linux/list.h
#include linux/slab.h
#include linux/clk.h
@@ -398,6 +399,8 @@ static int fimc_capture_open(struct file *file)
if (fimc_m2m_active(fimc))
return -EBUSY;
+ pm_runtime_get_sync(fimc-pdev-dev);
+
if (++fimc-vid_cap.refcnt == 1) {
ret = fimc_isp_subdev_init(fimc, 0);
if (ret) {
@@ -428,6 +431,8 @@ static int fimc_capture_close(struct file *file)
fimc_subdev_unregister(fimc);
}
+ pm_runtime_put_sync(fimc-pdev-dev);
+
return 0;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 6c919b3..ead5c0a 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -20,6 +20,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include linux/list.h
#include linux/io.h
#include linux/slab.h
@@ -1410,6 +1411,8 @@ static int fimc_m2m_open(struct file *file)
if (fimc-vid_cap.refcnt 0)
return -EBUSY;
+ pm_runtime_get_sync(fimc-pdev-dev);
+
fimc-m2m.refcnt++;
set_bit(ST_OUTDMA_RUN, fimc-state);
@@ -1452,6 +1455,8 @@ static int fimc_m2m_release(struct file *file)
if (--fimc-m2m.refcnt = 0)
clear_bit(ST_OUTDMA_RUN, fimc-state);
+ pm_runtime_put_sync(fimc-pdev-dev);
+
return 0;
}
@@ -1649,6 +1654,11 @@ static int fimc_probe(struct platform_device *pdev)
goto err_req_region;
}
+ pm_runtime_set_active(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+
+ pm_runtime_get_sync(pdev-dev);
+
fimc-num_clocks = MAX_FIMC_CLOCKS - 1;
/* Check if a video capture node needs to be registered. */
@@ -1706,6 +1716,8 @@ static int fimc_probe(struct platform_device *pdev)
dev_dbg(pdev-dev, %s(): fimc-%d registered successfully\n,
__func__, fimc-id);
+ pm_runtime_put_sync(pdev-dev);
+
return 0;
err_m2m:
@@ -1740,6 +1752,8 @@ static int __devexit fimc_remove(struct platform_device
*pdev)
vb2_dma_contig_cleanup_ctx(fimc-alloc_ctx);
+ pm_runtime_disable(pdev-dev);
+
iounmap(fimc-regs);
release_resource(fimc-regs_res);
kfree(fimc-regs_res);
--
1.7.1.569.g6f426
--
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/7] ARM: EXYNOS4: power domains: fixes and code cleanup
From: Tomasz Stanislawski t.stanisl...@samsung.com
This patch extends power domain driver with support for enabling and
disabling modules in S5P_CLKGATE_BLOCK register. It also performs a
little code cleanup to avoid confusion between exynos4_device_pd array
index and power domain id.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mach-exynos4/dev-pd.c | 93 +--
arch/arm/mach-exynos4/include/mach/regs-clock.h |7 ++
arch/arm/plat-samsung/include/plat/pd.h |1 +
3 files changed, 79 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-exynos4/dev-pd.c b/arch/arm/mach-exynos4/dev-pd.c
index 3273f25..44c6597 100644
--- a/arch/arm/mach-exynos4/dev-pd.c
+++ b/arch/arm/mach-exynos4/dev-pd.c
@@ -16,13 +16,17 @@
#include linux/delay.h
#include mach/regs-pmu.h
+#include mach/regs-clock.h
#include plat/pd.h
+static DEFINE_SPINLOCK(gate_block_slock);
+
static int exynos4_pd_enable(struct device *dev)
{
struct samsung_pd_info *pdata = dev-platform_data;
u32 timeout;
+ int ret = 0;
__raw_writel(S5P_INT_LOCAL_PWR_EN, pdata-base);
@@ -31,21 +35,39 @@ static int exynos4_pd_enable(struct device *dev)
while ((__raw_readl(pdata-base + 0x4) S5P_INT_LOCAL_PWR_EN)
!= S5P_INT_LOCAL_PWR_EN) {
if (timeout == 0) {
- printk(KERN_ERR Power domain %s enable failed.\n,
- dev_name(dev));
- return -ETIMEDOUT;
+ dev_err(dev, enable failed\n);
+ ret = -ETIMEDOUT;
+ goto done;
}
timeout--;
udelay(100);
}
- return 0;
+ /* configure clk gate mask if it is present */
+ if (pdata-gate_mask) {
+ unsigned long flags;
+ unsigned long value;
+
+ spin_lock_irqsave(gate_block_slock, flags);
+
+ value = __raw_readl(S5P_CLKGATE_BLOCK);
+ value |= pdata-gate_mask;
+ __raw_writel(value, S5P_CLKGATE_BLOCK);
+
+ spin_unlock_irqrestore(gate_block_slock, flags);
+ }
+
+done:
+ dev_info(dev, enable finished\n);
+
+ return ret;
}
static int exynos4_pd_disable(struct device *dev)
{
struct samsung_pd_info *pdata = dev-platform_data;
u32 timeout;
+ int ret = 0;
__raw_writel(0, pdata-base);
@@ -53,81 +75,108 @@ static int exynos4_pd_disable(struct device *dev)
timeout = 10;
while (__raw_readl(pdata-base + 0x4) S5P_INT_LOCAL_PWR_EN) {
if (timeout == 0) {
- printk(KERN_ERR Power domain %s disable failed.\n,
- dev_name(dev));
- return -ETIMEDOUT;
+ dev_err(dev, disable failed\n);
+ ret = -ETIMEDOUT;
+ goto done;
}
timeout--;
udelay(100);
}
- return 0;
+ if (pdata-gate_mask) {
+ unsigned long flags;
+ unsigned long value;
+
+ spin_lock_irqsave(gate_block_slock, flags);
+
+ value = __raw_readl(S5P_CLKGATE_BLOCK);
+ value = ~pdata-gate_mask;
+ __raw_writel(value, S5P_CLKGATE_BLOCK);
+
+ spin_unlock_irqrestore(gate_block_slock, flags);
+ }
+done:
+ dev_info(dev, disable finished\n);
+
+ return ret;
}
struct platform_device exynos4_device_pd[] = {
- {
+ [PD_MFC] = {
.name = samsung-pd,
- .id = 0,
+ .id = PD_MFC,
.dev = {
.platform_data = (struct samsung_pd_info) {
.enable = exynos4_pd_enable,
.disable= exynos4_pd_disable,
.base = S5P_PMU_MFC_CONF,
+ .gate_mask = S5P_CLKGATE_BLOCK_MFC,
},
},
- }, {
+ },
+ [PD_G3D] = {
.name = samsung-pd,
- .id = 1,
+ .id = PD_G3D,
.dev = {
.platform_data = (struct samsung_pd_info) {
.enable = exynos4_pd_enable,
.disable= exynos4_pd_disable,
.base = S5P_PMU_G3D_CONF,
+ .gate_mask = S5P_CLKGATE_BLOCK_G3D,
},
},
- }, {
+ },
+ [PD_LCD0] = {
.name
[PATCH 6/7] v4l: s5p-fimc: Add support for vb2-dma-iommu allocator
This patch adds support for videobuf2-dma-iommu allocator to s5p-fimc
driver. This allocator is selected only on systems that contains support
for S5P SYSMMU module (like EXYNOS4 platform). Otherwise the standard
videobuf2-dma-contig is used.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig |3 +-
drivers/media/video/s5p-fimc/fimc-capture.c |4 +-
drivers/media/video/s5p-fimc/fimc-core.c| 24 ---
drivers/media/video/s5p-fimc/fimc-core.h|1 +
drivers/media/video/s5p-fimc/fimc-mem.h | 104 +++
5 files changed, 123 insertions(+), 13 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-mem.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 40d7bcc..bf2d55d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1031,7 +1031,8 @@ config VIDEO_MEM2MEM_TESTDEV
config VIDEO_SAMSUNG_S5P_FIMC
tristate Samsung S5P FIMC (video postprocessor) driver
depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P
- select VIDEOBUF2_DMA_CONTIG
+ select VIDEOBUF2_DMA_IOMMU if S5P_SYSTEM_MMU
+ select VIDEOBUF2_DMA_CONTIG if !S5P_SYSTEM_MMU
select V4L2_MEM2MEM_DEV
help
This is a v4l2 driver for the S5P camera interface
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index f697ed1..714f0df 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -29,9 +29,9 @@
#include media/v4l2-ioctl.h
#include media/v4l2-mem2mem.h
#include media/videobuf2-core.h
-#include media/videobuf2-dma-contig.h
#include fimc-core.h
+#include fimc-mem.h
static struct v4l2_subdev *fimc_subdev_register(struct fimc_dev *fimc,
struct s5p_fimc_isp_info *isp_info)
@@ -884,7 +884,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
q-io_modes = VB2_MMAP | VB2_USERPTR;
q-drv_priv = fimc-vid_cap.ctx;
q-ops = fimc_capture_qops;
- q-mem_ops = vb2_dma_contig_memops;
+ q-mem_ops = fimc_vb2_allocator_memops;
q-buf_struct_size = sizeof(struct fimc_vid_buffer);
vb2_queue_init(q);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index ead5c0a..594c471 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -27,9 +27,9 @@
#include linux/clk.h
#include media/v4l2-ioctl.h
#include media/videobuf2-core.h
-#include media/videobuf2-dma-contig.h
#include fimc-core.h
+#include fimc-mem.h
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
sclk_fimc, fimc, sclk_cam
@@ -457,7 +457,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
dbg(memplanes= %d, colplanes= %d, pix_size= %d,
frame-fmt-memplanes, frame-fmt-colplanes, pix_size);
- paddr-y = vb2_dma_contig_plane_paddr(vb, 0);
+ paddr-y = fimc_vb2_plane_addr(vb, 0);
if (frame-fmt-memplanes == 1) {
switch (frame-fmt-colplanes) {
@@ -485,10 +485,10 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
} else {
if (frame-fmt-memplanes = 2)
- paddr-cb = vb2_dma_contig_plane_paddr(vb, 1);
+ paddr-cb = fimc_vb2_plane_addr(vb, 1);
if (frame-fmt-memplanes == 3)
- paddr-cr = vb2_dma_contig_plane_paddr(vb, 2);
+ paddr-cr = fimc_vb2_plane_addr(vb, 2);
}
dbg(PHYS_ADDR: y= 0x%X cb= 0x%X cr= 0x%X ret= %d,
@@ -1378,7 +1378,7 @@ static int queue_init(void *priv, struct vb2_queue
*src_vq,
src_vq-io_modes = VB2_MMAP | VB2_USERPTR;
src_vq-drv_priv = ctx;
src_vq-ops = fimc_qops;
- src_vq-mem_ops = vb2_dma_contig_memops;
+ src_vq-mem_ops = fimc_vb2_allocator_memops;
src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
ret = vb2_queue_init(src_vq);
@@ -1390,7 +1390,7 @@ static int queue_init(void *priv, struct vb2_queue
*src_vq,
dst_vq-io_modes = VB2_MMAP | VB2_USERPTR;
dst_vq-drv_priv = ctx;
dst_vq-ops = fimc_qops;
- dst_vq-mem_ops = vb2_dma_contig_memops;
+ dst_vq-mem_ops = fimc_vb2_allocator_memops;
dst_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
return vb2_queue_init(dst_vq);
@@ -1688,12 +1688,15 @@ static int fimc_probe(struct platform_device *pdev)
goto err_clk;
}
- /* Initialize contiguous memory allocator */
- fimc-alloc_ctx = vb2_dma_contig_init_ctx(fimc-pdev-dev);
+ /* Initialize memory allocator */
+ fimc-alloc_ctx = fimc_vb2_allocator_init(pdev, fimc);
if (IS_ERR(fimc-alloc_ctx)) {
[GIT PULL FOR 2.6.39] videobuf2 fixes
Hi Mauro,
The following changes since commit 0ce790e7d736cedc563e1fb4e998babf5a4dbc3d:
Linux 2.6.39-rc1 (2011-03-29 12:09:47 -0700)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-2.6-samsung vb2-for-mauro
Marek Szyprowski (2):
media: vb2: fix incorrect v4l2_buffer-flags handling
media: vb2: correct queue initialization order
drivers/media/video/videobuf2-core.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
The above message is intended solely for the named addressee and may contain
trade secret, industrial technology or privileged and confidential information
otherwise protected under applicable law. Any unauthorized dissemination,
distribution, copying or use of the information contained in this communication
is strictly prohibited. If you have received this communication in error,
please notify sender by email and delete this communication immediately.
Powyższa wiadomość przeznaczona jest wyłącznie dla adresata niniejszej
wiadomości i może zawierać informacje będące tajemnicą handlową, tajemnicą
przedsiębiorstwa oraz informacje o charakterze poufnym chronione obowiązującymi
przepisami prawa. Jakiekolwiek nieuprawnione ich rozpowszechnianie,
dystrybucja, kopiowanie lub użycie informacji zawartych w powyższej wiadomości
jest zabronione. Jeśli otrzymałeś powyższą wiadomość omyłkowo, uprzejmie proszę
poinformuj o tym fakcie drogą mailową nadawcę tej wiadomości oraz niezwłocznie
usuń powyższą wiadomość ze swojego komputera.
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Leadtek DTV2000DS half working
Hello, In July last year, I set up a Mythbuntu 10.04 system, which used a Leadtek DTV2000DS (af9013/af9015) dual tuner PCI card. I used the 4.95 firmware, with the v4l compiled over the top of the 2.6.32 kernel, and successfully got both tuners working. A week ago, I bought a second DTV2000DS new, to increase the concurrent recording capability of the box, thinking that it would be a safe bet - one works, why not two? Unfortunately, I have been unable to get the new card to work correctly. I can get one of the two tuners on the new card to work, but the second is being stubborn. In my dmesg log, I get the line af9015: firmware copy to 2nd frontend failed, will disable it, and no frontend0 device is created for the adapter. Down below, I have pasted the output of find /dev/dvb/, to show what device files are being created. I have also pasted the dvb related lines from dmesg. After it initially failed with my existing kernel, I tried upgrading to a 2.6.35 kernel, as that includes the drivers for the capture cards by default. No luck. I then found the page on the linux tv wiki (http://www.linuxtv.org/wiki/index.php/Leadtek_WinFast_DTV2000DS) and followed all the instructions (including the fix for 5.1 firmware) and still only got only one tuner working. I also tried the 5.1 firmware, but it was worse, none of the blue lights on either DTV card came on, so I am sticking with the 4.95 firmware for now! To try and isolate whether it is a combination of both cards that's causing problems, I tried uninstalling the original card, but that just left me with one working tuner, so I put it back in to keep the family happy. I saw on the wiki page (and Google searches) that I am not the only one having problems with the 2nd tuner. However, I think that I may be in the unique position of having one working and one problematic card - something must have changed in the hardware between the cards. I have pasted in the output of the lsusb command - but the only difference, apart from the bus number, is the iManufacturer line, which is 1 for the working card, and 1 Afatech for the new card. My thinking is that some hardware has changed on Leadtek's end, but not the model number, and that change is breaking the driver. A quick visual inspection of the cards didn't show anything, but I didn't look at individual chip identifications. Is there anything anyone can suggest to look into to see what has changed? Can my old/new combination in one PC help ferret out this problem for those that only own the new card? (And also fix it for me!) Sorry for the length of this post, I hope that I haven't gone too far in trying to get all the pertinent information in here! Thanks, Ian Marshall Output of find /dev/dvb/: /dev/dvb/adapter3 /dev/dvb/adapter3/net0 /dev/dvb/adapter3/dvr0 /dev/dvb/adapter3/demux0 /dev/dvb/adapter2 /dev/dvb/adapter2/frontend0 /dev/dvb/adapter2/net0 /dev/dvb/adapter2/dvr0 /dev/dvb/adapter2/demux0 /dev/dvb/adapter1 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter1/net0 /dev/dvb/adapter1/dvr0 /dev/dvb/adapter1/demux0 /dev/dvb/adapter0 /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/net0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 Lines from dmesg (unrelated lines removed): [ 15.695132] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in cold state, will try to load a firmware [ 15.746678] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [ 15.817171] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in warm state. [ 15.817221] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 15.817567] DVB: registering new adapter (Leadtek WinFast DTV2000DS) [ 15.882809] af9013: firmware version:4.95.0 [ 15.886310] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [ 15.905524] tda18271 1-00c0: creating new instance [ 15.911875] TDA18271HD/C2 detected @ 1-00c0 [ 16.277677] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 16.278075] DVB: registering new adapter (Leadtek WinFast DTV2000DS) [ 17.013415] af9013: found a 'Afatech AF9013 DVB-T' in warm state. [ 17.016041] af9013: firmware version:4.95.0 [ 17.027414] DVB: registering adapter 1 frontend 0 (Afatech AF9013 DVB-T)... [ 17.027555] tda18271 2-00c0: creating new instance [ 17.032539] TDA18271HD/C2 detected @ 2-00c0 [ 17.390342] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:14.4/:03:05.2/usb3/3-1/input/input2 [ 17.390389] dvb-usb: schedule remote query interval to 150 msecs. [ 17.390393] dvb-usb: Leadtek WinFast DTV2000DS successfully initialized and connected. [ 17.894086] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in cold state, will try to load a firmware [ 17.895515] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [ 17.966737] dvb-usb: found a 'Leadtek WinFast DTV2000DS' in warm state. [ 17.966786] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [
Re: [RFC, PATCH] libv4lconvert: Add support for Y10B grey format (V4L2_PIX_FMT_Y10BPACK)
On Mon, 11 Apr 2011 23:07:36 +0200 Hans de Goede hdego...@redhat.com wrote: [...] I don't know libv4l yet, so I am asking for advice providing some code to discuss on; looking at the last hunk of the patch: can I allocate a temporary buffer only once per device (and not per frame as I am horribly doing now) and reuse it in the conversion routines? libv4l has a mechanism for doing this, you can simply do: unpacked_buffer = v4lconvert_alloc_buffer(width * height * sizeof(unsigned short), data-convert_pixfmt_buf, data-convert_pixfmt_buf_size); v4lconvert_alloc_buffer will remember the buffer (and its size) and return the same buffer each call. Freeing it on closing of the device is also taken care of. You should still check for a NULL return. Thanks that works fine: I am still not sure I like passing 'v4l2convert_data' to the pixelformat conversion routines but we'll discuss that on the next review round. What has me worried more, is how libv4l will decide between asking Y10B grey versus raw bayer from the device when an app is asking for say RGB24. libv4l normally does this automatically on a best match basis (together with preferring compressed formats over uncompressed for high resolutions). But this won't work in the kinect case. If we prioritize one over the other we will always end up giving the app the one we prioritize. Mmh, I tried to materialize your worries, these are the native modes supported: - GRBG mode at 640x480 and 1280x1024 - UYVY mode ay 640x480 - Y10B mode at 640x488 and 1280x1024 ^ and this is the behavior I am observing in qv4l2 when in _wrapped_ mode: - If I choose the RGB3 output format all the three different resolutions are selectable: + at 640x480 I get the color image, as there is no greyscale format at the same resolution, + at 640x488 I get the grayscale image, as there is no color format at the same resolution, + if I choose 1280x1024 I get the grayscale image indeed, and I loose the possibility of using the color image. Everything works fine in _raw_ mode of course where only the native formats are shown. Ah, a strange thing (to me at least) happens in _wrapped_ mode even for GRBG (which is supposed to be a _native_ color format for the device): I get the grayscale image at 1280x1024 instead of the color image; can this just be a bug somewhere in qv4l2 or lib4vl? The only thing I can think of is adding a v4l2 control (like a brightness control) for choosing which format to prioritize... and this control would be created by libv4l when in wrapped mode? Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpiqJ4ep4hg4.pgp Description: PGP signature
Re: OMAP3 ISP deadlocks on my new arm
2011/4/16 David Cohen daco...@gmail.com:
Hi Bastian,
On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht hec...@googlemail.com wrote:
Yeah!
S... when I initialized the the camera (loading a 108 bytes
register listing) I just let run the camera and sent images. So I
first realized a counter overflow if (count++ 10) after a few
seconds. But this seemed to be handled correctly (ignore and delete
HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
hang.
I modified my register listing so that the chip gets booted silently.
In
static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
.s_stream = framix_s_stream, ===
};
I correctly check the stream status now and enable/disable the camera
signals.
I am unsure whether the isp should be able to handle an ongoing data
stream independently of ISP_PIPELINE_STREAM_STOPPED.
streamoff should finish synchronously with last ongoing data. So, it
should have no ongoing data afterwards. Was that your question?
I formulated my reply a bit strange. I meant that that the ongoing
datastream from my camera module (even when the isp-stack is in
stream_stopped state) produces my problem. The question was if it
should be allowed for the camera to send data all time long or only
when it is told to do so by s_stream.
best regards,
Bastian Hecht
Br,
David Cohen
If you decide it should, I will gladly help you find out more, just
ask. It worked on an OMAP3530 before, but I do not know if it is the
hardware or isp software that changed. Unfortunately I can't get an
3530 anymore (I trashed mine...).
You helped me so much! Big thanks.
Bastian Hecht
2011/4/14 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
2011/4/13 Sakari Ailus sakari.ai...@maxwell.research.nokia.com:
Bastian Hecht wrote:
Hello people,
Hi Bastian,
I'm cc'ing Laurent.
I switched to the new DM3730 from IGEP and while it's supposed to be
(almost) the same as the 3530 Version the isp deadlocks
deterministically after I start capturing the second time with yavta.
Does the capture work the first time w/o issues?
Yes, I can always run yavta once capturing 4 frames (3 skipped, last
saved). It usually deadlocks when running yavta the second time but I had
1 successful 2nd try (out of 20 maybe).
All extra locking debug output is enabled in the kernel .config.
I'm not fully certain on what this exactly is that you have below, but
it looks like your system is staying in interrupt context all the time.
My guess is that the ISP is producing interrupts that the driver is not
handling properly, causing the interrupt handler to be called again
immediately.
Nice! OK, I'd like to fully understand the panic output, maybe you can
help there:
After
[ 376.016906] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44)
from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90
the IRQs get enabled again. Immediately our offending irq wants to get
served but noone is clearing it.
At some time, the timer interrupt triggers the watchdog for a kernel panic.
So the last exception block is the process context that is currently
active. But why are there 2 irq routines displayed? Is the middle one the
hardware handling that causes a software irq to be triggered (upper
block)?
So my next step could be to find the unhandled irq number?
If the problem is caused by an interrupt storm, the following patch will
make
your system responsive again after a couple of seconds (but will kill the
ISP
driver :-)). If it doesn't, the problem is likely caused by something else.
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index de2dec5..6497300 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
IRQ0STATUS_CCDC_VD0_IRQ |
IRQ0STATUS_CCDC_VD1_IRQ |
IRQ0STATUS_HS_VS_IRQ;
+ static unsigned int count = 0;
struct isp_device *isp = _isp;
u32 irqstatus;
int ret;
@@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
+ if (count++ 10) {
+ isp_disable_interrupts(isp);
+ return IRQ_HANDLED;
+ }
+
isp_isr_sbl(isp);
if (irqstatus IRQ0STATUS_CSIA_IRQ) {
Do you have the same sensor working on OMAP 3530?
I never had this problem on an OMAP 3530, although I better test it
again with the current setup. I try to get my hands on an 3530 today.
I am unsure if this is an ISP thing or a problem in the
interrupthandling
Resume freezes laptop with Nova-TD Stick dvb-t tuner
Hi It seems like there is something broken with dvb-t driver. Upon resume it requests firmware load - and this is freezing laptop. usb 3-2: new high speed USB device number 2 using ehci_hcd usb 3-2: New USB device found, idVendor=2040, idProduct=5200 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: NovaT 500Stick usb 3-2: Manufacturer: Hauppauge usb 3-2: SerialNumber: 4031595310 IR NEC protocol handler initialized IR RC5(x) protocol handler initialized IR RC6 protocol handler initialized IR JVC protocol handler initialized IR Sony protocol handler initialized lirc_dev: IR Remote Control driver registered, major 252 dib0700: loaded with support for 20 different device-types IR LIRC bridge handler initialized dvb-usb: found a 'Hauppauge Nova-TD Stick (52009)' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' dib0700: firmware started successfully. dvb-usb: found a 'Hauppauge Nova-TD Stick (52009)' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-TD Stick (52009)) -- SUSPEND RESUME -- ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out ata1.00: configured for UDMA/100 thinkpad_acpi: ACPI backlight control delay disabled PM: resume of devices complete after 3537.435 msecs dvb-usb: found a 'Hauppauge Nova-TD Stick (52009)' in cold state, will try to load a firmware thinkpad_acpi: fan watchdog: enabling fan -- From this discussion: http://marc.info/?l=linux-kernelm=130305862617225w=2 firmware must be kept in memory - and not loaded from disk on resume. Zdenek -- 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
DiB0700: get rid of on-stack dma buffers
Hi I''ve tested patch: 115ab9ed519fa45f553b1d32241eb28e01430f7f (http://git.linuxtv.org/pb/media_tree.git?a=commit;h=16b54de2d8b46e48c5c8bdf9b350eac04e8f6b46) And I still get: dib0700: firmware started successfully. dvb-usb: found a 'Hauppauge Nova-TD Stick (52009)' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-TD Stick (52009)) [ cut here ] WARNING: at lib/dma-debug.c:867 check_for_stack+0xb3/0xf0() Hardware name: 6464CTO ehci_hcd :00:1d.7: DMA-API: device driver maps memory fromstack [addr=880138b13bd6] Modules linked in: ir_lirc_codec dvb_usb_dib0700(+) lirc_dev dib7000p ir_sony_decoder dib7000m dib0070 ir_jvc_decoder dvb_usb ir_rc6_decoder dib8000 dvb_core ir_rc5_decoder ir_nec_decoder dib3000mc rc_core dibx000_common ip6_tables ebtable_nat ebtables iptable_mangle xt_tcpudp tun bridge ipv6 stp llc sunrpc bluetooth ipt_REJECT xt_physdev xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables snd_hda_codec_analog arc4 ecb crypto_blkcipher cryptomgr aead crypto_algapi iwl3945 iwl_legacy snd_hda_intel mac80211 snd_hda_codec snd_seq snd_seq_device psmouse serio_raw cfg80211 e1000e snd_pcm i2c_i801 iTCO_wdt thinkpad_acpi snd_timer iTCO_vendor_support snd_page_alloc wmi snd soundcore nvram evdev i915 dm_mirror dm_region_hash dm_log dm_mod drm_kms_helper drm i2c_algo_bit i2c_core autofs4 usbhid hid pcmcia sdhci_pci uhci_hcd sr_mod ehci_hcd sdhci yenta_socket mmc_core cdrom usbcore video backlight Pid: 1185, comm: modprobe Not tainted 2.6.39-rc3-00236-g115ab9e #7 Call Trace: [810501df] warn_slowpath_common+0x7f/0xc0 [810502d6] warn_slowpath_fmt+0x46/0x50 [81496d69] ? sub_preempt_count+0xa9/0xe0 [812a3713] check_for_stack+0xb3/0xf0 [812a3acf] debug_dma_map_page+0xff/0x150 [a00baea2] usb_hcd_map_urb_for_dma+0x522/0x590 [usbcore] [81496d69] ? sub_preempt_count+0xa9/0xe0 [a00bb055] usb_hcd_submit_urb+0x145/0x7e0 [usbcore] [8108b463] ? lockdep_init_map+0xb3/0x560 [a00bc3e4] usb_submit_urb+0xf4/0x390 [usbcore] [a00bd94c] usb_start_wait_urb+0x6c/0x170 [usbcore] [a00bc7d5] ? usb_init_urb+0x55/0xf0 [usbcore] [a00bdcd6] usb_control_msg+0xe6/0x120 [usbcore] [a0571404] ? dib0700_i2c_xfer+0x64/0x350 [dvb_usb_dib0700] [a0571404] ? dib0700_i2c_xfer+0x64/0x350 [dvb_usb_dib0700] [a0571368] dib0700_ctrl_rd+0x88/0xc0 [dvb_usb_dib0700] [a05714da] dib0700_i2c_xfer+0x13a/0x350 [dvb_usb_dib0700] [a0044f3a] i2c_transfer+0xaa/0x120 [i2c_core] [a055989e] dib7000p_read_word+0x6e/0xd0 [dib7000p] [a055adf1] dib7000p_identify+0x31/0x110 [dib7000p] [a055afcb] dib7000p_i2c_enumeration+0xfb/0x310 [dib7000p] [a0571082] ? dib0700_rc_urb_completion+0x12/0x140 [dvb_usb_dib0700] [a0573b6c] stk7070pd_frontend_attach0+0xfc/0x1c0 [dvb_usb_dib0700] [a04ed46e] dvb_usb_adapter_frontend_init+0x1e/0x110 [dvb_usb] [a04ec960] dvb_usb_device_init+0x390/0x670 [dvb_usb] [a0571fca] dib0700_probe+0x6a/0xe0 [dvb_usb_dib0700] [a00c10b6] usb_probe_interface+0xf6/0x250 [usbcore] [81354c2c] driver_probe_device+0x9c/0x2b0 [81354eeb] __driver_attach+0xab/0xb0 [81354e40] ? driver_probe_device+0x2b0/0x2b0 [81354e40] ? driver_probe_device+0x2b0/0x2b0 [81353a24] bus_for_each_dev+0x64/0xa0 [8135484e] driver_attach+0x1e/0x20 [81354440] bus_add_driver+0x1c0/0x2b0 [81355466] driver_register+0x76/0x140 [81298028] ? __raw_spin_lock_init+0x38/0x70 [a00bfe75] usb_register_driver+0xc5/0x1b0 [usbcore] [a058e000] ? 0xa058dfff [a058e034] dib0700_module_init+0x34/0x51 [dvb_usb_dib0700] [810001d2] do_one_initcall+0x42/0x180 [8109df6b] sys_init_module+0xab/0x200 [8149ac6b] system_call_fastpath+0x16/0x1b ---[ end trace 5934ecdc00d47ffa ]--- DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... DiB0070: successfully identified dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-TD Stick (52009)) (as reported in https://bugzilla.kernel.org/show_bug.cgi?id=15977) Also the stick is impossible to suspend resume while it's in use: (essentially suspend led keeps flashing) [ 67.456753] PM: Syncing filesystems ... done. [ 67.471267] PM: Preparing system for mem sleep [ 67.478857] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 67.499501] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 67.519556] PM: Entering mem sleep [ 67.523442] uhci_hcd :00:1a.1: power state changed by ACPI to D0 [ 67.529871] uhci_hcd :00:1a.1: power state changed by ACPI to D0 [ 67.536396] uhci_hcd :00:1a.1:
RE: [RFC/PATCH v3 0/7] Samsung IOMMU videobuf2 allocator and s5p-fimc update
Hello, On Monday, April 18, 2011 11:27 AM Marek Szyprowski wrote: This is a third version of the Samsung IOMMU driver (see patch #2) and videobuf2 allocator for IOMMU mapped memory (see patch #4) as well as FIMC driver update. This update brings some minor bugfixes to Samsung IOMMU (SYSMMU) driver and support for pages larger than 4KiB in videobuf2-dma-iommu allocator. snip This patch series contains a collection of patches for various platform subsystems. Here is a detailed list: [PATCH 1/7] ARM: EXYNOS4: power domains: fixes and code cleanup - adds support for block gating in Samsung power domain driver and performs some cleanup [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver - a complete rewrite of sysmmu driver for Samsung platform, now uses linux/include/iommu.h api (key patch in this series) [PATCH 3/7] v4l: videobuf2: dma-sg: move some generic functions to memops - a little cleanup and preparations for the dma-iommu allocator [PATCH 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator - introduces new memory allocator for videobuf2 for drivers that support iommu dma memory mappings (key patch in this series) I was in a bit hurry and I forgot to mention that the above patch relies on some improvements to gen_alloc framework. The required 2 patches can be found in the following patch series: https://lkml.org/lkml/2011/3/31/213 [PATCH 01/12] lib: bitmap: Added alignment offset for bitmap_find_next_zero_area() https://lkml.org/lkml/2011/3/31/211 [PATCH 02/12] lib: genalloc: Generic allocator improvements https://lkml.org/lkml/2011/3/31/207 For easier testing I've uploaded the whole IOMMU patch series and prerequisites to public GIT repository to vb2-iommu branch (will be available in a about 2 hours): http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/vb2- iommu git://git.infradead.org/users/kmpark/linux-2.6-samsung vb2-iommu Best regards -- Marek Szyprowski 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: stb0899 signal strength value in dvb-s2l
On 04/16/2011 09:07 PM, Lutz Sammer wrote: Using a KNC-1 DVB-S2 board I noticed stb0899_read_signal_strength() in stb0899_drv.c always return the same value (1450) in dvb-s2 whatever the signal power is. It seems STB0899_READ_S2REG(STB0899_DEMOD, IF_AGC_GAIN) macro always returns zero. Any idea of what is causing this ? Try - reg = STB0899_READ_S2REG(STB0899_DEMOD, IF_AGC_GAIN); + reg = STB0899_READ_S2REG(STB0899_S2DEMOD, IF_AGC_GAIN); Than it is working, Indeed it works. We should commit that. Thanks for helping ! -- Florent AUDEBERT -- 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: soc_camera with V4L2 driver
Hello Guennadi,
Sorry for the sudden email but may I have your advice on soc_camera?
You can have a look at another driver
for a Sharp camera sensor:
drivers/media/video/rj54n1cb0c.c
and at its platform glue in arch/sh/boards/mach-kfr2r09/setup.c, there you
find
struct platform_device kfr2r09_camera
which links to
struct soc_camera_link rj54n1_link
The ARM cpu is made by Renesas.
Then, perhaps, something similar to
arch/arm/mach-shmobile/board-ap4evb.c
Thank you for your suggestion, I was able to bind my driver
with soc_camera(I believe...).
I attached my draft driver files at the end of this email
for any suggestions.
In the beginning, I would like to explain the fundamental
information.
1) 2 megapixel camera module is connected to
the ARM board, Renesas ag5evm, through I2C.
arch/arm/mach-shmobile/board-ag5evm.c
2) The camera module is connected to CEU on the ag5evm.
3) I followed your instruction to bind the camera
sensor driver to soc_camera as attached and
builds and boots fine.
4) I have not received the data sheet from the vender
for the camera yet ;)
5) But I have the prototype board on my hand.
6) I can not implement the details of the driver without
the data sheet but would like to start implement the
outline, so I could save my time while I am waiting
for the data sheet.
Also,
I would like to know, if I need to bind to
sh_mobile_ceu_camera.c
too, and how, because the camera is connected to CEU.
(I never knew the word CEU until I started to work with
this project...)
Thank you and best regards,
Akira
- rj65na20.c
/*
* Copyright (C) 2011 Nomovok Ltd.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include linux/slab.h
#include linux/delay.h
#include linux/i2c.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/soc_camera.h
#include media/soc_mediabus.h
MODULE_DESCRIPTION(Sharp RJ65NA20 sensor driver);
MODULE_AUTHOR(Akira Tsukamoto akira.tsukam...@nomovok.com);
MODULE_LICENSE(GPL);
static int debug;
module_param(debug, int, 1);
MODULE_PARM_DESC(debug, Debug level (0-1));
/*
* TODO This should go inside the following
* include/media/v4l2-chip-ident.h
*/
/* Sharp RJ65NA20, 0x = ?? */
#define V4L2_IDENT_RJ65NA20 00
#define I2C_WRITE_BYTES 2
#define I2C_READ_BYTES 1
#define R00_RJ65NA20_CHIP_VERSION 0x00 /* TODO fix me when after
receiving data sheet */
#define R00 0x00
#define R01 0x01
#define RJ65NA20_VERSION0x01
#define RJ65NA20_WIDTH 1600
#define RJ65NA20_HEIGHT 1200
/* supported controls */
static struct v4l2_queryctrl rj65na20_qctrl[] = { /* TODO fix me when after
receiving data sheet */
{
.id = V4L2_CID_AUTO_WHITE_BALANCE,
.type= V4L2_CTRL_TYPE_BOOLEAN,
.name= Auto White Balance,
.minimum = 0,
.maximum = 1,
.step= 1,
.default_value = 1,
.flags = 0,
}, {
.id = V4L2_CID_EXPOSURE_AUTO,
.type= V4L2_CTRL_TYPE_INTEGER,
.name= Auto Exposure,
.minimum = 0,
.maximum = 1,
.step= 1,
.default_value = 1,
.flags = 0,
}, {
.id = V4L2_CID_HFLIP,
.type= V4L2_CTRL_TYPE_BOOLEAN,
.name= Mirror,
.minimum = 0,
.maximum = 1,
.step= 1,
.default_value = 0,
.flags = 0,
}, {
.id = V4L2_CID_VFLIP,
.type= V4L2_CTRL_TYPE_BOOLEAN,
.name= Vflip,
.minimum = 0,
.maximum = 1,
.step= 1,
.default_value = 0,
.flags = 0,
}, {
}
};
struct rj65na20 {
struct v4l2_subdev sd;
unsigned int width, height;
unsigned int autowhitebalance:1;
unsigned int autoexposure:1;
unsigned int hflip:1;
unsigned int vflip:1;
};
static inline struct rj65na20
Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Monday 18 April 2011, Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- simplified the resource management: no more single platform
device with 32 resources is needed, better fits into linux driver model,
each sysmmu instance has it's own resource definition
- the new version uses kernel wide common iommu api defined in include/iommu.h
- cleaned support for sysmmu clocks
- added support for custom fault handlers and tlb replacement policy
Looks like good progress, but I fear that there is still quite a bit more
work needed here.
+static int debug;
+module_param(debug, int, 0644);
+
+#define sysmmu_debug(level, fmt, arg...)\
+ do { \
+ if (debug = level) \
+ printk(KERN_DEBUG [%s] fmt, __func__, ## arg);\
+ } while (0)
Just use dev_dbg() here, the kernel already has all the infrastructure.
+
+#define generic_extract(l, s, entry) \
+ ((entry) l##LPT_##s##_MASK)
+#define flpt_get_1m(entry) generic_extract(F, 1M, deref_va(entry))
+#define flpt_get_16m(entry)generic_extract(F, 16M, deref_va(entry))
+#define slpt_get_4k(entry) generic_extract(S, 4K, deref_va(entry))
+#define slpt_get_64k(entry)generic_extract(S, 64K, deref_va(entry))
+
+#define generic_entry(l, s, entry) \
+ (generic_extract(l, s, entry) | PAGE_##s)
+#define flpt_ent_4k_64k(entry) generic_entry(F, 4K_64K, entry)
+#define flpt_ent_1m(entry) generic_entry(F, 1M, entry)
+#define flpt_ent_16m(entry)generic_entry(F, 16M, entry)
+#define slpt_ent_4k(entry) generic_entry(S, 4K, entry)
+#define slpt_ent_64k(entry)generic_entry(S, 64K, entry)
+
+#define page_4k_64k(entry) (deref_va(entry) PAGE_4K_64K)
+#define page_1m(entry) (deref_va(entry) PAGE_1M)
+#define page_16m(entry)((deref_va(entry) PAGE_16M) ==
PAGE_16M)
+#define page_4k(entry) (deref_va(entry) PAGE_4K)
+#define page_64k(entry)(deref_va(entry) PAGE_64K)
+
+#define generic_pg_offs(l, s, va) \
+ (va ~l##LPT_##s##_MASK)
+#define pg_offs_1m(va) generic_pg_offs(F, 1M, va)
+#define pg_offs_16m(va)generic_pg_offs(F, 16M, va)
+#define pg_offs_4k(va) generic_pg_offs(S, 4K, va)
+#define pg_offs_64k(va)generic_pg_offs(S, 64K, va)
+
+#define flpt_index(va) (((va) FLPT_IDX_SHIFT) FLPT_IDX_MASK)
+
+#define generic_offset(l, va) (((va) l##LPT_OFFS_SHIFT)
l##LPT_OFFS_MASK)
+#define flpt_offs(va) generic_offset(F, va)
+#define slpt_offs(va) generic_offset(S, va)
+
+#define invalidate_slpt_ent(slpt_va) (deref_va(slpt_va) = 0UL)
+
+#define get_irq_callb(cb) \
+ (s5p_domain-irq_callb ? \
+ (s5p_domain-irq_callb-cb ? \
+ s5p_domain-irq_callb-cb : \
+ s5p_sysmmu_irq_callb.cb) \
+ : s5p_sysmmu_irq_callb.cb)
These macros are really confusing, especially the ones that implicitly
access variables with a specific name. How about converting them into
inline functions?
+phys_addr_t s5p_iova_to_phys(struct iommu_domain *domain, unsigned long iova)
This should be static.
+struct device *s5p_sysmmu_get(enum s5p_sysmmu_ip ip)
+{
+ struct device *ret = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(sysmmu_slock, flags);
+ if (sysmmu_table[ip]) {
+ try_module_get(THIS_MODULE);
+ ret = sysmmu_table[ip]-dev;
+ }
+ spin_unlock_irqrestore(sysmmu_slock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(s5p_sysmmu_get);
+
+void s5p_sysmmu_put(void *dev)
+{
+ BUG_ON(!dev);
+ module_put(THIS_MODULE);
+}
+EXPORT_SYMBOL_GPL(s5p_sysmmu_put);
These look wrong for a number of reasons:
* try_module_get(THIS_MODULE) makes no sense at all, the idea of the
try_module_get is to pin down another module that was calling down,
which I suppose is not needed here.
* This extends the generic IOMMU API in platform specific ways, don't
do that.
* I think you can do without these functions by including a pointer
to the iommu structure in dev_archdata, see
arch/powerpc/include/asm/device.h for an example.
+void s5p_sysmmu_domain_irq_callb(struct iommu_domain *domain,
+ struct s5p_sysmmu_irq_callb *ops, void *priv)
+{
+ struct s5p_sysmmu_domain *s5p_domain = domain-priv;
+ s5p_domain-irq_callb = ops;
+ s5p_domain-irq_callb_priv = priv;
+}
+EXPORT_SYMBOL(s5p_sysmmu_domain_irq_callb);
+
+
+void
Re: Wrong tv tuner card detedted
lsusb result is madhur@madhur-desktop:~$ lsusb Bus 005 Device 003: ID 12d1:140b Huawei Technologies Co., Ltd. EC1260 Wireless Data Modem HSD USB Card Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID eb1a:2860 eMPIA Technology, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub madhur@madhur-desktop:~$ Also when i am doing dmesg then it saying 712.469413] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 712.480166] em28xx #0: found i2c device @ 0x4a [saa7113h] [ 712.491657] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 712.496156] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 712.504280] em28xx #0: Your board has no unique USB ID. Waiting for your reply Thanks Madhur On Sat, Apr 9, 2011 at 9:51 PM, Another Sillyname anothersn...@googlemail.com wrote: On 09/04/2011, Madhur Jajoo jajoo.mad...@gmail.com wrote: Hi, I am using Ubuntu 10.10. I have Gadmei UTV300 USB TV Tuner card. When i am trying to do dmesg it saying card is detected as gadmei UTV330+ I have attached full log of the command. I am using tvtime software. I see that my tvtuner card is getting started (through LED) when i start tvtime. But it says No signal. Can you please help me out of this ? Please find attached [ 3523.461728] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x274ad199 [ 3523.461731] em28xx #0: EEPROM info: [ 3523.461733] em28xx #0: No audio on board. [ 3523.461736] em28xx #0: 500mA max power [ 3523.461739] em28xx #0: Table at 0x06, strings=0x226a, 0x108c, 0x [ 3523.472475] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 3523.484848] em28xx #0: found i2c device @ 0x4a [saa7113h] [ 3523.499345] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 3523.503842] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 3523.515217] em28xx #0: Your board has no unique USB ID. [ 3523.515222] em28xx #0: A hint were successfully done, based on i2c devicelist hash. [ 3523.515225] em28xx #0: This method is not 100% failproof. [ 3523.515228] em28xx #0: If the board were missdetected, please email this log to: [ 3523.515230] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 3523.515233] em28xx #0: Board detected as Gadmei UTV330+ [ 3523.876422] saa7115 1-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) [ 3524.588691] All bytes are equal. It is not a TEA5767 [ 3524.588904] tuner 1-0060: chip found @ 0xc0 (em28xx #0) [ 3524.589567] tuner-simple 1-0060: creating new instance [ 3524.589572] tuner-simple 1-0060: type set to 69 (Tena TNF 5335 and similar models) [ 3524.624020] Registered IR keymap rc-gadmei-rm008z [ 3524.624199] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb1/1-7/rc/rc0/input7 [ 3524.624378] rc0: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb1/1-7/rc/rc0 [ 3524.636187] em28xx #0: Config register raw data: 0xc0 [ 3524.684030] em28xx #0: v4l2 driver version 0.1.2 [ 3525.176259] em28xx #0: V4L2 video device registered as video0 [ 3525.176266] em28xx #0: V4L2 VBI device registered as vbi0 Waiting for your reply. Thanks Madhur Can you do a lsusb and report the results. -- 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: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, 11 Apr 2011, Eric B Munson wrote: On Sun, 10 Apr 2011, Andy Walls wrote: On Wed, 2011-04-06 at 13:28 -0400, Eric B Munson wrote: On Tue, Apr 5, 2011 at 10:58 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 14:36 -0400, Eric B Munson wrote: On Mon, Apr 4, 2011 at 11:16 AM, Eric B Munson emun...@mgebm.net wrote: On Mon, Apr 4, 2011 at 9:12 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 08:20 -0400, Eric B Munson wrote: I the above mentioned capture card and the digital side of the card works well. However, when I try to get video from the analog side of the card, all I get is a red screen and no sound regardless of channel requested. This is a problem I see in 2.6.39-rc1 though I typically run the ubuntu 10.10 kernel with the newest drivers built from source. Is there something in setup or configuration that I may be missing? Eric, You are likely missing the last 3 fixes here: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/cx18_39 (one of which is critical for analog to work). Also check the ivtv-users and ivtv-devel list for past discussions on the red screen showing up for known well supported models and what to try. Thanks, I will try hand applying these. I don't have a red screen anymore, now all get from analog static and mythtv's digital channel scanner now seems broken. Hmmm. 1. Please provide the output of dmesg when the cx18 driver loads. [332935.115343] cx18: Start initialization, version 1.4.1 [332935.115385] cx18-0: Initializing card 0 [332935.115389] cx18-0: Autodetected Hauppauge card [332935.115449] cx18 :04:01.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [332935.127005] cx18-0: cx23418 revision 0101 (B) [332935.342426] tveeprom 0-0050: Hauppauge model 74351, rev F1F5, serial# 7384278 [332935.342432] tveeprom 0-0050: MAC address is 00:0d:fe:70:ac:d6 [332935.342437] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54) [332935.342443] tveeprom 0-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) [332935.342448] tveeprom 0-0050: audio processor is CX23418 (idx 38) [332935.342453] tveeprom 0-0050: decoder processor is CX23418 (idx 31) [332935.342457] tveeprom 0-0050: has no radio [332935.342460] cx18-0: Autodetected Hauppauge HVR-1600 [332935.392016] cx18-0: Simultaneous Digital and Analog TV capture supported [332935.497007] tuner 1-0042: Tuner -1 found with type(s) Radio TV. [332935.501259] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [332935.548567] tda829x 1-0042: setting tuner address to 60 [332935.572554] tda18271 1-0060: creating new instance [332935.612568] TDA18271HD/C2 detected @ 1-0060 [332936.676587] tda18271: performing RF tracking filter calibration [332950.816567] tda18271: RF tracking filter calibration complete [332950.864571] tda829x 1-0042: type set to tda8295+18271 [332951.569137] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB) [332951.569143] DVB: registering new adapter (cx18) [332951.672187] tda18271 0-0060: creating new instance [332951.678691] TDA18271HD/C2 detected @ 0-0060 [332951.737797] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) [332951.876157] cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 bytes) [332951.882195] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) [332951.984040] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [332951.984208] cx18-0: DVB Frontend registered [332951.984214] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB) [332951.984268] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB) [332951.984320] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes) [332951.984367] cx18-0: Registered device video24 for encoder PCM audio (256 x 4.00 kB) [332951.984372] cx18-0: Initialized card: Hauppauge HVR-1600 [332951.984415] cx18: End initialization [332951.994916] cx18-alsa: module loading... [332952.733994] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes) [332952.753703] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes) 3. Please provide the relevant portion of the mythbackend log where where the digital scanner starts and then fails. So the Digital scanner doesn't fail per se, it just doesn't pick up most of the digital channels available. The same is true of scan, it seems to find only 1 channel when I know that I have access to 18. Make sure it's not a signal integrity problem: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality wild speculation: If the analog tuner driver init failed, maybe that is having some bad EMI efect on the digital
Re: [PATCH 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator
On Monday 18 April 2011, Marek Szyprowski wrote: From: Andrzej Pietrasiewicz andrze...@samsung.com This patch adds new videobuf2 memory allocator dedicated to devices that supports IOMMU DMA mappings. A device with IOMMU module and a driver with include/iommu.h compatible interface is required. This allocator aquires memory with standard alloc_page() call and doesn't suffer from memory fragmentation issues. The allocator support following page sizes: 4KiB, 64KiB, 1MiB and 16MiB to reduce iommu translation overhead. My feeling is that this is not the right abstraction. Why can't you just implement the regular dma-mapping.h interfaces for your IOMMU so that the videobuf code can use the existing allocators? Arnd -- 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: OMAP3 ISP deadlocks on my new arm
On Mon, Apr 18, 2011 at 1:43 PM, Bastian Hecht hec...@googlemail.com wrote:
2011/4/16 David Cohen daco...@gmail.com:
Hi Bastian,
On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht hec...@googlemail.com wrote:
Yeah!
S... when I initialized the the camera (loading a 108 bytes
register listing) I just let run the camera and sent images. So I
first realized a counter overflow if (count++ 10) after a few
seconds. But this seemed to be handled correctly (ignore and delete
HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
hang.
I modified my register listing so that the chip gets booted silently.
In
static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
.s_stream = framix_s_stream, ===
};
I correctly check the stream status now and enable/disable the camera
signals.
I am unsure whether the isp should be able to handle an ongoing data
stream independently of ISP_PIPELINE_STREAM_STOPPED.
streamoff should finish synchronously with last ongoing data. So, it
should have no ongoing data afterwards. Was that your question?
I formulated my reply a bit strange. I meant that that the ongoing
datastream from my camera module (even when the isp-stack is in
stream_stopped state) produces my problem. The question was if it
should be allowed for the camera to send data all time long or only
when it is told to do so by s_stream.
I may assume you are mentioning a pipeline which includes camera
sensor + ISP. In this case there should be no data.
Regards,
David
best regards,
Bastian Hecht
Br,
David Cohen
If you decide it should, I will gladly help you find out more, just
ask. It worked on an OMAP3530 before, but I do not know if it is the
hardware or isp software that changed. Unfortunately I can't get an
3530 anymore (I trashed mine...).
You helped me so much! Big thanks.
Bastian Hecht
2011/4/14 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
2011/4/13 Sakari Ailus sakari.ai...@maxwell.research.nokia.com:
Bastian Hecht wrote:
Hello people,
Hi Bastian,
I'm cc'ing Laurent.
I switched to the new DM3730 from IGEP and while it's supposed to be
(almost) the same as the 3530 Version the isp deadlocks
deterministically after I start capturing the second time with yavta.
Does the capture work the first time w/o issues?
Yes, I can always run yavta once capturing 4 frames (3 skipped, last
saved). It usually deadlocks when running yavta the second time but I had
1 successful 2nd try (out of 20 maybe).
All extra locking debug output is enabled in the kernel .config.
I'm not fully certain on what this exactly is that you have below, but
it looks like your system is staying in interrupt context all the time.
My guess is that the ISP is producing interrupts that the driver is not
handling properly, causing the interrupt handler to be called again
immediately.
Nice! OK, I'd like to fully understand the panic output, maybe you can
help there:
After
[ 376.016906] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44)
from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90
the IRQs get enabled again. Immediately our offending irq wants to get
served but noone is clearing it.
At some time, the timer interrupt triggers the watchdog for a kernel
panic.
So the last exception block is the process context that is currently
active. But why are there 2 irq routines displayed? Is the middle one the
hardware handling that causes a software irq to be triggered (upper
block)?
So my next step could be to find the unhandled irq number?
If the problem is caused by an interrupt storm, the following patch will
make
your system responsive again after a couple of seconds (but will kill the
ISP
driver :-)). If it doesn't, the problem is likely caused by something else.
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index de2dec5..6497300 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
IRQ0STATUS_CCDC_VD0_IRQ |
IRQ0STATUS_CCDC_VD1_IRQ |
IRQ0STATUS_HS_VS_IRQ;
+ static unsigned int count = 0;
struct isp_device *isp = _isp;
u32 irqstatus;
int ret;
@@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN,
ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN,
ISP_IRQ0STATUS);
+ if (count++ 10) {
+ isp_disable_interrupts(isp);
+ return IRQ_HANDLED;
+ }
+
isp_isr_sbl(isp);
if (irqstatus IRQ0STATUS_CSIA_IRQ) {
Do you have the same sensor working on OMAP
Re: soc_camera with V4L2 driver
Hello Akira
On Mon, 18 Apr 2011, Akira Tsukamoto wrote:
Hello Guennadi,
Sorry for the sudden email but may I have your advice on soc_camera?
You can have a look at another driver
for a Sharp camera sensor:
drivers/media/video/rj54n1cb0c.c
and at its platform glue in arch/sh/boards/mach-kfr2r09/setup.c, there you
find
struct platform_device kfr2r09_camera
which links to
struct soc_camera_link rj54n1_link
The ARM cpu is made by Renesas.
Then, perhaps, something similar to
arch/arm/mach-shmobile/board-ap4evb.c
Thank you for your suggestion, I was able to bind my driver
with soc_camera(I believe...).
I attached my draft driver files at the end of this email
for any suggestions.
Thanks for attaching your sources.
In the beginning, I would like to explain the fundamental
information.
1) 2 megapixel camera module is connected to
the ARM board, Renesas ag5evm, through I2C.
arch/arm/mach-shmobile/board-ag5evm.c
2) The camera module is connected to CEU on the ag5evm.
3) I followed your instruction to bind the camera
sensor driver to soc_camera as attached and
builds and boots fine.
4) I have not received the data sheet from the vender
for the camera yet ;)
5) But I have the prototype board on my hand.
6) I can not implement the details of the driver without
the data sheet but would like to start implement the
outline, so I could save my time while I am waiting
for the data sheet.
Also,
I would like to know, if I need to bind to
sh_mobile_ceu_camera.c
too, and how, because the camera is connected to CEU.
Yes, you do. Look at the board-ap4evb and board-mackerel files at
everything, containing the ceu string in it. The former configures a
serially connected camera sensor over the MIPI CSI-2 bus, the latter over
the parallel interface.
I haven't reviewed your sources in detail, just two comments, regarding
something, that caught my eye:
(I never knew the word CEU until I started to work with
this project...)
Thank you and best regards,
Akira
[snip]
--- linux_kernel_bsp/arch/arm/mach-shmobile/board-ag5evm.c2011-03-22
12:30:14.0 +0900
+++ linux_kernel/arch/arm/mach-shmobile/board-ag5evm.c2011-04-18
14:39:20.0 +0900
@@ -59,6 +59,7 @@
#include sound/sh_fsi.h
#include video/sh_mobile_lcdc.h
+#include media/soc_camera.h
static struct r8a66597_platdata usb_host_data = {
.on_chip= 1,
@@ -317,11 +318,38 @@ static struct platform_device fsi_device
},
};
+static struct i2c_board_info rj65na20_info = {
+ I2C_BOARD_INFO(rj65na20, 0x40),
+};
+
+struct soc_camera_link rj65na20_link = {
+ .bus_id = 0,
+ .board_info = rj65na20_info,
+ .i2c_adapter_id = 0,
+ .module_name= rj65na20,
+};
+
+static struct platform_device rj65na20_camera = {
+ .name = soc-camera-pdrv-2M,
This name has to match with what's advertised in
drivers/media/video/soc_camera.c, namely soc-camera-pdrv
+ .id = 0,
+ .dev= {
+ .platform_data = rj65na20_link,
+ },
+};
+
static struct i2c_board_info i2c0_devices[] = {
{
I2C_BOARD_INFO(ag5evm_ts, 0x20),
.irq= pint2irq(12), /* PINTC3 */
},
+ /* 2M camera */
+ {
+ I2C_BOARD_INFO(rj65na20, 0x40),
+ },
No, you do not have to include this here, the sensor must not be registered
automatically during the board initialisation.
Thanks
Guennadi
};
static struct i2c_board_info i2c1_devices[] = {
@@ -548,6 +576,8 @@ static struct platform_device *ag5evm_de
usb_mass_storage_device,
android_usb_device,
+
+ rj65na20_camera,
};
static struct map_desc ag5evm_io_desc[] __initdata = {
@@ -748,6 +778,7 @@ static void __init ag5evm_init(void)
struct clk *sub_clk = clk_get(NULL, sub_clk);
struct clk *extal2_clk = clk_get(NULL, extal2);
struct clk *fsia_clk = clk_get(NULL, fsia_clk);
+ struct clk *vck1_clk = clk_get(NULL, vck1_clk);
clk_set_parent(sub_clk, extal2_clk);
__raw_writel(__raw_readl(SUBCKCR) ~(19), SUBCKCR);
@@ -853,6 +884,43 @@ static void __init ag5evm_init(void)
__raw_writel(0x2a8b9111, DSI1PHYCR);
clk_enable(clk_get(NULL, dsi-tx));
+ /* 2M camera */
+ gpio_request(GPIO_PORT44, NULL);
+ gpio_direction_output(GPIO_PORT44, 0);
+ udelay(10);
+ gpio_set_value(GPIO_PORT44, 1);
+
/* Unreset LCD Panel */
gpio_request(GPIO_PORT217, NULL);
gpio_direction_output(GPIO_PORT217, 0);
--
Akira Tsukamoto
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wrong tv tuner card detedted
On Mon, Apr 18, 2011 at 10:11 AM, Madhur Jajoo jajoo.mad...@gmail.com wrote: lsusb result is madhur@madhur-desktop:~$ lsusb Bus 005 Device 003: ID 12d1:140b Huawei Technologies Co., Ltd. EC1260 Wireless Data Modem HSD USB Card Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID eb1a:2860 eMPIA Technology, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub madhur@madhur-desktop:~$ Also when i am doing dmesg then it saying 712.469413] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 712.480166] em28xx #0: found i2c device @ 0x4a [saa7113h] [ 712.491657] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 712.496156] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 712.504280] em28xx #0: Your board has no unique USB ID. Waiting for your reply Hello Madhur, Basically, the dmesg means the device is totally unsupported. The only reason it detects at all is because the vendor used the chipset vendor's USB PID/VID instead of issuing their own. Regards, 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: OMAP3 ISP deadlocks on my new arm
On Monday 18 April 2011 16:17:15 David Cohen wrote:
On Mon, Apr 18, 2011 at 1:43 PM, Bastian Hecht wrote:
2011/4/16 David Cohen:
On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht wrote:
Yeah!
S... when I initialized the the camera (loading a 108 bytes
register listing) I just let run the camera and sent images. So I
first realized a counter overflow if (count++ 10) after a few
seconds. But this seemed to be handled correctly (ignore and delete
HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
hang.
I modified my register listing so that the chip gets booted silently.
In
static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
.s_stream = framix_s_stream, ===
};
I correctly check the stream status now and enable/disable the camera
signals.
I am unsure whether the isp should be able to handle an ongoing data
stream independently of ISP_PIPELINE_STREAM_STOPPED.
streamoff should finish synchronously with last ongoing data. So, it
should have no ongoing data afterwards. Was that your question?
I formulated my reply a bit strange. I meant that that the ongoing
datastream from my camera module (even when the isp-stack is in
stream_stopped state) produces my problem. The question was if it
should be allowed for the camera to send data all time long or only
when it is told to do so by s_stream.
I may assume you are mentioning a pipeline which includes camera
sensor + ISP. In this case there should be no data.
That's the ideal situation: sensors should not produce any data (or rather any
transition on the VS/HS signals) when they're supposed to be stopped.
Unfortunately that's not always easy, as some dumb sensors (or sensor-like
hardware) can't be stopped. The ISP driver should be able to cope with that in
a way that doesn't kill the system completely.
I've noticed the same issue with a Caspa camera module and an OMAP3503-based
Gumstix. I'll try to come up with a good fix.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wrong tv tuner card detedted
Hi Devin, Thanks for the reply. How can i make it work ? Is there any wayout? Thanks Madhur On Mon, Apr 18, 2011 at 7:51 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Apr 18, 2011 at 10:11 AM, Madhur Jajoo jajoo.mad...@gmail.com wrote: lsusb result is madhur@madhur-desktop:~$ lsusb Bus 005 Device 003: ID 12d1:140b Huawei Technologies Co., Ltd. EC1260 Wireless Data Modem HSD USB Card Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID eb1a:2860 eMPIA Technology, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub madhur@madhur-desktop:~$ Also when i am doing dmesg then it saying 712.469413] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 712.480166] em28xx #0: found i2c device @ 0x4a [saa7113h] [ 712.491657] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 712.496156] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 712.504280] em28xx #0: Your board has no unique USB ID. Waiting for your reply Hello Madhur, Basically, the dmesg means the device is totally unsupported. The only reason it detects at all is because the vendor used the chipset vendor's USB PID/VID instead of issuing their own. Regards, 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: Wrong tv tuner card detedted
On Mon, Apr 18, 2011 at 10:28 AM, Madhur Jajoo jajoo.mad...@gmail.com wrote: Hi Devin, Thanks for the reply. How can i make it work ? Is there any wayout? Thanks Madhur Unless you're familiar with device driver development, there isn't really any solution for you. The driver needs to be extended to support whatever tuner chip, demodulator, and video decoder the device has. 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: soc_camera with V4L2 driver
Hello Guennadi,
Also,
I would like to know, if I need to bind to
sh_mobile_ceu_camera.c
too, and how, because the camera is connected to CEU.
Yes, you do. Look at the board-ap4evb and board-mackerel files at
everything, containing the ceu string in it. The former configures a
serially connected camera sensor over the MIPI CSI-2 bus, the latter over
the parallel interface.
Thank you, I will definitely look into those files about ceu.
+static struct platform_device rj65na20_camera = {
+ .name = soc-camera-pdrv-2M,
This name has to match with what's advertised in
drivers/media/video/soc_camera.c, namely soc-camera-pdrv
I will fix it.
static struct i2c_board_info i2c0_devices[] = {
{
I2C_BOARD_INFO(ag5evm_ts, 0x20),
.irq= pint2irq(12), /* PINTC3 */
},
+ /* 2M camera */
+ {
+ I2C_BOARD_INFO(rj65na20, 0x40),
+ },
No, you do not have to include this here, the sensor must not be registered
automatically during the board initialisation.
Thank you for your review. It is already midnight in Tokyo,
so I will try it first in the morning tomorrow.
With kind regards,
FYI:
the ARM board, Renesas, through I2C.
arch/arm/mach-shmobile/board-ag5evm.c
This file is temporal situation just for me to start with.
Akira
--
Akira Tsukamoto
--
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
Embedded Linux memory management interest group list
Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse -- 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: soc_camera with V4L2 driver
Hello Guennadi,
static struct i2c_board_info i2c0_devices[] = {
{
I2C_BOARD_INFO(ag5evm_ts, 0x20),
.irq= pint2irq(12), /* PINTC3 */
},
+ /* 2M camera */
+ {
+ I2C_BOARD_INFO(rj65na20, 0x40),
+ },
No, you do not have to include this here, the sensor must not be registered
automatically during the board initialisation.
I have one more question before sleeping :)
The camera module needs to be initialized by writing values to the registers.
Do I need to write init function at the following?
static const struct v4l2_subdev_core_ops rj65na20_core_ops = {
.reset = rj65na20_reset,
[snip]
}
With kind regards,
Akira
--
Akira Tsukamoto
--
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: soc_camera with V4L2 driver
On Tue, 19 Apr 2011, Akira Tsukamoto wrote:
Hello Guennadi,
static struct i2c_board_info i2c0_devices[] = {
{
I2C_BOARD_INFO(ag5evm_ts, 0x20),
.irq= pint2irq(12), /* PINTC3 */
},
+ /* 2M camera */
+ {
+ I2C_BOARD_INFO(rj65na20, 0x40),
+ },
No, you do not have to include this here, the sensor must not be
registered
automatically during the board initialisation.
I have one more question before sleeping :)
The camera module needs to be initialized by writing values to the registers.
Do I need to write init function at the following?
static const struct v4l2_subdev_core_ops rj65na20_core_ops = {
.reset = rj65na20_reset,
[snip]
}
AFAICS neither soc_camera.c, nor sh_mobile_ceu_camera.c call the .reset
subdevice core method, so, no, at the moment implementing it wouldn't
produce any result. Either you have to choose one of the methods, that are
currently called, or you have to add a call to .reset() as required.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: soc_camera with V4L2 driver
On Tue, 19 Apr 2011, Akira Tsukamoto wrote:
Hello Guennadi,
static struct i2c_board_info i2c0_devices[] = {
{
I2C_BOARD_INFO(ag5evm_ts, 0x20),
.irq= pint2irq(12), /* PINTC3 */
},
+ /* 2M camera */
+ {
+ I2C_BOARD_INFO(rj65na20, 0x40),
+ },
No, you do not have to include this here, the sensor must not be
registered
automatically during the board initialisation.
I have one more question before sleeping :)
The camera module needs to be initialized by writing values to the
registers.
Do I need to write init function at the following?
static const struct v4l2_subdev_core_ops rj65na20_core_ops = {
.reset = rj65na20_reset,
[snip]
}
AFAICS neither soc_camera.c, nor sh_mobile_ceu_camera.c call the .reset
subdevice core method, so, no, at the moment implementing it wouldn't
produce any result. Either you have to choose one of the methods, that are
currently called, or you have to add a call to .reset() as required.
I don't really like the use of reset for this. The reset op is a pretty
poorly defined op. There is a registration op as well these days that
might be better suited for this (see struct v4l2_subdev_internal_ops).
Regards,
Hans
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: HVR-1600 (model 74351 rev F1F5) analog Red Screen
Eric B Munson emun...@mgebm.net wrote: On Mon, 11 Apr 2011, Eric B Munson wrote: On Sun, 10 Apr 2011, Andy Walls wrote: On Wed, 2011-04-06 at 13:28 -0400, Eric B Munson wrote: On Tue, Apr 5, 2011 at 10:58 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 14:36 -0400, Eric B Munson wrote: On Mon, Apr 4, 2011 at 11:16 AM, Eric B Munson emun...@mgebm.net wrote: On Mon, Apr 4, 2011 at 9:12 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 08:20 -0400, Eric B Munson wrote: I the above mentioned capture card and the digital side of the card works well. However, when I try to get video from the analog side of the card, all I get is a red screen and no sound regardless of channel requested. This is a problem I see in 2.6.39-rc1 though I typically run the ubuntu 10.10 kernel with the newest drivers built from source. Is there something in setup or configuration that I may be missing? Eric, You are likely missing the last 3 fixes here: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/cx18_39 (one of which is critical for analog to work). Also check the ivtv-users and ivtv-devel list for past discussions on the red screen showing up for known well supported models and what to try. Thanks, I will try hand applying these. I don't have a red screen anymore, now all get from analog static and mythtv's digital channel scanner now seems broken. Hmmm. 1. Please provide the output of dmesg when the cx18 driver loads. [332935.115343] cx18: Start initialization, version 1.4.1 [332935.115385] cx18-0: Initializing card 0 [332935.115389] cx18-0: Autodetected Hauppauge card [332935.115449] cx18 :04:01.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [332935.127005] cx18-0: cx23418 revision 0101 (B) [332935.342426] tveeprom 0-0050: Hauppauge model 74351, rev F1F5, serial# 7384278 [332935.342432] tveeprom 0-0050: MAC address is 00:0d:fe:70:ac:d6 [332935.342437] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54) [332935.342443] tveeprom 0-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) [332935.342448] tveeprom 0-0050: audio processor is CX23418 (idx 38) [332935.342453] tveeprom 0-0050: decoder processor is CX23418 (idx 31) [332935.342457] tveeprom 0-0050: has no radio [332935.342460] cx18-0: Autodetected Hauppauge HVR-1600 [332935.392016] cx18-0: Simultaneous Digital and Analog TV capture supported [332935.497007] tuner 1-0042: Tuner -1 found with type(s) Radio TV. [332935.501259] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [332935.548567] tda829x 1-0042: setting tuner address to 60 [332935.572554] tda18271 1-0060: creating new instance [332935.612568] TDA18271HD/C2 detected @ 1-0060 [332936.676587] tda18271: performing RF tracking filter calibration [332950.816567] tda18271: RF tracking filter calibration complete [332950.864571] tda829x 1-0042: type set to tda8295+18271 [332951.569137] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB) [332951.569143] DVB: registering new adapter (cx18) [332951.672187] tda18271 0-0060: creating new instance [332951.678691] TDA18271HD/C2 detected @ 0-0060 [332951.737797] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) [332951.876157] cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 bytes) [332951.882195] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) [332951.984040] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [332951.984208] cx18-0: DVB Frontend registered [332951.984214] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB) [332951.984268] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB) [332951.984320] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes) [332951.984367] cx18-0: Registered device video24 for encoder PCM audio (256 x 4.00 kB) [332951.984372] cx18-0: Initialized card: Hauppauge HVR-1600 [332951.984415] cx18: End initialization [332951.994916] cx18-alsa: module loading... [332952.733994] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes) [332952.753703] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes) 3. Please provide the relevant portion of the mythbackend log where where the digital scanner starts and then fails. So the Digital scanner doesn't fail per se, it just doesn't pick up most of the digital channels available. The same is true of scan, it seems to find only 1 channel when I know that I have access to 18. Make sure it's not a signal integrity problem: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality wild speculation: If the analog tuner driver init failed, maybe that is having some bad EMI efect on the digital tuner I'm assumiong you got
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Apr 18 19:00:29 CEST 2011 git hash:5d8daaf1b641a623eb765e2fa1c2da4a35405523 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] gspca - jeilinj: suppress workqueue
Signed-off-by: Patrice CHOTARD patricechot...@free.fr
---
drivers/media/video/gspca/jeilinj.c | 194 ++-
1 files changed, 77 insertions(+), 117 deletions(-)
diff --git a/drivers/media/video/gspca/jeilinj.c
b/drivers/media/video/gspca/jeilinj.c
index 06b777f..33de177 100644
--- a/drivers/media/video/gspca/jeilinj.c
+++ b/drivers/media/video/gspca/jeilinj.c
@@ -5,6 +5,7 @@
* download raw JPEG data.
*
* Copyright (C) 2009 Theodore Kilgore
+ * Copyright (C) 2011 Patrice Chotard
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -23,7 +24,6 @@
#define MODULE_NAME jeilinj
-#include linux/workqueue.h
#include linux/slab.h
#include gspca.h
#include jpeg.h
@@ -38,25 +38,23 @@ MODULE_LICENSE(GPL);
/* Maximum transfer size to use. */
#define JEILINJ_MAX_TRANSFER 0x200
-
#define FRAME_HEADER_LEN 0x10
+#define FRAME_START 0x
/* Structure to hold all of our device specific stuff */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
+ int blocks_left;
const struct v4l2_pix_format *cap_mode;
/* Driver stuff */
- struct work_struct work_struct;
- struct workqueue_struct *work_thread;
u8 quality; /* image quality */
- u8 jpegqual;/* webcam quality */
u8 jpeg_hdr[JPEG_HDR_SZ];
};
- struct jlj_command {
- unsigned char instruction[2];
- unsigned char ack_wanted;
- };
+struct jlj_command {
+ unsigned char instruction[2];
+ unsigned char ack_wanted;
+};
/* AFAICT these cameras will only do 320x240. */
static struct v4l2_pix_format jlj_mode[] = {
@@ -107,6 +105,7 @@ static int jlj_start(struct gspca_dev *gspca_dev)
int i;
int retval = -1;
u8 response = 0xff;
+ struct sd *sd = (struct sd *) gspca_dev;
struct jlj_command start_commands[] = {
{{0x71, 0x81}, 0},
{{0x70, 0x05}, 0},
@@ -136,6 +135,8 @@ static int jlj_start(struct gspca_dev *gspca_dev)
{{0x71, 0x80}, 0},
{{0x70, 0x07}, 0}
};
+
+ sd-blocks_left = 0;
for (i = 0; i ARRAY_SIZE(start_commands); i++) {
retval = jlj_write2(gspca_dev, start_commands[i].instruction);
if (retval 0)
@@ -149,104 +150,47 @@ static int jlj_start(struct gspca_dev *gspca_dev)
return retval;
}
-static int jlj_stop(struct gspca_dev *gspca_dev)
-{
- int i;
- int retval;
- struct jlj_command stop_commands[] = {
- {{0x71, 0x00}, 0},
- {{0x70, 0x09}, 0},
- {{0x71, 0x80}, 0},
- {{0x70, 0x05}, 0}
- };
- for (i = 0; i ARRAY_SIZE(stop_commands); i++) {
- retval = jlj_write2(gspca_dev, stop_commands[i].instruction);
- if (retval 0)
- return retval;
- }
- return retval;
-}
-
-/* This function is called as a workqueue function and runs whenever the camera
- * is streaming data. Because it is a workqueue function it is allowed to sleep
- * so we can use synchronous USB calls. To avoid possible collisions with other
- * threads attempting to use the camera's USB interface the gspca usb_lock is
- * used when performing the one USB control operation inside the workqueue,
- * which tells the camera to close the stream. In practice the only thing
- * which needs to be protected against is the usb_set_interface call that
- * gspca makes during stream_off. Otherwise the camera doesn't provide any
- * controls that the user could try to change.
- */
-
-static void jlj_dostream(struct work_struct *work)
+static void sd_pkt_scan(struct gspca_dev *gspca_dev,
+ u8 *data, int len)
{
- struct sd *dev = container_of(work, struct sd, work_struct);
- struct gspca_dev *gspca_dev = dev-gspca_dev;
- int blocks_left; /* 0x200-sized blocks remaining in current frame. */
- int size_in_blocks;
- int act_len;
+ struct sd *sd = (struct sd *) gspca_dev;
int packet_type;
- int ret;
- u8 *buffer;
+ u32 header_marker;
- buffer = kmalloc(JEILINJ_MAX_TRANSFER, GFP_KERNEL | GFP_DMA);
- if (!buffer) {
- err(Couldn't allocate USB buffer);
- goto quit_stream;
+ PDEBUG(D_STREAM, Got %d bytes out of %d for Block 0,
+ len, JEILINJ_MAX_TRANSFER);
+ if (len != JEILINJ_MAX_TRANSFER) {
+ PDEBUG(D_PACK, bad length);
+ goto discard;
}
- while (gspca_dev-present gspca_dev-streaming) {
- /*
-* Now request data block 0. Line 0 reports the size
-* to download, in blocks of size 0x200, and also tells the
-* actual data
[PATCH 2/5] gspca - jeilinj: use gspca_dev-usb_err to forward error to upper layer
Signed-off-by: Patrice CHOTARD patricechot...@free.fr
---
drivers/media/video/gspca/jeilinj.c | 43 --
1 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/gspca/jeilinj.c
b/drivers/media/video/gspca/jeilinj.c
index 33de177..32494fb 100644
--- a/drivers/media/video/gspca/jeilinj.c
+++ b/drivers/media/video/gspca/jeilinj.c
@@ -71,39 +71,44 @@ static struct v4l2_pix_format jlj_mode[] = {
*/
/* All commands are two bytes only */
-static int jlj_write2(struct gspca_dev *gspca_dev, unsigned char *command)
+static void jlj_write2(struct gspca_dev *gspca_dev, unsigned char *command)
{
int retval;
+ if (gspca_dev-usb_err 0)
+ return;
memcpy(gspca_dev-usb_buf, command, 2);
retval = usb_bulk_msg(gspca_dev-dev,
usb_sndbulkpipe(gspca_dev-dev, 3),
gspca_dev-usb_buf, 2, NULL, 500);
- if (retval 0)
+ if (retval 0) {
err(command write [%02x] error %d,
gspca_dev-usb_buf[0], retval);
- return retval;
+ gspca_dev-usb_err = retval;
+ }
}
/* Responses are one byte only */
-static int jlj_read1(struct gspca_dev *gspca_dev, unsigned char response)
+static void jlj_read1(struct gspca_dev *gspca_dev, unsigned char response)
{
int retval;
+ if (gspca_dev-usb_err 0)
+ return;
retval = usb_bulk_msg(gspca_dev-dev,
usb_rcvbulkpipe(gspca_dev-dev, 0x84),
gspca_dev-usb_buf, 1, NULL, 500);
response = gspca_dev-usb_buf[0];
- if (retval 0)
+ if (retval 0) {
err(read command [%02x] error %d,
gspca_dev-usb_buf[0], retval);
- return retval;
+ gspca_dev-usb_err = retval;
+ }
}
static int jlj_start(struct gspca_dev *gspca_dev)
{
int i;
- int retval = -1;
u8 response = 0xff;
struct sd *sd = (struct sd *) gspca_dev;
struct jlj_command start_commands[] = {
@@ -138,16 +143,13 @@ static int jlj_start(struct gspca_dev *gspca_dev)
sd-blocks_left = 0;
for (i = 0; i ARRAY_SIZE(start_commands); i++) {
- retval = jlj_write2(gspca_dev, start_commands[i].instruction);
- if (retval 0)
- return retval;
+ jlj_write2(gspca_dev, start_commands[i].instruction);
if (start_commands[i].ack_wanted)
- retval = jlj_read1(gspca_dev, response);
- if (retval 0)
- return retval;
+ jlj_read1(gspca_dev, response);
}
- PDEBUG(D_ERR, jlj_start retval is %d, retval);
- return retval;
+ if (gspca_dev-usb_err 0)
+ PDEBUG(D_ERR, Start streaming command failed);
+ return gspca_dev-usb_err;
}
static void sd_pkt_scan(struct gspca_dev *gspca_dev,
@@ -250,26 +252,21 @@ static void sd_stopN(struct gspca_dev *gspca_dev)
/* this function is called at probe and resume time */
static int sd_init(struct gspca_dev *gspca_dev)
{
- return 0;
+ return gspca_dev-usb_err;
}
/* Set up for getting frames. */
static int sd_start(struct gspca_dev *gspca_dev)
{
struct sd *dev = (struct sd *) gspca_dev;
- int ret;
/* create the JPEG header */
jpeg_define(dev-jpeg_hdr, gspca_dev-height, gspca_dev-width,
0x21); /* JPEG 422 */
jpeg_set_qual(dev-jpeg_hdr, dev-quality);
PDEBUG(D_STREAM, Start streaming at 320x240);
- ret = jlj_start(gspca_dev);
- if (ret 0) {
- PDEBUG(D_ERR, Start streaming command failed);
- return ret;
- }
- return 0;
+ jlj_start(gspca_dev);
+ return gspca_dev-usb_err;
}
/* Table of supported USB devices */
--
1.7.0.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 3/5] gspca - jeilinj: add 640*480 resolution support
Signed-off-by: Patrice CHOTARD patricechot...@free.fr
---
drivers/media/video/gspca/jeilinj.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/gspca/jeilinj.c
b/drivers/media/video/gspca/jeilinj.c
index 32494fb..51b68db 100644
--- a/drivers/media/video/gspca/jeilinj.c
+++ b/drivers/media/video/gspca/jeilinj.c
@@ -62,6 +62,11 @@ static struct v4l2_pix_format jlj_mode[] = {
.bytesperline = 320,
.sizeimage = 320 * 240,
.colorspace = V4L2_COLORSPACE_JPEG,
+ .priv = 0},
+ { 640, 480, V4L2_PIX_FMT_JPEG, V4L2_FIELD_NONE,
+ .bytesperline = 640,
+ .sizeimage = 640 * 480,
+ .colorspace = V4L2_COLORSPACE_JPEG,
.priv = 0}
};
@@ -207,7 +212,7 @@ static int sd_config(struct gspca_dev *gspca_dev,
JEILINJ camera detected
(vid/pid 0x%04X:0x%04X), id-idVendor, id-idProduct);
cam-cam_mode = jlj_mode;
- cam-nmodes = 1;
+ cam-nmodes = ARRAY_SIZE(jlj_mode);
cam-bulk = 1;
cam-bulk_nurbs = 1;
cam-bulk_size = JEILINJ_MAX_TRANSFER;
@@ -264,7 +269,8 @@ static int sd_start(struct gspca_dev *gspca_dev)
jpeg_define(dev-jpeg_hdr, gspca_dev-height, gspca_dev-width,
0x21); /* JPEG 422 */
jpeg_set_qual(dev-jpeg_hdr, dev-quality);
- PDEBUG(D_STREAM, Start streaming at 320x240);
+ PDEBUG(D_STREAM, Start streaming at %dx%d,
+ gspca_dev-height, gspca_dev-width);
jlj_start(gspca_dev);
return gspca_dev-usb_err;
}
--
1.7.0.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 4/5] gspca - jeilinj: Add SPORTSCAM_DV15 camera support
Signed-off-by: Patrice CHOTARD patricechot...@free.fr
---
Documentation/video4linux/gspca.txt |1 +
drivers/media/video/gspca/jeilinj.c | 98 ---
2 files changed, 68 insertions(+), 31 deletions(-)
diff --git a/Documentation/video4linux/gspca.txt
b/Documentation/video4linux/gspca.txt
index 56ba7bb..6b85f4f 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -265,6 +265,7 @@ pac7302 093a:2629 Genious iSlim 300
pac7302093a:262a Webcam 300k
pac7302093a:262c Philips SPC 230 NC
jeilinj0979:0280 Sakar 57379
+jeilinj0979:0280 Sportscam DV15
zc3xx 0ac8:0302 Z-star Vimicro zc0302
vc032x 0ac8:0321 Vimicro generic vc0321
vc032x 0ac8:0323 Vimicro Vc0323
diff --git a/drivers/media/video/gspca/jeilinj.c
b/drivers/media/video/gspca/jeilinj.c
index 51b68db..da92867 100644
--- a/drivers/media/video/gspca/jeilinj.c
+++ b/drivers/media/video/gspca/jeilinj.c
@@ -34,6 +34,7 @@ MODULE_LICENSE(GPL);
/* Default timeouts, in ms */
#define JEILINJ_CMD_TIMEOUT 500
+#define JEILINJ_CMD_DELAY 160
#define JEILINJ_DATA_TIMEOUT 1000
/* Maximum transfer size to use. */
@@ -41,12 +42,17 @@ MODULE_LICENSE(GPL);
#define FRAME_HEADER_LEN 0x10
#define FRAME_START 0x
+enum {
+ SAKAR_57379,
+ SPORTSCAM_DV15,
+};
/* Structure to hold all of our device specific stuff */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
int blocks_left;
const struct v4l2_pix_format *cap_mode;
/* Driver stuff */
+ u8 type;
u8 quality; /* image quality */
u8 jpeg_hdr[JPEG_HDR_SZ];
};
@@ -54,6 +60,7 @@ struct sd {
struct jlj_command {
unsigned char instruction[2];
unsigned char ack_wanted;
+ unsigned char delay;
};
/* AFAICT these cameras will only do 320x240. */
@@ -114,41 +121,53 @@ static void jlj_read1(struct gspca_dev *gspca_dev,
unsigned char response)
static int jlj_start(struct gspca_dev *gspca_dev)
{
int i;
+ int start_commands_size;
u8 response = 0xff;
struct sd *sd = (struct sd *) gspca_dev;
struct jlj_command start_commands[] = {
- {{0x71, 0x81}, 0},
- {{0x70, 0x05}, 0},
- {{0x95, 0x70}, 1},
- {{0x71, 0x81}, 0},
- {{0x70, 0x04}, 0},
- {{0x95, 0x70}, 1},
- {{0x71, 0x00}, 0},
- {{0x70, 0x08}, 0},
- {{0x95, 0x70}, 1},
- {{0x94, 0x02}, 0},
- {{0xde, 0x24}, 0},
- {{0x94, 0x02}, 0},
- {{0xdd, 0xf0}, 0},
- {{0x94, 0x02}, 0},
- {{0xe3, 0x2c}, 0},
- {{0x94, 0x02}, 0},
- {{0xe4, 0x00}, 0},
- {{0x94, 0x02}, 0},
- {{0xe5, 0x00}, 0},
- {{0x94, 0x02}, 0},
- {{0xe6, 0x2c}, 0},
- {{0x94, 0x03}, 0},
- {{0xaa, 0x00}, 0},
- {{0x71, 0x1e}, 0},
- {{0x70, 0x06}, 0},
- {{0x71, 0x80}, 0},
- {{0x70, 0x07}, 0}
+ {{0x71, 0x81}, 0, 0},
+ {{0x70, 0x05}, 0, JEILINJ_CMD_DELAY},
+ {{0x95, 0x70}, 1, 0},
+ {{0x71, 0x81 - gspca_dev-curr_mode}, 0, 0},
+ {{0x70, 0x04}, 0, JEILINJ_CMD_DELAY},
+ {{0x95, 0x70}, 1, 0},
+ {{0x71, 0x00}, 0, 0}, /* start streaming ??*/
+ {{0x70, 0x08}, 0, JEILINJ_CMD_DELAY},
+ {{0x95, 0x70}, 1, 0},
+#define SPORTSCAM_DV15_CMD_SIZE 9
+ {{0x94, 0x02}, 0, 0},
+ {{0xde, 0x24}, 0, 0},
+ {{0x94, 0x02}, 0, 0},
+ {{0xdd, 0xf0}, 0, 0},
+ {{0x94, 0x02}, 0, 0},
+ {{0xe3, 0x2c}, 0, 0},
+ {{0x94, 0x02}, 0, 0},
+ {{0xe4, 0x00}, 0, 0},
+ {{0x94, 0x02}, 0, 0},
+ {{0xe5, 0x00}, 0, 0},
+ {{0x94, 0x02}, 0, 0},
+ {{0xe6, 0x2c}, 0, 0},
+ {{0x94, 0x03}, 0, 0},
+ {{0xaa, 0x00}, 0, 0},
+ {{0x71, 0x1e}, 0, 0},
+ {{0x70, 0x06}, 0, 0},
+ {{0x71, 0x80}, 0, 0},
+ {{0x70, 0x07}, 0, 0}
};
sd-blocks_left = 0;
- for (i = 0; i ARRAY_SIZE(start_commands); i++) {
+ /* Under Windows, USB spy shows that only the 9 first start
+* commands are used for SPORTSCAM_DV15 webcam
+*/
+ if (sd-type == SPORTSCAM_DV15)
+ start_commands_size = SPORTSCAM_DV15_CMD_SIZE;
+ else
+ start_commands_size = ARRAY_SIZE(start_commands);
+
+ for (i = 0; i start_commands_size; i++) {
jlj_write2(gspca_dev,
[PATCH 5/5] gspca - jeilinj: add SPORTSCAM specific controls
Signed-off-by: Patrice CHOTARD patricechot...@free.fr
---
drivers/media/video/gspca/jeilinj.c | 248 ++-
1 files changed, 242 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/gspca/jeilinj.c
b/drivers/media/video/gspca/jeilinj.c
index da92867..1bd9c4b 100644
--- a/drivers/media/video/gspca/jeilinj.c
+++ b/drivers/media/video/gspca/jeilinj.c
@@ -5,6 +5,8 @@
* download raw JPEG data.
*
* Copyright (C) 2009 Theodore Kilgore
+ *
+ * Sportscam DV15 support and control settings are
* Copyright (C) 2011 Patrice Chotard
*
* This program is free software; you can redistribute it and/or modify
@@ -46,14 +48,31 @@ enum {
SAKAR_57379,
SPORTSCAM_DV15,
};
+
+#define CAMQUALITY_MIN 0 /* highest cam quality */
+#define CAMQUALITY_MAX 97 /* lowest cam quality */
+
+enum e_ctrl {
+ LIGHTFREQ,
+ AUTOGAIN,
+ RED,
+ GREEN,
+ BLUE,
+ NCTRLS /* number of controls */
+};
+
/* Structure to hold all of our device specific stuff */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
+ struct gspca_ctrl ctrls[NCTRLS];
int blocks_left;
const struct v4l2_pix_format *cap_mode;
/* Driver stuff */
u8 type;
u8 quality; /* image quality */
+#define QUALITY_MIN 35
+#define QUALITY_MAX 85
+#define QUALITY_DEF 85
u8 jpeg_hdr[JPEG_HDR_SZ];
};
@@ -118,6 +137,162 @@ static void jlj_read1(struct gspca_dev *gspca_dev,
unsigned char response)
}
}
+static void setfreq(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 freq_commands[][2] = {
+ {0x71, 0x80},
+ {0x70, 0x07}
+ };
+
+ freq_commands[0][1] |= (sd-ctrls[LIGHTFREQ].val 1);
+
+ jlj_write2(gspca_dev, freq_commands[0]);
+ jlj_write2(gspca_dev, freq_commands[1]);
+}
+
+static void setcamquality(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 quality_commands[][2] = {
+ {0x71, 0x1E},
+ {0x70, 0x06}
+ };
+ u8 camquality;
+
+ /* adapt camera quality from jpeg quality */
+ camquality = ((QUALITY_MAX - sd-quality) * CAMQUALITY_MAX)
+ / (QUALITY_MAX - QUALITY_MIN);
+ quality_commands[0][1] += camquality;
+
+ jlj_write2(gspca_dev, quality_commands[0]);
+ jlj_write2(gspca_dev, quality_commands[1]);
+}
+
+static void setautogain(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 autogain_commands[][2] = {
+ {0x94, 0x02},
+ {0xcf, 0x00}
+ };
+
+ autogain_commands[1][1] = (sd-ctrls[AUTOGAIN].val 4);
+
+ jlj_write2(gspca_dev, autogain_commands[0]);
+ jlj_write2(gspca_dev, autogain_commands[1]);
+}
+
+static void setred(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 setred_commands[][2] = {
+ {0x94, 0x02},
+ {0xe6, 0x00}
+ };
+
+ setred_commands[1][1] = sd-ctrls[RED].val;
+
+ jlj_write2(gspca_dev, setred_commands[0]);
+ jlj_write2(gspca_dev, setred_commands[1]);
+}
+
+static void setgreen(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 setgreen_commands[][2] = {
+ {0x94, 0x02},
+ {0xe7, 0x00}
+ };
+
+ setgreen_commands[1][1] = sd-ctrls[GREEN].val;
+
+ jlj_write2(gspca_dev, setgreen_commands[0]);
+ jlj_write2(gspca_dev, setgreen_commands[1]);
+}
+
+static void setblue(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 setblue_commands[][2] = {
+ {0x94, 0x02},
+ {0xe9, 0x00}
+ };
+
+ setblue_commands[1][1] = sd-ctrls[BLUE].val;
+
+ jlj_write2(gspca_dev, setblue_commands[0]);
+ jlj_write2(gspca_dev, setblue_commands[1]);
+}
+
+static const struct ctrl sd_ctrls[NCTRLS] = {
+[LIGHTFREQ] = {
+ {
+ .id = V4L2_CID_POWER_LINE_FREQUENCY,
+ .type= V4L2_CTRL_TYPE_MENU,
+ .name= Light frequency filter,
+ .minimum = V4L2_CID_POWER_LINE_FREQUENCY_DISABLED, /* 1 */
+ .maximum = V4L2_CID_POWER_LINE_FREQUENCY_60HZ, /* 2 */
+ .step= 1,
+ .default_value = V4L2_CID_POWER_LINE_FREQUENCY_60HZ,
+ },
+ .set_control = setfreq
+ },
+[AUTOGAIN] = {
+ {
+ .id = V4L2_CID_AUTOGAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Automatic Gain (and Exposure),
+ .minimum = 0,
+ .maximum = 3,
+ .step = 1,
+#define AUTOGAIN_DEF 0
+ .default_value = AUTOGAIN_DEF,
+ },
+ .set_control = setautogain
+ },
+[RED] = {
+
usbvision with Nogatech MicroCam (NV3001P)
Hello, I have a webcam Nogatech MicroCam (NV3001P) which does not work in Linux. It's probably based on NT1003 chip. There are 3 small PCBs connected together inside, one with sensor, one with RAM and some unknown chip (no packaging, epoxy blob only) and one with another unknown chip. I've captured some communication in Windows: http://www.rainbow-software.org/linux_files/nogatech/usbsnoop-nogatech.log But matching the control commands to the usbvision driver does not make any sense to me. I wonder if support for this camera could be added to the usbvision driver. If not, gspca is probably the way to go. lsusb -v output: Bus 002 Device 002: ID 0573:3001 Zoran Co. Personal Media Division (Nogatech) Dazzle MicroCam (PAL) Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0573 Zoran Co. Personal Media Division (Nogatech) idProduct 0x3001 Dazzle MicroCam (PAL) bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 377 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes0 Transfer TypeControl Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes0 Transfer TypeControl Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x03bf 1x 959 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes0 Transfer TypeControl Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x037f 1x 895 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 3
Re: [PATCH 13/34] media/radio-maxiradio: Drop __TIME__ usage
On Tue, Apr 05, 2011 at 04:59:00PM +0200, Michal Marek wrote: The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time. Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-media@vger.kernel.org Signed-off-by: Michal Marek mma...@suse.cz --- drivers/media/radio/radio-maxiradio.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) Applied to kbuild-2.6.git#trivial. Michal -- 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 14/34] media/cx231xx: Drop __TIME__ usage
On Tue, Apr 05, 2011 at 04:59:01PM +0200, Michal Marek wrote: The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time. Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-media@vger.kernel.org Signed-off-by: Michal Marek mma...@suse.cz --- drivers/media/video/cx231xx/cx231xx-avcore.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to kbuild-2.6.git#trivial. Michal -- 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: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, 18 Apr 2011, Andy Walls wrote: Eric B Munson emun...@mgebm.net wrote: On Mon, 11 Apr 2011, Eric B Munson wrote: On Sun, 10 Apr 2011, Andy Walls wrote: On Wed, 2011-04-06 at 13:28 -0400, Eric B Munson wrote: On Tue, Apr 5, 2011 at 10:58 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 14:36 -0400, Eric B Munson wrote: On Mon, Apr 4, 2011 at 11:16 AM, Eric B Munson emun...@mgebm.net wrote: On Mon, Apr 4, 2011 at 9:12 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-04-04 at 08:20 -0400, Eric B Munson wrote: I the above mentioned capture card and the digital side of the card works well. However, when I try to get video from the analog side of the card, all I get is a red screen and no sound regardless of channel requested. This is a problem I see in 2.6.39-rc1 though I typically run the ubuntu 10.10 kernel with the newest drivers built from source. Is there something in setup or configuration that I may be missing? Eric, You are likely missing the last 3 fixes here: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/cx18_39 (one of which is critical for analog to work). Also check the ivtv-users and ivtv-devel list for past discussions on the red screen showing up for known well supported models and what to try. Thanks, I will try hand applying these. I don't have a red screen anymore, now all get from analog static and mythtv's digital channel scanner now seems broken. Hmmm. 1. Please provide the output of dmesg when the cx18 driver loads. [332935.115343] cx18: Start initialization, version 1.4.1 [332935.115385] cx18-0: Initializing card 0 [332935.115389] cx18-0: Autodetected Hauppauge card [332935.115449] cx18 :04:01.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [332935.127005] cx18-0: cx23418 revision 0101 (B) [332935.342426] tveeprom 0-0050: Hauppauge model 74351, rev F1F5, serial# 7384278 [332935.342432] tveeprom 0-0050: MAC address is 00:0d:fe:70:ac:d6 [332935.342437] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54) [332935.342443] tveeprom 0-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) [332935.342448] tveeprom 0-0050: audio processor is CX23418 (idx 38) [332935.342453] tveeprom 0-0050: decoder processor is CX23418 (idx 31) [332935.342457] tveeprom 0-0050: has no radio [332935.342460] cx18-0: Autodetected Hauppauge HVR-1600 [332935.392016] cx18-0: Simultaneous Digital and Analog TV capture supported [332935.497007] tuner 1-0042: Tuner -1 found with type(s) Radio TV. [332935.501259] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [332935.548567] tda829x 1-0042: setting tuner address to 60 [332935.572554] tda18271 1-0060: creating new instance [332935.612568] TDA18271HD/C2 detected @ 1-0060 [332936.676587] tda18271: performing RF tracking filter calibration [332950.816567] tda18271: RF tracking filter calibration complete [332950.864571] tda829x 1-0042: type set to tda8295+18271 [332951.569137] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB) [332951.569143] DVB: registering new adapter (cx18) [332951.672187] tda18271 0-0060: creating new instance [332951.678691] TDA18271HD/C2 detected @ 0-0060 [332951.737797] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) [332951.876157] cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 bytes) [332951.882195] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) [332951.984040] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [332951.984208] cx18-0: DVB Frontend registered [332951.984214] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB) [332951.984268] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB) [332951.984320] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes) [332951.984367] cx18-0: Registered device video24 for encoder PCM audio (256 x 4.00 kB) [332951.984372] cx18-0: Initialized card: Hauppauge HVR-1600 [332951.984415] cx18: End initialization [332951.994916] cx18-alsa: module loading... [332952.733994] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes) [332952.753703] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes) 3. Please provide the relevant portion of the mythbackend log where where the digital scanner starts and then fails. So the Digital scanner doesn't fail per se, it just doesn't pick up most of the digital channels available. The same is true of scan, it seems to find only 1 channel when I know that I have access to 18. Make sure it's not a signal integrity problem:
Re: [linux-dvb] ndiswrapper for dvb drivers?
Am Freitag, den 08.04.2011, 11:22 +0200 schrieb pigeonskil...@libero.it: Good day to you all. My question is simple: it would be possible to write a program like ndiswrapper for dvb drivers? Just think: only a small initial effort to write a program that can use hundreds of DVB drivers taken from the Windows world... Hi, I'm going through mail backlash again. Arrgh, what a not aware of anything major BS. Either you have the not yet public driver details, than you can write wrappers, please then do so. Not the preferred solution. Or you ask people still hacking on some stuff, why the damned hell some those idiots still try to hack it ... Patches are welcome. 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
imon: spews to dmesg
Hi list, I just (2011-04-19) upgraded to the current media_build with build.sh commit bcfdefe9f4538abf12fca1cdb631c80e3d598026 Author: Mauro Carvalho Chehab mchehab@nehalem.(none) Date: Sun Apr 17 08:21:25 2011 -0300 and hit a problem. I have an Antec case with an LCD screen. It needs the imon driver. The LCD screen has been working well using media_build from 2011-01-30. The imon kernel module now spews this at a high rate: [ 38.532581] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.544545] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.552548] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.560560] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.568546] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.576557] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.584554] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.592558] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.600533] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.608551] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.620024] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.636034] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.652034] imon 9-1:1.0: lcd_write: write 8 bytes to LCD If I stop LCDd # /etc/init.d/LCDd stop the spew stops. I'm running on ubuntu 10.04 i386, with lcdproc 0.5.3-0ubuntu2. $ uname -a Linux ubuntu 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux $ modinfo imon filename: /lib/modules/2.6.32-27-generic/kernel/drivers/media/rc/imon.ko license:GPL version:0.9.2 description:Driver for SoundGraph iMON MultiMedia IR/Display author: Jarod Wilson ja...@wilsonet.com srcversion: 268453AC090EFB24F487BE7 alias: usb:v15C2p0046d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0045d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0044d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0043d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0042d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0041d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0040d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Fd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Ed*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Dd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Cd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Ad*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0039d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0038d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0037d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0036d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0035d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0034d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2pFFDCd*dc*dsc*dp*ic*isc*ip* depends:rc-core vermagic: 2.6.32-27-generic SMP mod_unload modversions 586 parm: debug:Debug messages: 0=no, 1=yes (default: no) (bool) parm: display_type:Type of attached display. 0=autodetect, 1=vfd, 2=lcd, 3=vga, 4=none (default: autodetect) (int) parm: pad_stabilize:Apply stabilization algorithm to iMON PAD presses in arrow key mode. 0=disable, 1=enable (default). (int) parm: nomouse:Disable mouse input device mode when IR device is open. 0=don't disable, 1=disable. (default: don't disable) (bool) parm: pad_thresh:Threshold at which a pad push registers as an arrow key in kbd mode (default: 28) (int) The module load looks normal: $ dmesg|grep imon [4.454786] imon 9-1:1.0: imon_probe: found iMON device (15c2:ffdc, intf0) [4.454794] imon 9-1:1.0: imon_find_endpoints: found IR endpoint [4.454794] imon 9-1:1.0: imon_find_endpoints: found display endpoint [4.472053] imon 9-1:1.0: 0xffdc iMON LCD, MCE IR (id 0x9f) [5.024035] Registered IR keymap rc-imon-mce [5.024173] imon 9-1:1.0: Configuring IR receiver for MCE protocol [5.032117] imon 9-1:1.0: Registering iMON display with sysfs [5.032173] imon 9-1:1.0: iMON device (15c2:ffdc, intf0) on usb9:2 initialized [5.032198] usbcore: registered new interface driver imon Then the display port is opened... [ 38.519700] imon 9-1:1.0: display port opened [ 38.532581] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.544545] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.552548] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.560560] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.568546] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.576557] imon 9-1:1.0: lcd_write: write 8 bytes to LCD [ 38.584554] imon 9-1:1.0: lcd_write: write 8 bytes to LCD I don't have any load options defined for the imon module. Can anyone shed light on why the module is spewing to dmesg, and what should I do to fix it ? Thanks Vince -- 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
Winfast Dongle H support
Hello, I have Mandriva 2010.2 up to date and I try to install a Leadtek Winfast Dongle H. I couldn't make it run with the Mandriva provided v4l modules and drivers, so I have built v4l from the scratch. The build process performed wonderfully, but I could not find any channel. The same dongle works perfectly on a Windows 7, so the signal is not the problem. I need help to diagnose further or a hint if someone know what is special about this card. Thanks, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
