Re: [RFCv1 PATCH 3/6] videobuf2-core: move plane verification out of __fill_v4l2_buffer.
On Wed September 19 2012 18:55:25 Sylwester Nawrocki wrote:
On 09/19/2012 04:37 PM, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
The plane verification should be done before actually queuing or
dequeuing buffers, so move it out of __fill_v4l2_buffer and call it
as a separate step.
The also makes it possible to change the return type of __fill_v4l2_buffer
to void.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
There are just two small comment below...
---
drivers/media/v4l2-core/videobuf2-core.c | 29
+
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 2e26e58..929cc99 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -276,6 +276,9 @@ static void __vb2_queue_free(struct vb2_queue *q,
unsigned int buffers)
*/
static int __verify_planes_array(struct vb2_queue *q, const struct
v4l2_buffer *b)
{
+ if (!V4L2_TYPE_IS_MULTIPLANAR(b-type))
+ return 0;
+
/* Is memory for copying plane information present? */
if (NULL == b-m.planes) {
dprintk(1, Multi-planar buffer passed but
@@ -331,10 +334,9 @@ static bool __buffers_in_use(struct vb2_queue *q)
* __fill_v4l2_buffer() - fill in a struct v4l2_buffer with information to
be
* returned to userspace
*/
-static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
+static void __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer
*b)
{
struct vb2_queue *q = vb-vb2_queue;
- int ret;
/* Copy back data such as timestamp, flags, etc. */
memcpy(b, vb-v4l2_buf, offsetof(struct v4l2_buffer, m));
@@ -342,10 +344,6 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
b-reserved = vb-v4l2_buf.reserved;
if (V4L2_TYPE_IS_MULTIPLANAR(q-type)) {
- ret = __verify_planes_array(q, b);
- if (ret)
- return ret;
-
/*
* Fill in plane-related data if userspace provided an array
* for it. The memory and size is verified above.
This comment should be updated, since __verify_planes_array() is now removed.
Will do.
@@ -391,8 +389,6 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
if (__buffer_in_use(q, vb))
b-flags |= V4L2_BUF_FLAG_MAPPED;
-
- return 0;
}
/**
@@ -411,6 +407,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
int vb2_querybuf(struct vb2_queue *q, struct v4l2_buffer *b)
{
struct vb2_buffer *vb;
+ int ret;
if (b-type != q-type) {
dprintk(1, querybuf: wrong buffer type\n);
@@ -422,8 +419,10 @@ int vb2_querybuf(struct vb2_queue *q, struct
v4l2_buffer *b)
return -EINVAL;
}
vb = q-bufs[b-index];
-
- return __fill_v4l2_buffer(vb, b);
+ ret = __verify_planes_array(q, b);
+ if (!ret)
+ __fill_v4l2_buffer(vb, b);
+ return ret;
}
EXPORT_SYMBOL(vb2_querybuf);
@@ -1061,8 +1060,8 @@ int vb2_prepare_buf(struct vb2_queue *q, struct
v4l2_buffer *b)
dprintk(1, %s(): invalid buffer state %d\n, __func__,
vb-state);
return -EINVAL;
}
-
- ret = __buf_prepare(vb, b);
+ ret = __verify_planes_array(q, b);
+ ret = ret ? ret : __buf_prepare(vb, b);
Could we just make it:
ret = __verify_planes_array(q, b);
if (ret 0)
return ret;
ret = __buf_prepare(vb, b);
if (ret 0)
return ret;
?
OK.
Regards,
Hans
if (ret 0)
return ret;
@@ -1149,6 +1148,9 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer
*b)
ret = -EINVAL;
goto unlock;
}
+ ret = __verify_planes_array(q, b);
+ if (ret)
+ return ret;
switch (vb-state) {
case VB2_BUF_STATE_DEQUEUED:
@@ -1337,6 +1339,9 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
*b, bool nonblocking)
dprintk(1, dqbuf: invalid buffer type\n);
return -EINVAL;
}
+ ret = __verify_planes_array(q, b);
+ if (ret)
+ return ret;
ret = __vb2_get_done_vb(q, vb, nonblocking);
if (ret 0) {
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On Wed September 19 2012 20:46:19 Laurent Pinchart wrote: Hi Hans, On Thursday 13 September 2012 12:40:07 Hans Verkuil wrote: On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote: On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). I thought about that, but should that be defined in the spec? I'm not sure if that's the right place. On the other hand, if we don't specify the format of the bus_info field precisely, it will only be usable as an opaque identifier to userspace. What do we want to do with bus_info ? Telling otherwise identical devices apart is a must, but do we want to provide more information to userspace ? If the field had been longer a sysfs path might have been a good idea, but it won't fit. Well, we can use the bus_info to find a device in sysfs. E.g. for the ivtv card I get bus_info PCI::0b:01.0 and the same device is found here in sysfs: /sys/bus/pci/devices/:0b:01.0 We can try to document the relationship between bus_info and sysfs here and that would define bus_info exactly. I don't quite see how a usb bus_info maps to sysfs, however. Do you know? Regards, Hans -- 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 v2 00/34] i.MX multi-platform support
Here is the second post, which should have addressed the comments that
reviewers put on v1.
It's available on branch below.
git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform-v2
And it's based on the following branches.
calxeda/multi-plat
arm-soc/multiplatform/platform-data
arm-soc/multiplatform/smp_ops
arm-soc/imx/cleanup
arm-soc/imx/dt
sound/for-3.7
Subsystem maintainers,
I plan to send the whole series for 3.7 via arm-soc tree. Please let
me know if you have problem with that. Thanks.
Shawn
---
Shawn Guo (34):
ARM: imx: include board headers in the same folder
ARM: imx: move iomux drivers and headers into mach-imx
ARM: imx: remove unnecessary inclusion from device-imx*.h
ARM: imx: move platform device code into mach-imx
ARM: imx: merge plat-mxc into mach-imx
ARM: imx: include common.h rather than mach/common.h
ARM: imx: ARM: imx: include cpuidle.h rather than mach/cpuidle.h
ARM: imx: include iim.h rather than mach/iim.h
ARM: imx: include iram.h rather than mach/iram.h
ARM: imx: include ulpi.h rather than mach/ulpi.h
media: mx1_camera: remove the driver
ARM: imx: remove mach/dma-mx1-mx2.h
dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
dma: imx-sdma: remove unneeded mach/hardware.h inclusion
ASoC: imx-ssi: remove unneeded mach/hardware.h inclusion
usb: ehci-mxc: remove unneeded mach/hardware.h inclusion
video: mx3fb: remove unneeded mach/hardware.h inclusion
watchdog: imx2_wdt: remove unneeded mach/hardware.h inclusion
i2c: imx: remove cpu_is_xxx by using platform_device_id
mtd: mxc_nand: remove cpu_is_xxx by using platform_device_id
rtc: mxc_rtc: remove cpu_is_xxx by using platform_device_id
dma: imx-dma: use devm_kzalloc and devm_request_irq
dma: imx-dma: retrieve MEM and IRQ from resources
dma: imx-dma: remove cpu_is_xxx by using platform_device_id
media: mx2_camera: remove dead code in mx2_camera_add_device
media: mx2_camera: use managed functions to clean up code
media: mx2_camera: remove cpu_is_xxx by using platform_device_id
mmc: mxcmmc: remove cpu_is_xxx by using platform_device_id
video: imxfb: remove cpu_is_xxx by using platform_device_id
ARM: imx: move debug macros to include/debug
ARM: imx: include hardware.h rather than mach/hardware.h
ARM: imx: remove header file mach/irqs.h
ARM: imx: call mxc_device_init() in soc specific function
ARM: imx: enable multi-platform build
.../devicetree/bindings/i2c/fsl-imx-i2c.txt|4 +-
MAINTAINERS|1 -
arch/arm/Kconfig | 15 +-
arch/arm/Kconfig.debug |8 +
arch/arm/Makefile |1 -
arch/arm/boot/dts/imx27.dtsi |4 +-
arch/arm/boot/dts/imx51.dtsi |4 +-
arch/arm/boot/dts/imx53.dtsi |6 +-
arch/arm/boot/dts/imx6q.dtsi |6 +-
arch/arm/configs/imx_v4_v5_defconfig |5 +-
arch/arm/configs/imx_v6_v7_defconfig |3 +-
.../mach/debug-macro.S = include/debug/imx.S} | 33 +-
arch/arm/{plat-mxc = mach-imx}/3ds_debugboard.c |2 +-
.../include/mach = mach-imx}/3ds_debugboard.h |0
arch/arm/mach-imx/Kconfig | 89 +-
arch/arm/mach-imx/Makefile | 23 +-
arch/arm/{plat-mxc = mach-imx}/avic.c |5 +-
.../include/mach = mach-imx}/board-mx31lilly.h|0
.../include/mach = mach-imx}/board-mx31lite.h |0
.../include/mach = mach-imx}/board-mx31moboard.h |0
.../include/mach = mach-imx}/board-pcm038.h |0
arch/arm/mach-imx/clk-imx1.c | 18 +-
arch/arm/mach-imx/clk-imx21.c | 18 +-
arch/arm/mach-imx/clk-imx25.c | 26 +-
arch/arm/mach-imx/clk-imx27.c | 40 +-
arch/arm/mach-imx/clk-imx31.c | 21 +-
arch/arm/mach-imx/clk-imx35.c | 13 +-
arch/arm/mach-imx/clk-imx51-imx53.c| 15 +-
arch/arm/mach-imx/clk-imx6q.c |3 +-
arch/arm/mach-imx/clk-pllv1.c |4 +-
.../{plat-mxc/include/mach = mach-imx}/common.h |1 +
arch/arm/mach-imx/cpu-imx25.c |5 +-
arch/arm/mach-imx/cpu-imx27.c |2 +-
arch/arm/mach-imx/cpu-imx31.c |7 +-
arch/arm/mach-imx/cpu-imx35.c |5 +-
arch/arm/mach-imx/cpu-imx5.c |3 +-
arch/arm/{plat-mxc = mach-imx}/cpu.c |3 +-
arch/arm/mach-imx/cpu_op-mx51.c|3 +-
arch/arm/{plat-mxc = mach-imx}/cpufreq.c |3 +-
arch/arm/{plat-mxc = mach-imx}/cpuidle.c |0
.../{plat-mxc/include/mach = mach-imx}/cpuidle.h |0
arch/arm/mach-imx/devices-imx1.h
[PATCH v2 11/34] media: mx1_camera: remove the driver
The mx1_camera driver has been broken for a few release cycles since
commit 6bd0812 (dmaengine: imx-dma: merge old dma-v1.c with imx-dma.c).
It seems there is no one even compile tested it since then, as doing
so will end up with the following error.
CC drivers/media/video/mx1_camera.o
In file included from drivers/media/video/mx1_camera.c:44:0:
arch/arm/mach-imx/include/mach/dma-mx1-mx2.h:8:25: fatal error: mach/dma-v1.h:
No such file or directory
It looks that all the related folks have known the breakage [1], but
no one shows the interest to bring it back to work. Thus it becomes
a piece of unmaintained code, so let's remove it.
[1] https://lkml.org/lkml/2012/2/9/171
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Paulius Zaleckas paulius.zalec...@teltonika.lt
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: linux-media@vger.kernel.org
---
arch/arm/mach-imx/Makefile |3 -
arch/arm/mach-imx/clk-imx1.c|1 -
arch/arm/mach-imx/devices/Kconfig |3 -
arch/arm/mach-imx/devices/Makefile |1 -
arch/arm/mach-imx/devices/devices-common.h | 10 -
arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 --
arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 -
arch/arm/mach-imx/mx1-camera-fiq.S | 35 -
drivers/media/video/Kconfig | 12 -
drivers/media/video/Makefile|1 -
drivers/media/video/mx1_camera.c| 889 ---
include/linux/platform_data/camera-mx1.h| 35 -
12 files changed, 1050 deletions(-)
delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S
delete mode 100644 drivers/media/video/mx1_camera.c
delete mode 100644 include/linux/platform_data/camera-mx1.h
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index fe47b71..538d0ee 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -35,9 +35,6 @@ obj-y += ssi-fiq.o
obj-y += ssi-fiq-ksym.o
endif
-# Support for CMOS sensor interface
-obj-$(CONFIG_MX1_VIDEO) += mx1-camera-fiq.o mx1-camera-fiq-ksym.o
-
# i.MX1 based machines
obj-$(CONFIG_ARCH_MX1ADS) += mach-mx1ads.o
obj-$(CONFIG_MACH_SCB9328) += mach-scb9328.o
diff --git a/arch/arm/mach-imx/clk-imx1.c b/arch/arm/mach-imx/clk-imx1.c
index b5f90cc..ebfffd2 100644
--- a/arch/arm/mach-imx/clk-imx1.c
+++ b/arch/arm/mach-imx/clk-imx1.c
@@ -84,7 +84,6 @@ int __init mx1_clocks_init(unsigned long fref)
i, PTR_ERR(clk[i]));
clk_register_clkdev(clk[dma_gate], ahb, imx-dma);
- clk_register_clkdev(clk[csi_gate], NULL, mx1-camera.0);
clk_register_clkdev(clk[mma_gate], mma, NULL);
clk_register_clkdev(clk[usbd_gate], NULL, imx_udc.0);
clk_register_clkdev(clk[per1], per, imx-gpt.0);
diff --git a/arch/arm/mach-imx/devices/Kconfig
b/arch/arm/mach-imx/devices/Kconfig
index cb3e3ee..09d796e 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -46,9 +46,6 @@ config IMX_HAVE_PLATFORM_IMX_UDC
config IMX_HAVE_PLATFORM_IPU_CORE
bool
-config IMX_HAVE_PLATFORM_MX1_CAMERA
- bool
-
config IMX_HAVE_PLATFORM_MX2_CAMERA
bool
diff --git a/arch/arm/mach-imx/devices/Makefile
b/arch/arm/mach-imx/devices/Makefile
index ff22ed1..3cfdc37 100644
--- a/arch/arm/mach-imx/devices/Makefile
+++ b/arch/arm/mach-imx/devices/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_SSI) += platform-imx-ssi.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UART) += platform-imx-uart.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UDC) += platform-imx_udc.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IPU_CORE) += platform-ipu-core.o
-obj-$(CONFIG_IMX_HAVE_PLATFORM_MX1_CAMERA) += platform-mx1-camera.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MX2_CAMERA) += platform-mx2-camera.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI) += platform-mxc-ehci.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_MMC) += platform-mxc-mmc.o
diff --git a/arch/arm/mach-imx/devices/devices-common.h
b/arch/arm/mach-imx/devices/devices-common.h
index 9e3e3d8..34419b2 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -199,16 +199,6 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
const struct imx_ipu_core_data *data,
struct mx3fb_platform_data *pdata);
-#include linux/platform_data/camera-mx1.h
-struct imx_mx1_camera_data {
- resource_size_t iobase;
- resource_size_t iosize;
- resource_size_t irq;
-};
-struct platform_device *__init imx_add_mx1_camera(
- const struct imx_mx1_camera_data *data,
- const struct mx1_camera_pdata *pdata);
-
#include linux/platform_data/camera-mx2.h
struct imx_mx2_camera_data {
resource_size_t
[PATCH v2 13/34] dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
The header ipu.h really belongs to dma subsystem rather than imx
platform. Rename it to ipu-dma.h and put it into include/linux/dma/.
Signed-off-by: Shawn Guo shawn@linaro.org
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: linux-media@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
---
drivers/dma/ipu/ipu_idmac.c|3 +--
drivers/dma/ipu/ipu_irq.c |3 +--
drivers/media/video/mx3_camera.c |2 +-
drivers/video/mx3fb.c |2 +-
.../mach/ipu.h = include/linux/dma/ipu-dma.h |6 +++---
5 files changed, 7 insertions(+), 9 deletions(-)
rename arch/arm/mach-imx/include/mach/ipu.h = include/linux/dma/ipu-dma.h
(97%)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index c7573e5..6585537 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -22,8 +22,7 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/module.h
-
-#include mach/ipu.h
+#include linux/dma/ipu-dma.h
#include ../dmaengine.h
#include ipu_intern.h
diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index fa95bcc..a5ee37d 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -15,8 +15,7 @@
#include linux/irq.h
#include linux/io.h
#include linux/module.h
-
-#include mach/ipu.h
+#include linux/dma/ipu-dma.h
#include ipu_intern.h
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 1481b0d..892cba5 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -17,6 +17,7 @@
#include linux/vmalloc.h
#include linux/interrupt.h
#include linux/sched.h
+#include linux/dma/ipu-dma.h
#include media/v4l2-common.h
#include media/v4l2-dev.h
@@ -24,7 +25,6 @@
#include media/soc_camera.h
#include media/soc_mediabus.h
-#include mach/ipu.h
#include linux/platform_data/camera-mx3.h
#include linux/platform_data/dma-imx.h
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index d738108..3b63ad8 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -26,10 +26,10 @@
#include linux/console.h
#include linux/clk.h
#include linux/mutex.h
+#include linux/dma/ipu-dma.h
#include linux/platform_data/dma-imx.h
#include mach/hardware.h
-#include mach/ipu.h
#include linux/platform_data/video-mx3fb.h
#include asm/io.h
diff --git a/arch/arm/mach-imx/include/mach/ipu.h b/include/linux/dma/ipu-dma.h
similarity index 97%
rename from arch/arm/mach-imx/include/mach/ipu.h
rename to include/linux/dma/ipu-dma.h
index 539e559..1803111 100644
--- a/arch/arm/mach-imx/include/mach/ipu.h
+++ b/include/linux/dma/ipu-dma.h
@@ -9,8 +9,8 @@
* published by the Free Software Foundation.
*/
-#ifndef _IPU_H_
-#define _IPU_H_
+#ifndef __LINUX_DMA_IPU_DMA_H
+#define __LINUX_DMA_IPU_DMA_H
#include linux/types.h
#include linux/dmaengine.h
@@ -174,4 +174,4 @@ struct idmac_channel {
#define to_tx_desc(tx) container_of(tx, struct idmac_tx_desc, txd)
#define to_idmac_chan(c) container_of(c, struct idmac_channel, dma_chan)
-#endif
+#endif /* __LINUX_DMA_IPU_DMA_H */
--
1.7.9.5
--
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 v2 25/34] media: mx2_camera: remove dead code in mx2_camera_add_device
This is a piece of code becoming dead since commit 2c9ba37 ([media]
V4L: mx2_camera: remove unsupported i.MX27 DMA mode, make EMMA
mandatory). It should have been removed together with the commit.
Remove it now.
Signed-off-by: Shawn Guo shawn@linaro.org
Acked-by: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Javier Martin javier.mar...@vista-silicon.com
Cc: linux-media@vger.kernel.org
---
drivers/media/video/mx2_camera.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 965427f..89c7e28 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -441,11 +441,9 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
csicr1 = CSICR1_MCLKEN;
- if (cpu_is_mx27()) {
+ if (cpu_is_mx27())
csicr1 |= CSICR1_PRP_IF_EN | CSICR1_FCC |
CSICR1_RXFF_LEVEL(0);
- } else if (cpu_is_mx27())
- csicr1 |= CSICR1_SOF_INTEN | CSICR1_RXFF_LEVEL(2);
pcdev-csicr1 = csicr1;
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
--
1.7.9.5
--
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 v2 26/34] media: mx2_camera: use managed functions to clean up code
Use managed functions to clean up the error handling code and function
mx2_camera_remove(). Along with the change, a few variables get removed
from struct mx2_camera_dev.
Signed-off-by: Shawn Guo shawn@linaro.org
Acked-by: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Tested-by: Javier Martin javier.mar...@vista-silicon.com
Cc: linux-media@vger.kernel.org
---
drivers/media/video/mx2_camera.c | 149 --
1 file changed, 45 insertions(+), 104 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 89c7e28..9bb9e8c 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -274,12 +274,9 @@ struct mx2_camera_dev {
struct soc_camera_device *icd;
struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
- unsigned intirq_csi, irq_emma;
void __iomem*base_csi, *base_emma;
- unsigned long base_dma;
struct mx2_camera_platform_data *pdata;
- struct resource *res_csi, *res_emma;
unsigned long platform_flags;
struct list_headcapture;
@@ -1607,64 +1604,59 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
return IRQ_HANDLED;
}
-static int __devinit mx27_camera_emma_init(struct mx2_camera_dev *pcdev)
+static int __devinit mx27_camera_emma_init(struct platform_device *pdev)
{
- struct resource *res_emma = pcdev-res_emma;
+ struct mx2_camera_dev *pcdev = platform_get_drvdata(pdev);
+ struct resource *res_emma;
+ int irq_emma;
int err = 0;
- if (!request_mem_region(res_emma-start, resource_size(res_emma),
- MX2_CAM_DRV_NAME)) {
- err = -EBUSY;
+ res_emma = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ irq_emma = platform_get_irq(pdev, 1);
+ if (!res_emma || !irq_emma) {
+ dev_err(pcdev-dev, no EMMA resources\n);
goto out;
}
- pcdev-base_emma = ioremap(res_emma-start, resource_size(res_emma));
+ pcdev-base_emma = devm_request_and_ioremap(pcdev-dev, res_emma);
if (!pcdev-base_emma) {
- err = -ENOMEM;
- goto exit_release;
+ err = -EADDRNOTAVAIL;
+ goto out;
}
- err = request_irq(pcdev-irq_emma, mx27_camera_emma_irq, 0,
- MX2_CAM_DRV_NAME, pcdev);
+ err = devm_request_irq(pcdev-dev, irq_emma, mx27_camera_emma_irq, 0,
+ MX2_CAM_DRV_NAME, pcdev);
if (err) {
dev_err(pcdev-dev, Camera EMMA interrupt register failed \n);
- goto exit_iounmap;
+ goto out;
}
- pcdev-clk_emma_ipg = clk_get(pcdev-dev, emma-ipg);
+ pcdev-clk_emma_ipg = devm_clk_get(pcdev-dev, emma-ipg);
if (IS_ERR(pcdev-clk_emma_ipg)) {
err = PTR_ERR(pcdev-clk_emma_ipg);
- goto exit_free_irq;
+ goto out;
}
clk_prepare_enable(pcdev-clk_emma_ipg);
- pcdev-clk_emma_ahb = clk_get(pcdev-dev, emma-ahb);
+ pcdev-clk_emma_ahb = devm_clk_get(pcdev-dev, emma-ahb);
if (IS_ERR(pcdev-clk_emma_ahb)) {
err = PTR_ERR(pcdev-clk_emma_ahb);
- goto exit_clk_emma_ipg_put;
+ goto exit_clk_emma_ipg;
}
clk_prepare_enable(pcdev-clk_emma_ahb);
err = mx27_camera_emma_prp_reset(pcdev);
if (err)
- goto exit_clk_emma_ahb_put;
+ goto exit_clk_emma_ahb;
return err;
-exit_clk_emma_ahb_put:
+exit_clk_emma_ahb:
clk_disable_unprepare(pcdev-clk_emma_ahb);
- clk_put(pcdev-clk_emma_ahb);
-exit_clk_emma_ipg_put:
+exit_clk_emma_ipg:
clk_disable_unprepare(pcdev-clk_emma_ipg);
- clk_put(pcdev-clk_emma_ipg);
-exit_free_irq:
- free_irq(pcdev-irq_emma, pcdev);
-exit_iounmap:
- iounmap(pcdev-base_emma);
-exit_release:
- release_mem_region(res_emma-start, resource_size(res_emma));
out:
return err;
}
@@ -1672,9 +1664,8 @@ out:
static int __devinit mx2_camera_probe(struct platform_device *pdev)
{
struct mx2_camera_dev *pcdev;
- struct resource *res_csi, *res_emma;
- void __iomem *base_csi;
- int irq_csi, irq_emma;
+ struct resource *res_csi;
+ int irq_csi;
int err = 0;
dev_dbg(pdev-dev, initialising\n);
@@ -1687,21 +1678,20 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit;
}
- pcdev = kzalloc(sizeof(*pcdev), GFP_KERNEL);
+ pcdev = devm_kzalloc(pdev-dev, sizeof(*pcdev), GFP_KERNEL);
if (!pcdev) {
dev_err(pdev-dev, Could not allocate pcdev\n);
err = -ENOMEM;
[PATCH v2 27/34] media: mx2_camera: remove cpu_is_xxx by using platform_device_id
It changes the driver to use platform_device_id rather than cpu_is_xxx
to determine the controller type, and updates the platform code
accordingly.
As the result, mach/hardware.h inclusion gets removed from the driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Acked-by: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Tested-by: Javier Martin javier.mar...@vista-silicon.com
Cc: linux-media@vger.kernel.org
---
arch/arm/mach-imx/clk-imx25.c |6 +-
arch/arm/mach-imx/clk-imx27.c |6 +-
arch/arm/mach-imx/devices/devices-common.h |1 +
arch/arm/mach-imx/devices/platform-mx2-camera.c | 12 +--
drivers/media/video/mx2_camera.c| 95 +--
5 files changed, 85 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 1aea073..71fe521 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -231,9 +231,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[esdhc2_ipg_per], per, sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ipg], ipg, sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ahb], ahb, sdhci-esdhc-imx25.1);
- clk_register_clkdev(clk[csi_ipg_per], per, mx2-camera.0);
- clk_register_clkdev(clk[csi_ipg], ipg, mx2-camera.0);
- clk_register_clkdev(clk[csi_ahb], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ipg_per], per, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ipg], ipg, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ahb], ahb, imx25-camera.0);
clk_register_clkdev(clk[dummy], audmux, NULL);
clk_register_clkdev(clk[can1_ipg], NULL, flexcan.0);
clk_register_clkdev(clk[can2_ipg], NULL, flexcan.1);
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 82cb785..f4ec05e 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -224,7 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[per3_gate], per, imx-fb.0);
clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0);
clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0);
- clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ahb_gate], ahb, imx27-camera.0);
clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc);
@@ -251,8 +251,8 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[i2c2_ipg_gate], NULL, imx21-i2c.1);
clk_register_clkdev(clk[owire_ipg_gate], NULL, mxc_w1.0);
clk_register_clkdev(clk[kpp_ipg_gate], NULL, imx-keypad);
- clk_register_clkdev(clk[emma_ahb_gate], emma-ahb, mx2-camera.0);
- clk_register_clkdev(clk[emma_ipg_gate], emma-ipg, mx2-camera.0);
+ clk_register_clkdev(clk[emma_ahb_gate], emma-ahb, imx27-camera.0);
+ clk_register_clkdev(clk[emma_ipg_gate], emma-ipg, imx27-camera.0);
clk_register_clkdev(clk[emma_ahb_gate], ahb, m2m-emmaprp.0);
clk_register_clkdev(clk[emma_ipg_gate], ipg, m2m-emmaprp.0);
clk_register_clkdev(clk[iim_ipg_gate], iim, NULL);
diff --git a/arch/arm/mach-imx/devices/devices-common.h
b/arch/arm/mach-imx/devices/devices-common.h
index 7f2698c..8112a1a 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -202,6 +202,7 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
#include linux/platform_data/camera-mx2.h
struct imx_mx2_camera_data {
+ const char *devid;
resource_size_t iobasecsi;
resource_size_t iosizecsi;
resource_size_t irqcsi;
diff --git a/arch/arm/mach-imx/devices/platform-mx2-camera.c
b/arch/arm/mach-imx/devices/platform-mx2-camera.c
index 9ad5b2d..b88877d 100644
--- a/arch/arm/mach-imx/devices/platform-mx2-camera.c
+++ b/arch/arm/mach-imx/devices/platform-mx2-camera.c
@@ -9,14 +9,16 @@
#include mach/hardware.h
#include devices-common.h
-#define imx_mx2_camera_data_entry_single(soc) \
+#define imx_mx2_camera_data_entry_single(soc, _devid) \
{ \
+ .devid = _devid,\
.iobasecsi = soc ## _CSI_BASE_ADDR, \
.iosizecsi = SZ_4K, \
.irqcsi = soc ## _INT_CSI, \
}
-#define imx_mx2_camera_data_entry_single_emma(soc) \
+#define imx_mx2_camera_data_entry_single_emma(soc, _devid) \
{ \
+
[PATCH] media: sh-vou: fix compilation breakage
A recent commit
commit f135a8a224294fa0f60ec1b8bc120813b7cfc804
Author: Hans Verkuil hans.verk...@cisco.com
Date: Sun Jun 24 06:33:26 2012 -0300
[media] sh_vou: remove V4L2_FL_LOCK_ALL_FOPS
broke compilation of sh_vou.c:
drivers/media/platform/sh_vou.c: In function 'sh_vou_mmap':
drivers/media/platform/sh_vou.c:1227: error: 'vdev' undeclared (first use in
this function)
drivers/media/platform/sh_vou.c:1227: error: (Each undeclared identifier is
reported only once
drivers/media/platform/sh_vou.c:1227: error: for each function it appears in.)
drivers/media/platform/sh_vou.c: In function 'sh_vou_poll':
drivers/media/platform/sh_vou.c:1242: error: 'vdev' undeclared (first use in
this function)
make[2]: *** [drivers/media/platform/sh_vou.o] Error 1
Add missing variable definitions.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
This is a fix for 3.7
drivers/media/platform/sh_vou.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 9f62fd8..7f8b792 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -1224,6 +1224,7 @@ static int sh_vou_release(struct file *file)
static int sh_vou_mmap(struct file *file, struct vm_area_struct *vma)
{
+ struct video_device *vdev = video_devdata(file);
struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
struct sh_vou_file *vou_file = file-private_data;
int ret;
@@ -1239,6 +1240,7 @@ static int sh_vou_mmap(struct file *file, struct
vm_area_struct *vma)
static unsigned int sh_vou_poll(struct file *file, poll_table *wait)
{
+ struct video_device *vdev = video_devdata(file);
struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
struct sh_vou_file *vou_file = file-private_data;
unsigned int res;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver
Hi Richard, On 20 September 2012 05:32, Richard Zhao richard.z...@freescale.com wrote: why is it a request-pull? After 5 version of Philipp's patches we have agreed they are good enough to be merged; they don't break anything related to the old codadx6 while provide support for the new coda7: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627 The pull request is a way to tell Mauro this is ready to be merged in his linux-media tree and making things easier for him. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [media-workshop] [ANNOUNCE] media workshop in November
On Wed, Sep 19, 2012 at 11:19 PM, Michael Krufky mkru...@kernellabs.com wrote: On Wed, Sep 19, 2012 at 7:34 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Mauro, On Wednesday 19 September 2012 05:11:11 Mauro Carvalho Chehab wrote: Dear developers, We're feeling the need for one more media workshop this year. As there will be already several developers going to LinuxCon Europe and Embedded Linux Conference Europe, we'll be co-locating the workshop together with those two events. As there will be several developers speaking about the media subsystem at both LinuxCon and ELCE, we decided to take just one day (September, 8th) for the media workshop (while we expect that we'll likely have some other discussions during the week). In order to finish the arrangements, I need to know who will be attending, and also we need to receive the theme proposals. Please estimate how long do you think that it would be needed for the proposed theme presentation and discussions. I have a theme proposal already: How to improve the patch submission workflow for media patches - 2 hours. So, please confirm your intention to be there and propose the themes of your interests to media-works...@linuxtv.org mailing list. I'll be there. I will be there as well. -Mike Krufky I will be there Jean-Paul Saman -- 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 v2 00/34] i.MX multi-platform support
On Thursday 20 September 2012, Shawn Guo wrote: Here is the second post, which should have addressed the comments that reviewers put on v1. It's available on branch below. git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform-v2 And it's based on the following branches. calxeda/multi-plat arm-soc/multiplatform/platform-data arm-soc/multiplatform/smp_ops arm-soc/imx/cleanup arm-soc/imx/dt sound/for-3.7 Subsystem maintainers, I plan to send the whole series for 3.7 via arm-soc tree. Please let me know if you have problem with that. Thanks. The first five branches are scheduled to go through the arm-soc tree, so I'm fine with that. For the sound/for-3.7 branch, I'd like to know when to expect that hitting mainline. If it always gets in very early during the merge window, it's probably ok to put the imx/multi-platform patches into the same branch as the other ones in arm-soc and wait for the sound stuff to hit mainline first, otherwise I'd suggest we start a second next/multiplatform-2 branch for imx and send the first part early on but then wait with the second batch before sound gets in. 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
[PATCH] [1/5] dvb-apps - update scan file DVB-S 5E
I have created few more patches for DVB-APPS. I believe that even now in the age of blidscans it is better to just have somewhat up to date list to have current directories scanned quickly. My first patch for Hotbird went missing so far as some filter have that returned probably because of the links to the Kingofsat I wrote to the postmaster and it should return in a bit if not I'll send it again in few days. In the meantime here are patches for few more sattelites. I would like to prepare next listing for Astra 28E but I must ask what do You guys think about having it split into 2 separate listings its own for Astra 1N and 2A,B. The plus of that is that people that are (just like me) out of range of Astra 1N as it is directed with spot beam at UK only would not waste time at scanning frequencies they would not be able to reach unless they have 1.8m dish or larger and just to a scan of Astra 2A and 2B which is available in wider area The minus is that if one is living in the UK or are able to reach those frequencies with larger dish now would have to do a scan twice for the same sattelite posission. Anyways it is similar problem to the one with Turksat 42E where programs are send East, West and European spots Regards, Wojciech Myrda--- util/scan/dvb-s/Sirius-5.0E.old 2012-09-20 08:18:48.548053688 +0200 +++ util/scan/dvb-s/Sirius-5.0E 2012-09-20 08:27:49.279133255 +0200 @@ -1,9 +1,6 @@ # Sirius 5.0E # freq pol sr fec -S 11215000 V 000 1/2 -S 11227000 H 23145000 3/4 -S 11247000 V 23145000 3/4 -S 1142 H 23145000 3/4 +S2 11264000 V 3000 3/4 AUTO 8PSK S 11727000 H 2750 5/6 S 11747000 V 2750 3/4 S 11766000 H 2750 3/4 @@ -27,36 +24,29 @@ S 12111000 H 2750 5/6 S 1213 V 2750 3/4 S 12149000 H 2750 3/4 -S 12169000 V 2750 3/4 -S 12188000 H 2750 7/8 -S 12207000 V 2750 3/4 +S2 12169000 V 2750 3/4 AUTO 8PSK +S2 12188000 H 2750 3/4 AUTO 8PSK +S2 12207000 V 3000 3/4 AUTO 8PSK S 12226000 H 2554 7/8 S 12245000 V 2750 3/4 S 12265000 H 2750 3/4 S 12284000 V 2750 3/4 S 12303000 H 25547000 7/8 -S 12322000 V 2750 3/4 -S 12341000 H 2750 3/4 -S 1236 V 2750 7/8 +S 12322000 V 2750 7/8 +S2 12341000 H 2750 3/4 AUTO 8PSK +S 1236 V 2750 3/4 S 12379000 H 2750 3/4 -S 12399000 V 2750 2/3 +S2 12399000 V 2750 3/4 AUTO 8PSK S 12418000 H 2750 3/4 -S 12437000 V 2750 2/3 -S 12456000 H 2750 3/4 +S2 12437000 V 2750 3/4 AUTO 8PSK +S2 12456000 H 2750 3/4 AUTO 8PSK S 12476000 V 2750 3/4 S 12608000 H 2750 3/4 S 12637000 H 14465000 3/4 -S 12668000 V 000 1/2 S 12672000 H 330 3/4 -S 12674000 V 1000 3/4 -S 12678000 V 1000 5/6 -S 1268 H 9404000 3/4 -S 12685000 V 000 3/4 -S 1269 H 333 3/4 +S2 12682000 V 000 2/3 AUTO 8PSK +S 12687000 V 6667000 5/6 S 12693000 V 000 5/6 -S 12701000 H 6111000 3/4 -S 12715000 H 333 3/4 -S 12718000 V 2350 3/4 -S 12724000 H 1772000 3/4 -S 12728000 V 1972 3/4 -S 12737000 V 615 3/4 +S 12703000 V 2963000 3/4 +S 12718000 V 296 7/8 +S2 12728000 V 148 9/10 AUTO 8PSK
[PATCH] [2/5] dvb-apps - update scan file DVB-S 7E
Eutelsat 7E. As I see not available at all in the directory--- /dev/null 2012-09-20 10:05:33.314437212 +0200 +++ util/scan/dvb-s/Eutelsat7A-7.0E 2012-09-20 08:45:37.163331706 +0200 @@ -0,0 +1,28 @@ +# Eutelsat7A-7.0E +# freq pol sr fec +S 10721000 H 2200 3/4 +S 10721000 V 2750 3/4 +S 10762000 V 3000 3/4 +S 10804000 H 2990 3/4 +S2 10845000 H 3000 5/6 AUTO QPSK +S 10845000 V 3000 3/4 +S2 10886000 H 3000 5/6 AUTO QPSK +S2 10886000 V 3000 5/6 AUTO QPSK +S 10928000 H 3000 3/4 +S2 10928000 V 3000 5/6 AUTO QPSK +S 11186000 V 2893000 5/6 +S 11189000 V 2018000 5/6 +S 11221000 H 2750 3/4 +S 11445500 V 2005 3/4 +S 11471000 H 3000 3/4 +S 11492000 V 3000 3/4 +S 11513000 H 2990 3/4 +S 11534000 V 3000 3/4 +S 11554000 H 3000 3/4 +S 11575000 V 3000 3/4 +S 11596000 H 3000 3/4 +S 11617000 V 3000 3/4 +S 11637000 H 3000 3/4 +S 11678000 H 3000 3/4 +S2 1252 H 6144000 3/4 AUTO 8PSK +S2 12531000 V 1852000 2/3 AUTO 8PSK
[PATCH] [3/5] dvb-apps - update scan file DVB-S 9E
Eutelsat 9E--- util/scan/dvb-s/Eutelsat9-9.0E.old 2012-09-20 08:47:47.246366647 +0200 +++ util/scan/dvb-s/Eutelsat9-9.0E 2012-09-20 08:57:30.217456457 +0200 @@ -1,16 +1,33 @@ # Eurobird 9.0E # freq pol sr fec -S 11727000 V 2750 5/6 +S 11727000 V 2750 3/4 S 11747000 H 2750 3/4 -S 11766000 V 2750 5/6 -S 11785000 H 2750 3/4 -S 11804000 V 2750 3/4 +S 11766000 V 2750 3/4 +S2 11785000 H 2750 2/3 AUTO 8PSK S 11823000 H 2750 3/4 S 11843000 V 2750 3/4 -S 11881000 V 2670 3/4 -S 11919000 V 2750 5/6 +S2 11862000 H 2750 2/3 AUTO 8PSK +S2 11881000 V 2750 2/3 AUTO 8PSK +S2 1190 H 2750 2/3 AUTO 8PSK +S 11919000 V 2750 3/4 S 11938000 H 2750 3/4 +S2 11958000 V 2750 2/3 AUTO 8PSK S 11977000 H 2750 3/4 S 11996000 V 2750 3/4 -S 12054000 H 2750 3/4 -S 12092000 H 2750 3/4 +S2 12015000 H 2750 2/3 AUTO 8PSK +S2 12034000 V 2750 3/4 AUTO 8PSK +S2 12054000 H 2750 2/3 AUTO 8PSK +S2 12073000 V 2750 3/4 AUTO 8PSK +S2 12111000 V 2750 3/5 AUTO 8PSK +S 1213 H 2750 3/4 +S2 12149000 V 2750 2/3 AUTO 8PSK +S2 12226000 V 2750 2/3 AUTO 8PSK +S2 12245000 H 2750 3/4 AUTO 8PSK +S2 12265000 V 2750 2/3 AUTO 8PSK +S2 12284000 H 2750 2/3 AUTO 8PSK +S 12322000 H 2750 3/4 +S 12341000 V 2750 3/4 +S2 1236 H 2750 2/3 AUTO 8PSK +S2 12399000 H 2750 2/3 AUTO 8PSK +S 12418000 V 2750 3/4 +S2 12437000 H 2750 2/3 AUTO 8PSK
[PATCH] [4/5] dvb-apps - update scan file DVB-S 28.5E
Eurobird--- util/scan/dvb-s/Eurobird1-28.5E 2012-09-19 11:52:55.0 +0200 +++ /dev/null 2012-09-20 10:05:33.314437212 +0200 @@ -1,5 +0,0 @@ -# Eurobird 28.5E SDT info service transponder -# freq pol sr fec -S 11623000 H 2750 2/3 -S 11224000 V 2750 2/3 -S 11527000 V 2750 2/3
[PATCH] [5/5] dvb-apps - update scan file DVB-S 28.5E
Eutelsat--- /dev/null 2012-09-20 10:05:33.314437212 +0200 +++ util/scan/dvb-s/Eutelsat28A-28.5E 2012-09-20 09:23:16.483702298 +0200 @@ -0,0 +1,32 @@ +# Eutelsat 28.5E +# freq pol sr fec +S 11222000 H 2750 2/3 +S 11224000 V 2750 2/3 +S 11259000 V 2750 2/3 +S 11261000 H 2750 2/3 +S 11307000 H 2750 2/3 +S 11307000 V 2750 2/3 +S 11343000 V 2750 2/3 +S 11344000 H 2750 2/3 +S 11389000 H 2750 2/3 +S 1139 V 2750 2/3 +S 11426000 H 2750 2/3 +S 11426000 V 2750 2/3 +S 11469000 H 2750 2/3 +S 11488000 V 2750 2/3 +S 11508000 H 2750 2/3 +S 11527000 V 2750 2/3 +S 11546000 H 2750 2/3 +S 11565000 V 2750 2/3 +S 11585000 H 2750 2/3 +S 11604000 V 2750 2/3 +S 11623000 H 2750 2/3 +S 11661500 H 2750 2/3 +S 11681000 V 2750 2/3 +S 12524000 V 2750 2/3 +S 1256 H 2750 2/3 +S 1256 V 2750 2/3 +S 12607000 V 2750 2/3 +S 12607000 H 2750 2/3 +S 12643000 H 2750 2/3 +S 12643000 V 2750 2/3
Fwd: [PATCH] [1/5] dvb-apps - update scan file DVB-S 5E
I do not know why mailing list filter caches my first mails. But here they are without the explanations --- util/scan/dvb-s/Sirius-5.0E.old 2012-09-20 08:18:48.548053688 +0200 +++ util/scan/dvb-s/Sirius-5.0E 2012-09-20 08:27:49.279133255 +0200 @@ -1,9 +1,6 @@ # Sirius 5.0E # freq pol sr fec -S 11215000 V 000 1/2 -S 11227000 H 23145000 3/4 -S 11247000 V 23145000 3/4 -S 1142 H 23145000 3/4 +S2 11264000 V 3000 3/4 AUTO 8PSK S 11727000 H 2750 5/6 S 11747000 V 2750 3/4 S 11766000 H 2750 3/4 @@ -27,36 +24,29 @@ S 12111000 H 2750 5/6 S 1213 V 2750 3/4 S 12149000 H 2750 3/4 -S 12169000 V 2750 3/4 -S 12188000 H 2750 7/8 -S 12207000 V 2750 3/4 +S2 12169000 V 2750 3/4 AUTO 8PSK +S2 12188000 H 2750 3/4 AUTO 8PSK +S2 12207000 V 3000 3/4 AUTO 8PSK S 12226000 H 2554 7/8 S 12245000 V 2750 3/4 S 12265000 H 2750 3/4 S 12284000 V 2750 3/4 S 12303000 H 25547000 7/8 -S 12322000 V 2750 3/4 -S 12341000 H 2750 3/4 -S 1236 V 2750 7/8 +S 12322000 V 2750 7/8 +S2 12341000 H 2750 3/4 AUTO 8PSK +S 1236 V 2750 3/4 S 12379000 H 2750 3/4 -S 12399000 V 2750 2/3 +S2 12399000 V 2750 3/4 AUTO 8PSK S 12418000 H 2750 3/4 -S 12437000 V 2750 2/3 -S 12456000 H 2750 3/4 +S2 12437000 V 2750 3/4 AUTO 8PSK +S2 12456000 H 2750 3/4 AUTO 8PSK S 12476000 V 2750 3/4 S 12608000 H 2750 3/4 S 12637000 H 14465000 3/4 -S 12668000 V 000 1/2 S 12672000 H 330 3/4 -S 12674000 V 1000 3/4 -S 12678000 V 1000 5/6 -S 1268 H 9404000 3/4 -S 12685000 V 000 3/4 -S 1269 H 333 3/4 +S2 12682000 V 000 2/3 AUTO 8PSK +S 12687000 V 6667000 5/6 S 12693000 V 000 5/6 -S 12701000 H 6111000 3/4 -S 12715000 H 333 3/4 -S 12718000 V 2350 3/4 -S 12724000 H 1772000 3/4 -S 12728000 V 1972 3/4 -S 12737000 V 615 3/4 +S 12703000 V 2963000 3/4 +S 12718000 V 296 7/8 +S2 12728000 V 148 9/10 AUTO 8PSK
Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver
On Thu, Sep 20, 2012 at 09:10:46AM +0200, javier Martin wrote: Hi Richard, On 20 September 2012 05:32, Richard Zhao richard.z...@freescale.com wrote: why is it a request-pull? After 5 version of Philipp's patches we have agreed they are good enough to be merged; they don't break anything related to the old codadx6 while provide support for the new coda7: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627 The pull request is a way to tell Mauro this is ready to be merged in his linux-media tree and making things easier for him. I know the meaning. I just feel strange. Pull request is normally sent by maintainer to up level maintainer who agreed to receive pull request. Thanks Richard Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver
On 20 September 2012 10:03, Richard Zhao richard.z...@freescale.com wrote: On Thu, Sep 20, 2012 at 09:10:46AM +0200, javier Martin wrote: Hi Richard, On 20 September 2012 05:32, Richard Zhao richard.z...@freescale.com wrote: why is it a request-pull? After 5 version of Philipp's patches we have agreed they are good enough to be merged; they don't break anything related to the old codadx6 while provide support for the new coda7: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627 The pull request is a way to tell Mauro this is ready to be merged in his linux-media tree and making things easier for him. I know the meaning. I just feel strange. Pull request is normally sent by maintainer to up level maintainer who agreed to receive pull request. This was discussed some time ago here: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/078862.html Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver
On 09/20/2012 10:03 AM, Richard Zhao wrote: On Thu, Sep 20, 2012 at 09:10:46AM +0200, javier Martin wrote: Hi Richard, On 20 September 2012 05:32, Richard Zhao richard.z...@freescale.com wrote: why is it a request-pull? After 5 version of Philipp's patches we have agreed they are good enough to be merged; they don't break anything related to the old codadx6 while provide support for the new coda7: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627 The pull request is a way to tell Mauro this is ready to be merged in his linux-media tree and making things easier for him. I know the meaning. I just feel strange. Pull request is normally sent by maintainer to up level maintainer who agreed to receive pull request. There is really high volume of various kind of patches on linux-media mailing lists. Even with those pull requests it becomes hard for Mauro to respond and merge patches in timely manner. There is even a discussion related to this scheduled for media workshop during ELCE/LinuxCon. I think the rules may differ slightly across kernel subsystems, hence I find nothing unusual in using pull requests, especially by sub-subsystem maintainers or developers. Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] gspca_pac7302: add support for green balance adjustment
Hi, On 09/19/2012 10:54 PM, Frank Schäfer wrote: Am 19.09.2012 22:34, schrieb Hans de Goede: snip Hans, it seems like you didn't pick up these patches up yet... Is there anything wrong with them ? I've somehow completely missed them. Can you resend the entire set please? No problem, but I can't do that before weekend (I'm currently not at home). I've sent these 4 patches on last Sunday (16. Sept) evening. Maybe you can pick them up from patchwork ? http://patchwork.linuxtv.org/patch/14433/ Ah yes, patchwork, that will work. Unfortunately that only solves the me having missed the patches problem. First of all thanks for working on this! I'm afraid you've managed to find one of the weak spots in the v4l2 API, namely how we deal with RGB gains. Many webcams have RGB gains, but we don't have standard CID-s for these, instead we've Blue and Red Balance. This has grown historically because of the bttv cards which actually have Blue and Red balance controls in hardware, rather then the usual RGB gain triplet. Various gspca drivers cope with this in different ways. If you look at the pac7302 driver before your latest 4 patches it has a Red and Blue balance control controlling the Red and Blue gain, and a Whitebalance control, which is not White balance at all, but simply controls the green gain... And as said other drivers have similar (albeit usually different) hacks. At a minimum I would like you to rework your patches to: 1) Not add the new Green balance, and instead modify the existing whitebalance to control the new green gain you've found. Keeping things as broken as they are, but not worse; and 2) Try to use both the page 0 reg 0x01 - 0x03 and page 0 reg 0xc5 - 0xc7 at the same time to get a wider ranged control. Maybe 0xc5 - 0xc7 are simply the most significant bits of a wider ranged gain ? Note that if you cannot control them both from a single control in such a way that you get a smooth control range, then lets just fix 0xc5 - 0xc7 at a value of 2 for all 3 and be done with it, but at least we should try :) As said the above is the minimum, what I would really like is a discussion on linux-media about adding proper RGB gain controls for all the cameras which have these. Note this brings with itself the question should we export such lowlevel controls at all ? In some drivers the per color gains are simply all kept at the same level and controlled as part of the master gain control, giving it a wider and/or more fine grained range, leading to better autogain behavior. Given how our sw autowhitebalance works (and that that works reasonable well), their is not much added value in exporting them separately, while they do tend to improve the standard gain control when used as part of it ... So what we really need is a plan how to deal with these controls, and then send an RFC for this to the list. Regards, Hans -- 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] media: sh-vou: fix compilation breakage
On Thu 20 September 2012 08:58:48 Guennadi Liakhovetski wrote:
A recent commit
commit f135a8a224294fa0f60ec1b8bc120813b7cfc804
Author: Hans Verkuil hans.verk...@cisco.com
Date: Sun Jun 24 06:33:26 2012 -0300
[media] sh_vou: remove V4L2_FL_LOCK_ALL_FOPS
broke compilation of sh_vou.c:
drivers/media/platform/sh_vou.c: In function 'sh_vou_mmap':
drivers/media/platform/sh_vou.c:1227: error: 'vdev' undeclared (first use in
this function)
drivers/media/platform/sh_vou.c:1227: error: (Each undeclared identifier is
reported only once
drivers/media/platform/sh_vou.c:1227: error: for each function it appears in.)
drivers/media/platform/sh_vou.c: In function 'sh_vou_poll':
drivers/media/platform/sh_vou.c:1242: error: 'vdev' undeclared (first use in
this function)
make[2]: *** [drivers/media/platform/sh_vou.o] Error 1
Add missing variable definitions.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
I've added the sh arch to the daily build as well. So the next time the daily
build should catch such errors.
Regards,
Hans
---
This is a fix for 3.7
drivers/media/platform/sh_vou.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 9f62fd8..7f8b792 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -1224,6 +1224,7 @@ static int sh_vou_release(struct file *file)
static int sh_vou_mmap(struct file *file, struct vm_area_struct *vma)
{
+ struct video_device *vdev = video_devdata(file);
struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
struct sh_vou_file *vou_file = file-private_data;
int ret;
@@ -1239,6 +1240,7 @@ static int sh_vou_mmap(struct file *file, struct
vm_area_struct *vma)
static unsigned int sh_vou_poll(struct file *file, poll_table *wait)
{
+ struct video_device *vdev = video_devdata(file);
struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
struct sh_vou_file *vou_file = file-private_data;
unsigned int res;
--
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: [PATCHv3 2/9] ir-rx51: Handle signals properly
On Tue, 4 Sep 2012 13:43:56 +0100, Sean Young s...@mess.org wrote: This interface is much better but it's also an ABI change. How should this be handled? Should rc-core expose it's own /dev/rc[0-9] device with its own ioctls? That was the plan yes. I've posted a patchbomb in the past to the linux-media mailing list which implements a rc specific chardev with an ioctl/read/write based API. Since the entire patchset is a bit much to digest and merging of patches has been slow lately, I'm trying to drip-feed the patches. The lirc TX rework was part of that process. It basically lays the groundwork for later patches. //David -- 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 v2 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote: The first five branches are scheduled to go through the arm-soc tree, so I'm fine with that. For the sound/for-3.7 branch, I'd like to know when to expect that hitting mainline. If it always gets in very early during the merge window, it's probably ok to put the imx/multi-platform patches into the same branch as the other ones in arm-soc and wait for the sound stuff to hit mainline first, otherwise I'd suggest we start a second next/multiplatform-2 branch for imx and send the first part early on but then wait with the second batch before sound gets in. It's usually pretty early but Takashi will be on holiday this time so I'm not sure if things might be different (he was going to send the pull request from holiday). I also didn't guarantee that it'll be stable yet, can someone please tell me what the depenency is here? -- 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 v2 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote: It's usually pretty early but Takashi will be on holiday this time so I'm not sure if things might be different (he was going to send the pull request from holiday). I also didn't guarantee that it'll be stable yet, can someone please tell me what the depenency is here? We need the patch to have all imx drivers mach/* inclusion free, so that we can enable multi-platform support for imx, which is the whole point of the series. If your for-3.7 is not stable anyway, I guess the easiest the way to do it might be you drop the patch ASoC: mx27vis: retrieve gpio numbers from platform_data from your tree and I have it be part of the series to go via arm-soc tree as a whole. (This is the original plan that I mentioned in v1 cover letter) Shawn -- 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 4/4] gspca_pac7302: add support for green balance adjustment
Hi, Am 20.09.2012 11:08, schrieb Hans de Goede: Hi, Hans, it seems like you didn't pick up these patches up yet... Is there anything wrong with them ? I've somehow completely missed them. Can you resend the entire set please? No problem, but I can't do that before weekend (I'm currently not at home). I've sent these 4 patches on last Sunday (16. Sept) evening. Maybe you can pick them up from patchwork ? http://patchwork.linuxtv.org/patch/14433/ Ah yes, patchwork, that will work. Unfortunately that only solves the me having missed the patches problem. First of all thanks for working on this! I'm afraid you've managed to find one of the weak spots in the v4l2 API, namely how we deal with RGB gains. It seems like this is one of my talents... :( Many webcams have RGB gains, but we don't have standard CID-s for these, instead we've Blue and Red Balance. This has grown historically because of the bttv cards which actually have Blue and Red balance controls in hardware, rather then the usual RGB gain triplet. Various gspca drivers cope with this in different ways. If you look at the pac7302 driver before your latest 4 patches it has a Red and Blue balance control controlling the Red and Blue gain, and a Whitebalance control, which is not White balance at all, but simply controls the green gain... Ok, so if I understand you right, red+green+blue balance = white balance. And because we already have defined red, blue and whitebalance controls for historical reasons, we don't need green balance ? Maybe that matches physics, but I don't think it's a sane approach for a user interface... And as said other drivers have similar (albeit usually different) hacks. At a minimum I would like you to rework your patches to: 1) Not add the new Green balance, and instead modify the existing whitebalance to control the new green gain you've found. Keeping things as broken as they are, but not worse; and I prefer waiting for the results of the discussion you are proposing further down. 2) Try to use both the page 0 reg 0x01 - 0x03 and page 0 reg 0xc5 - 0xc7 at the same time to get a wider ranged control. Maybe 0xc5 - 0xc7 are simply the most significant bits of a wider ranged gain ? I don't think so. The windows driver does not use them. It even doesn't use the full range of registers 0x01-0x03. Of course, I have expermiented with the full range and it works, but it doesn't make much sense to use it. Experimenting with the device to determine the meaing of unknown registerts, you will notice, that there are several registert which affect RGB. But that doesn't mean that they are suitable for a user control... Note that if you cannot control them both from a single control in such a way that you get a smooth control range, then lets just fix 0xc5 - 0xc7 at a value of 2 for all 3 and be done with it, but at least we should try :) There is no need to fix registers 0xc5 and 0xc7. The Windows driver sets them to 1, which is exactly the value we are currently using as default value with the blue and red value controls. As said the above is the minimum, what I would really like is a discussion on linux-media about adding proper RGB gain controls for all the cameras which have these. Note this brings with itself the question should we export such lowlevel controls at all ? In some drivers the per color gains are simply all kept at the same level and controlled as part of the master gain control, giving it a wider and/or more fine grained range, leading to better autogain behavior. Given how our sw autowhitebalance works (and that that works reasonable well), their is not much added value in exporting them separately, while they do tend to improve the standard gain control when used as part of it ... I would say, let the drivers decide how to do things. It also depends on the hardware design. Regards, Frank So what we really need is a plan how to deal with these controls, and then send an RFC for this to the list. Regards, Hans -- 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
[RFCv2 PATCH 00/14] davinci: clean up input/output/subdev config
Hi Prabhakar, This is the second patch series for a vpif driver cleanup. The first version can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg52136.html Changes since RFCv1: - rebased to a newer git repo: http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/shortlog/refs/heads/da850_vpif_machine - fixed probe() cleanup code in both display and capture that was seriously broken. - fixed a broken s_routing implementation in the tvp514x driver: if there is no incoming video signal, then s_routing would return EINVAL and leave the driver with an inconsistent internal state. This has always been a problem, but with this patch series it suddenly became really noticable. s_routing shouldn't try to wait for a valid signal, that's not what s_routing should do. This patch series does some driver cleanup and reorganizes the config structs that are used to set up subdevices. The current driver associates an input or output with a subdev, but multiple inputs may use the same subdev and some inputs may not use a subdev at all (this is the case for our hardware). Several other things were also configured in the wrong structure. For example the vpif_interface struct is really part of the channel config and has nothing to do with the subdev. What is missing here is that the output doesn't have the same flexibility as the input when it comes to configuration. It would be good if someone can pick this up as a follow-up since it's unlikely I'll be working on that. What would also be nice is that by leaving the inputs or outputs for the second channel empty (NULL) in the configuration you can disable the second video node, e.g. trying to use it will always result in ENODEV or something. This patch series will at least make things more flexible. Regards, Hans -- 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
[RFCv2 PATCH 07/14] vpif_capture: first init subdevs, then register device nodes.
From: Hans Verkuil hans.verk...@cisco.com
When device nodes are registered they must be ready for use
immediately, so make sure the subdevs are loaded first.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_capture.c | 47 +++--
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index e40eacd1..98423b5 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2139,24 +2139,6 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
}
- for (j = 0; j VPIF_CAPTURE_MAX_DEVICES; j++) {
- ch = vpif_obj.dev[j];
- ch-channel_id = j;
- common = (ch-common[VPIF_VIDEO_INDEX]);
- spin_lock_init(common-irqlock);
- mutex_init(common-lock);
- ch-video_dev-lock = common-lock;
- /* Initialize prio member of channel object */
- v4l2_prio_init(ch-prio);
- err = video_register_device(ch-video_dev,
- VFL_TYPE_GRABBER, (j ? 1 : 0));
- if (err)
- goto probe_out;
-
- video_set_drvdata(ch-video_dev, ch);
-
- }
-
i2c_adap = i2c_get_adapter(1);
config = pdev-dev.platform_data;
@@ -2166,7 +2148,7 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd == NULL) {
vpif_err(unable to allocate memory for subdevice pointers\n);
err = -ENOMEM;
- goto probe_out;
+ goto vpif_dev_alloc_err;
}
for (i = 0; i subdev_count; i++) {
@@ -2183,19 +2165,27 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
v4l2_info(vpif_obj.v4l2_dev, registered sub device %s\n,
subdevdata-name);
-
- if (vpif_obj.sd[i])
- vpif_obj.sd[i]-grp_id = 1 i;
}
+ for (j = 0; j VPIF_CAPTURE_MAX_DEVICES; j++) {
+ ch = vpif_obj.dev[j];
+ ch-channel_id = j;
+ common = (ch-common[VPIF_VIDEO_INDEX]);
+ spin_lock_init(common-irqlock);
+ mutex_init(common-lock);
+ ch-video_dev-lock = common-lock;
+ /* Initialize prio member of channel object */
+ v4l2_prio_init(ch-prio);
+ video_set_drvdata(ch-video_dev, ch);
+
+ err = video_register_device(ch-video_dev,
+ VFL_TYPE_GRABBER, (j ? 1 : 0));
+ if (err)
+ goto probe_out;
+ }
v4l2_info(vpif_obj.v4l2_dev, VPIF capture driver initialized\n);
return 0;
-probe_subdev_out:
- /* free sub devices memory */
- kfree(vpif_obj.sd);
-
- j = VPIF_CAPTURE_MAX_DEVICES;
probe_out:
for (k = 0; k j; k++) {
/* Get the pointer to the channel object */
@@ -2203,6 +2193,9 @@ probe_out:
/* Unregister video device */
video_unregister_device(ch-video_dev);
}
+probe_subdev_out:
+ /* free sub devices memory */
+ kfree(vpif_obj.sd);
vpif_dev_alloc_err:
k = VPIF_CAPTURE_MAX_DEVICES-1;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 14/14] tvp514x: s_routing should just change routing, not try to detect a signal.
From: Hans Verkuil hans.verk...@cisco.com
The s_routing function should not try to detect a signal. It is a really
bad idea to try to detect a valid video signal and return an error if
you can't. Changing input should do just that and nothing more.
Also don't power on the ADCs on s_routing, instead do that on querystd.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/tvp514x.c | 77 ---
1 file changed, 6 insertions(+), 71 deletions(-)
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 1f3943b..d5e1021 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -519,6 +519,12 @@ static int tvp514x_querystd(struct v4l2_subdev *sd,
v4l2_std_id *std_id)
*std_id = V4L2_STD_UNKNOWN;
+ /* To query the standard the TVP514x must power on the ADCs. */
+ if (!decoder-streaming) {
+ tvp514x_s_stream(sd, 1);
+ msleep(LOCK_RETRY_DELAY);
+ }
+
/* query the current standard */
current_std = tvp514x_query_current_std(sd);
if (current_std == STD_INVALID)
@@ -625,25 +631,12 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd,
int err;
enum tvp514x_input input_sel;
enum tvp514x_output output_sel;
- u8 sync_lock_status, lock_mask;
- int try_count = LOCK_RETRY_COUNT;
if ((input = INPUT_INVALID) ||
(output = OUTPUT_INVALID))
/* Index out of bound */
return -EINVAL;
- /*
-* For the sequence streamon - streamoff and again s_input
-* it fails to lock the signal, since streamoff puts TVP514x
-* into power off state which leads to failure in sub-sequent s_input.
-*
-* So power up the TVP514x device here, since it is important to lock
-* the signal at this stage.
-*/
- if (!decoder-streaming)
- tvp514x_s_stream(sd, 1);
-
input_sel = input;
output_sel = output;
@@ -660,64 +653,6 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd,
decoder-tvp514x_regs[REG_INPUT_SEL].val = input_sel;
decoder-tvp514x_regs[REG_OUTPUT_FORMATTER1].val = output_sel;
-
- /* Clear status */
- msleep(LOCK_RETRY_DELAY);
- err =
- tvp514x_write_reg(sd, REG_CLEAR_LOST_LOCK, 0x01);
- if (err)
- return err;
-
- switch (input_sel) {
- case INPUT_CVBS_VI1A:
- case INPUT_CVBS_VI1B:
- case INPUT_CVBS_VI1C:
- case INPUT_CVBS_VI2A:
- case INPUT_CVBS_VI2B:
- case INPUT_CVBS_VI2C:
- case INPUT_CVBS_VI3A:
- case INPUT_CVBS_VI3B:
- case INPUT_CVBS_VI3C:
- case INPUT_CVBS_VI4A:
- lock_mask = STATUS_CLR_SUBCAR_LOCK_BIT |
- STATUS_HORZ_SYNC_LOCK_BIT |
- STATUS_VIRT_SYNC_LOCK_BIT;
- break;
-
- case INPUT_SVIDEO_VI2A_VI1A:
- case INPUT_SVIDEO_VI2B_VI1B:
- case INPUT_SVIDEO_VI2C_VI1C:
- case INPUT_SVIDEO_VI2A_VI3A:
- case INPUT_SVIDEO_VI2B_VI3B:
- case INPUT_SVIDEO_VI2C_VI3C:
- case INPUT_SVIDEO_VI4A_VI1A:
- case INPUT_SVIDEO_VI4A_VI1B:
- case INPUT_SVIDEO_VI4A_VI1C:
- case INPUT_SVIDEO_VI4A_VI3A:
- case INPUT_SVIDEO_VI4A_VI3B:
- case INPUT_SVIDEO_VI4A_VI3C:
- lock_mask = STATUS_HORZ_SYNC_LOCK_BIT |
- STATUS_VIRT_SYNC_LOCK_BIT;
- break;
- /* Need to add other interfaces*/
- default:
- return -EINVAL;
- }
-
- while (try_count-- 0) {
- /* Allow decoder to sync up with new input */
- msleep(LOCK_RETRY_DELAY);
-
- sync_lock_status = tvp514x_read_reg(sd,
- REG_STATUS1);
- if (lock_mask == (sync_lock_status lock_mask))
- /* Input detected */
- break;
- }
-
- if (try_count 0)
- return -EINVAL;
-
decoder-input = input;
decoder-output = output;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 03/14] vpif_capture: move input_idx to channel_obj.
From: Hans Verkuil hans.verk...@cisco.com
input_idx does not belong to video_obj. Move it where it belongs.
Also remove the bogus code in the open() function that suddenly
changes the input to 0 for no reason.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_capture.c |9 ++---
drivers/media/platform/davinci/vpif_capture.h |4 ++--
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 78edd01..4233554 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -888,8 +888,6 @@ static int vpif_open(struct file *filep)
if (vpif_obj.sd[i]) {
/* the sub device is registered */
ch-curr_subdev_info = config-subdev_info[i];
- /* make first input as the current input */
- vid_ch-input_idx = 0;
break;
}
}
@@ -1442,10 +1440,8 @@ static int vpif_g_input(struct file *file, void *priv,
unsigned int *index)
{
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
-
- *index = vid_ch-input_idx;
+ *index = ch-input_idx;
return 0;
}
@@ -1462,7 +1458,6 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
- struct video_obj *vid_ch = ch-video;
struct vpif_subdev_info *subdev_info;
int ret = 0, sd_index = 0;
u32 input = 0, output = 0;
@@ -1517,7 +1512,7 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
return ret;
}
}
- vid_ch-input_idx = index;
+ ch-input_idx = index;
ch-curr_subdev_info = subdev_info;
ch-curr_sd_index = sd_index;
/* copy interface parameters to vpif */
diff --git a/drivers/media/platform/davinci/vpif_capture.h
b/drivers/media/platform/davinci/vpif_capture.h
index 0a3904c..a284667 100644
--- a/drivers/media/platform/davinci/vpif_capture.h
+++ b/drivers/media/platform/davinci/vpif_capture.h
@@ -54,8 +54,6 @@ struct video_obj {
/* Currently selected or default standard */
v4l2_std_id stdid;
struct v4l2_dv_timings dv_timings;
- /* This is to track the last input that is passed to application */
- u32 input_idx;
};
struct vpif_cap_buffer {
@@ -121,6 +119,8 @@ struct channel_obj {
enum vpif_channel_id channel_id;
/* index into sd table */
int curr_sd_index;
+ /* Current input */
+ u32 input_idx;
/* ptr to current sub device information */
struct vpif_subdev_info *curr_subdev_info;
/* vpif configuration params */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 06/14] vpif_capture: move routing info from subdev to input.
From: Hans Verkuil hans.verk...@cisco.com
Routing information is a property of the input, not of the subdev.
One subdev may provide multiple inputs, each with its own routing
information.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
arch/arm/mach-davinci/board-da850-evm.c |8
arch/arm/mach-davinci/board-dm646x-evm.c |8
drivers/media/platform/davinci/vpif_capture.c |7 +--
include/media/davinci/vpif_types.h|4 ++--
4 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d92e0ab..514d4d4 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1184,6 +1184,8 @@ static const struct vpif_input da850_ch0_inputs[] = {
.type = V4L2_INPUT_TYPE_CAMERA,
.std = TVP514X_STD_ALL,
},
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.subdev_name = TVP5147_CH0,
},
};
@@ -1196,6 +1198,8 @@ static const struct vpif_input da850_ch1_inputs[] = {
.type = V4L2_INPUT_TYPE_CAMERA,
.std = TVP514X_STD_ALL,
},
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.subdev_name = TVP5147_CH1,
},
};
@@ -1207,8 +1211,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_CVBS_VI2B,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -1222,8 +1224,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_SVIDEO_VI2C_VI1C,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index a0be63b..0daec7e 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -601,8 +601,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_CVBS_VI2B,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -616,8 +614,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_SVIDEO_VI2C_VI1C,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -636,6 +632,8 @@ static const struct vpif_input dm6467_ch0_inputs[] = {
.std = TVP514X_STD_ALL,
},
.subdev_name = TVP5147_CH0,
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
},
};
@@ -648,6 +646,8 @@ static const struct vpif_input dm6467_ch1_inputs[] = {
.std = TVP514X_STD_ALL,
},
.subdev_name = TVP5147_CH1,
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
},
};
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 81ad6a2..e40eacd1 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1464,6 +1464,9 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
chan_cfg = config-chan_config[ch-channel_id];
+ if (index = chan_cfg-input_count)
+ return -EINVAL;
+
if (common-started) {
vpif_err(Streaming in progress\n);
return -EBUSY;
@@ -1502,8 +1505,8 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
}
}
- input = subdev_info-input;
- output = subdev_info-output;
+ input = chan_cfg-inputs[index].input_route;
+ output =
[RFCv2 PATCH 02/14] vpif_display: remove unused data structures.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_display.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.h
b/drivers/media/platform/davinci/vpif_display.h
index 19c7976..8654002 100644
--- a/drivers/media/platform/davinci/vpif_display.h
+++ b/drivers/media/platform/davinci/vpif_display.h
@@ -65,12 +65,6 @@ struct video_obj {
u32 output_id; /* Current output id */
};
-struct vbi_obj {
- int num_services;
- struct vpif_vbi_params vbiparams; /* vpif parameters for the raw
-* vbi data */
-};
-
struct vpif_disp_buffer {
struct vb2_buffer vb;
struct list_head list;
@@ -136,7 +130,6 @@ struct channel_obj {
struct vpif_params vpifparams;
struct common_obj common[VPIF_NUMOBJECTS];
struct video_obj video;
- struct vbi_obj vbi;
};
/* File handle structure */
@@ -168,12 +161,4 @@ struct config_vpif_params {
u8 min_numbuffers;
};
-/* Struct which keeps track of the line numbers for the sliced vbi service */
-struct vpif_service_line {
- u16 service_id;
- u16 service_line[2];
- u16 enc_service_id;
- u8 bytestowrite;
-};
-
#endif /* DAVINCIHD_DISPLAY_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 13/14] davinci: move struct vpif_interface to chan_cfg.
From: Hans Verkuil hans.verk...@cisco.com
struct vpif_interface is channel specific, not subdev specific.
Move it to the channel config.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
arch/arm/mach-davinci/board-da850-evm.c | 24
arch/arm/mach-davinci/board-dm646x-evm.c | 24
drivers/media/platform/davinci/vpif_capture.c |2 +-
include/media/davinci/vpif_types.h|2 +-
4 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 514d4d4..3081ea4 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1211,12 +1211,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
{
.name = TVP5147_CH1,
@@ -1224,12 +1218,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
};
@@ -1239,10 +1227,22 @@ static struct vpif_capture_config
da850_vpif_capture_config = {
.chan_config[0] = {
.inputs = da850_ch0_inputs,
.input_count = ARRAY_SIZE(da850_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
.chan_config[1] = {
.inputs = da850_ch1_inputs,
.input_count = ARRAY_SIZE(da850_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
.card_name = DA850/OMAP-L138 Video Capture,
};
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 0daec7e..ad249c7 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -601,12 +601,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
{
.name = TVP5147_CH1,
@@ -614,12 +608,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
};
@@ -659,10 +647,22 @@ static struct vpif_capture_config dm646x_vpif_capture_cfg
= {
.chan_config[0] = {
.inputs = dm6467_ch0_inputs,
.input_count = ARRAY_SIZE(dm6467_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
.chan_config[1] = {
.inputs = dm6467_ch1_inputs,
.input_count = ARRAY_SIZE(dm6467_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
};
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index f97eb0b..482 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1310,7 +1310,7 @@ static int vpif_set_input(
ch-input_idx = index;
ch-sd = sd;
/* copy interface parameters to vpif */
- ch-vpifparams.iface = subdev_info-vpif_if;
+ ch-vpifparams.iface = chan_cfg-vpif_if;
/* update tvnorms from
[RFCv2 PATCH 11/14] vpif_capture: separate subdev from input.
From: Hans Verkuil hans.verk...@cisco.com
vpif_capture relied on a 1-1 mapping of input and subdev. This is not
necessarily the case. Separate the two. So there is a list of subdevs
and a list of inputs. Each input refers to a subdev and has routing
information. An input does not have to have a subdev.
The initial input for each channel is set to the fist input.
Currently missing is support for associating multiple subdevs with
an input.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_capture.c | 239 -
drivers/media/platform/davinci/vpif_capture.h |6 +-
2 files changed, 113 insertions(+), 132 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 5f81e0f..f97eb0b 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -864,13 +864,11 @@ static unsigned int vpif_poll(struct file *filep,
poll_table * wait)
*/
static int vpif_open(struct file *filep)
{
- struct vpif_capture_config *config = vpif_dev-platform_data;
struct video_device *vdev = video_devdata(filep);
struct common_obj *common;
struct video_obj *vid_ch;
struct channel_obj *ch;
struct vpif_fh *fh;
- int i;
vpif_dbg(2, debug, vpif_open\n);
@@ -879,24 +877,6 @@ static int vpif_open(struct file *filep)
vid_ch = ch-video;
common = ch-common[VPIF_VIDEO_INDEX];
- if (NULL == ch-curr_subdev_info) {
- /**
-* search through the sub device to see a registered
-* sub device and make it as current sub device
-*/
- for (i = 0; i config-subdev_count; i++) {
- if (vpif_obj.sd[i]) {
- /* the sub device is registered */
- ch-curr_subdev_info = config-subdev_info[i];
- break;
- }
- }
- if (i == config-subdev_count) {
- vpif_err(No sub device registered\n);
- return -ENOENT;
- }
- }
-
/* Allocate memory for the file handle object */
fh = kzalloc(sizeof(struct vpif_fh), GFP_KERNEL);
if (NULL == fh) {
@@ -1174,10 +1154,9 @@ static int vpif_streamon(struct file *file, void *priv,
return ret;
/* Enable streamon on the sub device */
- ret = v4l2_subdev_call(vpif_obj.sd[ch-curr_sd_index], video,
- s_stream, 1);
+ ret = v4l2_subdev_call(ch-sd, video, s_stream, 1);
- if (ret (ret != -ENOIOCTLCMD)) {
+ if (ret ret != -ENOIOCTLCMD ret != -ENODEV) {
vpif_dbg(1, debug, stream on failed in subdev\n);
return ret;
}
@@ -1237,73 +1216,105 @@ static int vpif_streamoff(struct file *file, void
*priv,
common-started = 0;
- ret = v4l2_subdev_call(vpif_obj.sd[ch-curr_sd_index], video,
- s_stream, 0);
+ ret = v4l2_subdev_call(ch-sd, video, s_stream, 0);
- if (ret (ret != -ENOIOCTLCMD))
+ if (ret ret != -ENOIOCTLCMD ret != -ENODEV)
vpif_dbg(1, debug, stream off failed in subdev\n);
return vb2_streamoff(common-buffer_queue, buftype);
}
/**
- * vpif_map_sub_device_to_input() - Maps sub device to input
- * @ch - ptr to channel
- * @config - ptr to capture configuration
+ * vpif_input_to_subdev() - Maps input to sub device
+ * @vpif_cfg - global config ptr
+ * @chan_cfg - channel config ptr
* @input_index - Given input index from application
- * @sub_device_index - index into sd table
*
* lookup the sub device information for a given input index.
* we report all the inputs to application. inputs table also
* has sub device name for the each input
*/
-static struct vpif_subdev_info *vpif_map_sub_device_to_input(
- struct channel_obj *ch,
- struct vpif_capture_config *vpif_cfg,
- int input_index,
- int *sub_device_index)
+static int vpif_input_to_subdev(
+ struct vpif_capture_config *vpif_cfg,
+ struct vpif_capture_chan_config *chan_cfg,
+ int input_index)
{
- struct vpif_capture_chan_config *chan_cfg;
- struct vpif_subdev_info *subdev_info = NULL;
- const char *subdev_name = NULL;
+ struct vpif_subdev_info *subdev_info;
+ const char *subdev_name;
int i;
- vpif_dbg(2, debug, vpif_map_sub_device_to_input\n);
-
- chan_cfg = vpif_cfg-chan_config[ch-channel_id];
+ vpif_dbg(2, debug, vpif_input_to_subdev\n);
- /**
-* search through the inputs to find the sub device supporting
-* the input
-*/
-
[RFCv2 PATCH 12/14] vpif_display: use a v4l2_subdev pointer to call a subdev.
From: Hans Verkuil hans.verk...@cisco.com
This makes it easier to have outputs without subdevs.
This needs more work. The way the outputs are configured should be identical
to how inputs are configured.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_display.c | 17 +
drivers/media/platform/davinci/vpif_display.h |1 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 66b4b32..8d1ce09 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1246,6 +1246,8 @@ static int vpif_s_output(struct file *file, void *priv,
unsigned int i)
vpif_err(Failed to set output standard\n);
ch-output_idx = i;
+ if (vpif_obj.sd[i])
+ ch-sd = vpif_obj.sd[i];
return ret;
}
@@ -1317,14 +1319,13 @@ static int vpif_s_dv_timings(struct file *file, void
*priv,
}
/* Configure subdevice timings, if any */
- ret = v4l2_subdev_call(vpif_obj.sd[ch-output_idx],
- video, s_dv_timings, timings);
+ ret = v4l2_subdev_call(ch-sd, video, s_dv_timings, timings);
if (ret == -ENOIOCTLCMD) {
vpif_dbg(2, debug, Custom DV timings not supported by
subdevice\n);
- return -EINVAL;
+ return -ENODATA;
}
- if (ret 0) {
+ if (ret 0 ret != -ENODEV) {
vpif_dbg(2, debug, Error setting custom DV timings\n);
return ret;
}
@@ -1449,8 +1450,7 @@ static int vpif_dbg_g_register(struct file *file, void
*priv,
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
- g_register, reg);
+ return v4l2_subdev_call(ch-sd, core, g_register, reg);
}
/*
@@ -1467,8 +1467,7 @@ static int vpif_dbg_s_register(struct file *file, void
*priv,
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
- s_register, reg);
+ return v4l2_subdev_call(ch-sd, core, s_register, reg);
}
#endif
@@ -1737,6 +1736,8 @@ static __init int vpif_probe(struct platform_device *pdev)
}
ch-initialized = 0;
+ if (subdev_count)
+ ch-sd = vpif_obj.sd[0];
ch-channel_id = j;
if (j 2)
ch-common[VPIF_VIDEO_INDEX].numbuffers =
diff --git a/drivers/media/platform/davinci/vpif_display.h
b/drivers/media/platform/davinci/vpif_display.h
index 805704c..dca2a8c0 100644
--- a/drivers/media/platform/davinci/vpif_display.h
+++ b/drivers/media/platform/davinci/vpif_display.h
@@ -125,6 +125,7 @@ struct channel_obj {
u8 initialized; /* flag to indicate whether
* encoder is initialized */
u32 output_idx; /* Current output index */
+ struct v4l2_subdev *sd; /* Current output subdev (may be NULL)
*/
enum vpif_channel_id channel_id;/* Identifies channel */
struct vpif_params vpifparams;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 09/14] vpif_display: fix cleanup code.
From: Hans Verkuil hans.verk...@cisco.com
The cleanup sequence was incorrect and could cause a kernel oops.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_display.c | 30 +++--
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index e71c88f..66b4b32 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1607,7 +1607,8 @@ static __init int vpif_probe(struct platform_device *pdev)
{
struct vpif_subdev_info *subdevdata;
struct vpif_display_config *config;
- int i, j = 0, k, q, m, err = 0;
+ int i, j = 0, k, err = 0;
+ int res_idx = 0;
struct i2c_adapter *i2c_adap;
struct common_obj *common;
struct channel_obj *ch;
@@ -1630,21 +1631,21 @@ static __init int vpif_probe(struct platform_device
*pdev)
return err;
}
- k = 0;
- while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+ while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
for (i = res-start; i = res-end; i++) {
if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
VPIF_Display,
- (void *)(vpif_obj.dev[k]-channel_id))) {
+ (void
*)(vpif_obj.dev[res_idx]-channel_id))) {
err = -EBUSY;
+ for (j = 0; j i; j++)
+ free_irq(j, (void
*)(vpif_obj.dev[res_idx]-channel_id));
goto vpif_int_err;
}
}
- k++;
+ res_idx++;
}
for (i = 0; i VPIF_DISPLAY_MAX_DEVICES; i++) {
-
/* Get the pointer to the channel object */
ch = vpif_obj.dev[i];
@@ -1698,7 +1699,7 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd == NULL) {
vpif_err(unable to allocate memory for subdevice pointers\n);
err = -ENOMEM;
- goto vpif_int_err;
+ goto vpif_sd_error;
}
for (i = 0; i subdev_count; i++) {
@@ -1775,14 +1776,19 @@ probe_out:
}
probe_subdev_out:
kfree(vpif_obj.sd);
+vpif_sd_error:
+ for (i = 0; i VPIF_DISPLAY_MAX_DEVICES; i++) {
+ ch = vpif_obj.dev[i];
+ /* Note: does nothing if ch-video_dev == NULL */
+ video_device_release(ch-video_dev);
+ }
vpif_int_err:
v4l2_device_unregister(vpif_obj.v4l2_dev);
vpif_err(VPIF IRQ request failed\n);
- for (q = k; k = 0; k--) {
- for (m = i; m = res-start; m--)
- free_irq(m, (void *)(vpif_obj.dev[k]-channel_id));
- res = platform_get_resource(pdev, IORESOURCE_IRQ, k-1);
- m = res-end;
+ for (i = 0; i res_idx; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+ for (j = res-start; j = res-end; j++)
+ free_irq(j, (void *)(vpif_obj.dev[i]-channel_id));
}
return err;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 08/14] vpif_display: first init subdevs, then register device nodes.
From: Hans Verkuil hans.verk...@cisco.com
When device nodes are registered they must be ready for use
immediately, so make sure the subdevs are loaded first.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_display.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index f394599..e71c88f 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1689,6 +1689,32 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
}
+ i2c_adap = i2c_get_adapter(1);
+ config = pdev-dev.platform_data;
+ subdev_count = config-subdev_count;
+ subdevdata = config-subdevinfo;
+ vpif_obj.sd = kzalloc(sizeof(struct v4l2_subdev *) * subdev_count,
+ GFP_KERNEL);
+ if (vpif_obj.sd == NULL) {
+ vpif_err(unable to allocate memory for subdevice pointers\n);
+ err = -ENOMEM;
+ goto vpif_int_err;
+ }
+
+ for (i = 0; i subdev_count; i++) {
+ vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(vpif_obj.v4l2_dev,
+ i2c_adap,
+ subdevdata[i].board_info,
+ NULL);
+ if (!vpif_obj.sd[i]) {
+ vpif_err(Error registering v4l2 subdevice\n);
+ goto probe_subdev_out;
+ }
+
+ if (vpif_obj.sd[i])
+ vpif_obj.sd[i]-grp_id = 1 i;
+ }
+
for (j = 0; j VPIF_DISPLAY_MAX_DEVICES; j++) {
ch = vpif_obj.dev[j];
/* Initialize field of the channel objects */
@@ -1724,6 +1750,7 @@ static __init int vpif_probe(struct platform_device *pdev)
ch-common[VPIF_VIDEO_INDEX].fmt.type =
V4L2_BUF_TYPE_VIDEO_OUTPUT;
ch-video_dev-lock = common-lock;
+ video_set_drvdata(ch-video_dev, ch);
/* register video device */
vpif_dbg(1, debug, channel=%x,channel-video_dev=%x\n,
@@ -1733,42 +1760,12 @@ static __init int vpif_probe(struct platform_device
*pdev)
VFL_TYPE_GRABBER, (j ? 3 : 2));
if (err 0)
goto probe_out;
-
- video_set_drvdata(ch-video_dev, ch);
- }
-
- i2c_adap = i2c_get_adapter(1);
- config = pdev-dev.platform_data;
- subdev_count = config-subdev_count;
- subdevdata = config-subdevinfo;
- vpif_obj.sd = kzalloc(sizeof(struct v4l2_subdev *) * subdev_count,
- GFP_KERNEL);
- if (vpif_obj.sd == NULL) {
- vpif_err(unable to allocate memory for subdevice pointers\n);
- err = -ENOMEM;
- goto probe_out;
- }
-
- for (i = 0; i subdev_count; i++) {
- vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(vpif_obj.v4l2_dev,
- i2c_adap,
- subdevdata[i].board_info,
- NULL);
- if (!vpif_obj.sd[i]) {
- vpif_err(Error registering v4l2 subdevice\n);
- goto probe_subdev_out;
- }
-
- if (vpif_obj.sd[i])
- vpif_obj.sd[i]-grp_id = 1 i;
}
v4l2_info(vpif_obj.v4l2_dev,
VPIF display driver initialized\n);
return 0;
-probe_subdev_out:
- kfree(vpif_obj.sd);
probe_out:
for (k = 0; k j; k++) {
ch = vpif_obj.dev[k];
@@ -1776,6 +1773,8 @@ probe_out:
video_device_release(ch-video_dev);
ch-video_dev = NULL;
}
+probe_subdev_out:
+ kfree(vpif_obj.sd);
vpif_int_err:
v4l2_device_unregister(vpif_obj.v4l2_dev);
vpif_err(VPIF IRQ request failed\n);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 05/14] vpif_capture: remove unnecessary can_route flag.
From: Hans Verkuil hans.verk...@cisco.com
Calling a subdev op that isn't implemented will just return -ENOIOCTLCMD
No need to have a flag for that.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
arch/arm/mach-davinci/board-da850-evm.c |2 --
arch/arm/mach-davinci/board-dm646x-evm.c |2 --
drivers/media/platform/davinci/vpif_capture.c | 18 --
include/media/davinci/vpif_types.h|1 -
4 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d0954a2..d92e0ab 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1209,7 +1209,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
},
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -1225,7 +1224,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
},
.input = INPUT_SVIDEO_VI2C_VI1C,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 958679a..a0be63b 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -603,7 +603,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
},
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -619,7 +618,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
},
.input = INPUT_SVIDEO_VI2C_VI1C,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 4233554..81ad6a2 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1502,15 +1502,13 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
}
}
- if (subdev_info-can_route) {
- input = subdev_info-input;
- output = subdev_info-output;
- ret = v4l2_subdev_call(vpif_obj.sd[sd_index], video, s_routing,
- input, output, 0);
- if (ret 0) {
- vpif_dbg(1, debug, Failed to set input\n);
- return ret;
- }
+ input = subdev_info-input;
+ output = subdev_info-output;
+ ret = v4l2_subdev_call(vpif_obj.sd[sd_index], video, s_routing,
+ input, output, 0);
+ if (ret 0 ret != -ENOIOCTLCMD) {
+ vpif_dbg(1, debug, Failed to set input\n);
+ return ret;
}
ch-input_idx = index;
ch-curr_subdev_info = subdev_info;
@@ -1520,7 +1518,7 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
/* update tvnorms from the sub device input info */
ch-video_dev-tvnorms = chan_cfg-inputs[index].input.std;
- return ret;
+ return 0;
}
/**
diff --git a/include/media/davinci/vpif_types.h
b/include/media/davinci/vpif_types.h
index d8f6ab1..1fe46a5 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -39,7 +39,6 @@ struct vpif_subdev_info {
struct i2c_board_info board_info;
u32 input;
u32 output;
- unsigned can_route:1;
struct vpif_interface vpif_if;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 04/14] vpif_display: move output_id to channel_obj.
From: Hans Verkuil hans.verk...@cisco.com
The output index does not belong to video_obj, it belongs to
channel_obj. Also rename to output_idx to be consistent with
the input_idx name used in vpif_capture.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_display.c | 17 ++---
drivers/media/platform/davinci/vpif_display.h |2 +-
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 2c06778..f394599 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1231,7 +1231,6 @@ static int vpif_s_output(struct file *file, void *priv,
unsigned int i)
{
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
int ret = 0;
@@ -1246,7 +1245,7 @@ static int vpif_s_output(struct file *file, void *priv,
unsigned int i)
if (ret 0)
vpif_err(Failed to set output standard\n);
- vid_ch-output_id = i;
+ ch-output_idx = i;
return ret;
}
@@ -1254,9 +1253,8 @@ static int vpif_g_output(struct file *file, void *priv,
unsigned int *i)
{
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- *i = vid_ch-output_id;
+ *i = ch-output_idx;
return 0;
}
@@ -1291,9 +1289,8 @@ vpif_enum_dv_timings(struct file *file, void *priv,
{
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- return v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id],
+ return v4l2_subdev_call(vpif_obj.sd[ch-output_idx],
video, enum_dv_timings, timings);
}
@@ -1320,7 +1317,7 @@ static int vpif_s_dv_timings(struct file *file, void
*priv,
}
/* Configure subdevice timings, if any */
- ret = v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id],
+ ret = v4l2_subdev_call(vpif_obj.sd[ch-output_idx],
video, s_dv_timings, timings);
if (ret == -ENOIOCTLCMD) {
vpif_dbg(2, debug, Custom DV timings not supported by
@@ -1451,9 +1448,8 @@ static int vpif_dbg_g_register(struct file *file, void
*priv,
struct v4l2_dbg_register *reg){
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- return v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id], core,
+ return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
g_register, reg);
}
@@ -1470,9 +1466,8 @@ static int vpif_dbg_s_register(struct file *file, void
*priv,
struct v4l2_dbg_register *reg){
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- return v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id], core,
+ return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
s_register, reg);
}
#endif
diff --git a/drivers/media/platform/davinci/vpif_display.h
b/drivers/media/platform/davinci/vpif_display.h
index 8654002..805704c 100644
--- a/drivers/media/platform/davinci/vpif_display.h
+++ b/drivers/media/platform/davinci/vpif_display.h
@@ -62,7 +62,6 @@ struct video_obj {
v4l2_std_id stdid; /* Currently selected or default
* standard */
struct v4l2_dv_timings dv_timings;
- u32 output_id; /* Current output id */
};
struct vpif_disp_buffer {
@@ -125,6 +124,7 @@ struct channel_obj {
* which is being displayed */
u8 initialized; /* flag to indicate whether
* encoder is initialized */
+ u32 output_idx; /* Current output index */
enum vpif_channel_id channel_id;/* Identifies channel */
struct vpif_params vpifparams;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 01/14] vpif_capture: remove unused data structure.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_capture.h |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.h
b/drivers/media/platform/davinci/vpif_capture.h
index e4b54be..0a3904c 100644
--- a/drivers/media/platform/davinci/vpif_capture.h
+++ b/drivers/media/platform/davinci/vpif_capture.h
@@ -159,10 +159,6 @@ struct config_vpif_params {
u32 video_limit[VPIF_CAPTURE_NUM_CHANNELS];
u8 max_device_type;
};
-/* Struct which keeps track of the line numbers for the sliced vbi service */
-struct vpif_service_line {
- u16 service_id;
- u16 service_line[2];
-};
+
#endif /* End of __KERNEL__ */
#endif /* VPIF_CAPTURE_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 10/14] vpif_capture: fix cleanup code.
From: Hans Verkuil hans.verk...@cisco.com
The cleanup sequence was incorrect and could cause a kernel oops.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_capture.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 98423b5..5f81e0f 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2060,7 +2060,8 @@ static __init int vpif_probe(struct platform_device *pdev)
{
struct vpif_subdev_info *subdevdata;
struct vpif_capture_config *config;
- int i, j, k, m, q, err;
+ int i, j, k, err;
+ int res_idx = 0;
struct i2c_adapter *i2c_adap;
struct channel_obj *ch;
struct common_obj *common;
@@ -2083,18 +2084,18 @@ static __init int vpif_probe(struct platform_device
*pdev)
return err;
}
- k = 0;
- while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+ while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
for (i = res-start; i = res-end; i++) {
if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
VPIF_Capture,
- (void *)(vpif_obj.dev[k]-channel_id))) {
+ (void
*)(vpif_obj.dev[res_idx]-channel_id))) {
err = -EBUSY;
- i--;
+ for (j = 0; j i; j++)
+ free_irq(j, (void
*)(vpif_obj.dev[res_idx]-channel_id));
goto vpif_int_err;
}
}
- k++;
+ res_idx++;
}
for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
@@ -2108,7 +2109,7 @@ static __init int vpif_probe(struct platform_device *pdev)
video_device_release(ch-video_dev);
}
err = -ENOMEM;
- goto vpif_dev_alloc_err;
+ goto vpif_int_err;
}
/* Initialize field of video device */
@@ -2148,7 +2149,7 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd == NULL) {
vpif_err(unable to allocate memory for subdevice pointers\n);
err = -ENOMEM;
- goto vpif_dev_alloc_err;
+ goto vpif_sd_error;
}
for (i = 0; i subdev_count; i++) {
@@ -2197,21 +2198,19 @@ probe_subdev_out:
/* free sub devices memory */
kfree(vpif_obj.sd);
-vpif_dev_alloc_err:
- k = VPIF_CAPTURE_MAX_DEVICES-1;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, k);
- i = res-end;
-
-vpif_int_err:
- for (q = k; q = 0; q--) {
- for (m = i; m = (int)res-start; m--)
- free_irq(m, (void *)(vpif_obj.dev[q]-channel_id));
-
- res = platform_get_resource(pdev, IORESOURCE_IRQ, q-1);
- if (res)
- i = res-end;
+vpif_sd_error:
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ ch = vpif_obj.dev[i];
+ /* Note: does nothing if ch-video_dev == NULL */
+ video_device_release(ch-video_dev);
}
+vpif_int_err:
v4l2_device_unregister(vpif_obj.v4l2_dev);
+ for (i = 0; i res_idx; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+ for (j = res-start; j = res-end; j++)
+ free_irq(j, (void *)(vpif_obj.dev[i]-channel_id));
+ }
return err;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote: On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote: It's usually pretty early but Takashi will be on holiday this time so I'm not sure if things might be different (he was going to send the pull request from holiday). I also didn't guarantee that it'll be stable yet, can someone please tell me what the depenency is here? We need the patch to have all imx drivers mach/* inclusion free, so that we can enable multi-platform support for imx, which is the whole point of the series. That doesn't answer the question. What is the dependency - what is it about this patch that something else depends on? Your cover letters just say you'd like to do this but don't mention dependencies at all and when I asked the question last night you said the same thing. I've not seen the rest of the series... If your for-3.7 is not stable anyway, I guess the easiest the way It probably *is* stable but I'm not enthused about people pulling unsigned tags. I might rebase, though - I'm going to finalise the tree in the next few days. to do it might be you drop the patch ASoC: mx27vis: retrieve gpio numbers from platform_data from your tree and I have it be part of the series to go via arm-soc tree as a whole. (This is the original plan that I mentioned in v1 cover letter) You just mentioned it as a preference (you said it's something you'd like to do), please if you're doing this sort of cross tree thing be explicit about what the inter-tree relationships are. If things need to go in via the same tree say so explicitly (and ideally say way this is). The main reason I applied it straight away was that Javier mentioned that it was a bug fix and it's near the merge window and these random ARM cleanup serieses never seem to go in quickly. -- 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 v2 11/34] media: mx1_camera: remove the driver
Em 20-09-2012 03:45, Shawn Guo escreveu: The mx1_camera driver has been broken for a few release cycles since commit 6bd0812 (dmaengine: imx-dma: merge old dma-v1.c with imx-dma.c). It seems there is no one even compile tested it since then, as doing so will end up with the following error. CC drivers/media/video/mx1_camera.o In file included from drivers/media/video/mx1_camera.c:44:0: arch/arm/mach-imx/include/mach/dma-mx1-mx2.h:8:25: fatal error: mach/dma-v1.h: No such file or directory It looks that all the related folks have known the breakage [1], but no one shows the interest to bring it back to work. Thus it becomes a piece of unmaintained code, so let's remove it. It is better to mark it as BROKEN for the next Kernel, and then to move it to staging, before dropping a broken driver. That gives people some time to fix it, if someone has interests on fixing the issues. [1] https://lkml.org/lkml/2012/2/9/171 Signed-off-by: Shawn Guo shawn@linaro.org Cc: Paulius Zaleckas paulius.zalec...@teltonika.lt Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-media@vger.kernel.org --- arch/arm/mach-imx/Makefile |3 - arch/arm/mach-imx/clk-imx1.c|1 - arch/arm/mach-imx/devices/Kconfig |3 - arch/arm/mach-imx/devices/Makefile |1 - arch/arm/mach-imx/devices/devices-common.h | 10 - arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 -- arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 - arch/arm/mach-imx/mx1-camera-fiq.S | 35 - drivers/media/video/Kconfig | 12 - drivers/media/video/Makefile|1 - drivers/media/video/mx1_camera.c| 889 --- Btw, this conflicts with the tree renaming patches already at -staging, as this driver location is elsewhere. Regards, Mauro include/linux/platform_data/camera-mx1.h| 35 - 12 files changed, 1050 deletions(-) delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S delete mode 100644 drivers/media/video/mx1_camera.c delete mode 100644 include/linux/platform_data/camera-mx1.h diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index fe47b71..538d0ee 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -35,9 +35,6 @@ obj-y += ssi-fiq.o obj-y += ssi-fiq-ksym.o endif -# Support for CMOS sensor interface -obj-$(CONFIG_MX1_VIDEO) += mx1-camera-fiq.o mx1-camera-fiq-ksym.o - # i.MX1 based machines obj-$(CONFIG_ARCH_MX1ADS) += mach-mx1ads.o obj-$(CONFIG_MACH_SCB9328) += mach-scb9328.o diff --git a/arch/arm/mach-imx/clk-imx1.c b/arch/arm/mach-imx/clk-imx1.c index b5f90cc..ebfffd2 100644 --- a/arch/arm/mach-imx/clk-imx1.c +++ b/arch/arm/mach-imx/clk-imx1.c @@ -84,7 +84,6 @@ int __init mx1_clocks_init(unsigned long fref) i, PTR_ERR(clk[i])); clk_register_clkdev(clk[dma_gate], ahb, imx-dma); - clk_register_clkdev(clk[csi_gate], NULL, mx1-camera.0); clk_register_clkdev(clk[mma_gate], mma, NULL); clk_register_clkdev(clk[usbd_gate], NULL, imx_udc.0); clk_register_clkdev(clk[per1], per, imx-gpt.0); diff --git a/arch/arm/mach-imx/devices/Kconfig b/arch/arm/mach-imx/devices/Kconfig index cb3e3ee..09d796e 100644 --- a/arch/arm/mach-imx/devices/Kconfig +++ b/arch/arm/mach-imx/devices/Kconfig @@ -46,9 +46,6 @@ config IMX_HAVE_PLATFORM_IMX_UDC config IMX_HAVE_PLATFORM_IPU_CORE bool -config IMX_HAVE_PLATFORM_MX1_CAMERA - bool - config IMX_HAVE_PLATFORM_MX2_CAMERA bool diff --git a/arch/arm/mach-imx/devices/Makefile b/arch/arm/mach-imx/devices/Makefile index ff22ed1..3cfdc37 100644 --- a/arch/arm/mach-imx/devices/Makefile +++ b/arch/arm/mach-imx/devices/Makefile @@ -17,7 +17,6 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_SSI) += platform-imx-ssi.o obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UART) += platform-imx-uart.o obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UDC) += platform-imx_udc.o obj-$(CONFIG_IMX_HAVE_PLATFORM_IPU_CORE) += platform-ipu-core.o -obj-$(CONFIG_IMX_HAVE_PLATFORM_MX1_CAMERA) += platform-mx1-camera.o obj-$(CONFIG_IMX_HAVE_PLATFORM_MX2_CAMERA) += platform-mx2-camera.o obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI) += platform-mxc-ehci.o obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_MMC) += platform-mxc-mmc.o diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h index 9e3e3d8..34419b2 100644 --- a/arch/arm/mach-imx/devices/devices-common.h +++ b/arch/arm/mach-imx/devices/devices-common.h @@ -199,16 +199,6 @@ struct platform_device *__init imx_add_mx3_sdc_fb( const struct imx_ipu_core_data *data, struct
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
Hi Hans, On Thursday 20 September 2012 08:38:26 Hans Verkuil wrote: On Wed September 19 2012 20:46:19 Laurent Pinchart wrote: On Thursday 13 September 2012 12:40:07 Hans Verkuil wrote: On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote: On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++-- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). I thought about that, but should that be defined in the spec? I'm not sure if that's the right place. On the other hand, if we don't specify the format of the bus_info field precisely, it will only be usable as an opaque identifier to userspace. What do we want to do with bus_info ? Telling otherwise identical devices apart is a must, but do we want to provide more information to userspace ? If the field had been longer a sysfs path might have been a good idea, but it won't fit. Well, we can use the bus_info to find a device in sysfs. E.g. for the ivtv card I get bus_info PCI::0b:01.0 and the same device is found here in sysfs: /sys/bus/pci/devices/:0b:01.0 For PCI (and probably PCIe) devices we're probably safe. We can try to document the relationship between bus_info and sysfs here and that would define bus_info exactly. That sounds good to me. I don't quite see how a usb bus_info maps to sysfs, however. Do you know? It's a bit more difficult. usb_make_path() uses snprintf(buf, size, usb-%s-%s, dev-bus-bus_name, dev-devpath); to create the path. dev-bus-bus_name is the physical USB host controller name, and devpath the USB device path relative to that controller. For instance my UVC webcam produces usb-:00:1d.0-1.4 :00:1d.0 refers to the PCI USB host controller, but doesn't mention that it's a PCI device. If I'm not mistaken, 1.4 refers to port 4 on root hub 1. Knowing that the USB host controller is a PCI device, I can get the USB host controller number: $ ls -d /sys/bus/pci/devices/:00:1d.0/usb[0-9] /sys/bus/pci/devices/:00:1d.0/usb2 and then go the to USB device itself: $ ls -d /sys/bus/usb/devices/2-1.4 /sys/bus/usb/devices/2-1.4 That's a bit hackish though. -- 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: [PATCH v2 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 08:47:10AM -0400, Mark Brown wrote: On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote: On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote: It's usually pretty early but Takashi will be on holiday this time so I'm not sure if things might be different (he was going to send the pull request from holiday). I also didn't guarantee that it'll be stable yet, can someone please tell me what the depenency is here? We need the patch to have all imx drivers mach/* inclusion free, so that we can enable multi-platform support for imx, which is the whole point of the series. That doesn't answer the question. What is the dependency - what is it about this patch that something else depends on? Your cover letters just say you'd like to do this but don't mention dependencies at all and when I asked the question last night you said the same thing. I've not seen the rest of the series... Ah, right. You did get copied on the whole series. So the whole point of patch ASoC: mx27vis: retrieve gpio numbers from platform_data is to get rid of inclusion mach/iomux-mx27.h. This has to be done before we enable multi-platform support for imx, since mach/* has to be removed completely for multi-platform build. If your for-3.7 is not stable anyway, I guess the easiest the way It probably *is* stable but I'm not enthused about people pulling unsigned tags. I might rebase, though - I'm going to finalise the tree in the next few days. to do it might be you drop the patch ASoC: mx27vis: retrieve gpio numbers from platform_data from your tree and I have it be part of the series to go via arm-soc tree as a whole. (This is the original plan that I mentioned in v1 cover letter) You just mentioned it as a preference (you said it's something you'd like to do), please if you're doing this sort of cross tree thing be explicit about what the inter-tree relationships are. If things need to go in via the same tree say so explicitly (and ideally say way this is). Ok, my bad. The main reason I applied it straight away was that Javier mentioned that it was a bug fix and it's near the merge window and these random ARM cleanup serieses never seem to go in quickly. The series is planned for 3.7 merge window. Is it still possible for you to drop the patch from your tree to ease the process? Or I will hold my pull-request to arm-soc until you tell me you have your tree finalized. Shawn -- 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 v2 11/34] media: mx1_camera: remove the driver
On Thu, Sep 20, 2012 at 09:56:34AM -0300, Mauro Carvalho Chehab wrote: It is better to mark it as BROKEN for the next Kernel, and then to move it to staging, before dropping a broken driver. That gives people some time to fix it, if someone has interests on fixing the issues. Ok. The driver has already been broken, and the patch marking it BROKEN does not necessarily need to be in this series. I will drop the patch from this series and send a separate patch based on media tree for that. drivers/media/video/Kconfig | 12 - drivers/media/video/Makefile|1 - drivers/media/video/mx1_camera.c| 889 --- Btw, this conflicts with the tree renaming patches already at -staging, as this driver location is elsewhere. mx1_camera.c is not a concern any more. However the series touches mx2_camera.c and mx3_camera.c as well. I just tested to merge the series with linux-next. Strangely, git does not detect the renaming for automatically merging changes. Do you have a stable branch for media patches that I can pull as dependency? Shawn -- 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 v2 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote: The first five branches are scheduled to go through the arm-soc tree, so I'm fine with that. For the sound/for-3.7 branch, I'd like to know when to expect that hitting mainline. If it always gets in very early during the merge window, it's probably ok to put the imx/multi-platform patches into the same branch as the other ones in arm-soc and wait for the sound stuff to hit mainline first, otherwise I'd suggest we start a second next/multiplatform-2 branch for imx and send the first part early on but then wait with the second batch before sound gets in. It seems that we will have to go with next/multiplatform-2. I just tried to merge the series with linux-next together, and got some non-trivial conflicts with media and mtd tree. I might have to rebase my series on top of these trees to sort out those conflicts. That said, I will have several dependencies outside arm-soc tree, and have to pend my series until all those trees get merged into mainline. Shawn -- 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 v2 00/34] i.MX multi-platform support
On Thursday 20 September 2012, Shawn Guo wrote: On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote: The first five branches are scheduled to go through the arm-soc tree, so I'm fine with that. For the sound/for-3.7 branch, I'd like to know when to expect that hitting mainline. If it always gets in very early during the merge window, it's probably ok to put the imx/multi-platform patches into the same branch as the other ones in arm-soc and wait for the sound stuff to hit mainline first, otherwise I'd suggest we start a second next/multiplatform-2 branch for imx and send the first part early on but then wait with the second batch before sound gets in. It seems that we will have to go with next/multiplatform-2. I just tried to merge the series with linux-next together, and got some non-trivial conflicts with media and mtd tree. I might have to rebase my series on top of these trees to sort out those conflicts. That said, I will have several dependencies outside arm-soc tree, and have to pend my series until all those trees get merged into mainline. Ok, fair enough. I think we can put it in arm-soc/for-next as a staging branch anyway to give it some exposure to linux-next, and then we can decide whether a rebase is necessary before sending it to Linus. 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
[PATCH] em28xx: PCTV 520e workaround for DRX-K fw loading
This is hack to make device working again.
Looks like we need to wait DRX-K fw loading is ready until tuner
is attached as tuner is behind demod I2C bus.
For some reason it still crash when device is re-plugged without
module unloading...
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/em28xx/em28xx-dvb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 5b7f2b3..4e46fef 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1128,6 +1128,9 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb-fe[0] = dvb_attach(drxk_attach, pctv_520e_drxk,
dev-i2c_adap);
+ /* FIXME: wait demod fw is loaded, up and running */
+ msleep(2000);
+
if (dvb-fe[0]) {
/* attach tuner */
if (!dvb_attach(tda18271_attach, dvb-fe[0], 0x60,
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tda18271 driver power consumption
On Mon, Aug 6, 2012 at 3:13 PM, Antti Palosaari cr...@iki.fi wrote: On 08/06/2012 09:57 PM, Michael Krufky wrote: On Mon, Aug 6, 2012 at 2:35 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Aug 6, 2012 at 2:19 PM, Antti Palosaari cr...@iki.fi wrote: You should understand from DVB driver model: * attach() called only once when driver is loaded * init() called to wake-up device * sleep() called to sleep device What I would like to say is that there is very big risk to shoot own leg when doing some initialization on attach(). For example resuming from the suspend could cause device reset and if you rely some settings that are done during attach() you will likely fail as Kernel / USB-host controller has reset your device. See reset_resume from Kernel documentation: Documentation/usb/power-management.txt Be forewarned: there is a very high likelihood that this patch will cause regressions on hybrid devices due to known race conditions related to dvb_frontend sleeping the tuner asynchronously on close. This is a hybrid tuner, and unless code is specifically added to the bridge or tuner driver, going from digital to analog mode too quickly will cause the tuner to be shutdown while it's actively in analog mode. (I discovered this the hard way when working on problems MythTV users reported against the HVR-950q). Description of race: 1. User opens DVB frontend tunes 2. User closes DVB frontend 3. User *immediately* opens V4L device using same tuner 4. User performs tuning request for analog 5. DVB frontend issues sleep() call to tuner, causing analog tuning to fail. This class of problem isn't seen on DVB only devices or those that have dedicated digital tuners not shared for analog usage. And in some cases it isn't noticed because a delay between closing the DVB device and opening the analog devices causes the sleep() call to happen before the analog tune (in which case you don't hit the race). I'm certainly not against improved power management, but it will require the race conditions to be fixed first in order to avoid regressions. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Devin's right. I'm sorry, please *don't* merge the patch, Mauro. Antti, you should just call sleep from your driver after attach(), as I had previously suggested. We can revisit this some time in the future after we can be sure that these race conditions wont occur. OK, maybe it is safer then. I have no any hybrid hardware to test... Anyhow, I wonder how many years it will take to resolve that V4L2/DVB API hybrid usage pŕoblem. I ran thinking that recently when looked how to implement DVB SDR for V4L2 API... I could guess problem will not disappear near future even analog TV disappears, because there is surely coming new nasty features which spreads over both V4L2 and DVB APIs. Guys, Please take another look at this branch and test if possible -- I pushed an additional patch that takes Devin's concerns into account. After applying these patches, the tda18271 driver will behave as it always has, but it will sleep the tuner after attaching the first instance. If there is only one instance, then this works exactly as Antti desires. If there are more instances, then the tuner will only be woken up again during attach if the tda18271_need_cal_on_startup() returns non-zero. The driver does not attempt to re-sleep the hardware again during successive attach() calls. I have not tested this yet myself, but I believe it resolves the matter -- please comment. Regards, Mike Krufky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tda18271 driver power consumption
On Thu, Sep 20, 2012 at 1:47 PM, Michael Krufky mkru...@linuxtv.org wrote: On Mon, Aug 6, 2012 at 3:13 PM, Antti Palosaari cr...@iki.fi wrote: On 08/06/2012 09:57 PM, Michael Krufky wrote: On Mon, Aug 6, 2012 at 2:35 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Aug 6, 2012 at 2:19 PM, Antti Palosaari cr...@iki.fi wrote: You should understand from DVB driver model: * attach() called only once when driver is loaded * init() called to wake-up device * sleep() called to sleep device What I would like to say is that there is very big risk to shoot own leg when doing some initialization on attach(). For example resuming from the suspend could cause device reset and if you rely some settings that are done during attach() you will likely fail as Kernel / USB-host controller has reset your device. See reset_resume from Kernel documentation: Documentation/usb/power-management.txt Be forewarned: there is a very high likelihood that this patch will cause regressions on hybrid devices due to known race conditions related to dvb_frontend sleeping the tuner asynchronously on close. This is a hybrid tuner, and unless code is specifically added to the bridge or tuner driver, going from digital to analog mode too quickly will cause the tuner to be shutdown while it's actively in analog mode. (I discovered this the hard way when working on problems MythTV users reported against the HVR-950q). Description of race: 1. User opens DVB frontend tunes 2. User closes DVB frontend 3. User *immediately* opens V4L device using same tuner 4. User performs tuning request for analog 5. DVB frontend issues sleep() call to tuner, causing analog tuning to fail. This class of problem isn't seen on DVB only devices or those that have dedicated digital tuners not shared for analog usage. And in some cases it isn't noticed because a delay between closing the DVB device and opening the analog devices causes the sleep() call to happen before the analog tune (in which case you don't hit the race). I'm certainly not against improved power management, but it will require the race conditions to be fixed first in order to avoid regressions. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Devin's right. I'm sorry, please *don't* merge the patch, Mauro. Antti, you should just call sleep from your driver after attach(), as I had previously suggested. We can revisit this some time in the future after we can be sure that these race conditions wont occur. OK, maybe it is safer then. I have no any hybrid hardware to test... Anyhow, I wonder how many years it will take to resolve that V4L2/DVB API hybrid usage pŕoblem. I ran thinking that recently when looked how to implement DVB SDR for V4L2 API... I could guess problem will not disappear near future even analog TV disappears, because there is surely coming new nasty features which spreads over both V4L2 and DVB APIs. Guys, Please take another look at this branch and test if possible -- I pushed an additional patch that takes Devin's concerns into account. After applying these patches, the tda18271 driver will behave as it always has, but it will sleep the tuner after attaching the first instance. If there is only one instance, then this works exactly as Antti desires. If there are more instances, then the tuner will only be woken up again during attach if the tda18271_need_cal_on_startup() returns non-zero. The driver does not attempt to re-sleep the hardware again during successive attach() calls. I have not tested this yet myself, but I believe it resolves the matter -- please comment. Regards, Mike Krufky ...in case the URL got lost: The following changes since commit 0c7d5a6da75caecc677be1fda207b7578936770d: Linux 3.5-rc5 (2012-07-03 22:57:41 +0300) are available in the git repository at: git://linuxtv.org/mkrufky/tuners tda18271 for you to fetch changes up to 4e46c5d1bbb920165fecfe7de18b2c01d9787230: tda18271: make 'low-power standby mode after attach' multi-instance safe (2012-09-20 13:34:29 -0400) Michael Krufky (2): tda18271: enter low-power standby mode at the end of tda18271_attach() tda18271: make 'low-power standby mode after attach' multi-instance safe drivers/media/common/tuners/tda18271-fe.c |4 1 file changed, 4 insertions(+) Best regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 19-09-12 22:52, Devin Heitmueller wrote: On Wed, Sep 19, 2012 at 2:44 PM, oli...@schinagl.nl wrote: From: Oliver Schinagl oli...@schinagl.nl This is initial support for the Asus MyCinema U3100Mini Plus. The driver in its current form gets detected and loads properly. Scanning using dvbscan works without problems, Locking onto a channel using tzap also works fine. Only playback using tzap -r + mplayer was tested and was fully functional. Hi Oliver, The previous thread suggested that this driver didn't work with dvbv5-scan and w_scan. Is that still the case? If so, do we really want a half working driver upstream? Seems like this is more likely to cause support headaches than the device not being supported at all (since users will think it's supported but it's actually broken in some pretty common use cases). After working in antti's changes. dvbscan: works dvbv5-scan: works w_scan -X: works w_scan -x: works tzap: works (only tested the 3 available FTA channels) dvbv5-zap: couldn't figure out how to work it :) It says: Usage: dvbv5-zap [OPTION...] initial file but probably means Channel name? I tried several combinations, with both a regular channels.conf file and a dvb_channels.conf file. I will play more with it when I find some extra time. dvbscan and dvbv5-scan does constantly say 'tuning failed' but it does say that on my terratec too. It does work fine however, so probably a bug in driver/tool unrelated to this patch. Or perhaps I'm mistaken and the issues have been addressed and now it works with all the common applications. Devin -- 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] Support for Asus MyCinema U3100Mini Plus
From: Oliver Schinagl oli...@schinagl.nl
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.
Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.
It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
used is the FCI FC2580.
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/dvb-frontends/af9033.c | 4
drivers/media/dvb-frontends/af9033.h | 1 +
drivers/media/dvb-frontends/af9033_priv.h | 37 +++
drivers/media/tuners/fc2580.c | 3 ++-
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++
drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
8 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
#define USB_PID_ASUS_U3000 0x171f
#define USB_PID_ASUS_U3000H0x1736
#define USB_PID_ASUS_U3100 0x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
#define USB_PID_YUAN_EC372S0x1edc
#define USB_PID_YUAN_STK7700PH 0x1f08
#define USB_PID_YUAN_PD378S0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+ case AF9033_TUNER_FC2580:
+ len = ARRAY_SIZE(tuner_init_fc2580);
+ init = tuner_init_fc2580;
+ break;
default:
dev_dbg(state-i2c-dev, %s: unsupported tuner ID=%d\n,
__func__, state-cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h
b/drivers/media/dvb-frontends/af9033.h
index 288622b..bfa4313 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
#define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */
#define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
#define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580 0x32 /* FCI FC2580 */
u8 tuner;
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..34dddcd 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,42 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
};
+/* FCI FC2580 tuner init */
+static const struct reg_val tuner_init_fc2580[] = {
+ { 0x800046, 0x32 },
+ { 0x800057, 0x01 },
+ { 0x800058, 0x00 },
+ { 0x80005f, 0x00 },
+ { 0x800060, 0x00 },
+ { 0x800071, 0x05 },
+ { 0x800072, 0x02 },
+ { 0x800074, 0x01 },
+ { 0x800079, 0x01 },
+ { 0x800093, 0x00 },
+ { 0x800094, 0x00 },
+ { 0x800095, 0x00 },
+ { 0x800096, 0x05 },
+ { 0x8000b3, 0x01 },
+ { 0x8000c3, 0x01 },
+ { 0x8000c4, 0x00 },
+ { 0x80f007, 0x00 },
+ { 0x80f00c, 0x19 },
+ { 0x80f00d, 0x1A },
+ { 0x80f00e, 0x00 },
+ { 0x80f00f, 0x02 },
+ { 0x80f010, 0x00 },
+ { 0x80f011, 0x02 },
+ { 0x80f012, 0x00 },
+ { 0x80f013, 0x02 },
+ { 0x80f014, 0x00 },
+ { 0x80f015, 0x02 },
+ { 0x80f01f, 0x96 },
+ { 0x80f020, 0x00 },
+ { 0x80f029, 0x96 },
+ { 0x80f02a, 0x00 },
+ { 0x80f077, 0x01 },
+ { 0x80f1e6, 0x01 },
+};
+
#endif /* AF9033_PRIV_H */
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index afc0491..51bc39c 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
dev_dbg(priv-i2c-dev, %s: chip_id=%02x\n, __func__, chip_id);
- if (chip_id != 0x56)
+ if ((chip_id != 0x56) (chip_id != 0x5a)) {
goto err;
+ }
dev_info(priv-i2c-dev,
%s: FCI FC2580 successfully identified\n,
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index e09930c..834bfec 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 19-09-12 23:36, Antti Palosaari wrote:
This is review, please fix those minor findings mentioned and resend
fixed patch!
Will do!
On 09/19/2012 09:44 PM, oli...@schinagl.nl wrote:
From: Oliver Schinagl oli...@schinagl.nl
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.
Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.
It uses the af9035 USB Bridge chip, with an af9033 demodulator. The
tuner
used is the FCI FC2580.
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/dvb-frontends/af9033.c | 4
drivers/media/dvb-frontends/af9033.h | 1 +
drivers/media/dvb-frontends/af9033_priv.h | 38
+++
drivers/media/tuners/fc2580.c | 3 ++-
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++
drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
8 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
#define USB_PID_ASUS_U30000x171f
#define USB_PID_ASUS_U3000H0x1736
#define USB_PID_ASUS_U31000x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
#define USB_PID_YUAN_EC372S0x1edc
#define USB_PID_YUAN_STK7700PH0x1f08
#define USB_PID_YUAN_PD378S0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+case AF9033_TUNER_FC2580:
+len = ARRAY_SIZE(tuner_init_fc2580);
+init = tuner_init_fc2580;
+break;
default:
dev_dbg(state-i2c-dev, %s: unsupported tuner ID=%d\n,
__func__, state-cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h
b/drivers/media/dvb-frontends/af9033.h
index 288622b..739137e 100644 This is review, please fix those minor
findings mentioned an
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
#define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */
#define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
#define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580 0x32 /* FIC FC2580 */
typo in name
It took me atleast 5 minutes to realize I wrote FCI as FIC. I corrected
all instances.
u8 tuner;
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..d2c9ae6 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,43 @@ static const struct reg_val
tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
};
+/* FIC FC2580 tuner init
+ AF9033_TUNER_FC2580 = 0x32 */
+static const struct reg_val tuner_init_fc2580[] = {
+{ 0x800046, AF9033_TUNER_FC2580 },
Personally I don't like that define here. It causes some extra work
last time I looked USB sniffs as *just* that field is the field you
are first looking for. I am going to change it anyway, feel free to
leave if you wish, it is not error, thus I am not going to say you
must change it.
I was actually going to ask if it is 100% guaranteed to always be the
tuner identifier here. If that is the case, for all tuners, I don't see
the harm, especially with comment above. But I have removed it as per
request, and also since I doubt one can always guarantee that all
tuners have the tunerid there.
+{ 0x800057, 0x01 },
+{ 0x800058, 0x00 },
+{ 0x80005f, 0x00 },
+{ 0x800060, 0x00 },
+{ 0x800071, 0x05 },
+{ 0x800072, 0x02 },
+{ 0x800074, 0x01 },
+{ 0x800079, 0x01 },
+{ 0x800093, 0x00 },
+{ 0x800094, 0x00 },
+{ 0x800095, 0x00 },
+{ 0x800096, 0x05 },
+{ 0x8000b3, 0x01 },
+{ 0x8000c3, 0x01 },
+{ 0x8000c4, 0x00 },
+{ 0x80f007, 0x00 },
+{ 0x80f00c, 0x19 },
+{ 0x80f00d, 0x1A },
+{ 0x80f00e, 0x00 },
+{ 0x80f00f, 0x02 },
+{ 0x80f010, 0x00 },
+{ 0x80f011, 0x02 },
+{ 0x80f012, 0x00 },
+{ 0x80f013, 0x02 },
+{ 0x80f014, 0x00 },
+{ 0x80f015, 0x02 },
+{ 0x80f01f, 0x96 },
+{ 0x80f020, 0x00 },
+{ 0x80f029, 0x96 },
+{ 0x80f02a, 0x00 },
+{ 0x80f077, 0x01 },
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Sep 20 19:00:22 CEST 2012 git hash:4313902ebe33155209472215c62d2f29d117be29 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS 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: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 09/20/2012 09:57 PM, oli...@schinagl.nl wrote:
From: Oliver Schinagl oli...@schinagl.nl
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.
Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.
It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
used is the FCI FC2580.
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi
It is OK. Mauro, please merge to the master.
@Oliver, you didn't fixed FC2580 useless braces as I requested. Anyway,
I will sent another patch to fix it later. Action not required.
regards
Antti
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/dvb-frontends/af9033.c | 4
drivers/media/dvb-frontends/af9033.h | 1 +
drivers/media/dvb-frontends/af9033_priv.h | 37 +++
drivers/media/tuners/fc2580.c | 3 ++-
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++
drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
8 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
#define USB_PID_ASUS_U30000x171f
#define USB_PID_ASUS_U3000H 0x1736
#define USB_PID_ASUS_U31000x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
#define USB_PID_YUAN_EC372S 0x1edc
#define USB_PID_YUAN_STK7700PH0x1f08
#define USB_PID_YUAN_PD378S 0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+ case AF9033_TUNER_FC2580:
+ len = ARRAY_SIZE(tuner_init_fc2580);
+ init = tuner_init_fc2580;
+ break;
default:
dev_dbg(state-i2c-dev, %s: unsupported tuner ID=%d\n,
__func__, state-cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h
b/drivers/media/dvb-frontends/af9033.h
index 288622b..bfa4313 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
#define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */
#define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
#define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580 0x32 /* FCI FC2580 */
u8 tuner;
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..34dddcd 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,42 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
};
+/* FCI FC2580 tuner init */
+static const struct reg_val tuner_init_fc2580[] = {
+ { 0x800046, 0x32 },
+ { 0x800057, 0x01 },
+ { 0x800058, 0x00 },
+ { 0x80005f, 0x00 },
+ { 0x800060, 0x00 },
+ { 0x800071, 0x05 },
+ { 0x800072, 0x02 },
+ { 0x800074, 0x01 },
+ { 0x800079, 0x01 },
+ { 0x800093, 0x00 },
+ { 0x800094, 0x00 },
+ { 0x800095, 0x00 },
+ { 0x800096, 0x05 },
+ { 0x8000b3, 0x01 },
+ { 0x8000c3, 0x01 },
+ { 0x8000c4, 0x00 },
+ { 0x80f007, 0x00 },
+ { 0x80f00c, 0x19 },
+ { 0x80f00d, 0x1A },
+ { 0x80f00e, 0x00 },
+ { 0x80f00f, 0x02 },
+ { 0x80f010, 0x00 },
+ { 0x80f011, 0x02 },
+ { 0x80f012, 0x00 },
+ { 0x80f013, 0x02 },
+ { 0x80f014, 0x00 },
+ { 0x80f015, 0x02 },
+ { 0x80f01f, 0x96 },
+ { 0x80f020, 0x00 },
+ { 0x80f029, 0x96 },
+ { 0x80f02a, 0x00 },
+ { 0x80f077, 0x01 },
+ { 0x80f1e6, 0x01 },
+};
+
#endif /* AF9033_PRIV_H */
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index afc0491..51bc39c 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
dev_dbg(priv-i2c-dev, %s: chip_id=%02x\n, __func__, chip_id);
- if (chip_id != 0x56)
+ if ((chip_id
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On Thu, Sep 20, 2012 at 2:54 PM, Oliver Schinagl oliver+l...@schinagl.nl wrote: dvbscan and dvbv5-scan does constantly say 'tuning failed' but it does say that on my terratec too. It does work fine however, so probably a bug in driver/tool unrelated to this patch. Just to be clear, the message tuning failed is expected behavior (albeit very misleading). Basically it means that the tuning attempt was performed but it failed to get a frequency lock on that channel. This is very common in cases where you're scanning a range of frequencies where many of them will not actually achieve a signal lock. I would really like to change that message to something more clear, especially since you're certainly not the first one to think it indicated there was a problem. Suggestions/patches welcome. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 20-09-12 21:15, Antti Palosaari wrote: On 09/20/2012 09:57 PM, oli...@schinagl.nl wrote: From: Oliver Schinagl oli...@schinagl.nl This is initial support for the Asus MyCinema U3100Mini Plus. The driver in its current form gets detected and loads properly. Scanning using dvbscan works without problems, Locking onto a channel using tzap also works fine. Only playback using tzap -r + mplayer was tested and was fully functional. It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner used is the FCI FC2580. Signed-off-by: Oliver Schinagl oli...@schinagl.nl Acked-by: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi It is OK. Mauro, please merge to the master. I do hope that it won't be a problem as I based it on your remotes/origin/for_v3.7-13 @Oliver, you didn't fixed FC2580 useless braces as I requested. Anyway, I will sent another patch to fix it later. Action not required. Ah, I did comment on that change in my reply on your comments; a re-paste from that: Checkpatch did not trigger on this. Which makes sense. Kernel CodingStyle is in very strong favor of KR and from what I know from KR, KR strongly discourage not using braces as it is very likely to introduce bugs. Wikipedia has a small mention of this, then again wikipedia is wikipedia. I will take it out of you really want it out, but with checkpatch not even complaining, I would think this as an improvement. :D regards Antti -- 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] Support for Asus MyCinema U3100Mini Plus
On 09/20/2012 10:28 PM, Oliver Schinagl wrote:
On 20-09-12 21:15, Antti Palosaari wrote:
On 09/20/2012 09:57 PM, oli...@schinagl.nl wrote:
From: Oliver Schinagl oli...@schinagl.nl
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.
Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.
It uses the af9035 USB Bridge chip, with an af9033 demodulator. The
tuner
used is the FCI FC2580.
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi
It is OK. Mauro, please merge to the master.
I do hope that it won't be a problem as I based it on your
remotes/origin/for_v3.7-13
@Oliver, you didn't fixed FC2580 useless braces as I requested.
Anyway, I will sent another patch to fix it later. Action not required.
Ah, I did comment on that change in my reply on your comments; a
re-paste from that:
Checkpatch did not trigger on this. Which makes sense. Kernel
CodingStyle is in very strong favor of KR and from what I know from
KR, KR strongly discourage not using braces as it is very likely to
introduce bugs. Wikipedia has a small mention of this, then again
wikipedia is wikipedia.
I am quite sure it says braces are not allowed for if () when it is
single line.
I will take it out of you really want it out, but with checkpatch not
even complaining, I would think this as an improvement. :D
Seems like you are correct, it does not detect it from the patch for
reason or the other. Maybe you could sent patch to fix checkpatch.pl :)
But it seems to find it when asked to check file correctness.
Anyway, my eyes seems to be again more careful than checkpatch ;-)
[crope@localhost linux]$ git show --format=email | ./scripts/checkpatch.pl -
total: 0 errors, 0 warnings, 141 lines checked
Your patch has no obvious style problems and is ready for submission.
[crope@localhost linux]$ ./scripts/checkpatch.pl --file
drivers/media/tuners/fc2580.c
WARNING: braces {} are not necessary for single statement blocks
#501: FILE: media/tuners/fc2580.c:501:
+ if ((chip_id != 0x56) (chip_id != 0x5a)) {
+ goto err;
+ }
total: 0 errors, 1 warnings, 525 lines checked
drivers/media/tuners/fc2580.c has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[crope@localhost linux]$
Antti
--
http://palosaari.fi/
--
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] Timestamps and V4L2
Hi all,
This RFC intends to summarise and further the recent discussion on
linux-media regarding the proposed changes of timestamping V4L2 buffers.
The problem
===
The V4L2 has long used realtime timestamps (such as
clock_gettime(CLOCK_REALTIME, ...)) to stamp the video buffers before
handing them over to the user. This has been found problematic in
associating the video buffers with data from other sources: realtime clock
may jump around due to daylight saving time, for example, and ALSA
(audio-video synchronisation is a common use case) user space API does not
provide the user with realtime timestamps, but instead uses monotonic time
(i.e. clock_gettime(CLOCK_MONOTONIC, ...)).
This is especially an issue in embedded systems where video recording is a
common use case. Drivers typically used in such systems have silently
switched to use monotonic timestamps. While against the spec, this is
necessary for those systems to operate properly.
In general, realtime timestamps are seen of little use in other than
debugging purposes, but monotonic timestamps are fine for that as well. It's
still possible that an application I'm not aware of uses them in a peculiar
way that would be adversely affected by changing to monotonic timestamps.
Nevertheless, we're not supposed to break the API (or ABI). It'd be also
very important for the application to know what kind of timestamps are
provided by the device.
Requirements, wishes and constraints
Now that it seems to be about the time to fix these issues, it's worth
looking a little bit to the future to anticipate the coming changes to be
able to accommodate them better later on.
- The new default should be monotonic. As the monotonic timestamps are seen
to be the most useful, they should be made the default.
- timeval vs. timespec. The two structs can be used to store timestamp
information. They are not compatible with each other. It's a little bit
uncertain what's the case with all the architectures but it looks like the
timespec fits into the space of timeval in all cases. If timespec is
considered to be used somewhere the compatibility must be ensured. Timespec
is better than timeval since timespec has more precision and it's the same
struct that's used everywhere else in the V4L2 API: timespec does not need
conversion to timespec in the user space.
struct timespec {
__kernel_time_t tv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};
struct timeval {
__kernel_time_t tv_sec; /* seconds */
__kernel_suseconds_ttv_usec;/* microseconds */
};
To be able to use timespec, the user would have to most likely explicitly
choose to do that.
- Users should know what kind of timestamps the device produces. This
includes existing and future kernels. What should be considered are
uninformed porting drivers back and forth across kernel versions and
out-of-date kernel header files.
- Device-dependent timestamps. Some devices such as the uvcvideo ones
produce device-dependent timestamps for synchronising video and audio, both
produced by the same physical hardware device. For uvcvideo these timestamps
are unsigned 32-bit integers.
- There's also another clock, Linux-specific raw monotonic clock (as in
clock_gettime(CLOCK_RAW_MONOTONIC, ...)) that could be better in some use
cases than the regular monotonic clock. The difference is that the raw
monotonic clock is free from the NTP adjustments. It would be nice for the
user to be able to choose the clock used for timestamps. This is especially
important for device-dependent timestamps: not all applications can be
expected to be able to use them.
- The field adjacent to timestamp, timecode, is 128 bits wide, and not used
by a single driver. This field could be re-used.
Possible solutions
==
Not all of the solutions below that have been proposed are mutually
exclusive. That's also what's making the choice difficult: the ultimate
solution to the issue of timestamping may involve several of these --- or
possibly something better that's not on the list.
Use of timespec
---
If we can conclude timespec will always fit into the size of timeval (or
timecode) we could use timespec instead. The solution should still make
the use of timespec explicit to the user space. This seems to conflict with
the idea of making monotonic timestamps the default: the default can't be
anything incompatible with timeval, and at the same time it's the most
important that the monotonic timestamps are timespec.
Kernel version as indicator of timestamp
Conversion of drivers to use monotonic timestamp is trivial, so the
conversion could be done once and for all drivers. The kernel version could
be used to indicate the type of the timestamp.
If this approach is taken care must be taken when new drivers are
integrated: developers
[GIT PULL FOR 3.7] SMIA++ fixes and improvements
Hi Mauro, This patch contains three fixes for the SMIA++ driver and one patch that provides additional module identification information through sysfs --- the non-volatile memory contents are already provided through sysfs. The following changes since commit 780d61704cf62a51c06c0ca8210d0282591e00b2: [media] gspca_pac7302: extend register documentation (2012-09-13 17:54:49 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git smiapp-for-3.7 Sachin Kamat (2): smiapp: Use devm_* functions in smiapp-core.c file smiapp: Remove unused function Sakari Ailus (2): smiapp: Use highest bits-per-pixel for sensor internal format smiapp: Provide module identification information through sysfs drivers/media/i2c/smiapp/smiapp-core.c | 81 --- drivers/media/i2c/smiapp/smiapp-quirk.c | 20 2 files changed, 42 insertions(+), 59 deletions(-) Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Timestamps and V4L2
Le jeudi 20 septembre 2012 23:21:22, Sakari Ailus a écrit : The problem === The V4L2 has long used realtime timestamps (such as clock_gettime(CLOCK_REALTIME, ...)) to stamp the video buffers before handing them over to the user. This has been found problematic in associating the video buffers with data from other sources: realtime clock may jump around due to daylight saving time, for example, and ALSA (audio-video synchronisation is a common use case) user space API does not provide the user with realtime timestamps, but instead uses monotonic time (i.e. clock_gettime(CLOCK_MONOTONIC, ...)). This is especially an issue in embedded systems where video recording is a common use case. Drivers typically used in such systems have silently switched to use monotonic timestamps. While against the spec, this is necessary for those systems to operate properly. In general, realtime timestamps are seen of little use in other than debugging purposes, but monotonic timestamps are fine for that as well. It's still possible that an application I'm not aware of uses them in a peculiar way that would be adversely affected by changing to monotonic timestamps. Nevertheless, we're not supposed to break the API (or ABI). You cannot break something that never worked. Aside from debugging, the main use of timestamp is to synchronize the video signal with something else and/or to detect drift (which is more or less the same thing anyway). The current timestamp infos are _not_ usable. gstreamer has some fuzzy logic to try to figure out what it really means. VLC just ignores it and generates its own imprecise timestamp. It'd be also very important for the application to know what kind of timestamps are provided by the device. I would rather expect the HAL to convert the timestamp to something standard than have the application deal with an ever expanding list of types of timestamp that need to be supported. In other words, either V4L2 converts the timestamp to a type set by the application, or there is only one type of timestamp at all (CLOCK_MONOTONIC). Anything else *will* fail. Requirements, wishes and constraints Now that it seems to be about the time to fix these issues, it's worth looking a little bit to the future to anticipate the coming changes to be able to accommodate them better later on. - The new default should be monotonic. As the monotonic timestamps are seen to be the most useful, they should be made the default. - timeval vs. timespec. (...) - Users should know what kind of timestamps the device produces. This includes existing and future kernels. What should be considered are uninformed porting drivers back and forth across kernel versions and out-of-date kernel header files. - Device-dependent timestamps. Some devices such as the uvcvideo ones produce device-dependent timestamps for synchronising video and audio, both produced by the same physical hardware device. For uvcvideo these timestamps are unsigned 32-bit integers. - There's also another clock, Linux-specific raw monotonic clock (as in clock_gettime(CLOCK_RAW_MONOTONIC, ...)) that could be better in some use cases than the regular monotonic clock. The difference is that the raw monotonic clock is free from the NTP adjustments. It would be nice for the user to be able to choose the clock used for timestamps. This is especially important for device-dependent timestamps: not all applications can be expected to be able to use them. Then you need to create a new VIODIC_S_CLOCK control. If the control fails, then the application knows that it cannot trust the timestamp. So there is no need for a version number neither a flag. This does seem overkill though. You'll need to keep a clockid_t for each open V4L2 file handle. - The field adjacent to timestamp, timecode, is 128 bits wide, and not used by a single driver. This field could be re-used. Possible solutions == Not all of the solutions below that have been proposed are mutually exclusive. That's also what's making the choice difficult: the ultimate solution to the issue of timestamping may involve several of these --- or possibly something better that's not on the list. Use of timespec --- If we can conclude timespec will always fit into the size of timeval (or timecode) we could use timespec instead. The solution should still make the use of timespec explicit to the user space. This seems to conflict with the idea of making monotonic timestamps the default: the default can't be anything incompatible with timeval, and at the same time it's the most important that the monotonic timestamps are timespec. That is totally irrelevant. If the application knows what type of timestamp is used, it knows whether to use timespec or timeval, presumably timespec. If the default is changed to CLOCK_MONOTONIC, compatibility is broken, even
RE: [media-workshop] [ANNOUNCE] media workshop in November
Hi Mauro, I'd like to attend this one (couldn't attend the one last month in San-Diego). That would be me and possibly another member (Silvano Vigna) also. Amount various parts we have in our LinuxDVB/V4L2 model that need discussion with you, we would particularly like to discuss about a TSMux (a Mux rather than a demux) device within LinuxTV. Can you confirm the possibility of our attendance? Regards, Alain -Original Message- From: media-workshop-boun...@linuxtv.org [mailto:media-workshop-boun...@linuxtv.org] On Behalf Of Mauro Carvalho Chehab Sent: mercredi 19 septembre 2012 10:21 To: media-works...@linuxtv.org; Linux Media Mailing List Subject: Re: [media-workshop] [ANNOUNCE] media workshop in November Em 19-09-2012 05:11, Mauro Carvalho Chehab escreveu: Dear developers, We're feeling the need for one more media workshop this year. As there will be already several developers going to LinuxCon Europe and Embedded Linux Conference Europe, we'll be co-locating the workshop together with those two events. As there will be several developers speaking about the media subsystem at both LinuxCon and ELCE, we decided to take just one day (September, 8th) Sorry, I meant November, 8th. for the media workshop (while we expect that we'll likely have some other discussions during the week). In order to finish the arrangements, I need to know who will be attending, and also we need to receive the theme proposals. Please estimate how long do you think that it would be needed for the proposed theme presentation and discussions. I have a theme proposal already: How to improve the patch submission workflow for media patches - 2 hours. So, please confirm your intention to be there and propose the themes of your interests to media-works...@linuxtv.org mailing list. Thanks! Mauro ___ media-workshop mailing list media-works...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop ___ media-workshop mailing list media-works...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop -- 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 v4] of: Add videomode helper
Hi,
(CC'ing the linux-media mailing list, as video modes are of interest there as
well)
On Wednesday 19 September 2012 12:19:22 Tomi Valkeinen wrote:
On Wed, 2012-09-19 at 10:20 +0200, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the
devicetree. The videomode can be either converted to a struct
drm_display_mode or a struct fb_videomode.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
Hi!
changes since v3:
- print error messages
- free alloced memory
- general cleanup
Regards
Steffen
.../devicetree/bindings/video/displaymode | 74 +
drivers/of/Kconfig |5 +
drivers/of/Makefile|1 +
drivers/of/of_videomode.c | 283 +++
include/linux/of_videomode.h | 56
5 files changed, 419 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/displaymode
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/Documentation/devicetree/bindings/video/displaymode
b/Documentation/devicetree/bindings/video/displaymode new file mode
100644
index 000..990ca52
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/displaymode
@@ -0,0 +1,74 @@
+videomode bindings
+==
+
+Required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing
parameters in
+ lines
+ - clock: displayclock in Hz
+
+Optional properties:
+ - width-mm, height-mm: Display dimensions in mm
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - interlaced (bool): This is an interlaced mode
+ - doublescan (bool): This is a doublescan mode
+
+There are different ways of describing a display mode. The devicetree
representation
+corresponds to the one commonly found in datasheets for displays.
+The description of the display and its mode is split in two parts: first
the display
+properties like size in mm and (optionally) multiple subnodes with the
supported modes.
+
+Example:
+
+ display@0 {
+ width-mm = 800;
+ height-mm = 480;
+ modes {
+ mode0: mode@0 {
+ /* 1920x1080p24 */
+ clock = 5200;
+ hactive = 1920;
+ vactive = 1080;
+ hfront-porch = 25;
+ hback-porch = 25;
+ hsync-len = 25;
+ vback-porch = 2;
+ vfront-porch = 2;
+ vsync-len = 2;
+ hsync-active-high;
+ };
+ };
+ };
+
+Every property also supports the use of ranges, so the commonly used
datasheet +description with min typ max-tuples can be used.
+
+Example:
+
+ mode1: mode@1 {
+ /* 1920x1080p24 */
+ clock = 14850;
+ hactive = 1920;
+ vactive = 1080;
+ hsync-len = 0 44 60;
+ hfront-porch = 80 88 95;
+ hback-porch = 100 148 160;
+ vfront-porch = 0 4 6;
+ vback-porch = 0 36 50;
+ vsync-len = 0 5 6;
+ };
+
+The videomode can be linked to a connector via phandles. The connector
has to
+support the display- and default-mode-property to link to and select a
mode.
+
+Example:
+
+ hdmi@0012 {
+ status = okay;
+ display = benq;
+ default-mode = mode1;
+ };
+
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..a3acaa3 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -83,4 +83,9 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_VIDEOMODE
+ def_bool y
+ help
+ helper to parse videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..80e6db3 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 000..52bfc74
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,283 @@
+/*
+ * OF helpers for
[PATCH] rtl28xxu: [0413:6680] DigitalNow Quad DVB-T Receiver
It is 4 x RTL2832U + 4 x FC0012 in one PCIe board.
Of course there is a PCIe USB host controller too.
Big thanks for Darryl Bond reporting and testing that!
Cc: Darryl Bond darryl.b...@gmail.com
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 70c2df1..f62cfba 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1342,6 +1342,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
rtl2832u_props, Dexatek DK DVB-T Dongle, NULL) },
+ { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6680,
+ rtl2832u_props, DigitalNow Quad DVB-T Receiver, NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add a core driver for SI476x MFD
On 09/13/2012 11:44 PM, Hans Verkuil wrote:
Hi Andrey!
Thanks for posting this driver. One request for the future: please split this
patch up in smaller pieces: one for each c source for example. That makes it
easier to review.
Will do for next version.
+
+/**
+ * __core_send_command() - sends a command to si476x and waits its
+ * response
+ * @core:si476x_device structure for the device we are
+ *communicating with
+ * @command: command id
+ * @args: command arguments we are sending
+ * @argn: actual size of @args
+ * @response: buffer to place the expected response from the device
+ * @respn:actual size of @response
+ * @usecs:amount of time to wait before reading the response (in
+ *usecs)
+ *
+ * Function returns 0 on succsess and negative error code on
+ * failure
+ */
+static int __core_send_command(struct si476x_core *core,
+ const u8 command,
+ const u8 args[],
+ const int argn,
+ u8 resp[],
+ const int respn,
+ const int usecs)
+{
+ struct i2c_client *client = core-client;
+ int err;
+ u8 data[CMD_MAX_ARGS_COUNT + 1];
+
+ if (argn CMD_MAX_ARGS_COUNT) {
+ err = -ENOMEM;
+ goto exit;
Why goto exit? There is no clean up after the exit label, so just return
immediately. Ditto for all the other goto exit's in this function.
To have only just on point of exit from the function that's just
personal coding style preference.
There are no technical reasons behind that, I can change that.
+}
+
+if (!client-adapter) {
+err = -ENODEV;
+goto exit;
+}
+
+/* First send the command and its arguments */
+data[0] = command;
+memcpy(data[1], args, argn);
+DBG_BUFFER(client-dev, Command:\n, data, argn + 1);
+
+err = si476x_i2c_xfer(core, SI476X_I2C_SEND, (char *) data, argn + 1);
+if (err != argn + 1) {
+dev_err(core-client-dev,
+Error while sending command 0x%02x\n,
+command);
+err = (err = 0) ? -EIO : err;
+goto exit;
+}
+/* Set CTS to zero only after the command is send to avoid
+ * possible racing conditions when working in polling mode */
+atomic_set(core-cts, 0);
+
+if (!wait_event_timeout(core-command,
+atomic_read(core-cts),
+usecs_to_jiffies(usecs) + 1))
+dev_warn(core-client-dev,
+ (%s) [CMD 0x%02x] Device took too much time to
answer.\n,
+ __func__, command);
+
+/*
+ When working in polling mode, for some reason the tuner will
+ report CTS bit as being set in the first status byte read,
+ but all the consequtive ones will return zros until the
+ tuner is actually completed the POWER_UP command. To
+ workaround that we wait for second CTS to be reported
+ */
+if (unlikely(!core-client-irq command == CMD_POWER_UP)) {
+if (!wait_event_timeout(core-command,
+atomic_read(core-cts),
+usecs_to_jiffies(usecs) + 1))
+dev_warn(core-client-dev,
+ (%s) Power up took too much time.\n,
+ __func__);
+}
+
+/* Then get the response */
+err = si476x_i2c_xfer(core, SI476X_I2C_RECV, resp, respn);
+if (err != respn) {
+dev_err(core-client-dev,
+Error while reading response for command 0x%02x\n,
+command);
+err = (err = 0) ? -EIO : err;
+goto exit;
+}
+DBG_BUFFER(client-dev, Response:\n, resp, respn);
+
+err = 0;
+
+if (resp[0] SI476X_ERR) {
+dev_err(core-client-dev, Chip set error flag\n);
+err = si476x_core_parse_and_nag_about_error(core);
+goto exit;
+}
+
+if (!(resp[0] SI476X_CTS))
+err = -EBUSY;
+exit:
+return err;
+}
+
+#define CORE_SEND_COMMAND(core, cmd, args, resp, timeout) \
+__core_send_command(core, cmd, args,\
+ARRAY_SIZE(args), \
+resp, ARRAY_SIZE(resp), \
+timeout)
+
+
+static int __cmd_tune_seek_freq(struct si476x_core *core,
+uint8_t cmd,
+const uint8_t args[], size_t argn,
+uint8_t *resp, size_t respn,
+int (*clear_stcint) (struct si476x_core *core))
+{
+int err;
+
+atomic_set(core-stc, 0);
+err =
[PATCH] media: mx1_camera: mark the driver BROKEN
The mx1_camera driver has been broken for a few release cycles since commit 6bd0812 (dmaengine: imx-dma: merge old dma-v1.c with imx-dma.c). It seems there is no one even compile tested it since then, as doing so will end up with the following error. CC drivers/media/platform/soc_camera/mx1_camera.o In file included from drivers/media/platform/soc_camera/mx1_camera.c:44:0: arch/arm/mach-imx/include/mach/dma-mx1-mx2.h:8:25: fatal error: mach/dma-v1.h: No such file or directory It seems there is no one being interested in bringing it back to work [1] so far. Let's mark it BROKEN. [1] https://lkml.org/lkml/2012/2/9/171 Signed-off-by: Shawn Guo shawn@linaro.org --- drivers/media/platform/soc_camera/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index 9afe1e7..cb6791e 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -19,6 +19,7 @@ config MX1_VIDEO config VIDEO_MX1 tristate i.MX1/i.MXL CMOS Sensor Interface driver + depends on BROKEN depends on VIDEO_DEV ARCH_MX1 SOC_CAMERA select FIQ select VIDEOBUF_DMA_CONTIG -- 1.7.9.5 -- 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 2/3] iommu/omap: Merge iommu2.h into iommu.h
Since iommu is not currently supported on OMAP1, merge plat/iommu2.h into
iommu.h so only one file would have to move to platform_data/ as part of the
single zImage effort.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h | 88 +++--
arch/arm/plat-omap/include/plat/iommu2.h | 96
2 files changed, 83 insertions(+), 101 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iommu2.h
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 88be3e6..42f64e7 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,12 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include linux/io.h
+
+#if defined(CONFIG_ARCH_OMAP1)
+#error iommu for this processor not implemented yet
+#endif
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -144,11 +150,70 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 3)
#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 4)
-#if defined(CONFIG_ARCH_OMAP1)
-#error iommu for this processor not implemented yet
-#else
-#include plat/iommu2.h
-#endif
+/*
+ * MMU Register offsets
+ */
+#define MMU_REVISION 0x00
+#define MMU_SYSCONFIG 0x10
+#define MMU_SYSSTATUS 0x14
+#define MMU_IRQSTATUS 0x18
+#define MMU_IRQENABLE 0x1c
+#define MMU_WALKING_ST 0x40
+#define MMU_CNTL 0x44
+#define MMU_FAULT_AD 0x48
+#define MMU_TTB0x4c
+#define MMU_LOCK 0x50
+#define MMU_LD_TLB 0x54
+#define MMU_CAM0x58
+#define MMU_RAM0x5c
+#define MMU_GFLUSH 0x60
+#define MMU_FLUSH_ENTRY0x64
+#define MMU_READ_CAM 0x68
+#define MMU_READ_RAM 0x6c
+#define MMU_EMU_FAULT_AD 0x70
+
+#define MMU_REG_SIZE 256
+
+/*
+ * MMU Register bit definitions
+ */
+#define MMU_LOCK_BASE_SHIFT10
+#define MMU_LOCK_BASE_MASK (0x1f MMU_LOCK_BASE_SHIFT)
+#define MMU_LOCK_BASE(x) \
+ ((x MMU_LOCK_BASE_MASK) MMU_LOCK_BASE_SHIFT)
+
+#define MMU_LOCK_VICT_SHIFT4
+#define MMU_LOCK_VICT_MASK (0x1f MMU_LOCK_VICT_SHIFT)
+#define MMU_LOCK_VICT(x) \
+ ((x MMU_LOCK_VICT_MASK) MMU_LOCK_VICT_SHIFT)
+
+#define MMU_CAM_VATAG_SHIFT12
+#define MMU_CAM_VATAG_MASK \
+ ((~0UL MMU_CAM_VATAG_SHIFT) MMU_CAM_VATAG_SHIFT)
+#define MMU_CAM_P (1 3)
+#define MMU_CAM_V (1 2)
+#define MMU_CAM_PGSZ_MASK 3
+#define MMU_CAM_PGSZ_1M(0 0)
+#define MMU_CAM_PGSZ_64K (1 0)
+#define MMU_CAM_PGSZ_4K(2 0)
+#define MMU_CAM_PGSZ_16M (3 0)
+
+#define MMU_RAM_PADDR_SHIFT12
+#define MMU_RAM_PADDR_MASK \
+ ((~0UL MMU_RAM_PADDR_SHIFT) MMU_RAM_PADDR_SHIFT)
+#define MMU_RAM_ENDIAN_SHIFT 9
+#define MMU_RAM_ENDIAN_MASK(1 MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_BIG (1 MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_LITTLE (0 MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ELSZ_SHIFT 7
+#define MMU_RAM_ELSZ_MASK (3 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_8 (0 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_16(1 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_32(2 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_NONE (3 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_MIXED_SHIFT6
+#define MMU_RAM_MIXED_MASK (1 MMU_RAM_MIXED_SHIFT)
+#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
/*
* utilities for super page(16MB, 1MB, 64KB and 4KB)
@@ -203,4 +268,17 @@ omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len);
extern size_t
omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
+/*
+ * register accessors
+ */
+static inline u32 iommu_read_reg(struct omap_iommu *obj, size_t offs)
+{
+ return __raw_readl(obj-regbase + offs);
+}
+
+static inline void iommu_write_reg(struct omap_iommu *obj, u32 val, size_t
offs)
+{
+ __raw_writel(val, obj-regbase + offs);
+}
+
#endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
deleted file mode 100644
index d4116b5..000
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
- * omap iommu: omap2 architecture specific definitions
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __MACH_IOMMU2_H
-#define __MACH_IOMMU2_H
-
-#include linux/io.h
-
-/*
- * MMU Register offsets
- */
-#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG
[PATCH 3/3] arm: omap: Move iommu/iovmm headers to platform_data
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/iommu2.c| 2 +-
arch/arm/mach-omap2/omap-iommu.c| 2 +-
drivers/iommu/omap-iommu-debug.c| 4 ++--
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/omap-iovmm.c | 4 ++--
drivers/media/platform/omap3isp/isp.h | 5 +++--
drivers/media/platform/omap3isp/ispvideo.c | 6 --
.../plat/iommu.h = include/linux/platform_data/iommu-omap.h| 0
.../plat/iovmm.h = include/linux/platform_data/iovmm-omap.h| 0
10 files changed, 15 insertions(+), 12 deletions(-)
rename arch/arm/plat-omap/include/plat/iommu.h =
include/linux/platform_data/iommu-omap.h (100%)
rename arch/arm/plat-omap/include/plat/iovmm.h =
include/linux/platform_data/iovmm-omap.h (100%)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1bb2e92..5bde5c2 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
#if defined(CONFIG_IOMMU_API)
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
static struct resource omap3isp_resources[] = {
{
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..cab7acc 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -18,7 +18,7 @@
#include linux/slab.h
#include linux/stringify.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
/*
* omap2 architecture specific register bit definitions
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..a6a4ff8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -13,7 +13,7 @@
#include linux/module.h
#include linux/platform_device.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
#include soc.h
#include common.h
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index f55fc5d..e6ee7c2 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -19,8 +19,8 @@
#include linux/platform_device.h
#include linux/debugfs.h
-#include plat/iommu.h
-#include plat/iovmm.h
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include plat/iopgtable.h
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d0b1234..298ca19 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -24,7 +24,7 @@
#include asm/cacheflush.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
#include plat/iopgtable.h
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index 2e10c3e..ade7c6c 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -21,8 +21,8 @@
#include asm/cacheflush.h
#include asm/mach/map.h
-#include plat/iommu.h
-#include plat/iovmm.h
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include plat/iopgtable.h
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 8be7487..62c76f9 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -34,8 +34,9 @@
#include linux/platform_device.h
#include linux/wait.h
#include linux/iommu.h
-#include plat/iommu.h
-#include plat/iovmm.h
+
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include ispstat.h
#include ispccdc.h
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 3a5085e..1093f07 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -34,8 +34,10 @@
#include linux/vmalloc.h
#include media/v4l2-dev.h
#include media/v4l2-ioctl.h
-#include plat/iommu.h
-#include plat/iovmm.h
+
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
+
#include plat/omap-pm.h
#include ispvideo.h
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/include/linux/platform_data/iommu-omap.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/iommu.h
rename to include/linux/platform_data/iommu-omap.h
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/include/linux/platform_data/iovmm-omap.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/iovmm.h
rename to include/linux/platform_data/iovmm-omap.h
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a
[PATCH 1/3] [media] omap3isp: Fix compilation error in ispreg.h
Commit c49f34bc (ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2) moved omap34xx.h to mach-omap2. This broke omap3isp, as it includes omap34xx.h. Instead of moving omap34xx to platform_data, simply add the two definitions the driver needs and remove the include altogether. Signed-off-by: Ido Yariv i...@wizery.com --- drivers/media/platform/omap3isp/ispreg.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/omap3isp/ispreg.h b/drivers/media/platform/omap3isp/ispreg.h index 084ea77..e2c57f3 100644 --- a/drivers/media/platform/omap3isp/ispreg.h +++ b/drivers/media/platform/omap3isp/ispreg.h @@ -27,13 +27,13 @@ #ifndef OMAP3_ISP_REG_H #define OMAP3_ISP_REG_H -#include plat/omap34xx.h - - #define CM_CAM_MCLK_HZ 17280 /* Hz */ /* ISP Submodules offset */ +#define L4_34XX_BASE 0x4800 +#define OMAP3430_ISP_BASE (L4_34XX_BASE + 0xBC000) + #define OMAP3ISP_REG_BASE OMAP3430_ISP_BASE #define OMAP3ISP_REG(offset) (OMAP3ISP_REG_BASE + (offset)) -- 1.7.11.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
