Re: [PATCH/RFC] V4L: add media bus configuration subdev operations

[Sakari Ailus]

On Tue, Jun 07, 2011 at 05:25:32PM +0200, Laurent Pinchart wrote:
> Hi Guennadi,
> 
> Thanks for the patch.
> 
> On Monday 06 June 2011 14:31:57 Guennadi Liakhovetski wrote:
> > Add media bus configuration types and two subdev operations to get
> > supported mediabus configurations and to set a specific configuration.
> > Subdevs can support several configurations, e.g., they can send video data
> > on 1 or several lanes, can be configured to use a specific CSI-2 channel,
> > in such cases subdevice drivers return bitmasks with all respective bits
> > set. When a set-configuration operation is called, it has to specify a
> > non-ambiguous configuration.
> > 
> > Signed-off-by: Stanimir Varbanov 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> > 
> > This change would allow a re-use of soc-camera and "standard" subdev
> > drivers. It is a modified and extended version of
> > 
> > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/294
> > 08
> > 
> > therefore the original Sob. After this we only would have to switch to the
> > control framework:) Please, comment.
> 
> I still believe we shouldn't use any set operation :-) The host/bridge driver 
> should just use the get operation before starting the stream to configure 
> it's 
> sensor interface. 

I agree with Laurent.

What about implementing just get first?

Regards,

-- 
Sakari Ailus
sakari.ai...@iki.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

Re: Remote control TechnoTrend S2-3650 CI not working

[Andreas Steinel]

Hi Jürgen, Hi List,

On Wed, Jun 8, 2011 at 1:01 AM, Juergen Lock  wrote:
> On Mon, Jun 06, 2011 at 11:55:44PM +0200, Andreas Steinel wrote:
>> Yet, i further investigated the errors and the source code and turned
>> on dvb-usb-debugging which yields:
>>
>> [11423.302006] key mapping failed - no appropriate key found in keymapping
>> [11423.501806] pctv452e_rc_query: cmd=0x26 sys=0x18
>> [11423.501815] key mapping failed - no appropriate key found in keymapping
>> [11423.701615] pctv452e_rc_query: cmd=0x26 sys=0x18
>> [11423.701628] key mapping failed - no appropriate key found in keymapping
>> [11424.001763] pctv452e_rc_query: cmd=0x26 sys=0x18
>> [11424.001775] key mapping failed - no appropriate key found in keymapping
>> [11424.102026] pctv452e_rc_query: cmd=0x26 sys=0x18
>> [11424.102034] key mapping failed - no appropriate key found in keymapping
>> [11424.202030] pctv452e_rc_query: cmd=0x26 sys=0x18
>> [11424.202038] key mapping failed - no appropriate key found in keymapping
>>
>> Which explains the error. I further debugged the problem and found this:
>>
>> [13242.485965] key mapping failed - no appropriate key found in keymapping
>> [13242.585948] pctv452e_rc_query: cmd=0x26 sys=0x18
>> [13242.585955]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
>> rc5_custom=0x01
>> [...]
>> [13242.586099]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
>> rc5_custom=0x3e
>> [13242.586103]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
>> rc5_custom=0x3f
>> [13242.586106] key mapping failed - no appropriate key found in keymapping
>>
>> I patched the file to get one key responding, but unfortunately
>> failed. The problem is not obvious to me:
>>
>> diff -r 41388e396e0f linux/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
>> --- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-remote.c  Mon May 23
>> 00:50:21 2011 +0300
>> +++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-remote.c  Mon Jun 06
>> 23:53:27 2011 +0200
>> @@ -272,6 +272,8 @@
>>                         }
>>                         /* See if we can match the raw key code. */
>>                         for (i = 0; i < d->props.rc_key_map_size; i++)
>> +        printk(" keycode is [1]=0x%02x vs rc5_custom=0x%02x,
>> [3]=0x%02x vs rc5_custom=0x%02x\n",
>> +                keybuf[1], rc5_custom(&keymap[i]), keybuf[3],
>> rc5_data(&keymap[i]));
>>                                 if (rc5_custom(&keymap[i]) == keybuf[1] &&
>>                                         rc5_data(&keymap[i]) == keybuf[3]) {
>>                                         *event = keymap[i].event;
>
>  You forgot the curly brackets there, now the for loop only runs
> the printf...

Argh... too obvious ... don't code near midnight :-/
I'll fix that and will incorporate all of "my new keyevents" and will
report back here.

Best,
Andreas
--
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

Getting IR to work on a hvr-1250 tuner.

[Dark Shadow]

I have a capture card that was sold as a Hauppauge HVR-1250 (according
to the box) that I am trying to use but I am having trouble getting
all it's features at once. When I leave it auto detected by the module
I have working TV in MythTV even though it thinks it is a 1270 but IR
isn't setup.

dmesg outputs
#modprobe cx23885 enable_885_ir=1
[7.592714] cx23885 driver version 0.0.2 loaded
[7.592748] cx23885 :07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[7.592926] CORE cx23885[0]: subsystem: 0070:2211, board: Hauppauge
WinTV-HVR1270 [card=18,autodetected]
[7.728163] IR JVC protocol handler initialized
[7.738971] tveeprom 0-0050: Hauppauge model 22111, rev C2F5, serial# 6429897
[7.738974] tveeprom 0-0050: MAC address is 00:0d:fe:62:1c:c9
[7.738975] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54)
[7.738977] tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital
(eeprom 0x88)
[7.738979] tveeprom 0-0050: audio processor is CX23888 (idx 40)
[7.738980] tveeprom 0-0050: decoder processor is CX23888 (idx 34)
[7.738982] tveeprom 0-0050: has no radio, has IR receiver, has no
IR transmitter
[7.738983] cx23885[0]: hauppauge eeprom: model=22111
[7.738985] cx23885_dvb_register() allocating 1 frontend(s)
[7.738991] cx23885[0]: cx23885 based dvb card
[7.961122] IR Sony protocol handler initialized
[7.977301] tda18271 1-0060: creating new instance
[7.979325] TDA18271HD/C2 detected @ 1-0060
[8.209663] DVB: registering new adapter (cx23885[0])
[8.209668] DVB: registering adapter 0 frontend 0 (LG Electronics
LGDT3305 VSB/QAM Frontend)...
[8.210095] cx23885_dev_checkrevision() Hardware revision = 0xd0
[8.210101] cx23885[0]/0: found at :07:00.0, rev: 4, irq: 17,
latency: 0, mmio: 0xf7c0
[8.210109] cx23885 :07:00.0: setting latency timer to 64
[8.210186] cx23885 :07:00.0: irq 49 for MSI/MSI-X


When I force it to be a 1250 no video works but IR seems to show up
(with the exception that it never seems to receive signals from the
remote)

#modprobe cx23885 enable_885_ir=1 card=3
[38647.660740] cx23885 driver version 0.0.2 loaded
[38647.660779] cx23885 :07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[38647.661009] CORE cx23885[0]: subsystem: 0070:2211, board: Hauppauge
WinTV-HVR1250 [card=3,insmod option]
[38647.787427] tveeprom 0-0050: Hauppauge model 22111, rev C2F5, serial# 6429897
[38647.787431] tveeprom 0-0050: MAC address is 00:0d:fe:62:1c:c9
[38647.787434] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54)
[38647.787437] tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital
(eeprom 0x88)
[38647.787439] tveeprom 0-0050: audio processor is CX23888 (idx 40)
[38647.787442] tveeprom 0-0050: decoder processor is CX23888 (idx 34)
[38647.787444] tveeprom 0-0050: has no radio, has IR receiver, has no
IR transmitter
[38647.787447] cx23885[0]: hauppauge eeprom: model=22111
[38647.824508] cx25840 2-0044: cx23888 A/V decoder found @ 0x88 (cx23885[0])
[38648.457502] cx25840 2-0044: loaded v4l-cx23885-avcore-01.fw
firmware (16382 bytes)
[38648.465061] cx23885_dvb_register() allocating 1 frontend(s)
[38648.465064] cx23885[0]: cx23885 based dvb card
[38648.492632] cx23885[0]: frontend initialization failed
[38648.492637] cx23885_dvb_register() dvb_register failed err = -22
[38648.492640] cx23885_dev_setup() Failed to register dvb on VID_C
[38648.492644] cx23885_dev_checkrevision() Hardware revision = 0xd0
[38648.492650] cx23885[0]/0: found at :07:00.0, rev: 4, irq: 17,
latency: 0, mmio: 0xf7c0
[38648.492660] cx23885 :07:00.0: setting latency timer to 64
[38648.492740] cx23885 :07:00.0: irq 48 for MSI/MSI-X
[38648.539598] Registered IR keymap rc-hauppauge
[38648.539775] input: cx23885 IR (Hauppauge WinTV-HVR1250) as
/devices/pci:00/:00:1c.1/:07:00.0/rc/rc0/input4
[38648.539852] rc0: cx23885 IR (Hauppauge WinTV-HVR1250) as
/devices/pci:00/:00:1c.1/:07:00.0/rc/rc0
[38648.539926] rc rc0: lirc_dev: driver ir-lirc-codec (cx23885)
registered at minor = 0


My setup commands for it's settings when using card=3

(I have read this is needed for this remote although according to the
Internet my grey remote is supposed to need a "hauppauge=1" parameter
but it doesn't exist (modinfo) in my version of the module from kernel
3.0-rc1
#modprobe ir-kbd-i2c

#ir-keytable -a /etc/rc_maps.cfg
Old keytable cleared
Wrote 136 keycode(s) to driver
Protocols changed to RC-5

#lsinput
/dev/input/event4
   bustype : BUS_PCI
   vendor  : 0x70
   product : 0x2211
   version : 1
   name: "cx23885 IR (Hauppauge WinTV-HVR1"
   phys: "pci-:07:00.0/ir0"
   bits ev : EV_SYN EV_KEY EV_MSC EV_REP

#lspci -v (plus a little -n)
07:00.0 0400: 14f1:8880 (rev 04)
Subsystem: 0070:2211

07:00.0 Multimedia video controller: Conexant Systems, Inc. Hauppauge
Inc. HDPVR-1250 model 1196 (rev 04)
Subsystem: Hauppauge computer works Inc. Device 2211
Flags: bus master, 

[PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC

[Kassey Lee]

This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.

Signed-off-by: Kassey Lee 
---
 arch/arm/mach-mmp/include/mach/camera.h |   37 ++
 drivers/media/video/Kconfig |7 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/mv_camera.c | 1071 +++
 4 files changed, 1116 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
 create mode 100644 drivers/media/video/mv_camera.c

V3 Changes:
1) add cafe-ccic copyright
2) add VSYNC, HSYNC, PCLK check for CCIC
3) code style fix as Guennadi's comments


diff --git a/arch/arm/mach-mmp/include/mach/camera.h 
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee 
+ * Angela Wan 
+ * Lei Wen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER   1
+#define MV_CAMERA_DATAWIDTH_8  8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN  0x40
+#define MV_CAMERA_MCLK_EN  0x80
+#define MV_CAMERA_PCP  0x100
+#define MV_CAMERA_HSP  0x200
+#define MV_CAMERA_VSP  0x400
+
+struct mv_cam_pdata {
+   int dphy[3];
+   unsigned long flags;
+   int dma_burst;
+   int mclk_min;
+   int mclk_src;
+   int (*init_clk) (struct device *dev, int init);
+   void (*enable_clk) (struct device *dev, int on);
+   int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
  This is a v4l2 driver for the i.MX3x Camera Sensor Interface
 
+config VIDEO_MV_CCIC
+   tristate "Marvell CMOS Camera Interface Controller driver"
+   depends on VIDEO_DEV && CPU_PXA910 && SOC_CAMERA
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
 config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && PXA27x && SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM)   += soc_camera_platform.o
 obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
 obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
 obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
 obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..3a03a40
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1071 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2
+ * framework, but part of the low level register function
+ * is base on cafe_ccic.c
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee 
+ * Angela Wan 
+ * Lei Wen 
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "cafe_ccic-regs.h"
+
+/* Register definition for PXA910 */
+
+#define REG_U0BAR   0x0c
+#define REG_U1BAR   0x10
+#define REG_U2BAR   0x14
+#define REG_V0BAR   0x18
+#define REG_V1BAR   0x1C
+#define REG_V2BAR   0x20
+
+/* for MIPI enable */
+#define REG_CSI2_CTRL0  0x100
+#define REG_CSI2_DPHY0  0x120
+#define REG_CSI2_DPHY1  0x124
+#define REG_CSI2_DPHY2  0x128
+#define REG_CSI2_

[PATCH V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC

[Kassey Lee]

This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.

Signed-off-by: Kassey Lee 
---
 arch/arm/mach-mmp/include/mach/camera.h |   37 ++
 drivers/media/video/Kconfig |7 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/mv_camera.c | 1071 +++
 4 files changed, 1116 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
 create mode 100644 drivers/media/video/mv_camera.c

diff --git a/arch/arm/mach-mmp/include/mach/camera.h 
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee 
+ * Angela Wan 
+ * Lei Wen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER   1
+#define MV_CAMERA_DATAWIDTH_8  8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN  0x40
+#define MV_CAMERA_MCLK_EN  0x80
+#define MV_CAMERA_PCP  0x100
+#define MV_CAMERA_HSP  0x200
+#define MV_CAMERA_VSP  0x400
+
+struct mv_cam_pdata {
+   int dphy[3];
+   unsigned long flags;
+   int dma_burst;
+   int mclk_min;
+   int mclk_src;
+   int (*init_clk) (struct device *dev, int init);
+   void (*enable_clk) (struct device *dev, int on);
+   int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
  This is a v4l2 driver for the i.MX3x Camera Sensor Interface
 
+config VIDEO_MV_CCIC
+   tristate "Marvell CMOS Camera Interface Controller driver"
+   depends on VIDEO_DEV && CPU_PXA910 && SOC_CAMERA
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
 config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && PXA27x && SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM)   += soc_camera_platform.o
 obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
 obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
 obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
 obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..ed2397f
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1071 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2
+ * framework, but part of the low level register function
+ * is base on cafe_ccic.c
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee 
+ * Angela Wan 
+ * Lei Wen 
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "cafe_ccic-regs.h"
+
+/* Register definition for PXA910 */
+
+#define REG_U0BAR   0x0c
+#define REG_U1BAR   0x10
+#define REG_U2BAR   0x14
+#define REG_V0BAR   0x18
+#define REG_V1BAR   0x1C
+#define REG_V2BAR   0x20
+
+/* for MIPI enable */
+#define REG_CSI2_CTRL0  0x100
+#define REG_CSI2_DPHY0  0x120
+#define REG_CSI2_DPHY1  0x124
+#define REG_CSI2_DPHY2  0x128
+#define REG_CSI2_DPHY3  0x12c
+#define REG_CSI2_DPHY4  0x130
+#define REG_CSI2_DPHY5  0x134
+#define REG_CSI2_DPHY6  0x138
+/* REG_CTRL0 */

Re: [RFC] Refactor the cafe_ccic driver and add Armada 610 support

[Kassey Lee]

Hi, Jon:
for PXA910, MMP2(Armda 610)
actually,  CCIC are almost the same.
but MMP2 has 2 CCIC controllers, and PXA910 only has 1 CCIC controller.
so it is quite make your driver works on MMP2 and PXA910.

On Tue, Jun 7, 2011 at 9:45 PM, Jonathan Corbet  wrote:
> On Tue, 7 Jun 2011 13:30:11 +0800
> Kassey Lee  wrote:
>
>>       1)  this driver is still based on cafe_ccic.c, as you said, we
>> can abstract the low level register function, and use soc_camera and
>> videofbu2 to manage the buff and state machine,  how do you think ?
>
> As I said, videobuf2 is on my list of things to do.  Note that the driver
> works just fine without - that code has been in the kernel and working for
> years.  But it's a cleanup that needs to be done at this point, and I will
> do it.
>
Since we have converted a videfbuf2 version for PXA910, could you have
time to review ?
and find the common part to make a better one works on cafe-ccic,
PXA910, and MMP2 ?
 it takes quite time to convert from cafe-ccic.c to videfbuf2 for me.
>>       2) i2c_adapter, how about move this code to driver/i2c, then
>> ccic driver will become clean?
>
> The problem there is that you can't easily disentangle the two devices -
> they use the same registers, the same IRQ line, etc.  One *could* turn the
> whole thing into an MFD driver and split them apart, but I honestly don't
> see a reason to do that.  I'd be surprised if a Cafe chip ever shows up in
> anything new these days, so it's only used in the OLPC XO 1, and that i2c
> will never be used for anything but the sensor.
>
> The i2c *has* been abstracted out of the camera core, so the Cafe i2c
> implementation will not get in the way of any new drivers.
>
for cafe i2c, it is OK.
but for PXA910 and MMP2, the i2c adapter is out of CCIC.

>>       3) in mmp_driver.c, it has the sensor name, OV7670,  we wish
>> that ccic driver do not need to aware of the sensor, also we need to
>> support front and back camera sensor cases.
>
> The only reason the ov7670 dependency is there is because that's the only
> sensor the driver has ever been used with.  Adding other sensors has been
> complicated a bit by Hans's changes which pushed awareness of the
> available video formats into the controller driver (I complained at the
> time), but that can be worked around.
>
> For front and back: I didn't wire up the second controller in the mmp
> driver because I don't have a device that uses both.  I very much wrote
> the driver with the idea that both controllers could be used, though;
> finishing that job will be easy.
>
sorry for confusion, we have another case:
one CCIC should work with two sensors, and switch them by need.
what i mean, for CCIC driver it should not aware the sensor, it can be
 done by user application.

> One thing I haven't done is to look at your driver closely enough to think
> about whether mmp_camera can drive your hardware or not.  You'll have a
> better idea of that than me, I suspect; is the hardware pretty much the
> same?
>
I will update my driver again after Guennadi's comments, would you
please have time to review ?

1) add Jon's email, and cafe-ccic.c copyright.
2) set_bus_param  check for HSYNC, PCLK
3) code stye fix.

> Thanks,
>
> jon
>



-- 
Best regards
Kassey
Application Processor Systems Engineering, Marvell Technology Group Ltd.
Shanghai, China.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/15] DVB Frontend Documentation patches

[Mauro Carvalho Chehab]

Em 07-06-2011 22:45, Mauro Carvalho Chehab escreveu:
> This series of patches updates the DVB v5 documentation, sinchronizing
> the current implementation with the API spec.
> Among other things, it:
>   - adds a logic that discovers API gaps between the header
> file and the API specs;
>   - adds/fixes the DVB S2API (DVBv5) additions;
>   - adds the FE_ATSC frontend descriptions (both v3 and v5);
>   - adds a relation of DVBv5 parameters for usage for each
> supported delivery system.
> 
> The API updates were made at the best effort basis, by doing a sort
> of "reverse engineering" approach, e. g., by looking at the code
> and trying to figure out what changed, why and how. Due to that,
> I bet people will find errors on it. Also, English is not my native
> language, and I didn't have time for doing a language review.
> 
> so I'm sure that language/style/typo fixes are needed.
> 
> So, I'd like to encourage people to carefully read the docs and
> send us patches with fixes.
> 
> Anyway, as the situation after those patches are better than before them,
> I'm pushing it to the main repository. This helps to review, as the
> linuxtv scripts will re-format the DocBook into html.

The linuxtv API specs were updated at linuxtv.org. For those that want 
to review, the changes were at chapter 9 of the API spec[1], mainly at:

http://linuxtv.org/downloads/v4l-dvb-apis/dvb_frontend.html
http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html
http://linuxtv.org/downloads/v4l-dvb-apis/frontend_h.html

[1] http://linuxtv.org/downloads/v4l-dvb-apis/

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 16/15] [media] DocBook/dvbproperty.xml: Better name the ISDB-T layers

[Mauro Carvalho Chehab]

In order to improve the DVB index, replace the title to a
better name.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index a9863a3..caec58c 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -449,13 +449,14 @@ typedef enum fe_delivery_system {
Note: This value cannot be determined by an automatic 
channel search.


-   Hierarchical layers
+   DTV-ISDBT-LAYER* parameters
ISDB-T channels can be coded hierarchically. As opposed 
to DVB-T in
ISDB-T hierarchical layers can be decoded 
simultaneously. For that
reason a ISDB-T demodulator has 3 viterbi and 3 
reed-solomon-decoders.
ISDB-T has 3 hierarchical layers which each can use a 
part of the
available segments. The total number of segments over 
all layers has
to 13 in ISDB-T.
+   There are 3 parameter sets, for Layers A, B and C.


DTV_ISDBT_LAYER_ENABLED
Hierarchical reception in ISDB-T is achieved by 
enabling or disabling
--
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 09/15] [media] DocBook/dvbproperty.xml: Reorganize the parameters

[Mauro Carvalho Chehab]

Put the parameters at the sequencial order as they appear inside
the frontend.h header.

TODO: fix the per-standard section, to reflect the parameters
that should actually be used for each transmission system type.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 01f3933..d8a6424 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -197,8 +197,8 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
 DTV_DVBT2_PLP_ID
 
 
-
-   Parameters that are common to all Digital TV standards
+
+   Digital TV property parameters

DTV_UNDEFINED
Used internally. A GET/SET operation for it won't change or 
return anything.
@@ -211,6 +211,20 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
DTV_CLEAR
Reset a cache of data specific to the frontend here. This does 
not effect hardware.

+   
+   DTV_FREQUENCY
+
+   Central frequency of the channel, in HZ.
+
+   Notes:
+   1)For ISDB-T, the channels are usually transmitted with 
an offset of 143kHz.
+   E.g. a valid frequncy could be 474143 kHz. The stepping 
is bound to the bandwidth of
+   the channel which is 6MHz.
+
+   2)As in ISDB-Tsb the channel consists of only one or 
three segments the
+   frequency step is 429kHz, 3*429 respectively. As for 
ISDB-T the
+   central frequency of the channel is expected.
+   

DTV_MODULATION
 Specifies the frontend modulation type for cable and satellite types. 
The modulation can be one of the types bellow:
@@ -232,6 +246,32 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
  } fe_modulation_t;
 

+   
+   DTV_BANDWIDTH_HZ
+
+   Bandwidth for the channel, in HZ.
+
+   Possible values:
+   1712000,
+   500,
+   600,
+   700,
+   800,
+   1000.
+   
+
+   Notes:
+
+   1) For ISDB-T it should be always 600Hz (6MHz)
+   2) For ISDB-Tsb it can vary depending on the number of 
connected segments
+   3) Bandwidth doesn't apply for DVB-C transmissions, as 
the bandwidth
+for DVB-C depends on the symbol rate
+   4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily 
derived from
+   other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
+   DTV_ISDBT_SB_SEGMENT_COUNT).
+   5) DVB-T supports 6, 7 and 8MHz.
+   6) In addition, DVB-T2 supports 1.172, 5 and 10MHz.
+   

DTV_INVERSION
The Inversion field can take one of these values:
@@ -338,116 +378,11 @@ typedef enum fe_rolloff {
DTV_FE_CAPABILITY
Currently not implemented.

-   
-   DTV_API_VERSION
-   Returns the major/minor version of the DVB API
-   
-   
-   DTV_CODE_RATE_HP
-   Used on terrestrial transmissions. The acceptable values are:
-   
-   
-typedef enum fe_code_rate {
-   FEC_NONE = 0,
-   FEC_1_2,
-   FEC_2_3,
-   FEC_3_4,
-   FEC_4_5,
-   FEC_5_6,
-   FEC_6_7,
-   FEC_7_8,
-   FEC_8_9,
-   FEC_AUTO,
-   FEC_3_5,
-   FEC_9_10,
-} fe_code_rate_t;
-   
-   
-   
-   DTV_CODE_RATE_LP
-   Used on terrestrial transmissions. The acceptable values are:
-   
-   
-typedef enum fe_code_rate {
-   FEC_NONE = 0,
-   FEC_1_2,
-   FEC_2_3,
-   FEC_3_4,
-   FEC_4_5,
-   FEC_5_6,
-   FEC_6_7,
-   FEC_7_8,
-   FEC_8_9,
-   FEC_AUTO,
-   FEC_3_5,
-   FEC_9_10,
-} fe_code_rate_t;
-   
-   
-   
-   DTV_HIERARCHY
-   Frontend hierarchy
-   
-typedef enum fe_hierarchy {
-HIERARCHY_NONE,
-HIERARCHY_1,
-HIERARCHY_2,
-HIERARCHY_4,
-HIERARCHY_AUTO
- } fe_hierarchy_t;
-   
-   
-   
-   DTV_ISDBS_TS_ID
-   Currently unused.
-   
-   
-   DTV_FREQUENCY
-
-   Central frequency of the channel, in HZ.
-
-   Notes:
-   1)For ISDB-T, the channels are usually transmitted with 
an offset of 143kHz.
-   E.g. a valid frequncy could be 474143 kHz. The stepping 
is bound to the bandwidth of
-   the channel which is 6MHz.
-
-   2)As in ISDB-Tsb the channel consists of only one or 
three segments the
-   frequency step is 429kHz, 3*429 respectively. As for 
ISDB-T the
-   

[PATCH 14/15] [media] DocBook/dvbproperty.xml: Add ATSC standard

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 262d995..9cbb289 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -766,6 +766,19 @@ typedef enum fe_hierarchy {
DTV_ISDBT_LAYERC_TIME_INTERLEAVING


+   
+   ATSC delivery system
+   The following parameters are valid for 
ATSC:
+   
+   DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_MODULATION
+   DTV_BANDWIDTH_HZ
+   
+   



@@ -796,8 +809,6 @@ typedef enum fe_hierarchy {
DTV_FREQUENCY
DTV_MODULATION
DTV_INVERSION
-   DTV_SYMBOL_RATE
-   DTV_INNER_FEC


Properties used on cable delivery systems
diff --git a/Documentation/DocBook/media/dvb/frontend.xml 
b/Documentation/DocBook/media/dvb/frontend.xml
index 1417d50..304d54e 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -276,7 +276,7 @@ OFDM frontends the frequency specifies 
the absolute frequen
 
 
 VSB parameters
-DVB-T frontends are supported by the 
dvb_vsb_parameters structure:
+ATSC frontends are supported by the 
dvb_vsb_parameters structure:
 
 struct dvb_vsb_parameters {
fe_modulation_t modulation; /⋆ modulation type (see above) 
⋆/
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/15] [media] DocBook/dvbproperty.xml: Document the terrestrial delivery systems

[Mauro Carvalho Chehab]

Instead of repeating duplicate parameters to each delivery system,
just add a section for each specific delivery system, showing
what's applicable to each case. This helps userspace app developers
to know what DVB parameters are applicable to each delivery system.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index d8a6424..4c45f3c 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -1,6 +1,12 @@
 
-FE_GET_PROPERTY/FE_SET_PROPERTY
-
+FE_GET_PROPERTY/FE_SET_PROPERTY
+This section describes the DVB version 5 extention of the DVB-API, also
+called "S2API", as this API were added to provide support for DVB-S2. It was
+designed to be able to replace the old frontend API. Yet, the DISEQC and
+the capability ioctls weren't implemented yet via the new way.
+The typical usage for the 
FE_GET_PROPERTY/FE_SET_PROPERTY
+API is to replace the ioctl's were the 
+struct dvb_frontend_parameters were used.
 
 /* Reserved fields should be set to 0 */
 struct dtv_property {
@@ -149,52 +155,7 @@ the actual action is determined by the dtv_property 
cmd/data pairs. With one sin
 get/set up to 64 properties. The actual meaning of each property is described 
on the next sections.
 
 
-The available frontend property types are:
-
-DTV_UNDEFINED
-DTV_TUNE
-DTV_CLEAR
-DTV_FREQUENCY
-DTV_MODULATION
-DTV_BANDWIDTH_HZ
-DTV_INVERSION
-DTV_DISEQC_MASTER
-DTV_SYMBOL_RATE
-DTV_INNER_FEC
-DTV_VOLTAGE
-DTV_TONE
-DTV_PILOT
-DTV_ROLLOFF
-DTV_DISEQC_SLAVE_REPLY
-DTV_FE_CAPABILITY_COUNT
-DTV_FE_CAPABILITY
-DTV_DELIVERY_SYSTEM
-DTV_ISDBT_PARTIAL_RECEPTION
-DTV_ISDBT_SOUND_BROADCASTING
-DTV_ISDBT_SB_SUBCHANNEL_ID
-DTV_ISDBT_SB_SEGMENT_IDX
-DTV_ISDBT_SB_SEGMENT_COUNT
-DTV_ISDBT_LAYERA_FEC
-DTV_ISDBT_LAYERA_MODULATION
-DTV_ISDBT_LAYERA_SEGMENT_COUNT
-DTV_ISDBT_LAYERA_TIME_INTERLEAVING
-DTV_ISDBT_LAYERB_FEC
-DTV_ISDBT_LAYERB_MODULATION
-DTV_ISDBT_LAYERB_SEGMENT_COUNT
-DTV_ISDBT_LAYERB_TIME_INTERLEAVING
-DTV_ISDBT_LAYERC_FEC
-DTV_ISDBT_LAYERC_MODULATION
-DTV_ISDBT_LAYERC_SEGMENT_COUNT
-DTV_ISDBT_LAYERC_TIME_INTERLEAVING
-DTV_API_VERSION
-DTV_CODE_RATE_HP
-DTV_CODE_RATE_LP
-DTV_GUARD_INTERVAL
-DTV_TRANSMISSION_MODE
-DTV_HIERARCHY
-DTV_ISDBT_LAYER_ENABLED
-DTV_ISDBS_TS_ID
-DTV_DVBT2_PLP_ID
+The available frontend property types are shown on the next 
section.
 
 
 
@@ -696,13 +657,53 @@ typedef enum fe_hierarchy {
many data types via a single multiplex. The API will 
soon support this
at which point this section will be expanded.

-   
-   Properties used by each DTV type
+
+   
+   Properties used on terrestrial delivery systems
+   
+   DVB-T delivery system
+   The following parameters are valid for 
DVB-T:
+   
+   DTV_API_VERSION
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_MODULATION
+   DTV_BANDWIDTH_HZ
+   DTV_INVERSION
+   DTV_CODE_RATE_HP
+   DTV_CODE_RATE_LP
+   DTV_GUARD_INTERVAL
+   DTV_TRANSMISSION_MODE
+   DTV_HIERARCHY
+   DTV_DELIVERY_SYSTEM
+   
+   
+   
+   DVB-T2 delivery system
+   DVB-T2support is currently in the early stages
+   of development so expect this section to grow and become
+   more detailed with time.
+   The following parameters are valid for DVB-T2:
+   
+   DTV_API_VERSION
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_MODULATION
+   DTV_BANDWIDTH_HZ
+   DTV_INVERSION
+   DTV_CODE_RATE_HP
+   DTV_CODE_RATE_LP
+   DTV_GUARD_INTERVAL
+   DTV_TRANSMISSION_MODE
+   DTV_HIERARCHY
+   DTV_DELIVERY_SYSTEM
+   DTV_DVBT2_PLP_ID
+   
+   

-   ISDB-T frontend
-   This section describes shortly what are the possible 
parameters in the Linux
-   DVB-API called "S2API" and now DVB API 5 in order to 
tune an ISDB-T/ISDB-Tsb
-   demodulator:
+   ISDB-T delivery system
This ISDB-T/ISDB-Tsb API extension should reflect all 
information
needed to tune any ISDB-T/ISDB-Tsb hardwar

[PATCH 08/15] [media] DocBook/dvbproperty.xml: Use links for all parameters

[Mauro Carvalho Chehab]

Instead of adding a program listing, just add there all parameters.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 67a2deb..01f3933 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -150,51 +150,51 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
 
 
 The available frontend property types are:
-
-#define DTV_UNDEFINED  0
-#define DTV_TUNE   1
-#define DTV_CLEAR  2
-#define DTV_FREQUENCY  3
-#define DTV_MODULATION 4
-#define DTV_BANDWIDTH_HZ   5
-#define DTV_INVERSION  6
-#define DTV_DISEQC_MASTER  7
-#define DTV_SYMBOL_RATE8
-#define DTV_INNER_FEC  9
-#define DTV_VOLTAGE10
-#define DTV_TONE   11
-#define DTV_PILOT  12
-#define DTV_ROLLOFF13
-#define DTV_DISEQC_SLAVE_REPLY 14
-#define DTV_FE_CAPABILITY_COUNT15
-#define DTV_FE_CAPABILITY  16
-#define DTV_DELIVERY_SYSTEM17
-#define DTV_ISDBT_PARTIAL_RECEPTION18
-#define DTV_ISDBT_SOUND_BROADCASTING   19
-#define DTV_ISDBT_SB_SUBCHANNEL_ID 20
-#define DTV_ISDBT_SB_SEGMENT_IDX   21
-#define DTV_ISDBT_SB_SEGMENT_COUNT 22
-#define DTV_ISDBT_LAYERA_FEC   23
-#define DTV_ISDBT_LAYERA_MODULATION24
-#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25
-#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26
-#define DTV_ISDBT_LAYERB_FEC   27
-#define DTV_ISDBT_LAYERB_MODULATION28
-#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29
-#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30
-#define DTV_ISDBT_LAYERC_FEC   31
-#define DTV_ISDBT_LAYERC_MODULATION32
-#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33
-#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34
-#define DTV_API_VERSION35
-#define DTV_CODE_RATE_HP   36
-#define DTV_CODE_RATE_LP   37
-#define DTV_GUARD_INTERVAL 38
-#define DTV_TRANSMISSION_MODE  39
-#define DTV_HIERARCHY  40
-#define DTV_ISDBT_LAYER_ENABLED41
-#define DTV_ISDBS_TS_ID42
-
+
+DTV_UNDEFINED
+DTV_TUNE
+DTV_CLEAR
+DTV_FREQUENCY
+DTV_MODULATION
+DTV_BANDWIDTH_HZ
+DTV_INVERSION
+DTV_DISEQC_MASTER
+DTV_SYMBOL_RATE
+DTV_INNER_FEC
+DTV_VOLTAGE
+DTV_TONE
+DTV_PILOT
+DTV_ROLLOFF
+DTV_DISEQC_SLAVE_REPLY
+DTV_FE_CAPABILITY_COUNT
+DTV_FE_CAPABILITY
+DTV_DELIVERY_SYSTEM
+DTV_ISDBT_PARTIAL_RECEPTION
+DTV_ISDBT_SOUND_BROADCASTING
+DTV_ISDBT_SB_SUBCHANNEL_ID
+DTV_ISDBT_SB_SEGMENT_IDX
+DTV_ISDBT_SB_SEGMENT_COUNT
+DTV_ISDBT_LAYERA_FEC
+DTV_ISDBT_LAYERA_MODULATION
+DTV_ISDBT_LAYERA_SEGMENT_COUNT
+DTV_ISDBT_LAYERA_TIME_INTERLEAVING
+DTV_ISDBT_LAYERB_FEC
+DTV_ISDBT_LAYERB_MODULATION
+DTV_ISDBT_LAYERB_SEGMENT_COUNT
+DTV_ISDBT_LAYERB_TIME_INTERLEAVING
+DTV_ISDBT_LAYERC_FEC
+DTV_ISDBT_LAYERC_MODULATION
+DTV_ISDBT_LAYERC_SEGMENT_COUNT
+DTV_ISDBT_LAYERC_TIME_INTERLEAVING
+DTV_API_VERSION
+DTV_CODE_RATE_HP
+DTV_CODE_RATE_LP
+DTV_GUARD_INTERVAL
+DTV_TRANSMISSION_MODE
+DTV_HIERARCHY
+DTV_ISDBT_LAYER_ENABLED
+DTV_ISDBS_TS_ID
+DTV_DVBT2_PLP_ID
 
 
 
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/15] DVB Frontend Documentation patches

[Mauro Carvalho Chehab]

This series of patches updates the DVB v5 documentation, sinchronizing
the current implementation with the API spec.
Among other things, it:
- adds a logic that discovers API gaps between the header
  file and the API specs;
- adds/fixes the DVB S2API (DVBv5) additions;
- adds the FE_ATSC frontend descriptions (both v3 and v5);
- adds a relation of DVBv5 parameters for usage for each
  supported delivery system.

The API updates were made at the best effort basis, by doing a sort
of "reverse engineering" approach, e. g., by looking at the code
and trying to figure out what changed, why and how. Due to that,
I bet people will find errors on it. Also, English is not my native
language, and I didn't have time for doing a language review.

so I'm sure that language/style/typo fixes are needed.

So, I'd like to encourage people to carefully read the docs and
send us patches with fixes.

Anyway, as the situation after those patches are better than before them,
I'm pushing it to the main repository. This helps to review, as the
linuxtv scripts will re-format the DocBook into html.

Mauro Carvalho Chehab (15):
  [media] DocBook/Makefile: add references for several dvb structures
  [media] DocBook/frontend.xml: Better document fe_type_t
  [media] DocBook/frontend.xml: Link DVB S2API parameters
  [media] DocBook/frontend.xml: Correlate dvb delivery systems
  [media] DocBook/frontend.xml: add references for some missing info
  [media] DocBook/frontend.xml: Better describe the frontend parameters
  [media] DocBook/dvbproperty.xml: Document the remaining S2API parameters
  [media] DocBook/dvbproperty.xml: Use links for all parameters
  [media] DocBook/dvbproperty.xml: Reorganize the parameters
  [media] DocBook/frontend.xml: Recomend the usage of the new API
  [media] DocBook/dvbproperty.xml: Document the terrestrial delivery systems
  [media] DocBook: Finish synchronizing the frontend API
  [media] DocBook/dvbproperty.xml: Add Cable standards
  [media] DocBook/dvbproperty.xml: Add ATSC standard
  [media] DocBook/dvbproperty.xml: Add Satellite standards

 Documentation/DocBook/media/Makefile|   17 +-
 Documentation/DocBook/media/dvb/dvbproperty.xml |  965 +++
 Documentation/DocBook/media/dvb/frontend.xml|  285 +---
 3 files changed, 833 insertions(+), 434 deletions(-)

--
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 15/15] [media] DocBook/dvbproperty.xml: Add Satellite standards

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 9cbb289..a9863a3 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -688,8 +688,8 @@ typedef enum fe_hierarchy {


DVB-T2 delivery system
-   DVB-T2support is currently in the early stages
-   of development so expect this section to grow and become
+   DVB-T2 support is currently in the early stages
+   of development, so expect that this section maygrow and 
become
more detailed with time.
The following parameters are valid for DVB-T2:

@@ -781,6 +781,7 @@ typedef enum fe_hierarchy {



+   Properties used on cable delivery systems

DVB-C delivery system
The DVB-C Annex-A/C is the widely used cable standard. 
Transmission uses QAM modulation.
@@ -811,11 +812,66 @@ typedef enum fe_hierarchy {
DTV_INVERSION


-   Properties used on cable delivery systems
-   TODO


Properties used on satellital delivery systems
-   TODO
+   
+   DVB-S delivery system
+   The following parameters are valid for DVB-S:
+   
+   DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_INVERSION
+   DTV_SYMBOL_RATE
+   DTV_INNER_FEC
+   
+   Future implementations might add those two missing 
parameters:
+   
+   DTV_DISEQC_MASTER
+   DTV_DISEQC_SLAVE_REPLY
+   
+   
+   
+   DVB-S2 delivery system
+   The following parameters are valid for DVB-S2:
+   
+   DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_INVERSION
+   DTV_SYMBOL_RATE
+   DTV_INNER_FEC
+   DTV_VOLTAGE
+   DTV_TONE
+   DTV_PILOT
+   DTV_ROLLOFF
+   
+   Future implementations might add those two missing 
parameters:
+   
+   DTV_DISEQC_MASTER
+   DTV_DISEQC_SLAVE_REPLY
+   
+   
+   
+   ISDB-S delivery system
+   The following parameters are valid for ISDB-S:
+   
+   DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_INVERSION
+   DTV_SYMBOL_RATE
+   DTV_INNER_FEC
+   DTV_VOLTAGE
+   DTV_ISDBS_TS_ID
+   
+   

 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/15] [media] DocBook/dvbproperty.xml: Add Cable standards

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 64151bb..262d995 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -672,6 +672,7 @@ typedef enum fe_hierarchy {
The following parameters are valid for 
DVB-T:

DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
DTV_TUNE
DTV_CLEAR
DTV_FREQUENCY
@@ -683,7 +684,6 @@ typedef enum fe_hierarchy {
DTV_GUARD_INTERVAL
DTV_TRANSMISSION_MODE
DTV_HIERARCHY
-   DTV_DELIVERY_SYSTEM



@@ -694,6 +694,7 @@ typedef enum fe_hierarchy {
The following parameters are valid for DVB-T2:

DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
DTV_TUNE
DTV_CLEAR
DTV_FREQUENCY
@@ -705,7 +706,6 @@ typedef enum fe_hierarchy {
DTV_GUARD_INTERVAL
DTV_TRANSMISSION_MODE
DTV_HIERARCHY
-   DTV_DELIVERY_SYSTEM
DTV_DVBT2_PLP_ID


@@ -734,6 +734,7 @@ typedef enum fe_hierarchy {
The following parameters are valid for ISDB-T:

DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
DTV_TUNE
DTV_CLEAR
DTV_FREQUENCY
@@ -745,7 +746,6 @@ typedef enum fe_hierarchy {
DTV_GUARD_INTERVAL
DTV_TRANSMISSION_MODE
DTV_HIERARCHY
-   DTV_DELIVERY_SYSTEM
DTV_ISDBT_LAYER_ENABLED
DTV_ISDBT_PARTIAL_RECEPTION
DTV_ISDBT_SOUND_BROADCASTING
@@ -768,6 +768,38 @@ typedef enum fe_hierarchy {



+   
+   DVB-C delivery system
+   The DVB-C Annex-A/C is the widely used cable standard. 
Transmission uses QAM modulation.
+   The following parameters are valid for DVB-C Annex 
A/C:
+   
+   DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_MODULATION
+   DTV_INVERSION
+   DTV_SYMBOL_RATE
+   DTV_INNER_FEC
+   
+   
+   
+   DVB-C Annex B delivery system
+   The DVB-C Annex-B is only used on a few Countries like 
the United States.
+   The following parameters are valid for DVB-C Annex 
B:
+   
+   DTV_API_VERSION
+   DTV_DELIVERY_SYSTEM
+   DTV_TUNE
+   DTV_CLEAR
+   DTV_FREQUENCY
+   DTV_MODULATION
+   DTV_INVERSION
+   DTV_SYMBOL_RATE
+   DTV_INNER_FEC
+   
+   
Properties used on cable delivery systems
TODO

-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/15] [media] DocBook: Finish synchronizing the frontend API

[Mauro Carvalho Chehab]

Remove the remaining:
Error: no ID for constraint linkend:

With this patch, the dvb frontend API matches the current
dvb core implementation.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index f2216b0..eb64087 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -73,7 +73,7 @@ ENUMS = \
 
 STRUCTS = \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/videodev2.h) \
-   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/dvb/frontend.h) \
+   $(shell perl -ne 'print "$$1 " if (!/dtv\_cmds\_h/ && 
/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/frontend.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/v4l2-subdev.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/v4l2-mediabus.h)
@@ -124,10 +124,10 @@ DVB_DOCUMENTED = \
-e "s,\(struct\s\+\)\([a-z0-9_]\+\)\(\s\+{\),\1\\2\<\/link\>\3,g" \
-e "s,\(}\s\+\)\([a-z0-9_]\+_t\+\),\1\\2\<\/link\>,g" \
-e "s,\(define\s\+\)\(DTV_[A-Z0-9_]\+\)\(\s\+[0-9]\+\),\1\\2\<\/link\>\3,g" \
+   -e "s,\(DTV_IOCTL_MAX_MSGS\|dtv_cmds_h\)<\/link>,\1,g" \
-e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \
-e "s,DTV-ISDBT-LAYER[A-C],DTV-ISDBT-LAYER,g" \
-e "s,\(define\s\+\)\([A-Z0-9_]\+\)\(\s\+_IO\),\1\\2\<\/link\>\3,g" \
-#  -e "s,\(\s\+\)\(FE_[A-Z0-9_]\+\)\([\s\=\,]*\),\1\\2\<\/link\>\3,g" \
 
 #
 # Media targets and dependencies
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 4c45f3c..64151bb 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -7,6 +7,8 @@ the capability ioctls weren't implemented yet via the new 
way.
 The typical usage for the 
FE_GET_PROPERTY/FE_SET_PROPERTY
 API is to replace the ioctl's were the 
 struct dvb_frontend_parameters were used.
+
+DTV property type
 
 /* Reserved fields should be set to 0 */
 struct dtv_property {
@@ -25,12 +27,17 @@ struct dtv_property {
 
 /* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
 #define DTV_IOCTL_MAX_MSGS 64
-
+
+
+
+DTV properties type
+
 struct dtv_properties {
__u32 num;
struct dtv_property *props;
 };
 
+
 
 
 FE_GET_PROPERTY
diff --git a/Documentation/DocBook/media/dvb/frontend.xml 
b/Documentation/DocBook/media/dvb/frontend.xml
index 086e62b..1417d50 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -140,7 +140,7 @@ a specific frontend type.
};
 
 
-
+
 diseqc slave reply
 
 A reply to the frontend from DiSEqC 2.0 capable equipment.
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/15] [media] DocBook/frontend.xml: Recomend the usage of the new API

[Mauro Carvalho Chehab]

The old way of setting delivery system parameters were to use
an union with specific per-system parameters. However, as newer
delivery systems required more data, the structure size weren't
enough to fit. So, recomend using the DVBS2API instead.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/frontend.xml 
b/Documentation/DocBook/media/dvb/frontend.xml
index b1f0123..086e62b 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -221,8 +221,20 @@ by
 
 frontend parameters
 The kind of parameters passed to the frontend device for tuning depend on
-the kind of hardware you are using. All kinds of parameters are combined as an
-union in the FrontendParameters structure:
+the kind of hardware you are using.
+The struct dvb_frontend_parameters uses an
+union with specific per-system parameters. However, as newer delivery systems
+required more data, the structure size weren't enough to fit, and just
+extending its size would break the existing applications. So, those parameters
+were replaced by the usage of 
+FE_GET_PROPERTY/FE_SET_PROPERTY ioctl's. The
+new API is flexible enough to add new parameters to existing delivery systems,
+and to add newer delivery systems.
+So, newer applications should use 
+FE_GET_PROPERTY/FE_SET_PROPERTY instead, in
+order to be able to support the newer System Delivery like  DVB-S2, DVB-T2,
+DVB-C2, ISDB, etc.
+All kinds of parameters are combined as an union in the 
FrontendParameters structure:
 
 struct dvb_frontend_parameters {
uint32_t frequency; /⋆ (absolute) frequency in Hz for 
QAM/OFDM ⋆/
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/15] [media] DocBook/dvbproperty.xml: Document the remaining S2API parameters

[Mauro Carvalho Chehab]

There were lots of DVB S2API parameters that were never documented.
Let's add a definition for all of them, based on what's currently
used inside the core and the drivers.

The description here is not complete nor perfect, so patches
improving it are welcome.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 3a1ecb2..67a2deb 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -199,6 +199,208 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
 
 
Parameters that are common to all Digital TV standards
+   
+   DTV_UNDEFINED
+   Used internally. A GET/SET operation for it won't change or 
return anything.
+   
+   
+   DTV_TUNE
+   Interpret the cache of data, build either a traditional frontend 
tunerequest so we can pass validation in the 
FE_SET_FRONTEND ioctl.
+   
+   
+   DTV_CLEAR
+   Reset a cache of data specific to the frontend here. This does 
not effect hardware.
+   
+   
+   DTV_MODULATION
+Specifies the frontend modulation type for cable and satellite types. 
The modulation can be one of the types bellow:
+
+ typedef enum fe_modulation {
+   QPSK,
+   QAM_16,
+   QAM_32,
+   QAM_64,
+   QAM_128,
+   QAM_256,
+   QAM_AUTO,
+   VSB_8,
+   VSB_16,
+   PSK_8,
+   APSK_16,
+   APSK_32,
+   DQPSK,
+ } fe_modulation_t;
+
+   
+   
+   DTV_INVERSION
+   The Inversion field can take one of these values:
+   
+   
+   typedef enum fe_spectral_inversion {
+   INVERSION_OFF,
+   INVERSION_ON,
+   INVERSION_AUTO
+   } fe_spectral_inversion_t;
+   
+   It indicates if spectral inversion should be presumed or not. In 
the automatic setting
+   (INVERSION_AUTO) the hardware will try to figure 
out the correct setting by
+   itself.
+   
+   
+   
+   DTV_DISEQC_MASTER
+   Currently not implemented.
+   
+   
+   DTV_SYMBOL_RATE
+   Digital TV symbol rate, in bauds (symbols/second). Used on cable 
standards.
+   
+   
+   DTV_INNER_FEC
+   Used cable/satellite transmissions. The acceptable values are:
+   
+   
+typedef enum fe_code_rate {
+   FEC_NONE = 0,
+   FEC_1_2,
+   FEC_2_3,
+   FEC_3_4,
+   FEC_4_5,
+   FEC_5_6,
+   FEC_6_7,
+   FEC_7_8,
+   FEC_8_9,
+   FEC_AUTO,
+   FEC_3_5,
+   FEC_9_10,
+} fe_code_rate_t;
+   
+   which correspond to error correction rates of 1/2, 2/3, etc.,
+   no error correction or auto detection.
+   
+   
+   DTV_VOLTAGE
+   The voltage is usually used with non-DiSEqC capable LNBs to switch
+   the polarzation (horizontal/vertical). When using DiSEqC epuipment this
+   voltage has to be switched consistently to the DiSEqC commands as
+   described in the DiSEqC spec.
+   
+   typedef enum fe_sec_voltage {
+   SEC_VOLTAGE_13,
+   SEC_VOLTAGE_18
+   } fe_sec_voltage_t;
+   
+   
+   
+   DTV_TONE
+   Currently not used.
+   
+   
+   DTV_PILOT
+   Sets DVB-S2 pilot
+   
+   fe_pilot type
+   
+typedef enum fe_pilot {
+   PILOT_ON,
+   PILOT_OFF,
+   PILOT_AUTO,
+} fe_pilot_t;
+   
+   
+   
+   
+   DTV_ROLLOFF
+   Sets DVB-S2 rolloff
+
+   
+   fe_rolloff type
+   
+typedef enum fe_rolloff {
+   ROLLOFF_35, /* Implied value in DVB-S, default for DVB-S2 */
+   ROLLOFF_20,
+   ROLLOFF_25,
+   ROLLOFF_AUTO,
+} fe_rolloff_t;
+   
+   
+   
+   
+   DTV_DISEQC_SLAVE_REPLY
+   Currently not implemented.
+   
+   
+   DTV_FE_CAPABILITY_COUNT
+   Currently not implemented.
+   
+   
+   DTV_FE_CAPABILITY
+   Currently not implemented.
+   
+   
+   DTV_API_VERSION
+   Returns the major/minor version of the DVB API
+   
+   
+   DTV_CODE_RATE_HP
+   Used on terrestrial transmissions. The acceptable values are:
+   
+   
+typedef enum fe_code_rate {
+   FEC_NONE = 0,
+   FEC_1_2,
+   FEC_2_3,
+   FEC_3_4,
+   FEC_4_5,
+   FEC_5_6,
+   FEC_6_7,
+   FEC_7_8,
+   FEC_8_9,
+   FEC_AUTO,
+   FEC_3_5,
+   FEC_9_10,
+} fe_code_rate_t;
+   
+   
+   
+   DTV_CODE_RATE_LP
+   Used on terrestrial transmissions. The acceptable values are:
+   
+   
+typedef enum fe_code_rate {
+   FEC_NONE = 0,
+   FEC_1_2,
+   FEC_2_3,
+   FEC_3_4,
+   FEC_4_5,
+   FEC_5_6,
+   FEC_6_7,
+   FEC_7_8,
+   FEC_8_9,
+   FEC_AUTO,
+  

[PATCH 06/15] [media] DocBook/frontend.xml: Better describe the frontend parameters

[Mauro Carvalho Chehab]

Update the DVB parameter structs to reflect VSB modulation and
improve a few descriptions.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/frontend.xml 
b/Documentation/DocBook/media/dvb/frontend.xml
index a925b45..b1f0123 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -262,6 +262,15 @@ OFDM frontends the frequency 
specifies the absolute frequen
  };
 
 
+
+VSB parameters
+DVB-T frontends are supported by the 
dvb_vsb_parameters structure:
+
+struct dvb_vsb_parameters {
+   fe_modulation_t modulation; /⋆ modulation type (see above) 
⋆/
+};
+
+
 
 OFDM parameters
 DVB-T frontends are supported by the 
dvb_ofdm_parameters structure:
@@ -277,15 +286,6 @@ OFDM frontends the frequency 
specifies the absolute frequen
  };
 
 
-
-VSB parameters
-DVB-T frontends are supported by the 
dvb_vsb_parameters structure:
-
-struct dvb_vsb_parameters {
-   fe_modulation_t modulation; /⋆ modulation type (see above) 
⋆/
-};
-
-
 
 frontend spectral inversion
 The Inversion field can take one of these values:
@@ -304,7 +304,9 @@ itself.
 
 
 frontend code rate
-The possible values for the FEC_inner field are
+The possible values for the fec_inner field used on
+struct 
dvb_qpsk_parameters and
+struct 
dvb_qam_parameters are:
 
 
 typedef enum fe_code_rate {
@@ -327,9 +329,12 @@ detection.
 
 
 
-frontend modulation type for QAM and OFDM
-For cable and terrestrial frontends (QAM and OFDM) one also has to 
specify the quadrature
-modulation mode which can be one of the following:
+frontend modulation type for QAM, OFDM and VSB
+For cable and terrestrial frontends, e. g. for
+struct 
dvb_qpsk_parameters,
+struct 
dvb_qam_parameters and
+struct 
dvb_qam_parameters,
+it needs to specify the quadrature modulation mode which can be one of the 
following:
 
 
  typedef enum fe_modulation {
@@ -352,7 +357,7 @@ modulation mode which can be one of the following:
 Finally, there are several more parameters for OFDM:
 
 
-Number of carriers per channel, on OFTM modulation
+Number of carriers per channel
 
 typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/15] [media] DocBook/frontend.xml: add references for some missing info

[Mauro Carvalho Chehab]

The frontend.h.xml now references to the main document. However,
several references are missed.

Links the trivial ones with the corresponding API descriptions.

While here, updates the main API to reflect the API improvements.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index 3036070..f2216b0 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -120,13 +120,13 @@ DOCUMENTED = \
-e "s/v4l2\-mpeg\-vbi\-ITV0/v4l2-mpeg-vbi-itv0-1/g"
 
 DVB_DOCUMENTED = \
-   -e "s,\(define\s\+\)\([A-Z0-9_]\+\)\(\s\+_IO\),\1\\2\<\/link\>\3,g" \
-e "s/\(linkend\=\"\)FE_SET_PROPERTY/\1FE_GET_PROPERTY/g" \
-e "s,\(struct\s\+\)\([a-z0-9_]\+\)\(\s\+{\),\1\\2\<\/link\>\3,g" \
-e "s,\(}\s\+\)\([a-z0-9_]\+_t\+\),\1\\2\<\/link\>,g" \
-e "s,\(define\s\+\)\(DTV_[A-Z0-9_]\+\)\(\s\+[0-9]\+\),\1\\2\<\/link\>\3,g" \
-e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \
-e "s,DTV-ISDBT-LAYER[A-C],DTV-ISDBT-LAYER,g" \
+   -e "s,\(define\s\+\)\([A-Z0-9_]\+\)\(\s\+_IO\),\1\\2\<\/link\>\3,g" \
 #  -e "s,\(\s\+\)\(FE_[A-Z0-9_]\+\)\([\s\=\,]*\),\1\\2\<\/link\>\3,g" \
 
 #
diff --git a/Documentation/DocBook/media/dvb/frontend.xml 
b/Documentation/DocBook/media/dvb/frontend.xml
index 65a790e..a925b45 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -65,7 +65,7 @@ supported via the new FE_GET_PROPERTY/FE_GET
 
 
 
-
+
 frontend capabilities
 
 Capabilities describe what a frontend can do. Some capabilities can only 
be supported for
@@ -106,7 +106,7 @@ a specific frontend type.
 
 
 
-
+
 frontend information
 
 Information about the frontend ca be queried with
@@ -129,7 +129,7 @@ a specific frontend type.
 
 
 
-
+
 diseqc master command
 
 A message sent from the frontend to DiSEqC capable equipment.
@@ -153,7 +153,7 @@ a specific frontend type.
 
 
 
-
+
 diseqc slave reply
 The voltage is usually used with non-DiSEqC capable LNBs to switch the 
polarzation
 (horizontal/vertical). When using DiSEqC epuipment this voltage has to be 
switched
@@ -166,7 +166,7 @@ consistently to the DiSEqC commands as described in the 
DiSEqC spec.
 
 
 
-
+
 SEC continuous tone
 
 The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs 
to switch the
@@ -181,7 +181,7 @@ spec.
 
 
 
-
+
 SEC tone burst
 
 The 22KHz tone burst is usually used with non-DiSEqC capable switches to 
select
@@ -198,7 +198,7 @@ spec.
 
 
 
-
+
 frontend status
 Several functions of the frontend device use the fe_status data type 
defined
 by
@@ -218,31 +218,42 @@ by
 
 
 
-
+
 frontend parameters
 The kind of parameters passed to the frontend device for tuning depend on
 the kind of hardware you are using. All kinds of parameters are combined as an
 union in the FrontendParameters structure:
 
- struct dvb_frontend_parameters {
-uint32_t frequency;   /⋆ (absolute) frequency in Hz for 
QAM/OFDM ⋆/
-  /⋆ intermediate frequency in kHz for 
QPSK ⋆/
-fe_spectral_inversion_t inversion;
-union {
-struct dvb_qpsk_parameters qpsk;
-struct dvb_qam_parameters  qam;
-struct dvb_ofdm_parameters ofdm;
-} u;
- };
+struct dvb_frontend_parameters {
+   uint32_t frequency; /⋆ (absolute) frequency in Hz for 
QAM/OFDM ⋆/
+   /⋆ intermediate frequency in kHz for 
QPSK ⋆/
+   fe_spectral_inversion_t inversion;
+   union {
+   struct dvb_qpsk_parameters qpsk;
+   struct dvb_qam_parameters  qam;
+   struct dvb_ofdm_parameters ofdm;
+   struct dvb_vsb_parameters  vsb;
+   } u;
+};
 
-For satellite QPSK frontends you have to use the 
QPSKParameters member defined by
+In the case of QPSK frontends the frequency field 
specifies the intermediate
+frequency, i.e. the offset which is effectively added to the local oscillator 
frequency (LOF) of
+the LNB. The intermediate frequency has to be specified in units of kHz. For 
QAM and
+OFDM frontends the frequency specifies the absolute 
frequency and is given in Hz.
+
+
+QPSK parameters
+For satellite QPSK frontends you have to use the 
dvb_qpsk_parameters structure:
 
  struct dvb_qpsk_parameters {
 uint32_tsymbol_rate;  /⋆ symbol rate in Symbols per 
second ⋆/
 fe_code_rate_t  fec_inner;/⋆ forward error correction (see 
above) ⋆/
  };
 
-for cable QAM frontend you use the QAMParameters 
structure
+
+
+QAM parameters
+for cable QAM frontend you use the 
dvb_qam_parameters structure:
 
  struct dvb_qam_parameters {
 uint32_t symbol_rate; /⋆ symbol rate in Symbols per 
second ⋆/
@@ -250,8 +261,10 @@ union in the FrontendParameters structure:
 fe_modulation_t  modulation;  /⋆ modulation type (see above) 
⋆/
  };
 
-DVB-T frontends are supported by the O

[PATCH 04/15] [media] DocBook/frontend.xml: Correlate dvb delivery systems

[Mauro Carvalho Chehab]

As the DVB API provides two ways to specify the delivery
systems, correlate both ways into a table.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/dvb/frontend.xml 
b/Documentation/DocBook/media/dvb/frontend.xml
index b52f66a..65a790e 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -23,40 +23,45 @@ cards, in which case there exists no frontend device.
 
 Frontend type
 
-For historical reasons frontend types are named after the type of 
modulation used in
+For historical reasons, frontend types are named by the type of 
modulation used in
 transmission. The fontend types are given by fe_type_t type, defined as:
 
 
 Frontend types
-
+
&cs-def;

  
fe_type
Description
+   DTV_DELIVERY_SYSTEM 
equivalent type
  
   
   
   
  FE_QPSK
  For DVB-S standard
+ SYS_DVBS
   
   
  FE_QAM
- For DVB-C standard
+ For DVB-C annex A/C standard
+ SYS_DVBC_ANNEX_AC
   
   
  FE_OFDM
- For DVB-T standard. Also used for ISDB-T on compatibility 
mode
+ For DVB-T standard
+ SYS_DVBT
   
   
  FE_ATSC
- For ATSC standard (terrestrial or cable)
+ For ATSC standard (terrestrial) or for DVB-C Annex B (cable) used 
in US.
+ SYS_ATSC (terrestrial) or 
SYS_DVBC_ANNEX_B (cable)
   
 
 
 Newer formats like DVB-S2, ISDB-T, ISDB-S and DVB-T2 are not described 
at the above, as they're
-supported via the new FE_GET_PROPERTY/FE_GET_SET_PROPERTY method.
+supported via the new FE_GET_PROPERTY/FE_GET_SET_PROPERTY 
ioctl's, using the DTV_DELIVERY_SYSTEM parameter.
 
 
 
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/15] [media] DocBook/frontend.xml: Link DVB S2API parameters

[Mauro Carvalho Chehab]

Associate the frontend.h DVB S2API parmeters to the corresponding
documentation at the spec.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index 34afc54..3036070 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -124,7 +124,9 @@ DVB_DOCUMENTED = \
-e "s/\(linkend\=\"\)FE_SET_PROPERTY/\1FE_GET_PROPERTY/g" \
-e "s,\(struct\s\+\)\([a-z0-9_]\+\)\(\s\+{\),\1\\2\<\/link\>\3,g" \
-e "s,\(}\s\+\)\([a-z0-9_]\+_t\+\),\1\\2\<\/link\>,g" \
+   -e "s,\(define\s\+\)\(DTV_[A-Z0-9_]\+\)\(\s\+[0-9]\+\),\1\\2\<\/link\>\3,g" \
-e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \
+   -e "s,DTV-ISDBT-LAYER[A-C],DTV-ISDBT-LAYER,g" \
 #  -e "s,\(\s\+\)\(FE_[A-Z0-9_]\+\)\([\s\=\,]*\),\1\\2\<\/link\>\3,g" \
 
 #
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index b5365f6..3a1ecb2 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -199,7 +199,7 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
 
 
Parameters that are common to all Digital TV standards
-   
+   
DTV_FREQUENCY
 
Central frequency of the channel, in HZ.
@@ -214,7 +214,7 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
central frequency of the channel is expected.

 
-   
+   
DTV_BANDWIDTH_HZ
 
Bandwidth for the channel, in HZ.
@@ -241,7 +241,7 @@ get/set up to 64 properties. The actual meaning of each 
property is described on
6) In addition, DVB-T2 supports 1.172, 5 and 10MHz.

 
-   
+   
DTV_DELIVERY_SYSTEM
 
Specifies the type of Delivery system
@@ -271,7 +271,7 @@ typedef enum fe_delivery_system {
 

 
-   
+   
DTV_TRANSMISSION_MODE
 
Specifies the number of carriers used by the 
standard
@@ -300,7 +300,7 @@ typedef enum fe_transmit_mode {
4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.

 
-   
+   
DTV_GUARD_INTERVAL
 
Possible values are:
@@ -359,10 +359,10 @@ typedef enum fe_guard_interval {

ISDB-T only parameters
 
-   
+   

DTV_ISDBT_PARTIAL_RECEPTION
 
-   If 
DTV_ISDBT_SOUND_BROADCASTING is '0' this bit-field represents whether
+   If 
DTV_ISDBT_SOUND_BROADCASTING is '0' this bit-field 
represents whether
the channel is in partial reception mode or 
not.
 
If '1' DTV_ISDBT_LAYERA_* 
values are assigned to the center segment and
@@ -375,7 +375,7 @@ typedef enum fe_guard_interval {
Possible values: 0, 1, -1 (AUTO)

 
-   
+   

DTV_ISDBT_SOUND_BROADCASTING
 
This field represents whether the other 
DTV_ISDBT_*-parameters are
@@ -385,7 +385,7 @@ typedef enum fe_guard_interval {
Possible values: 0, 1, -1 (AUTO)

 
-   
+   

DTV_ISDBT_SB_SUBCHANNEL_ID
 
This field only applies if 
DTV_ISDBT_SOUND_BROADCASTING is '1'.
@@ -418,7 +418,7 @@ typedef enum fe_guard_interval {
Possible values: 0 .. 41, -1 (AUTO)

 
-   
+   
 

DTV_ISDBT_SB_SEGMENT_IDX
 
@@ -433,7 +433,7 @@ typedef enum fe_guard_interval {
Note: This value cannot be determined by an 
automatic channel search.

 
-   
+   

DTV_ISDBT_SB_SEGMENT_COUNT
 
This field only applies if 
DTV_ISDBT_SOUND_BROADCASTING is '1'.
@@ -457,7 +457,7 @@ typedef enum fe_guard_interval {
available segments. The total number of 
segments over all layers has
to 13 in ISDB-T.
 
-   
+   

DTV_ISDBT_LAYER_ENABLED
 
Hierarchical reception in ISDB-T is 
achieved by enabling or disabling
@@ -482,13 +482,13 @@ typedef enum fe_guard_interval {

DTV_ISDBT_LAYER_ENABLED[31:3] unused

 
-   
+   

DTV_ISDBT_LAYER*_FEC
 
Possible values: 
FEC_AUTO, FEC_1_2, 
FEC_2_3, FEC_3_4, 
FEC_5_6, FEC_7_8

 
-   
+   
 

[PATCH 02/15] [media] DocBook/frontend.xml: Better document fe_type_t

[Mauro Carvalho Chehab]

The fe_type_t documentation was incomplete and not linked to the
dvb/frontend.h.xml. Properly document it.

Also, drop a note that newer formats are only supported via
FE_GET_PROPERTY/FE_GET_SET_PROPERTY ioctls.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index d9a21d3..34afc54 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -124,6 +124,7 @@ DVB_DOCUMENTED = \
-e "s/\(linkend\=\"\)FE_SET_PROPERTY/\1FE_GET_PROPERTY/g" \
-e "s,\(struct\s\+\)\([a-z0-9_]\+\)\(\s\+{\),\1\\2\<\/link\>\3,g" \
-e "s,\(}\s\+\)\([a-z0-9_]\+_t\+\),\1\\2\<\/link\>,g" \
+   -e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \
 #  -e "s,\(\s\+\)\(FE_[A-Z0-9_]\+\)\([\s\=\,]*\),\1\\2\<\/link\>\3,g" \
 
 #
diff --git a/Documentation/DocBook/media/dvb/frontend.xml 
b/Documentation/DocBook/media/dvb/frontend.xml
index 60c6976..b52f66a 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -20,19 +20,44 @@ cards, in which case there exists no frontend device.
 
 Frontend Data Types
 
-
-frontend type
+
+Frontend type
 
 For historical reasons frontend types are named after the type of 
modulation used in
-transmission.
-
-   typedef enum fe_type {
-   FE_QPSK,   /⋆ DVB-S ⋆/
-   FE_QAM,/⋆ DVB-C ⋆/
-   FE_OFDM/⋆ DVB-T ⋆/
-   } fe_type_t;
-
+transmission. The fontend types are given by fe_type_t type, defined as:
 
+
+Frontend types
+
+   &cs-def;
+   
+ 
+   fe_type
+   Description
+ 
+  
+  
+  
+ FE_QPSK
+ For DVB-S standard
+  
+  
+ FE_QAM
+ For DVB-C standard
+  
+  
+ FE_OFDM
+ For DVB-T standard. Also used for ISDB-T on compatibility 
mode
+  
+  
+ FE_ATSC
+ For ATSC standard (terrestrial or cable)
+  
+
+
+Newer formats like DVB-S2, ISDB-T, ISDB-S and DVB-T2 are not described 
at the above, as they're
+supported via the new FE_GET_PROPERTY/FE_GET_SET_PROPERTY method.
+
 
 
 
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/15] [media] DocBook/Makefile: add references for several dvb structures

[Mauro Carvalho Chehab]

With this change, it is now possible to discover the gap between
the API defined inside include/dvb/frontend.h and the one documented
into the specs.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index baeea17..d9a21d3 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -51,6 +51,7 @@ FUNCS = \
 
 IOCTLS = \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/linux/videodev2.h) \
+   $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/linux/dvb/frontend.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/linux/v4l2-subdev.h) \
VIDIOC_SUBDEV_G_FRAME_INTERVAL \
@@ -60,16 +61,19 @@ IOCTLS = \
VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL \
 
 TYPES = \
-   $(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' 
$(srctree)/include/linux/videodev2.h)
+   $(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' 
$(srctree)/include/linux/videodev2.h) \
+   $(shell perl -ne 'print "$$1 " if /^}\s+([a-z0-9_]+_t)/' 
$(srctree)/include/linux/dvb/frontend.h)
 
 ENUMS = \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' 
$(srctree)/include/linux/videodev2.h) \
+   $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' 
$(srctree)/include/linux/dvb/frontend.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' 
$(srctree)/include/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' 
$(srctree)/include/linux/v4l2-mediabus.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' 
$(srctree)/include/linux/v4l2-subdev.h)
 
 STRUCTS = \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/videodev2.h) \
+   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/dvb/frontend.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/v4l2-subdev.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/v4l2-mediabus.h)
@@ -116,9 +120,11 @@ DOCUMENTED = \
-e "s/v4l2\-mpeg\-vbi\-ITV0/v4l2-mpeg-vbi-itv0-1/g"
 
 DVB_DOCUMENTED = \
-   -e "s,\(define \)\([A-Z0-9_]\+\)\(\s\+_IO\),\1\\2\<\/link\>\3,g" \
-   -e "s/\(linkend\=\"\)FE_SET_PROPERTY/\1FE_GET_PROPERTY/g"
-
+   -e "s,\(define\s\+\)\([A-Z0-9_]\+\)\(\s\+_IO\),\1\\2\<\/link\>\3,g" \
+   -e "s/\(linkend\=\"\)FE_SET_PROPERTY/\1FE_GET_PROPERTY/g" \
+   -e "s,\(struct\s\+\)\([a-z0-9_]\+\)\(\s\+{\),\1\\2\<\/link\>\3,g" \
+   -e "s,\(}\s\+\)\([a-z0-9_]\+_t\+\),\1\\2\<\/link\>,g" \
+#  -e "s,\(\s\+\)\(FE_[A-Z0-9_]\+\)\([\s\=\,]*\),\1\\2\<\/link\>\3,g" \
 
 #
 # Media targets and dependencies
-- 
1.7.1


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] [media] at91: add Atmel Image Sensor Interface (ISI) support

[Josh Wu]

This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640

Signed-off-by: Josh Wu 
---
base on branch staging/for_v3.0
Modified in V4:
remove redundant spin_lock code.
using isi_dma_desc in frame_buffer structure.
refactor the error handling code in probe() function.
other coding style fix.

 drivers/media/video/Kconfig |8 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/atmel-isi.c | 1048 +++
 include/media/atmel-isi.h   |  119 +
 4 files changed, 1176 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/atmel-isi.c
 create mode 100644 include/media/atmel-isi.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bb53de7..93d1098 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -952,6 +952,14 @@ config  VIDEO_SAMSUNG_S5P_FIMC
  To compile this driver as a module, choose M here: the
  module will be called s5p-fimc.
 
+config VIDEO_ATMEL_ISI
+   tristate "ATMEL Image Sensor Interface (ISI) support"
+   depends on VIDEO_DEV && SOC_CAMERA && ARCH_AT91
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This module makes the ATMEL Image Sensor Interface available
+ as a v4l2 device.
+
 config VIDEO_S5P_MIPI_CSIS
tristate "Samsung S5P and EXYNOS4 MIPI CSI receiver driver"
depends on VIDEO_V4L2 && PM_RUNTIME && PLAT_S5P && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f0fecd6..d9833f4 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -166,6 +166,7 @@ obj-$(CONFIG_VIDEO_PXA27x)  += pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
 obj-$(CONFIG_VIDEO_OMAP1)  += omap1_camera.o
+obj-$(CONFIG_VIDEO_ATMEL_ISI)  += atmel-isi.o
 
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC)   += s5p-fimc/
 
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
new file mode 100644
index 000..4742c28
--- /dev/null
+++ b/drivers/media/video/atmel-isi.c
@@ -0,0 +1,1048 @@
+/*
+ * Copyright (c) 2011 Atmel Corporation
+ * Josh Wu, 
+ *
+ * Based on previous work by Lars Haring, 
+ * and Sedji Gaouaou
+ * Based on the bttv driver for Bt848 with respective copyright holders
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_BUFFER_NUM 32
+#define MAX_SUPPORT_WIDTH  2048
+#define MAX_SUPPORT_HEIGHT 2048
+#define VID_LIMIT_BYTES(16 * 1024 * 1024)
+#define MIN_FRAME_RATE 15
+#define FRAME_INTERVAL_MILLI_SEC   (1000 / MIN_FRAME_RATE)
+
+/* ISI states */
+enum {
+   ISI_STATE_IDLE = 0,
+   ISI_STATE_READY,
+   ISI_STATE_WAIT_SOF,
+};
+
+/* Frame buffer descriptor */
+struct fbd {
+   /* Physical address of the frame buffer */
+   u32 fb_address;
+   /* DMA Control Register(only in HISI2) */
+   u32 dma_ctrl;
+   /* Physical address of the next fbd */
+   u32 next_fbd_address;
+};
+
+static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl)
+{
+   fb_desc->dma_ctrl = ctrl;
+}
+
+struct isi_dma_desc {
+   struct list_head list;
+   struct fbd *p_fbd;
+   u32 fbd_phys;
+};
+
+/* Frame buffer data */
+struct frame_buffer {
+   struct vb2_buffer vb;
+   struct isi_dma_desc *p_dma_desc;
+   struct list_head list;
+};
+
+struct atmel_isi {
+   /* Protects the access of variables shared with the ISR */
+   spinlock_t  lock;
+   void __iomem*regs;
+
+   int sequence;
+   /* State of the ISI module in capturing mode */
+   int state;
+
+   /* Wait queue for waiting for SOF */
+   wait_queue_head_t   vsync_wq;
+
+   struct vb2_alloc_ctx*alloc_ctx;
+
+   /* Allocate descriptors for dma buffer use */
+   struct fbd  *p_fb_descriptors;
+   u32 fb_descriptors_phys;
+   struct  list_head dma_desc_head;
+   struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
+
+   struct completion   complete;
+   struct clk  *pclk;
+   unsigned intirq;
+
+   struct isi_platform_data*pdata;
+
+   struct list

Re: Remote control TechnoTrend S2-3650 CI not working

[Juergen Lock]

On Mon, Jun 06, 2011 at 11:55:44PM +0200, Andreas Steinel wrote:
> Hi Jürgen, Hi List,
Hi!
> 
> Thank you for your answer.
> 
> On Sat, Jun 4, 2011 at 4:34 PM, Juergen Lock  wrote:
> > Ok let me try...
> >
> > 1. Your remote is the same as in this (googled) picture?
> >
> >        
> > http://4.bp.blogspot.com/_B0OTxmaxXPU/SfL1yGqvGjI/ABU/GFOklS4R9GM/s320/tt_s2_3650.jpg
> 
> At first glance yes, but it is not. Very similar, but yet different.
> (also discovered in the source, please see above)
> 
 Hm, interesting.

> > 2. Do you see remote events logged in dmesg when you modprobe the
> >   pctv452e driver with debug=3 and then test the remote?
> 
> Oh yes, I can see events from the remote:
> [ 8108.169526] pctv452e_rc_query: cmd=0x0d sys=0x18
> [ 8108.273332] pctv452e_rc_query: cmd=0x0d sys=0x18
> [ 8108.473326] pctv452e_rc_query: cmd=0x0d sys=0x18
> 
> 
> > 3. You can also test for events coming in on /dev/input/event8 using
> >   evtest, or (if you have up-to-date v4l-utils) using ir-keytable:
> 
> None of them showed any keyinput, but it is recognized (now its on event1):
> 
> Input driver version is 1.0.0
> Input device ID: bus 0x3 vendor 0xb48 product 0x300a version 0x101
> Input device name: "IR-receiver inside an USB DVB receiver"
> Supported events:
>   Event type 0 (Sync)
>   Event type 1 (Key)
> Event code 2 (1)
> Event code 3 (2)
> Event code 4 (3)
> Event code 5 (4)
> Event code 6 (5)
> Event code 7 (6)
> Event code 8 (7)
> Event code 9 (8)
> Event code 10 (9)
> Event code 11 (0)
> Event code 103 (Up)
> Event code 105 (Left)
> Event code 106 (Right)
> Event code 108 (Down)
> Event code 113 (Mute)
> Event code 114 (VolumeDown)
> Event code 115 (VolumeUp)
> Event code 116 (Power)
> Event code 119 (Pause)
> Event code 128 (Stop)
> Event code 141 (Setup)
> Event code 159 (Forward)
> Event code 167 (Record)
> Event code 168 (Rewind)
> Event code 174 (Exit)
> Event code 207 (Play)
> Event code 352 (Ok)
> Event code 357 (Option)
> Event code 358 (Info)
> Event code 365 (EPG)
> Event code 373 (Mode)
> Event code 388 (Text)
> Event code 398 (Red)
> Event code 399 (Green)
> Event code 400 (Yellow)
> Event code 401 (Blue)
> Event code 402 (ChannelUp)
> Event code 403 (ChannelDown)
> Event code 410 (Shuffle)
> 
> But no event is registered there :-/
> 
> ir-keytable doesn't found any rc even after triggering the udev rules
> (v4l ir-keytable from git and from debian unstable package).
> 
> > 4. Do you use the lirc devinput driver and the lircd.conf.devinput
> >   config?  Maybe this post helps:
> >
> >        http://forum.xbmc.org/showthread.php?t=101151
> 
> This link is - according to the headline - only for 2.6.35+ and I'
> running 2.6.32 (Squeeze default kernel)

 Ah I missed that, sorry.

>  and the post also builds on
> ir-keytable, which is not working properly.
> 
 *nod*

> Yet, i further investigated the errors and the source code and turned
> on dvb-usb-debugging which yields:
> 
> [11423.302006] key mapping failed - no appropriate key found in keymapping
> [11423.501806] pctv452e_rc_query: cmd=0x26 sys=0x18
> [11423.501815] key mapping failed - no appropriate key found in keymapping
> [11423.701615] pctv452e_rc_query: cmd=0x26 sys=0x18
> [11423.701628] key mapping failed - no appropriate key found in keymapping
> [11424.001763] pctv452e_rc_query: cmd=0x26 sys=0x18
> [11424.001775] key mapping failed - no appropriate key found in keymapping
> [11424.102026] pctv452e_rc_query: cmd=0x26 sys=0x18
> [11424.102034] key mapping failed - no appropriate key found in keymapping
> [11424.202030] pctv452e_rc_query: cmd=0x26 sys=0x18
> [11424.202038] key mapping failed - no appropriate key found in keymapping
> 
> Which explains the error. I further debugged the problem and found this:
> 
> [13242.485965] key mapping failed - no appropriate key found in keymapping
> [13242.585948] pctv452e_rc_query: cmd=0x26 sys=0x18
> [13242.585955]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x01
> [13242.585960]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x02
> [13242.585964]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x03
> [13242.585968]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x04
> [13242.585972]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x05
> [13242.585976]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x06
> [13242.585980]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x07
> [13242.585983]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x08
> [13242.585987]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x09
> [13242.585991]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 vs
> rc5_custom=0x0a
> [13242.585995]  keycode is [1]=0x18 vs rc5_custom=0x15, [3]=0x26 v

Re: DM04 USB DVB-S TUNER

[Malcolm Priestley]

On Tue, 2011-06-07 at 06:31 +0100, Malcolm Priestley wrote:
> On Tue, 2011-06-07 at 02:28 +0300, Mehmet Altan Pire wrote:
> > 06-06-2011 00:47, Malcolm Priestley yazmış:
> > > On Sun, 2011-06-05 at 21:42 +0100, Malcolm Priestley wrote:
> > >> On Sun, 2011-06-05 at 19:34 +0300, Mehmet Altan Pire wrote:
> > >>> 05-06-2011 17:16, Malcolm Priestley yazmış:
> >  On Sun, 2011-06-05 at 03:35 +0300, Mehmet Altan Pire wrote:
> > > Hi,
> > > I have "DM04 USB DVBS TUNER", using ubuntu with v4l media-build
> > > drivers/modules but device  doesn't working (unknown device).
> > >
> > > lsusb message:
> > > ID 3344:22f0
> > >
> > > under of the box:
> > > DM04P2011050176
> > >>> Yes, i have windows xp driver, name is "US2B0D.sys" I sending it,
> > >>> attached in this mail. Thanks. 
> > >> Here is a modified lmedm04.c and lme2510b_fw.sh using the US2B0D.sys
> > >>
> > to modify the interrupt return.
> > >
> 
> > >
> > Ok, i tested it. Device recognized on WinXP with original driver, but tv
> > application says "no lock".
> > I'm not sure it worked on WinXP but driver cd is original and
> > succesfully loaded and recognized.
> > Again tested on ubuntu with new lmedm04.c and lme2510b_fw.sh than make,
> > make install, and restart.
> > 
> > lsusb says:
> > Bus 001 Device 008: ID 3344:1120  (changes 22f0 to 1120)
> > dmesg says:
> Yes this should happen. The firmware will reboot with the correct id.

> 
> > My device different or chip is damaged? Label, box and driver cd title
> > writes "DM04P". DM04 and DM04P different devices?
> 
> I think the id of the chip is faulty or default.
> 
> I will test the firmware with LG tuner later.

It is not the LG, s7395 or S0194 tuner.

So the id is intentional. 

How does it identify itself in windows?


tvboxspy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[cron job] v4l-dvb daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Tue Jun  7 19:06:46 CEST 2011
git hash:35c310b56740292c1e2f1d679feca3b9ed02555d
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
spec-git: ERRORS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/media_api.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] cx88: replaced duplicated code with function call

[Istvan Varga]

The following patch replaces code to reset the XC3028 tuner with a call
to the tuner reset callback.

Signed-off-by: Istvan Varga 

diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-cards.c 
xc4000/drivers/media/video/cx88/cx88-cards.c
--- xc4000_orig/drivers/media/video/cx88/cx88-cards.c   2011-06-07 
18:02:28.0 +0200
+++ xc4000/drivers/media/video/cx88/cx88-cards.c2011-06-07 
18:09:01.0 +0200
@@ -3245,13 +3245,7 @@
 
case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL:
case CX88_BOARD_WINFAST_DTV1800H:
-   /* GPIO 12 (xc3028 tuner reset) */
-   cx_set(MO_GP1_IO, 0x1010);
-   mdelay(50);
-   cx_clear(MO_GP1_IO, 0x10);
-   mdelay(50);
-   cx_set(MO_GP1_IO, 0x10);
-   mdelay(50);
+   cx88_xc3028_winfast1800h_callback(core, XC2028_TUNER_RESET, 0);
break;
 
case CX88_BOARD_WINFAST_DTV1800H_XC4000:
--
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] cx231xx: Add support for Hauppauge WinTV USB2-FM

[Devin Heitmueller]

On Tue, Jun 7, 2011 at 12:12 PM, Peter Moon  wrote:
> According to the Windows driver inf file that I have, the USB ID of
> the NTSC version is 2040:b111.

Correct.  The PAL defaulted device is b110.  The NTSC defaulted device is B111.

> I can add the USB device definition for the NTSC targeted device as well.

You can do this either one of two ways:  you can add just the USB ID
and point them both to the same card profile.  Or you can create two
card profiles that are identical in every way except for the default
standard.  The second approach is probably a better end-user
experience (since the default standard would match the user's
expectations), but the first approach is less code.

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

[PATCH 3/4] cx88: added support for Leadtek WinFast DTV1800 H with XC4000 tuner

[Istvan Varga]

This patch implements support for the Leadtek WinFast DTV1800 H card with
XC4000 tuner (107d:6f38).

Signed-off-by: Istvan Varga 

diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-cards.c 
xc4000/drivers/media/video/cx88/cx88-cards.c
--- xc4000_orig/drivers/media/video/cx88/cx88-cards.c   2011-06-07 
17:42:58.0 +0200
+++ xc4000/drivers/media/video/cx88/cx88-cards.c2011-06-07 
18:01:53.0 +0200
@@ -2120,6 +2120,47 @@
},
.mpeg   = CX88_MPEG_DVB,
},
+   [CX88_BOARD_WINFAST_DTV1800H_XC4000] = {
+   .name   = "Leadtek WinFast DTV1800 H (XC4000)",
+   .tuner_type = TUNER_XC4000,
+   .radio_type = TUNER_XC4000,
+   .tuner_addr = 0x61,
+   .radio_addr = 0x61,
+   /*
+* GPIO setting
+*
+*  2: mute (0=off,1=on)
+* 12: tuner reset pin
+* 13: audio source (0=tuner audio,1=line in)
+* 14: FM (0=on,1=off ???)
+*/
+   .input  = {{
+   .type   = CX88_VMUX_TELEVISION,
+   .vmux   = 0,
+   .gpio0  = 0x0400,   /* pin 2 = 0 */
+   .gpio1  = 0x6040,   /* pin 13 = 0, pin 14 = 1 */
+   .gpio2  = 0x,
+   }, {
+   .type   = CX88_VMUX_COMPOSITE1,
+   .vmux   = 1,
+   .gpio0  = 0x0400,   /* pin 2 = 0 */
+   .gpio1  = 0x6060,   /* pin 13 = 1, pin 14 = 1 */
+   .gpio2  = 0x,
+   }, {
+   .type   = CX88_VMUX_SVIDEO,
+   .vmux   = 2,
+   .gpio0  = 0x0400,   /* pin 2 = 0 */
+   .gpio1  = 0x6060,   /* pin 13 = 1, pin 14 = 1 */
+   .gpio2  = 0x,
+   }},
+   .radio = {
+   .type   = CX88_RADIO,
+   .gpio0  = 0x0400,   /* pin 2 = 0 */
+   .gpio1  = 0x6000,   /* pin 13 = 0, pin 14 = 0 */
+   .gpio2  = 0x,
+   },
+   .mpeg   = CX88_MPEG_DVB,
+   },
[CX88_BOARD_WINFAST_DTV2000H_PLUS] = {
.name   = "Leadtek WinFast DTV2000 H PLUS",
.tuner_type = TUNER_XC4000,
@@ -2634,6 +2675,11 @@
.subdevice = 0x6654,
.card  = CX88_BOARD_WINFAST_DTV1800H,
}, {
+   /* WinFast DTV1800 H with XC4000 tuner */
+   .subvendor = 0x107d,
+   .subdevice = 0x6f38,
+   .card  = CX88_BOARD_WINFAST_DTV1800H_XC4000,
+   }, {
.subvendor = 0x107d,
.subdevice = 0x6f42,
.card  = CX88_BOARD_WINFAST_DTV2000H_PLUS,
@@ -3027,6 +3073,7 @@
 {
/* Board-specific callbacks */
switch (core->boardnr) {
+   case CX88_BOARD_WINFAST_DTV1800H_XC4000:
case CX88_BOARD_WINFAST_DTV2000H_PLUS:
return cx88_xc4000_winfast2000h_plus_callback(core,
  command, arg);
@@ -3207,6 +3254,7 @@
mdelay(50);
break;
 
+   case CX88_BOARD_WINFAST_DTV1800H_XC4000:
case CX88_BOARD_WINFAST_DTV2000H_PLUS:
cx88_xc4000_winfast2000h_plus_callback(core,
   XC4000_TUNER_RESET, 0);
diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-dvb.c 
xc4000/drivers/media/video/cx88/cx88-dvb.c
--- xc4000_orig/drivers/media/video/cx88/cx88-dvb.c 2011-06-07 
17:42:58.0 +0200
+++ xc4000/drivers/media/video/cx88/cx88-dvb.c  2011-06-07 17:56:07.0 
+0200
@@ -1328,6 +1328,7 @@
goto frontend_detach;
}
break;
+   case CX88_BOARD_WINFAST_DTV1800H_XC4000:
case CX88_BOARD_WINFAST_DTV2000H_PLUS:
fe0->dvb.frontend = dvb_attach(zl10353_attach,
   &cx88_pinnacle_hybrid_pctv,
diff -uNr xc4000_orig/drivers/media/video/cx88/cx88.h 
xc4000/drivers/media/video/cx88/cx88.h
--- xc4000_orig/drivers/media/video/cx88/cx88.h 2011-06-07 17:42:58.0 
+0200
+++ xc4000/drivers/media/video/cx88/cx88.h  2011-06-07 17:56:39.0 
+0200
@@ -243,6 +243,7 @@
 #define CX88_BOARD_TWINHAN_VP1027_DVBS 85
 #define CX88_BOARD_TEVII_S464  86
 #define CX88_BOARD_WINFAST_DTV2000H_PLUS   87
+#define CX88_BOARD_WINFAST_DTV1800H_XC4000 88
 
 enum cx88_itype {
CX88_VMUX_COMPOSITE1 = 1,
diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-input.c 
xc4000/drivers/media/video/cx88/cx88-input.c
--- xc4000_orig/drivers/media/video/cx88/cx88-input.c   2011-06-07 
17:42:58.0 +02

[PATCH 2/4] cx88: added support for Leadtek WinFast DTV2000 H Plus

[Istvan Varga]

This patch implements support for the Leadtek WinFast DTV2000 H Plus card
with XC4000 tuner (107d:6f42).

Signed-off-by: Istvan Varga 

diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-cards.c 
xc4000/drivers/media/video/cx88/cx88-cards.c
--- xc4000_orig/drivers/media/video/cx88/cx88-cards.c   2011-06-07 
15:34:32.0 +0200
+++ xc4000/drivers/media/video/cx88/cx88-cards.c2011-06-07 
17:37:32.0 +0200
@@ -2120,6 +2120,58 @@
},
.mpeg   = CX88_MPEG_DVB,
},
+   [CX88_BOARD_WINFAST_DTV2000H_PLUS] = {
+   .name   = "Leadtek WinFast DTV2000 H PLUS",
+   .tuner_type = TUNER_XC4000,
+   .radio_type = TUNER_XC4000,
+   .tuner_addr = 0x61,
+   .radio_addr = 0x61,
+   /*
+* GPIO
+*   2: 1: mute audio
+*  12: 0: reset XC4000
+*  13: 1: audio input is line in (0: tuner)
+*  14: 0: FM radio
+*  16: 0: RF input is cable
+*/
+   .input  = {{
+   .type   = CX88_VMUX_TELEVISION,
+   .vmux   = 0,
+   .gpio0  = 0x0403,
+   .gpio1  = 0xF0D7,
+   .gpio2  = 0x0101,
+   .gpio3  = 0x,
+   }, {
+   .type   = CX88_VMUX_CABLE,
+   .vmux   = 0,
+   .gpio0  = 0x0403,
+   .gpio1  = 0xF0D7,
+   .gpio2  = 0x0100,
+   .gpio3  = 0x,
+   }, {
+   .type   = CX88_VMUX_COMPOSITE1,
+   .vmux   = 1,
+   .gpio0  = 0x0403,   /* was 0x0407 */
+   .gpio1  = 0xF0F7,
+   .gpio2  = 0x0101,
+   .gpio3  = 0x,
+   }, {
+   .type   = CX88_VMUX_SVIDEO,
+   .vmux   = 2,
+   .gpio0  = 0x0403,   /* was 0x0407 */
+   .gpio1  = 0xF0F7,
+   .gpio2  = 0x0101,
+   .gpio3  = 0x,
+   }},
+   .radio = {
+   .type   = CX88_RADIO,
+   .gpio0  = 0x0403,
+   .gpio1  = 0xF097,
+   .gpio2  = 0x0100,
+   .gpio3  = 0x,
+   },
+   .mpeg   = CX88_MPEG_DVB,
+   },
[CX88_BOARD_PROF_7301] = {
.name   = "Prof 7301 DVB-S/S2",
.tuner_type = UNSET,
@@ -2582,6 +2634,10 @@
.subdevice = 0x6654,
.card  = CX88_BOARD_WINFAST_DTV1800H,
}, {
+   .subvendor = 0x107d,
+   .subdevice = 0x6f42,
+   .card  = CX88_BOARD_WINFAST_DTV2000H_PLUS,
+   }, {
/* PVR2000 PAL Model [107d:6630] */
.subvendor = 0x107d,
.subdevice = 0x6630,
@@ -2847,6 +2903,23 @@
return -EINVAL;
 }
 
+static int cx88_xc4000_winfast2000h_plus_callback(struct cx88_core *core,
+ int command, int arg)
+{
+   switch (command) {
+   case XC4000_TUNER_RESET:
+   /* GPIO 12 (xc4000 tuner reset) */
+   cx_set(MO_GP1_IO, 0x1010);
+   mdelay(50);
+   cx_clear(MO_GP1_IO, 0x10);
+   mdelay(75);
+   cx_set(MO_GP1_IO, 0x10);
+   mdelay(75);
+   return 0;
+   }
+   return -EINVAL;
+}
+
 /* --- */
 /* some Divco specific stuff   */
 static int cx88_pv_8000gt_callback(struct cx88_core *core,
@@ -2954,6 +3027,9 @@
 {
/* Board-specific callbacks */
switch (core->boardnr) {
+   case CX88_BOARD_WINFAST_DTV2000H_PLUS:
+   return cx88_xc4000_winfast2000h_plus_callback(core,
+ command, arg);
}
return -EINVAL;
 }
@@ -3131,6 +3207,11 @@
mdelay(50);
break;
 
+   case CX88_BOARD_WINFAST_DTV2000H_PLUS:
+   cx88_xc4000_winfast2000h_plus_callback(core,
+  XC4000_TUNER_RESET, 0);
+   break;
+
case CX88_BOARD_TWINHAN_VP1027_DVBS:
cx_write(MO_GP0_IO, 0x3230);
cx_write(MO_GP0_IO, 0x3210);
diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-dvb.c 
xc4000/drivers/media/video/cx88/cx88-dvb.c
--- xc4000_orig/drivers/media/video/cx88/cx88-dvb.c 2011-06-07 
15:34:32.0 +0200
+++ xc4000/drivers/media/video/cx88/cx88-dvb.c  2011-06-07 17:41:57.0 
+0200

Re: [PATCH] cx231xx: Add support for Hauppauge WinTV USB2-FM

[Peter Moon]

On Mon, Jun 6, 2011 at 10:00 PM, Devin Heitmueller
 wrote:
> On Mon, Jun 6, 2011 at 3:22 PM, Peter Moon  wrote:
>> This patch adds support for the " Hauppauge WinTV USB2-FM" Analog Stick.
>>
>> Signed-off-by: Peter Moon 
>
> My only comment is that the func_mode in cx231xx_dif_set_standard()
> should be 0x01, not 0x03.  Change that, resubmit the patch after
> testing, and I will put my Reviewed-By on it.

I will make the change you suggest and retest.

> Also, there is actually another USB ID which is the exact same product
> (but targeted at NTSC by default).  I'll have to lookup the ID though.

According to the Windows driver inf file that I have, the USB ID of
the NTSC version is 2040:b111.

I can add the USB device definition for the NTSC targeted device as well.

Peter Moon
--
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/4] cx88: added XC4000 tuner callback and DVB attach functions

[Istvan Varga]

Added functions for XC4000 tuner reset and attaching DVB frontend.

Signed-off-by: Istvan Varga 

diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-cards.c 
xc4000/drivers/media/video/cx88/cx88-cards.c
--- xc4000_orig/drivers/media/video/cx88/cx88-cards.c   2011-06-07 
14:33:39.0 +0200
+++ xc4000/drivers/media/video/cx88/cx88-cards.c2011-06-07 
15:28:03.0 +0200
@@ -28,6 +28,7 @@
 
 #include "cx88.h"
 #include "tea5767.h"
+#include "xc4000.h"
 
 static unsigned int tuner[] = {[0 ... (CX88_MAXBOARDS - 1)] = UNSET };
 static unsigned int radio[] = {[0 ... (CX88_MAXBOARDS - 1)] = UNSET };
@@ -2948,6 +2949,15 @@
return -EINVAL;
 }
 
+static int cx88_xc4000_tuner_callback(struct cx88_core *core,
+ int command, int arg)
+{
+   /* Board-specific callbacks */
+   switch (core->boardnr) {
+   }
+   return -EINVAL;
+}
+
 /* --- */
 /* Tuner callback function. Currently only needed for the Pinnacle*
  * PCTV HD 800i with an xc5000 sillicon tuner. This is used for both  *
@@ -3022,6 +3032,9 @@
case TUNER_XC2028:
info_printk(core, "Calling XC2028/3028 callback\n");
return cx88_xc2028_tuner_callback(core, command, arg);
+   case TUNER_XC4000:
+   info_printk(core, "Calling XC4000 callback\n");
+   return cx88_xc4000_tuner_callback(core, command, arg);
case TUNER_XC5000:
info_printk(core, "Calling XC5000 callback\n");
return cx88_xc5000_tuner_callback(core, command, arg);
diff -uNr xc4000_orig/drivers/media/video/cx88/cx88-dvb.c 
xc4000/drivers/media/video/cx88/cx88-dvb.c
--- xc4000_orig/drivers/media/video/cx88/cx88-dvb.c 2011-06-07 
14:33:39.0 +0200
+++ xc4000/drivers/media/video/cx88/cx88-dvb.c  2011-06-07 15:33:09.0 
+0200
@@ -41,6 +41,7 @@
 #include "or51132.h"
 #include "lgdt330x.h"
 #include "s5h1409.h"
+#include "xc4000.h"
 #include "xc5000.h"
 #include "nxt200x.h"
 #include "cx24123.h"
@@ -604,6 +605,39 @@
 
return 0;
 }
+
+static int attach_xc4000(struct cx8802_dev *dev, struct xc4000_config *cfg)
+{
+   struct dvb_frontend *fe;
+   struct videobuf_dvb_frontend *fe0 = NULL;
+
+   /* Get the first frontend */
+   fe0 = videobuf_dvb_get_frontend(&dev->frontends, 1);
+   if (!fe0)
+   return -EINVAL;
+
+   if (!fe0->dvb.frontend) {
+   printk(KERN_ERR "%s/2: dvb frontend not attached. "
+   "Can't attach xc4000\n",
+  dev->core->name);
+   return -EINVAL;
+   }
+
+   fe = dvb_attach(xc4000_attach, fe0->dvb.frontend, &dev->core->i2c_adap,
+   cfg);
+   if (!fe) {
+   printk(KERN_ERR "%s/2: xc4000 attach failed\n",
+  dev->core->name);
+   dvb_frontend_detach(fe0->dvb.frontend);
+   dvb_unregister_frontend(fe0->dvb.frontend);
+   fe0->dvb.frontend = NULL;
+   return -EINVAL;
+   }
+
+   printk(KERN_INFO "%s/2: xc4000 attached\n", dev->core->name);
+
+   return 0;
+}
 
 static int cx24116_set_ts_param(struct dvb_frontend *fe,
int is_punctured)
--
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: Last key repeated after every keypress on remote control (saa7134 lirc devinput driver)

[Jarod Wilson]

On Jun 7, 2011, at 2:45 AM, Radim wrote:

> 
>>  Pôvodná správa 
>> Od: Jarod Wilson 
>> Predmet: Re: Last key repeated after every keypress on remote control 
>> (saa7134
>> lirc devinput driver)
>> Dátum: 06.6.2011 20:39:50
>> 
>> Devin Heitmueller wrote:
>> > On Mon, Jun 6, 2011 at 2:13 PM, Radim  wrote:
>> >> Hello to everybody,
>> >> I was redirected here from lirc mailinglist (reason is at the end).
>> >>
>> >> I'm asking for any help because I wasn't able to solve
>> >> this problem by my self (and google of course).
>> >>
>> >> When I'm testing lirc configuration using irw, last pressed key is 
>> >> repeated
>> >> just befor the new one:
>> >>
>> >> after pressing key 1:
>> >> 80010002 00 KEY_1 devinput
>> >>
>> >> after pressing key 2:
>> >> 80010002 00 KEY_1 devinput
>> >> 80010003 00 KEY_2 devinput
>> >>
>> >> after pressing key 3:
>> >> 80010003 00 KEY_2 devinput
>> >> 80010004 00 KEY_3 devinput
>> >>
>> >> after pressing key 4:
>> >> 80010004 00 KEY_3 devinput
>> >> 80010005 00 KEY_4 devinput
>> >>
>> >> after pressing key 5:
>> >> 80010005 00 KEY_4 devinput
>> >> 80010006 00 KEY_5 devinput
>> >>
>> >>
>> >> My configuration:
>> >> Archlinux (allways up-to-date)
>> >> Asus MyCinema P7131 with remote control PC-39
>> >> lircd 0.9.0, driver devinput, default config file lirc.conf.devinput
>> >> kernel 2.6.38
>> >>
>> >> # ir-keytable
>> >> Found /sys/class/rc/rc0/ (/dev/input/event5) with:
>> >>Driver saa7134, table rc-asus-pc39
>> >>Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
>> >>Enabled protocols: RC-5
>> >>Repeat delay = 500 ms, repeat period = 33 ms
>> >>
>> >> Answare from lirc-mainlinglist (Jarod Wilson):
>> >> Looks like a bug in saa7134-input.c, which doesn't originate in lirc land,
>> >> its from the kernel itself. The more apropos location to tackle this issue
>> >> is linux-media@vger.kernel.org.
>> >>
>> >> I can provide any other listings, just ask for them.
>> >>
>> >> Thank you for any help,
>> >> Radim
>> >
>> > I actually sent Jarod a board specifically to investigate this issue
>> > (the same issue occurs on the saa7134 based HVR-1150).  I believe it's
>> > on his TODO list.
>> Yep, he chopped out the part of my reply where I said as much. :)
>> Just waiting on the IR receiver cable to arrive, could well be here in 
>> today's mail...
> 
> Oh, I misunderstood Jarod answer - he pointed me to this list as a right 
> place for posting this possible bug in saa7134 driver, so I sent it also 
> here. I was thinking that this is not a job for member of lirc developers, so 
> I was trying luck here..

I work on both lirc and media tree drivers. In this case, lircd is doing
exactly the right thing with the data its being fed, the bug is in the
kernel driver, which is from the media tree. Best to discuss the bug on
the list for the layer at which it exists. :)

(No cable yet, still awaiting its arrival).

-- 
Jarod Wilson
ja...@wilsonet.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/RFC] V4L: add media bus configuration subdev operations

[Laurent Pinchart]

Hi Guennadi,

Thanks for the patch.

On Monday 06 June 2011 14:31:57 Guennadi Liakhovetski wrote:
> Add media bus configuration types and two subdev operations to get
> supported mediabus configurations and to set a specific configuration.
> Subdevs can support several configurations, e.g., they can send video data
> on 1 or several lanes, can be configured to use a specific CSI-2 channel,
> in such cases subdevice drivers return bitmasks with all respective bits
> set. When a set-configuration operation is called, it has to specify a
> non-ambiguous configuration.
> 
> Signed-off-by: Stanimir Varbanov 
> Signed-off-by: Guennadi Liakhovetski 
> ---
> 
> This change would allow a re-use of soc-camera and "standard" subdev
> drivers. It is a modified and extended version of
> 
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/294
> 08
> 
> therefore the original Sob. After this we only would have to switch to the
> control framework:) Please, comment.

I still believe we shouldn't use any set operation :-) The host/bridge driver 
should just use the get operation before starting the stream to configure it's 
sensor interface. 

> diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
> index 971c7fa..0983b7b 100644
> --- a/include/media/v4l2-mediabus.h
> +++ b/include/media/v4l2-mediabus.h
> @@ -13,6 +13,76 @@
> 
>  #include 
> 
> +/* Parallel flags */
> +/* Can the client run in master or in slave mode */
> +#define V4L2_MBUS_MASTER (1 << 0)
> +#define V4L2_MBUS_SLAVE  (1 << 1)
> +/* Which signal polarities it supports */
> +#define V4L2_MBUS_HSYNC_ACTIVE_HIGH  (1 << 2)
> +#define V4L2_MBUS_HSYNC_ACTIVE_LOW   (1 << 3)
> +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH  (1 << 4)
> +#define V4L2_MBUS_VSYNC_ACTIVE_LOW   (1 << 5)
> +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 << 6)
> +#define V4L2_MBUS_PCLK_SAMPLE_FALLING(1 << 7)
> +#define V4L2_MBUS_DATA_ACTIVE_HIGH   (1 << 8)
> +#define V4L2_MBUS_DATA_ACTIVE_LOW(1 << 9)
> +/* Which datawidths are supported */
> +#define V4L2_MBUS_DATAWIDTH_4(1 << 10)
> +#define V4L2_MBUS_DATAWIDTH_8(1 << 11)
> +#define V4L2_MBUS_DATAWIDTH_9(1 << 12)
> +#define V4L2_MBUS_DATAWIDTH_10   (1 << 13)
> +#define V4L2_MBUS_DATAWIDTH_15   (1 << 14)
> +#define V4L2_MBUS_DATAWIDTH_16   (1 << 15)
> +
> +#define V4L2_MBUS_DATAWIDTH_MASK (V4L2_MBUS_DATAWIDTH_4 |
> V4L2_MBUS_DATAWIDTH_8 | \ +
> V4L2_MBUS_DATAWIDTH_9 |
> V4L2_MBUS_DATAWIDTH_10 | \
> +  V4L2_MBUS_DATAWIDTH_15 | 
> V4L2_MBUS_DATAWIDTH_16)

The mbus data width is selected by the mbus format. Why do we need an explicit 
width here ?

> +/* Serial flags */
> +/* How many lanes the client can use */
> +#define V4L2_MBUS_CSI2_1_LANE(1 << 0)
> +#define V4L2_MBUS_CSI2_2_LANE(1 << 1)
> +#define V4L2_MBUS_CSI2_3_LANE(1 << 2)
> +#define V4L2_MBUS_CSI2_4_LANE(1 << 3)
> +/* On which channels it can send video data */
> +#define V4L2_MBUS_CSI2_CHANNEL_0 (1 << 4)
> +#define V4L2_MBUS_CSI2_CHANNEL_1 (1 << 5)
> +#define V4L2_MBUS_CSI2_CHANNEL_2 (1 << 6)
> +#define V4L2_MBUS_CSI2_CHANNEL_3 (1 << 7)
> +/* Does it support only continuous or also non-contimuous clock mode */
> +#define V4L2_MBUS_CSI2_CONTINUOUS_CLOCK  (1 << 8)
> +#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK   (1 << 9)
> +
> +#define V4L2_MBUS_CSI2_LANES (V4L2_MBUS_CSI2_1_LANE |
> V4L2_MBUS_CSI2_2_LANE | \ +
> V4L2_MBUS_CSI2_3_LANE |
> V4L2_MBUS_CSI2_4_LANE)
> +#define V4L2_MBUS_CSI2_CHANNELS  (V4L2_MBUS_CSI2_CHANNEL_0 |
> V4L2_MBUS_CSI2_CHANNEL_1 | \ + 
> V4L2_MBUS_CSI2_CHANNEL_2 |
> V4L2_MBUS_CSI2_CHANNEL_3)
> +
> +/**
> + * v4l2_mbus_type - media bus type
> + * @V4L2_MBUS_PARALLEL:  parallel interface with hsync and vsync
> + * @V4L2_MBUS_BT656: parallel interface with embedded synchronisation
> + * @V4L2_MBUS_CSI2:  MIPI CSI-2 serial interface
> + */
> +enum v4l2_mbus_type {
> + V4L2_MBUS_PARALLEL,
> + V4L2_MBUS_BT656,
> + V4L2_MBUS_CSI2,
> +};
> +
> +/**
> + * v4l2_mbus_config - media bus configuration
> + * @type:interface type
> + * @flags:   configuration flags, depending on @type
> + * @clk: output clock, the bridge driver can try to use clk_set_parent()
> + *   to specify the master clock to the client
> + */
> +struct v4l2_mbus_config {
> + enum v4l2_mbus_type type;
> + unsigned long flags;
> + struct clk *clk;
> +};

struct clk is being generalized as part of the ARM clock consolidation work, 
bu

[RFCv3 PATCH 05/18] v4l2-subdev: implement per-filehandle control handlers.

[Hans Verkuil]

From: Hans Verkuil 

To be consistent with v4l2-ioctl.c.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-device.c |1 +
 drivers/media/video/v4l2-subdev.c |   14 +++---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/v4l2-device.c 
b/drivers/media/video/v4l2-device.c
index 4aae501..c72856c 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -209,6 +209,7 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device 
*v4l2_dev)
vdev->v4l2_dev = v4l2_dev;
vdev->fops = &v4l2_subdev_fops;
vdev->release = video_device_release_empty;
+   vdev->ctrl_handler = sd->ctrl_handler;
err = __video_register_device(vdev, VFL_TYPE_SUBDEV, -1, 1,
  sd->owner);
if (err < 0)
diff --git a/drivers/media/video/v4l2-subdev.c 
b/drivers/media/video/v4l2-subdev.c
index 812729e..f396cc3 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -155,25 +155,25 @@ static long subdev_do_ioctl(struct file *file, unsigned 
int cmd, void *arg)
 
switch (cmd) {
case VIDIOC_QUERYCTRL:
-   return v4l2_queryctrl(sd->ctrl_handler, arg);
+   return v4l2_queryctrl(vfh->ctrl_handler, arg);
 
case VIDIOC_QUERYMENU:
-   return v4l2_querymenu(sd->ctrl_handler, arg);
+   return v4l2_querymenu(vfh->ctrl_handler, arg);
 
case VIDIOC_G_CTRL:
-   return v4l2_g_ctrl(sd->ctrl_handler, arg);
+   return v4l2_g_ctrl(vfh->ctrl_handler, arg);
 
case VIDIOC_S_CTRL:
-   return v4l2_s_ctrl(sd->ctrl_handler, arg);
+   return v4l2_s_ctrl(vfh->ctrl_handler, arg);
 
case VIDIOC_G_EXT_CTRLS:
-   return v4l2_g_ext_ctrls(sd->ctrl_handler, arg);
+   return v4l2_g_ext_ctrls(vfh->ctrl_handler, arg);
 
case VIDIOC_S_EXT_CTRLS:
-   return v4l2_s_ext_ctrls(sd->ctrl_handler, arg);
+   return v4l2_s_ext_ctrls(vfh->ctrl_handler, arg);
 
case VIDIOC_TRY_EXT_CTRLS:
-   return v4l2_try_ext_ctrls(sd->ctrl_handler, arg);
+   return v4l2_try_ext_ctrls(vfh->ctrl_handler, arg);
 
case VIDIOC_DQEVENT:
if (!(sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS))
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 04/18] v4l2-ioctl: add ctrl_handler to v4l2_fh

[Hans Verkuil]

This is required to implement control events and is also needed to allow
for per-filehandle control handlers.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-fh.c|2 ++
 drivers/media/video/v4l2-ioctl.c |   36 +++-
 include/media/v4l2-fh.h  |2 ++
 3 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
index 717f71e..8635011 100644
--- a/drivers/media/video/v4l2-fh.c
+++ b/drivers/media/video/v4l2-fh.c
@@ -32,6 +32,8 @@
 int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
 {
fh->vdev = vdev;
+   /* Inherit from video_device. May be overridden by the driver. */
+   fh->ctrl_handler = vdev->ctrl_handler;
INIT_LIST_HEAD(&fh->list);
set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
fh->prio = V4L2_PRIORITY_UNSET;
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..9811b1e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1418,7 +1418,9 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_queryctrl *p = arg;
 
-   if (vfd->ctrl_handler)
+   if (vfh && vfh->ctrl_handler)
+   ret = v4l2_queryctrl(vfh->ctrl_handler, p);
+   else if (vfd->ctrl_handler)
ret = v4l2_queryctrl(vfd->ctrl_handler, p);
else if (ops->vidioc_queryctrl)
ret = ops->vidioc_queryctrl(file, fh, p);
@@ -1438,7 +1440,9 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_control *p = arg;
 
-   if (vfd->ctrl_handler)
+   if (vfh && vfh->ctrl_handler)
+   ret = v4l2_g_ctrl(vfh->ctrl_handler, p);
+   else if (vfd->ctrl_handler)
ret = v4l2_g_ctrl(vfd->ctrl_handler, p);
else if (ops->vidioc_g_ctrl)
ret = ops->vidioc_g_ctrl(file, fh, p);
@@ -1470,12 +1474,16 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls ctrls;
struct v4l2_ext_control ctrl;
 
-   if (!vfd->ctrl_handler &&
+   if (!(vfh && vfh->ctrl_handler) && !vfd->ctrl_handler &&
!ops->vidioc_s_ctrl && !ops->vidioc_s_ext_ctrls)
break;
 
dbgarg(cmd, "id=0x%x, value=%d\n", p->id, p->value);
 
+   if (vfh && vfh->ctrl_handler) {
+   ret = v4l2_s_ctrl(vfh->ctrl_handler, p);
+   break;
+   }
if (vfd->ctrl_handler) {
ret = v4l2_s_ctrl(vfd->ctrl_handler, p);
break;
@@ -1501,7 +1509,9 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls *p = arg;
 
p->error_idx = p->count;
-   if (vfd->ctrl_handler)
+   if (vfh && vfh->ctrl_handler)
+   ret = v4l2_g_ext_ctrls(vfh->ctrl_handler, p);
+   else if (vfd->ctrl_handler)
ret = v4l2_g_ext_ctrls(vfd->ctrl_handler, p);
else if (ops->vidioc_g_ext_ctrls && check_ext_ctrls(p, 0))
ret = ops->vidioc_g_ext_ctrls(file, fh, p);
@@ -1515,10 +1525,13 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls *p = arg;
 
p->error_idx = p->count;
-   if (!vfd->ctrl_handler && !ops->vidioc_s_ext_ctrls)
+   if (!(vfh && vfh->ctrl_handler) && !vfd->ctrl_handler &&
+   !ops->vidioc_s_ext_ctrls)
break;
v4l_print_ext_ctrls(cmd, vfd, p, 1);
-   if (vfd->ctrl_handler)
+   if (vfh && vfh->ctrl_handler)
+   ret = v4l2_s_ext_ctrls(vfh->ctrl_handler, p);
+   else if (vfd->ctrl_handler)
ret = v4l2_s_ext_ctrls(vfd->ctrl_handler, p);
else if (check_ext_ctrls(p, 0))
ret = ops->vidioc_s_ext_ctrls(file, fh, p);
@@ -1529,10 +1542,13 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_ext_controls *p = arg;
 
p->error_idx = p->count;
-   if (!vfd->ctrl_handler && !ops->vidioc_try_ext_ctrls)
+   if (!(vfh && vfh->ctrl_handler) && !vfd->ctrl_handler &&
+   !ops->vidioc_try_ext_ctrls)
break;
v4l_print_ext_ctrls(cmd, vfd, p, 1);
-   if (vfd->ctrl_handler)
+   if (vfh && vfh->ctrl_handler)
+   ret = v4l2_try_ext_ctrls(vfh->ctrl_handler, p);
+   else if (vfd->ctrl_handler)
ret = v4l2_try_ext_ctrls(vfd->ctrl_handler, p);

[RFCv3 PATCH 07/18] v4l2-controls.txt: update to latest v4l2-ctrl.c changes.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 Documentation/video4linux/v4l2-controls.txt |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/Documentation/video4linux/v4l2-controls.txt 
b/Documentation/video4linux/v4l2-controls.txt
index 881e7f4..95a3813 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -277,16 +277,13 @@ implement g_volatile_ctrl like this:
{
switch (ctrl->id) {
case V4L2_CID_BRIGHTNESS:
-   ctrl->cur.val = read_reg(0x123);
+   ctrl->val = read_reg(0x123);
break;
}
}
 
-The 'new value' union is not used in g_volatile_ctrl. In general controls
-that need to implement g_volatile_ctrl are read-only controls.
-
-Note that if one or more controls in a control cluster are marked as volatile,
-then all the controls in the cluster are seen as volatile.
+Note that you use the 'new value' union as well in g_volatile_ctrl. In general
+controls that need to implement g_volatile_ctrl are read-only controls.
 
 To mark a control as volatile you have to set the is_volatile flag:
 
@@ -636,9 +633,7 @@ button controls are write-only controls.
 -EINVAL as the spec says.
 
 5) The spec does not mention what should happen when you try to set/get a
-control class controls. ivtv currently returns -EINVAL (indicating that the
-control ID does not exist) while the framework will return -EACCES, which
-makes more sense.
+control class controls. The framework will return -EACCES.
 
 
 Proposals for Extensions
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 02/18] v4l2-ctrls: simplify error_idx handling.

[Hans Verkuil]

From: Hans Verkuil 

The lower-level prepare functions just set error_idx for each control that
might have an error. The high-level functions will override this with
cs->count in the get and set cases. Only try will keep the error_idx.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |   24 +---
 1 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 3f2a0c5..d9e0439 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1450,8 +1450,7 @@ EXPORT_SYMBOL(v4l2_subdev_querymenu);
Find the controls in the control array and do some basic checks. */
 static int prepare_ext_ctrls(struct v4l2_ctrl_handler *hdl,
 struct v4l2_ext_controls *cs,
-struct ctrl_helper *helpers,
-bool try)
+struct ctrl_helper *helpers)
 {
u32 i;
 
@@ -1460,8 +1459,7 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
struct v4l2_ctrl *ctrl;
u32 id = c->id & V4L2_CTRL_ID_MASK;
 
-   if (try)
-   cs->error_idx = i;
+   cs->error_idx = i;
 
if (cs->ctrl_class && V4L2_CTRL_ID2CLASS(id) != cs->ctrl_class)
return -EINVAL;
@@ -1554,7 +1552,8 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
return -ENOMEM;
}
 
-   ret = prepare_ext_ctrls(hdl, cs, helpers, false);
+   ret = prepare_ext_ctrls(hdl, cs, helpers);
+   cs->error_idx = cs->count;
 
for (i = 0; !ret && i < cs->count; i++)
if (helpers[i].ctrl->flags & V4L2_CTRL_FLAG_WRITE_ONLY)
@@ -1701,12 +1700,10 @@ static int try_or_set_ext_ctrls(struct 
v4l2_ctrl_handler *hdl,
unsigned i, j;
int ret = 0;
 
-   cs->error_idx = cs->count;
for (i = 0; i < cs->count; i++) {
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
 
-   if (!set)
-   cs->error_idx = i;
+   cs->error_idx = i;
 
if (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY)
return -EACCES;
@@ -1724,11 +1721,10 @@ static int try_or_set_ext_ctrls(struct 
v4l2_ctrl_handler *hdl,
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
struct v4l2_ctrl *master = ctrl->cluster[0];
 
-   cs->error_idx = i;
-
if (helpers[i].handled)
continue;
 
+   cs->error_idx = i;
v4l2_ctrl_lock(ctrl);
 
/* Reset the 'is_new' flags of the cluster */
@@ -1777,12 +1773,11 @@ static int try_set_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
if (!helpers)
return -ENOMEM;
}
-   ret = prepare_ext_ctrls(hdl, cs, helpers, !set);
-   if (ret)
-   goto free;
+   ret = prepare_ext_ctrls(hdl, cs, helpers);
 
/* First 'try' all controls and abort on error */
-   ret = try_or_set_ext_ctrls(hdl, cs, helpers, false);
+   if (!ret)
+   ret = try_or_set_ext_ctrls(hdl, cs, helpers, false);
/* If this is a 'set' operation and the initial 'try' failed,
   then set error_idx to count to tell the application that no
   controls changed value yet. */
@@ -1795,7 +1790,6 @@ static int try_set_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
ret = try_or_set_ext_ctrls(hdl, cs, helpers, true);
}
 
-free:
if (cs->count > ARRAY_SIZE(helper))
kfree(helpers);
return ret;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 08/18] v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios

[Hans Verkuil]

From: Hans Verkuil 

It is a bit tricky to handle autogain/gain type scenerios correctly. Such
controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on
the autofoo controls. In addition, the manual controls should be marked
inactive when the automatic mode is on, and active when the manual mode is on.
This also requires specialized volatile handling.

The chances of drivers doing all these things correctly are pretty remote.
So a new v4l2_ctrl_auto_cluster function was added that takes care of these
issues.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |   69 +++--
 include/media/v4l2-ctrls.h   |   45 
 2 files changed, 102 insertions(+), 12 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index a46d5c1..c39ab0c 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -39,6 +39,20 @@ struct ctrl_helper {
bool handled;
 };
 
+/* Small helper function to determine if the autocluster is set to manual
+   mode. In that case the is_volatile flag should be ignored. */
+static bool is_cur_manual(const struct v4l2_ctrl *master)
+{
+   return master->is_auto && master->cur.val == master->manual_mode_value;
+}
+
+/* Same as above, but this checks the against the new value instead of the
+   current value. */
+static bool is_new_manual(const struct v4l2_ctrl *master)
+{
+   return master->is_auto && master->val == master->manual_mode_value;
+}
+
 /* Returns NULL or a character pointer array containing the menu for
the given control ID. The pointer array ends with a NULL pointer.
An empty string signifies a menu entry that is invalid. This allows
@@ -643,7 +657,7 @@ static int ctrl_is_volatile(struct v4l2_ext_control *c,
 }
 
 /* Copy the new value to the current value. */
-static void new_to_cur(struct v4l2_ctrl *ctrl)
+static void new_to_cur(struct v4l2_ctrl *ctrl, bool update_inactive)
 {
if (ctrl == NULL)
return;
@@ -659,6 +673,11 @@ static void new_to_cur(struct v4l2_ctrl *ctrl)
ctrl->cur.val = ctrl->val;
break;
}
+   if (update_inactive) {
+   ctrl->flags &= ~V4L2_CTRL_FLAG_INACTIVE;
+   if (!is_cur_manual(ctrl->cluster[0]))
+   ctrl->flags |= V4L2_CTRL_FLAG_INACTIVE;
+   }
 }
 
 /* Copy the current value to the new value */
@@ -1166,7 +1185,7 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
v4l2_ctrl **controls)
int i;
 
/* The first control is the master control and it must not be NULL */
-   BUG_ON(controls[0] == NULL);
+   BUG_ON(ncontrols == 0 || controls[0] == NULL);
 
for (i = 0; i < ncontrols; i++) {
if (controls[i]) {
@@ -1177,6 +1196,28 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct 
v4l2_ctrl **controls)
 }
 EXPORT_SYMBOL(v4l2_ctrl_cluster);
 
+void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
+   u8 manual_val, bool set_volatile)
+{
+   struct v4l2_ctrl *master = controls[0];
+   u32 flag;
+   int i;
+
+   v4l2_ctrl_cluster(ncontrols, controls);
+   WARN_ON(ncontrols <= 1);
+   master->is_auto = true;
+   master->manual_mode_value = manual_val;
+   master->flags |= V4L2_CTRL_FLAG_UPDATE;
+   flag = is_cur_manual(master) ? 0 : V4L2_CTRL_FLAG_INACTIVE;
+
+   for (i = 1; i < ncontrols; i++)
+   if (controls[i]) {
+   controls[i]->is_volatile = set_volatile;
+   controls[i]->flags |= flag;
+   }
+}
+EXPORT_SYMBOL(v4l2_ctrl_auto_cluster);
+
 /* Activate/deactivate a control. */
 void v4l2_ctrl_activate(struct v4l2_ctrl *ctrl, bool active)
 {
@@ -1595,7 +1636,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
ctrl_is_volatile);
 
/* g_volatile_ctrl will update the new control values */
-   if (has_volatiles) {
+   if (has_volatiles && !is_cur_manual(master)) {
for (j = 0; j < master->ncontrols; j++)
cur_to_new(master->cluster[j]);
ret = call_op(master, g_volatile_ctrl);
@@ -1633,7 +1674,7 @@ static int get_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
 
v4l2_ctrl_lock(master);
/* g_volatile_ctrl will update the current control values */
-   if (ctrl->is_volatile) {
+   if (ctrl->is_volatile && !is_cur_manual(master)) {
for (i = 0; i < master->ncontrols; i++)
cur_to_new(master->cluster[i]);
ret = call_op(master, g_volatile_ctrl);
@@ -1678,6 +1719,7 @@ EXPORT_SYMBOL(v4l2_ctrl_g_ctrl);
Must be called with ctrl->handler->lock held. */
 static int try_or_set_control_cluster(struct v4l2_ctrl *master, bool set)
 {

[RFCv3 PATCH 12/18] vb2_poll: don't start DMA, leave that to the first read().

[Hans Verkuil]

From: Hans Verkuil 

The vb2_poll function would start read-DMA if called without any streaming
in progress. This unfortunately does not work if the application just wants
to poll for exceptions. This information of what the application is polling
for is sadly unavailable in the driver.

Andy Walls suggested to just return POLLIN | POLLRDNORM and let the first
call to read() start the DMA. This initial read() call will return EAGAIN
since no actual data is available yet, but it does start the DMA.

Applications must handle EAGAIN in any case since there can be other reasons
for EAGAIN as well.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/videobuf2-core.c |   17 +++--
 1 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index 6ba1461..ad75c95 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1372,27 +1372,16 @@ static int __vb2_cleanup_fileio(struct vb2_queue *q);
 unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
 {
unsigned long flags;
-   unsigned int ret;
struct vb2_buffer *vb = NULL;
 
/*
 * Start file I/O emulator only if streaming API has not been used yet.
 */
if (q->num_buffers == 0 && q->fileio == NULL) {
-   if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ)) {
-   ret = __vb2_init_fileio(q, 1);
-   if (ret)
-   return POLLERR;
-   }
-   if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE)) {
-   ret = __vb2_init_fileio(q, 0);
-   if (ret)
-   return POLLERR;
-   /*
-* Write to OUTPUT queue can be done immediately.
-*/
+   if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ))
+   return POLLIN | POLLRDNORM;
+   if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE))
return POLLOUT | POLLWRNORM;
-   }
}
 
/*
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 16/18] vivi: support control events.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/vivi.c |   28 ++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 6e62ddf..f4f599a 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define VIVI_MODULE_NAME "vivi"
@@ -983,12 +984,26 @@ static int vidioc_s_input(struct file *file, void *priv, 
unsigned int i)
if (i >= NUM_INPUTS)
return -EINVAL;
 
+   if (i == dev->input)
+   return 0;
+
dev->input = i;
precalculate_bars(dev);
precalculate_line(dev);
return 0;
 }
 
+static int vidioc_subscribe_event(struct v4l2_fh *fh,
+   struct v4l2_event_subscription *sub)
+{
+   switch (sub->type) {
+   case V4L2_EVENT_CTRL:
+   return v4l2_ctrl_subscribe_fh(fh, sub, 0);
+   default:
+   return -EINVAL;
+   }
+}
+
 /* --- controls -- */
 
 static int vivi_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
@@ -1027,10 +1042,17 @@ static unsigned int
 vivi_poll(struct file *file, struct poll_table_struct *wait)
 {
struct vivi_dev *dev = video_drvdata(file);
+   struct v4l2_fh *fh = file->private_data;
struct vb2_queue *q = &dev->vb_vidq;
+   unsigned int res;
 
dprintk(dev, 1, "%s\n", __func__);
-   return vb2_poll(q, file, wait);
+   res = vb2_poll(q, file, wait);
+   if (v4l2_event_pending(fh))
+   res |= POLLPRI;
+   else
+   poll_wait(file, &fh->events->wait, wait);
+   return res;
 }
 
 static int vivi_close(struct file *file)
@@ -1137,7 +1159,7 @@ static const struct v4l2_ctrl_config vivi_ctrl_string = {
 
 static const struct v4l2_file_operations vivi_fops = {
.owner  = THIS_MODULE,
-   .open   = v4l2_fh_open,
+   .open   = v4l2_fh_open,
.release= vivi_close,
.read   = vivi_read,
.poll   = vivi_poll,
@@ -1161,6 +1183,8 @@ static const struct v4l2_ioctl_ops vivi_ioctl_ops = {
.vidioc_s_input   = vidioc_s_input,
.vidioc_streamon  = vidioc_streamon,
.vidioc_streamoff = vidioc_streamoff,
+   .vidioc_subscribe_event = vidioc_subscribe_event,
+   .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
 };
 
 static struct video_device vivi_template = {
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 13/18] v4l2-ctrls: add control events.

[Hans Verkuil]

From: Hans Verkuil 

Whenever a control changes value or state an event is sent to anyone
that subscribed to it.

This functionality is useful for control panels but also for applications
that need to wait for (usually status) controls to change value.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |  115 --
 drivers/media/video/v4l2-event.c |  130 +++--
 drivers/media/video/v4l2-fh.c|4 +-
 include/linux/videodev2.h|   29 -
 include/media/v4l2-ctrls.h   |   23 +--
 include/media/v4l2-event.h   |2 +
 6 files changed, 253 insertions(+), 50 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index a38bdf9..99987fe 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define has_op(master, op) \
@@ -556,6 +557,41 @@ static bool type_is_int(const struct v4l2_ctrl *ctrl)
}
 }
 
+static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32 
changes)
+{
+   memset(ev->reserved, 0, sizeof(ev->reserved));
+   ev->type = V4L2_EVENT_CTRL;
+   ev->id = ctrl->id;
+   ev->u.ctrl.changes = changes;
+   ev->u.ctrl.type = ctrl->type;
+   ev->u.ctrl.flags = ctrl->flags;
+   if (ctrl->type == V4L2_CTRL_TYPE_STRING)
+   ev->u.ctrl.value64 = 0;
+   else
+   ev->u.ctrl.value64 = ctrl->cur.val64;
+   ev->u.ctrl.minimum = ctrl->minimum;
+   ev->u.ctrl.maximum = ctrl->maximum;
+   if (ctrl->type == V4L2_CTRL_TYPE_MENU)
+   ev->u.ctrl.step = 1;
+   else
+   ev->u.ctrl.step = ctrl->step;
+   ev->u.ctrl.default_value = ctrl->default_value;
+}
+
+static void send_event(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32 changes)
+{
+   struct v4l2_event ev;
+   struct v4l2_ctrl_fh *pos;
+
+   if (list_empty(&ctrl->fhs))
+   return;
+   fill_event(&ev, ctrl, changes);
+
+   list_for_each_entry(pos, &ctrl->fhs, node)
+   if (pos->fh != fh)
+   v4l2_event_queue_fh(pos->fh, &ev);
+}
+
 /* Helper function: copy the current control value back to the caller */
 static int cur_to_user(struct v4l2_ext_control *c,
   struct v4l2_ctrl *ctrl)
@@ -660,17 +696,25 @@ static int ctrl_is_volatile(struct v4l2_ext_control *c,
 static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
bool update_inactive)
 {
+   bool changed = false;
+
if (ctrl == NULL)
return;
switch (ctrl->type) {
+   case V4L2_CTRL_TYPE_BUTTON:
+   changed = true;
+   break;
case V4L2_CTRL_TYPE_STRING:
/* strings are always 0-terminated */
+   changed = strcmp(ctrl->string, ctrl->cur.string);
strcpy(ctrl->cur.string, ctrl->string);
break;
case V4L2_CTRL_TYPE_INTEGER64:
+   changed = ctrl->val64 != ctrl->cur.val64;
ctrl->cur.val64 = ctrl->val64;
break;
default:
+   changed = ctrl->val != ctrl->cur.val;
ctrl->cur.val = ctrl->val;
break;
}
@@ -679,6 +723,10 @@ static void new_to_cur(struct v4l2_fh *fh, struct 
v4l2_ctrl *ctrl,
if (!is_cur_manual(ctrl->cluster[0]))
ctrl->flags |= V4L2_CTRL_FLAG_INACTIVE;
}
+   if (changed || update_inactive)
+   send_event(fh, ctrl,
+   (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) |
+   (update_inactive ? V4L2_EVENT_CTRL_CH_FLAGS : 0));
 }
 
 /* Copy the current value to the new value */
@@ -819,6 +867,7 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
 {
struct v4l2_ctrl_ref *ref, *next_ref;
struct v4l2_ctrl *ctrl, *next_ctrl;
+   struct v4l2_ctrl_fh *ctrl_fh, *next_ctrl_fh;
 
if (hdl == NULL || hdl->buckets == NULL)
return;
@@ -832,6 +881,10 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
/* Free all controls owned by the handler */
list_for_each_entry_safe(ctrl, next_ctrl, &hdl->ctrls, node) {
list_del(&ctrl->node);
+   list_for_each_entry_safe(ctrl_fh, next_ctrl_fh, &ctrl->fhs, 
node) {
+   list_del(&ctrl_fh->node);
+   kfree(ctrl_fh);
+   }
kfree(ctrl);
}
kfree(hdl->buckets);
@@ -1030,6 +1083,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
}
 
INIT_LIST_HEAD(&ctrl->node);
+   INIT_LIST_HEAD(&ctrl->fhs);
ctrl->handler = hdl;
ctrl->ops = ops;
ctrl->id = id;
@@ -1171,6 +1225,9 @@ int v4l2_ctrl_add_handler(struct v4l2_c

[RFCv3 PATCH 11/18] v4l2-ctrls: add v4l2_fh pointer to the set control functions.

[Hans Verkuil]

From: Hans Verkuil 

When an application changes a control you want to generate an event.
However, you want to avoid sending such an event back to the application
(file handle) that caused the change.

Add the filehandle to the various set control functions.

The filehandle isn't used yet, but the control event patches will need
this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c  |   45 
 drivers/media/video/v4l2-ioctl.c  |8 +++---
 drivers/media/video/v4l2-subdev.c |4 +-
 include/media/v4l2-ctrls.h|8 --
 4 files changed, 36 insertions(+), 29 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index c39ab0c..a38bdf9 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -657,7 +657,8 @@ static int ctrl_is_volatile(struct v4l2_ext_control *c,
 }
 
 /* Copy the new value to the current value. */
-static void new_to_cur(struct v4l2_ctrl *ctrl, bool update_inactive)
+static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
+   bool update_inactive)
 {
if (ctrl == NULL)
return;
@@ -1717,7 +1718,8 @@ EXPORT_SYMBOL(v4l2_ctrl_g_ctrl);
 /* Core function that calls try/s_ctrl and ensures that the new value is
copied to the current value on a set.
Must be called with ctrl->handler->lock held. */
-static int try_or_set_control_cluster(struct v4l2_ctrl *master, bool set)
+static int try_or_set_control_cluster(struct v4l2_fh *fh,
+   struct v4l2_ctrl *master, bool set)
 {
bool update_flag;
bool try = !set;
@@ -1768,12 +1770,13 @@ static int try_or_set_control_cluster(struct v4l2_ctrl 
*master, bool set)
 
update_flag = is_cur_manual(master) != is_new_manual(master);
for (i = 0; i < master->ncontrols; i++)
-   new_to_cur(master->cluster[i], update_flag && i > 0);
+   new_to_cur(fh, master->cluster[i], update_flag && i > 0);
return 0;
 }
 
 /* Try or set controls. */
-static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
+   struct v4l2_ctrl_handler *hdl,
struct v4l2_ext_controls *cs,
struct ctrl_helper *helpers,
bool set)
@@ -1818,7 +1821,7 @@ static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
ret = cluster_walk(i, cs, helpers, user_to_new);
 
if (!ret)
-   ret = try_or_set_control_cluster(master, set);
+   ret = try_or_set_control_cluster(fh, master, set);
 
/* Copy the new values back to userspace. */
if (!ret)
@@ -1831,7 +1834,7 @@ static int try_or_set_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
 }
 
 /* Try or try-and-set controls */
-static int try_set_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
 struct v4l2_ext_controls *cs,
 bool set)
 {
@@ -1858,7 +1861,7 @@ static int try_set_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
 
/* First 'try' all controls and abort on error */
if (!ret)
-   ret = try_or_set_ext_ctrls(hdl, cs, helpers, false);
+   ret = try_or_set_ext_ctrls(NULL, hdl, cs, helpers, false);
/* If this is a 'set' operation and the initial 'try' failed,
   then set error_idx to count to tell the application that no
   controls changed value yet. */
@@ -1868,7 +1871,7 @@ static int try_set_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
/* Reset 'handled' state */
for (i = 0; i < cs->count; i++)
helpers[i].handled = false;
-   ret = try_or_set_ext_ctrls(hdl, cs, helpers, true);
+   ret = try_or_set_ext_ctrls(fh, hdl, cs, helpers, true);
}
 
if (cs->count > ARRAY_SIZE(helper))
@@ -1878,30 +1881,31 @@ static int try_set_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
 
 int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls 
*cs)
 {
-   return try_set_ext_ctrls(hdl, cs, false);
+   return try_set_ext_ctrls(NULL, hdl, cs, false);
 }
 EXPORT_SYMBOL(v4l2_try_ext_ctrls);
 
-int v4l2_s_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls 
*cs)
+int v4l2_s_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
+   struct v4l2_ext_controls *cs)
 {
-   return try_set_ext_ctrls(hdl, cs, true);
+   return try_set_ext_ctrls(fh, hdl, cs, true);
 }
 EXPORT_SYMBOL(v4l2_s_ext_ctrls);
 
 int v4l2_subdev_try_ext_ctrls(struct v4l2_subdev *sd, struct v4l2_ext_controls 
*cs)
 {
-   return try_set_ext_ctrls(sd->ctrl_handler,

[RFCv3 PATCH 17/18] ivtv: add control event support.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/ivtv/ivtv-fileops.c |   34 +-
 drivers/media/video/ivtv/ivtv-ioctl.c   |2 +
 2 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-fileops.c 
b/drivers/media/video/ivtv/ivtv-fileops.c
index a7f54b0..75c0354 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -750,31 +750,27 @@ unsigned int ivtv_v4l2_enc_poll(struct file *filp, 
poll_table * wait)
struct ivtv *itv = id->itv;
struct ivtv_stream *s = &itv->streams[id->type];
int eof = test_bit(IVTV_F_S_STREAMOFF, &s->s_flags);
+   unsigned res = 0;
 
-   /* Start a capture if there is none */
-   if (!eof && !test_bit(IVTV_F_S_STREAMING, &s->s_flags)) {
-   int rc;
+   IVTV_DEBUG_HI_FILE("Encoder poll\n");
 
-   mutex_lock(&itv->serialize_lock);
-   rc = ivtv_start_capture(id);
-   mutex_unlock(&itv->serialize_lock);
-   if (rc) {
-   IVTV_DEBUG_INFO("Could not start capture for %s (%d)\n",
-   s->name, rc);
-   return POLLERR;
-   }
-   IVTV_DEBUG_FILE("Encoder poll started capture\n");
-   }
+   /* Start a capture if there is none */
+   if (!eof && !test_bit(IVTV_F_S_STREAMING, &s->s_flags))
+   res = POLLIN | POLLRDNORM;
 
-   /* add stream's waitq to the poll list */
-   IVTV_DEBUG_HI_FILE("Encoder poll\n");
-   poll_wait(filp, &s->waitq, wait);
+   if (v4l2_event_pending(&id->fh))
+   res |= POLLPRI;
+   else
+   poll_wait(filp, &id->fh.events->wait, wait);
 
if (s->q_full.length || s->q_io.length)
-   return POLLIN | POLLRDNORM;
+   return res | POLLIN | POLLRDNORM;
if (eof)
-   return POLLHUP;
-   return 0;
+   return res | POLLHUP;
+
+   /* add stream's waitq to the poll list */
+   poll_wait(filp, &s->waitq, wait);
+   return res;
 }
 
 void ivtv_stop_capture(struct ivtv_open_id *id, int gop_end)
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c 
b/drivers/media/video/ivtv/ivtv-ioctl.c
index 1689783..a81b4be 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -1445,6 +1445,8 @@ static int ivtv_subscribe_event(struct v4l2_fh *fh, 
struct v4l2_event_subscripti
case V4L2_EVENT_VSYNC:
case V4L2_EVENT_EOS:
break;
+   case V4L2_EVENT_CTRL:
+   return v4l2_ctrl_subscribe_fh(fh, sub, 0);
default:
return -EINVAL;
}
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 15/18] V4L2 spec: document control events.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   17 +++-
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |  142 +++-
 2 files changed, 157 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 4e0a7cc..b8c4f76 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -81,6 +81,13 @@
  
  

+   &v4l2-event-ctrl;
+ctrl
+   Event data for event V4L2_EVENT_CTRL.
+
+ 
+ 
+   
__u8
 data[64]
Event data. Defined by the event type. The union
@@ -110,8 +117,16 @@
Event timestamp.
  
  
+   u32
+   id
+
+   The ID associated with the event source. If the event does 
not
+   have an associated ID (this depends on the event type), then 
this
+   is 0.
+ 
+ 
__u32
-   reserved[9]
+   reserved[8]
 
Reserved for future extensions. Drivers must set
the array to zero.
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 8b50179..975f603 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -64,7 +64,19 @@
  
  
__u32
-   reserved[7]
+   id
+   ID of the event source. If there is no ID associated with
+   the event source, then set this to 0. Whether or not an event
+   needs an ID depends on the event type.
+ 
+ 
+   __u32
+   flags
+   Event flags, see .
+ 
+ 
+   __u32
+   reserved[5]
Reserved for future extensions. Drivers and applications
must set the array to zero.
  
@@ -100,6 +112,23 @@

  
  
+   V4L2_EVENT_CTRL
+   3
+   This event requires that the id
+   matches the control ID from which you want to receive events.
+   This event is triggered if the control's value changes, if a
+   button control is pressed or if the control's flags change.
+   This event has &v4l2-event-ctrl; associated with it. This struct
+   contains much of the same information as &v4l2-queryctrl; and
+   &v4l2-control;.
+
+   If the event is generated due to a call to &VIDIOC-S-CTRL; or
+   &VIDIOC-S-EXT-CTRLS;, then the event will not be sent to
+   the file handle that called the ioctl function. This prevents
+   nasty feedback loops.
+   
+ 
+ 
V4L2_EVENT_PRIVATE_START
0x0800
Base event number for driver-private events.
@@ -108,6 +137,23 @@
   
 
 
+
+  Event Flags
+  
+   &cs-def;
+   
+ 
+   V4L2_EVENT_SUB_FL_SEND_INITIAL
+   0x0001
+   When this event is subscribed an initial event will be sent
+   containing the current status. This only makes sense for events
+   that are triggered by a status change. Other events will ignore
+   this flag.
+ 
+   
+  
+
+
 
   struct v4l2_event_vsync
   
@@ -122,6 +168,100 @@
   
 
 
+
+  struct v4l2_event_ctrl
+  
+   &cs-str;
+   
+ 
+   __u32
+   changes
+   
+   A bitmask that tells what has changed. See .
+ 
+ 
+   __u32
+   type
+   
+   The type of the control. See &v4l2-ctrl-type;.
+ 
+ 
+   union (anonymous)
+   
+   
+   
+ 
+ 
+   
+   __s32
+   value
+   The 32-bit value of the control for 32-bit control types.
+   This is 0 for string controls since the value of a string
+   cannot be passed using &VIDIOC-DQEVENT;.
+ 
+ 
+   
+   __s64
+   value64
+   The 64-bit value of the control for 64-bit control 
types.
+ 
+ 
+   __u32
+   flags
+   
+   The control flags. See .
+ 
+ 
+   __s32
+   minimum
+   
+   The minimum value of the control. See 
&v4l2-queryctrl;.
+ 
+ 
+   __s32
+   maximum
+   
+   The maximum value of the control. See 
&v4l2-queryctrl;.
+ 
+ 
+   __s32
+   step
+   
+ 

[RFCv3 PATCH 18/18] v4l2-compat-ioctl32: add VIDIOC_DQEVENT support.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-compat-ioctl32.c |   37 +
 kernel/compat.c   |1 +
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
b/drivers/media/video/v4l2-compat-ioctl32.c
index 7c26947..61979b7 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -662,6 +662,32 @@ static int put_v4l2_ext_controls32(struct 
v4l2_ext_controls *kp, struct v4l2_ext
return 0;
 }
 
+struct v4l2_event32 {
+   __u32   type;
+   union {
+   __u8data[64];
+   } u;
+   __u32   pending;
+   __u32   sequence;
+   struct compat_timespec  timestamp;
+   __u32   id;
+   __u32   reserved[8];
+};
+
+static int put_v4l2_event32(struct v4l2_event *kp, struct v4l2_event32 __user 
*up)
+{
+   if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_event32)) ||
+   put_user(kp->type, &up->type) ||
+   copy_to_user(&up->u, &kp->u, sizeof(kp->u)) ||
+   put_user(kp->pending, &up->pending) ||
+   put_user(kp->sequence, &up->sequence) ||
+   put_compat_timespec(&kp->timestamp, &up->timestamp) ||
+   put_user(kp->id, &up->id) ||
+   copy_to_user(up->reserved, kp->reserved, 8 * sizeof(__u32)))
+   return -EFAULT;
+   return 0;
+}
+
 #define VIDIOC_G_FMT32 _IOWR('V',  4, struct v4l2_format32)
 #define VIDIOC_S_FMT32 _IOWR('V',  5, struct v4l2_format32)
 #define VIDIOC_QUERYBUF32  _IOWR('V',  9, struct v4l2_buffer32)
@@ -675,6 +701,7 @@ static int put_v4l2_ext_controls32(struct v4l2_ext_controls 
*kp, struct v4l2_ext
 #define VIDIOC_G_EXT_CTRLS32_IOWR('V', 71, struct v4l2_ext_controls32)
 #define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
 #define VIDIOC_TRY_EXT_CTRLS32  _IOWR('V', 73, struct v4l2_ext_controls32)
+#defineVIDIOC_DQEVENT32_IOR ('V', 89, struct v4l2_event32)
 
 #define VIDIOC_OVERLAY32   _IOW ('V', 14, s32)
 #define VIDIOC_STREAMON32  _IOW ('V', 18, s32)
@@ -693,6 +720,7 @@ static long do_video_ioctl(struct file *file, unsigned int 
cmd, unsigned long ar
struct v4l2_input v2i;
struct v4l2_standard v2s;
struct v4l2_ext_controls v2ecs;
+   struct v4l2_event v2ev;
unsigned long vx;
int vi;
} karg;
@@ -715,6 +743,7 @@ static long do_video_ioctl(struct file *file, unsigned int 
cmd, unsigned long ar
case VIDIOC_G_EXT_CTRLS32: cmd = VIDIOC_G_EXT_CTRLS; break;
case VIDIOC_S_EXT_CTRLS32: cmd = VIDIOC_S_EXT_CTRLS; break;
case VIDIOC_TRY_EXT_CTRLS32: cmd = VIDIOC_TRY_EXT_CTRLS; break;
+   case VIDIOC_DQEVENT32: cmd = VIDIOC_DQEVENT; break;
case VIDIOC_OVERLAY32: cmd = VIDIOC_OVERLAY; break;
case VIDIOC_STREAMON32: cmd = VIDIOC_STREAMON; break;
case VIDIOC_STREAMOFF32: cmd = VIDIOC_STREAMOFF; break;
@@ -778,6 +807,9 @@ static long do_video_ioctl(struct file *file, unsigned int 
cmd, unsigned long ar
err = get_v4l2_ext_controls32(&karg.v2ecs, up);
compatible_arg = 0;
break;
+   case VIDIOC_DQEVENT:
+   compatible_arg = 0;
+   break;
}
if (err)
return err;
@@ -818,6 +850,10 @@ static long do_video_ioctl(struct file *file, unsigned int 
cmd, unsigned long ar
err = put_v4l2_framebuffer32(&karg.v2fb, up);
break;
 
+   case VIDIOC_DQEVENT:
+   err = put_v4l2_event32(&karg.v2ev, up);
+   break;
+
case VIDIOC_G_FMT:
case VIDIOC_S_FMT:
case VIDIOC_TRY_FMT:
@@ -920,6 +956,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int 
cmd, unsigned long arg)
case VIDIOC_S_DV_TIMINGS:
case VIDIOC_G_DV_TIMINGS:
case VIDIOC_DQEVENT:
+   case VIDIOC_DQEVENT32:
case VIDIOC_SUBSCRIBE_EVENT:
case VIDIOC_UNSUBSCRIBE_EVENT:
ret = do_video_ioctl(file, cmd, arg);
diff --git a/kernel/compat.c b/kernel/compat.c
index fc9eb09..d4abc5b 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -158,6 +158,7 @@ int put_compat_timespec(const struct timespec *ts, struct 
compat_timespec __user
__put_user(ts->tv_sec, &cts->tv_sec) ||
__put_user(ts->tv_nsec, &cts->tv_nsec)) ? -EFAULT : 0;
 }
+EXPORT_SYMBOL_GPL(put_compat_timespec);
 
 static long compat_nanosleep_restart(struct restart_block *restart)
 {
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordom

[RFCv3 PATCH 14/18] v4l2-ctrls: simplify event subscription.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |   27 +++
 include/media/v4l2-ctrls.h   |   28 
 2 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 99987fe..bf649cf 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -862,6 +862,13 @@ int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
 }
 EXPORT_SYMBOL(v4l2_ctrl_handler_init);
 
+/* Count the number of controls */
+unsigned v4l2_ctrl_handler_cnt(const struct v4l2_ctrl_handler *hdl)
+{
+   return hdl ? hdl->nr_of_refs : 0;
+}
+EXPORT_SYMBOL(v4l2_ctrl_handler_cnt);
+
 /* Free all controls and control refs */
 void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
 {
@@ -1013,6 +1020,7 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
   insertion is an O(1) operation. */
if (list_empty(&hdl->ctrl_refs) || id > node2id(hdl->ctrl_refs.prev)) {
list_add_tail(&new_ref->node, &hdl->ctrl_refs);
+   hdl->nr_of_refs++;
goto insert_in_hash;
}
 
@@ -2061,3 +2069,22 @@ void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct 
v4l2_fh *fh)
v4l2_ctrl_unlock(ctrl);
 }
 EXPORT_SYMBOL(v4l2_ctrl_del_fh);
+
+int v4l2_ctrl_subscribe_fh(struct v4l2_fh *fh,
+   struct v4l2_event_subscription *sub, unsigned n)
+{
+   struct v4l2_ctrl_handler *hdl = fh->ctrl_handler;
+   int ret = 0;
+
+   if (!fh->events)
+   ret = v4l2_event_init(fh);
+   if (!ret) {
+   if (v4l2_ctrl_handler_cnt(hdl) * 2 > n)
+   n = v4l2_ctrl_handler_cnt(hdl) * 2;
+   ret = v4l2_event_alloc(fh, n);
+   }
+   if (!ret)
+   ret = v4l2_event_subscribe(fh, sub);
+   return ret;
+}
+EXPORT_SYMBOL(v4l2_ctrl_subscribe_fh);
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index c45bf40..72dafcf 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -169,6 +169,7 @@ struct v4l2_ctrl_ref {
   *control is needed multiple times, so this is a simple
   *optimization.
   * @buckets:  Buckets for the hashing. Allows for quick control lookup.
+  * @nr_of_refs: Total number of control references in the list.
   * @nr_of_buckets: Total number of buckets in the array.
   * @error:The error code of the first failed control addition.
   */
@@ -178,6 +179,7 @@ struct v4l2_ctrl_handler {
struct list_head ctrl_refs;
struct v4l2_ctrl_ref *cached;
struct v4l2_ctrl_ref **buckets;
+   u16 nr_of_refs;
u16 nr_of_buckets;
int error;
 };
@@ -263,6 +265,14 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
 int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler *hdl,
   unsigned nr_of_controls_hint);
 
+/** v4l2_ctrl_handler_cnt() - Count the number of controls in the handler.
+  * @hdl:  The control handler.
+  *
+  * Returns the number of controls referenced by this handler.
+  * Returns 0 if @hdl == NULL.
+  */
+unsigned v4l2_ctrl_handler_cnt(const struct v4l2_ctrl_handler *hdl);
+
 /** v4l2_ctrl_handler_free() - Free all controls owned by the handler and free
   * the control list.
   * @hdl:  The control handler.
@@ -494,11 +504,29 @@ s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
   */
 int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
 
+/* Internal helper functions that deal with control events. */
 void v4l2_ctrl_add_fh(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl_fh *ctrl_fh,
struct v4l2_event_subscription *sub);
 void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct v4l2_fh *fh);
 
+/** v4l2_ctrl_subscribe_fh() - Helper function that subscribes a control event.
+  * @fh:   The file handler that subscribed the control event.
+  * @sub:  The event to subscribe (type must be V4L2_EVENT_CTRL).
+  * @n:How many events should be allocated? (Passed to 
v4l2_event_alloc).
+  *Recommended to set to twice the number of controls plus whatever
+  *is needed for other events. This function will set n to
+  *max(n, 2 * v4l2_ctrl_handler_cnt(fh->ctrl_handler)).
+  *
+  * A helper function that initializes the fh for events, allocates the
+  * list of events and subscribes the control event.
+  *
+  * Typically called in the handler of VIDIOC_SUBSCRIBE_EVENT in the
+  * V4L2_EVENT_CTRL case.
+  */
+int v4l2_ctrl_subscribe_fh(struct v4l2_fh *fh,
+   struct v4l2_event_subscription *sub, unsigned n);
+
 /* Helpers for ioctl_ops. If hdl == NULL then they will all return -EINVAL. */
 int v4l2_queryctrl(struct v4l2_ctrl_handler *hdl, struct v4l2_queryctrl *qc);
 int v4l2_querymenu(struct v4l2_ctrl_handler *hdl, struct v4l2_querymenu *qm);
-- 
1.7

[RFCv3 PATCH 10/18] vivi: add autogain/gain support to test the autocluster functionality.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/vivi.c |   25 -
 1 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 2238a61..6e62ddf 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -167,6 +167,11 @@ struct vivi_dev {
struct v4l2_ctrl   *contrast;
struct v4l2_ctrl   *saturation;
struct v4l2_ctrl   *hue;
+   struct {
+   /* autogain/gain cluster */
+   struct v4l2_ctrl   *autogain;
+   struct v4l2_ctrl   *gain;
+   };
struct v4l2_ctrl   *volume;
struct v4l2_ctrl   *button;
struct v4l2_ctrl   *boolean;
@@ -457,6 +462,7 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct 
vivi_buffer *buf)
unsigned ms;
char str[100];
int h, line = 1;
+   s32 gain;
 
if (!vbuf)
return;
@@ -479,6 +485,7 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct 
vivi_buffer *buf)
dev->width, dev->height, dev->input);
gen_text(dev, vbuf, line++ * 16, 16, str);
 
+   gain = v4l2_ctrl_g_ctrl(dev->gain);
mutex_lock(&dev->ctrl_handler.lock);
snprintf(str, sizeof(str), " brightness %3d, contrast %3d, saturation 
%3d, hue %d ",
dev->brightness->cur.val,
@@ -486,7 +493,8 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct 
vivi_buffer *buf)
dev->saturation->cur.val,
dev->hue->cur.val);
gen_text(dev, vbuf, line++ * 16, 16, str);
-   snprintf(str, sizeof(str), " volume %3d ", dev->volume->cur.val);
+   snprintf(str, sizeof(str), " autogain %d, gain %3d, volume %3d ",
+   dev->autogain->cur.val, gain, dev->volume->cur.val);
gen_text(dev, vbuf, line++ * 16, 16, str);
snprintf(str, sizeof(str), " int32 %d, int64 %lld ",
dev->int32->cur.val,
@@ -983,6 +991,15 @@ static int vidioc_s_input(struct file *file, void *priv, 
unsigned int i)
 
 /* --- controls -- */
 
+static int vivi_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct vivi_dev *dev = container_of(ctrl->handler, struct vivi_dev, 
ctrl_handler);
+
+   if (ctrl == dev->autogain)
+   dev->gain->val = jiffies & 0xff;
+   return 0;
+}
+
 static int vivi_s_ctrl(struct v4l2_ctrl *ctrl)
 {
struct vivi_dev *dev = container_of(ctrl->handler, struct vivi_dev, 
ctrl_handler);
@@ -1045,6 +1062,7 @@ static int vivi_mmap(struct file *file, struct 
vm_area_struct *vma)
 }
 
 static const struct v4l2_ctrl_ops vivi_ctrl_ops = {
+   .g_volatile_ctrl = vivi_g_volatile_ctrl,
.s_ctrl = vivi_s_ctrl,
 };
 
@@ -1213,6 +1231,10 @@ static int __init vivi_create_instance(int inst)
V4L2_CID_SATURATION, 0, 255, 1, 127);
dev->hue = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
+   dev->autogain = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
+   V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
+   dev->gain = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
+   V4L2_CID_GAIN, 0, 255, 1, 100);
dev->button = v4l2_ctrl_new_custom(hdl, &vivi_ctrl_button, NULL);
dev->int32 = v4l2_ctrl_new_custom(hdl, &vivi_ctrl_int32, NULL);
dev->int64 = v4l2_ctrl_new_custom(hdl, &vivi_ctrl_int64, NULL);
@@ -1223,6 +1245,7 @@ static int __init vivi_create_instance(int inst)
ret = hdl->error;
goto unreg_dev;
}
+   v4l2_ctrl_auto_cluster(2, &dev->autogain, 0, true);
dev->v4l2_dev.ctrl_handler = hdl;
 
/* initialize locks */
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 09/18] DocBook: Improve cluster documentation and document the new autoclusters.

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 Documentation/video4linux/v4l2-controls.txt |   56 +++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/Documentation/video4linux/v4l2-controls.txt 
b/Documentation/video4linux/v4l2-controls.txt
index 95a3813..9346fc8 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -450,6 +450,25 @@ In the example above the following are equivalent for the 
VOLUME case:
ctrl == ctrl->cluster[AUDIO_CL_VOLUME] == 
state->audio_cluster[AUDIO_CL_VOLUME]
ctrl->cluster[AUDIO_CL_MUTE] == state->audio_cluster[AUDIO_CL_MUTE]
 
+In practice using cluster arrays like this becomes very tiresome. So instead
+the following equivalent method is used:
+
+   struct {
+   /* audio cluster */
+   struct v4l2_ctrl *volume;
+   struct v4l2_ctrl *mute;
+   };
+
+The anonymous struct is used to clearly 'cluster' these two control pointers,
+but it serves no other purpose. The effect is the same as creating an
+array with two control pointers. So you can just do:
+
+   state->volume = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
+   state->mute = v4l2_ctrl_new_std(&state->ctrl_handler, ...);
+   v4l2_ctrl_cluster(2, &state->volume);
+
+And in foo_s_ctrl you can use these pointers directly: state->mute->val.
+
 Note that controls in a cluster may be NULL. For example, if for some
 reason mute was never added (because the hardware doesn't support that
 particular feature), then mute will be NULL. So in that case we have a
@@ -472,6 +491,43 @@ controls, then the 'is_new' flag would be 1 for both 
controls.
 The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup().
 
 
+Handling autogain/gain-type Controls with Auto Clusters
+===
+
+A common type of control cluster is one that handles 'auto-foo/foo'-type
+controls. Typical examples are autogain/gain, autoexposure/exposure,
+autowhitebalance/red balance/blue balance. In all cases you have one controls
+that determines whether another control is handled automatically by the 
hardware,
+or whether it is under manual control from the user.
+
+If the cluster is in automatic mode, then the manual controls should be
+marked inactive. When the volatile controls are read the g_volatile_ctrl
+operation should return the value that the hardware's automatic mode set up
+automatically.
+
+If the cluster is put in manual mode, then the manual controls should become
+active again and the is_volatile flag should be ignored (so g_volatile_ctrl is
+no longer called while in manual mode).
+
+Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since
+changing that control affects the control flags of the manual controls.
+
+In order to simplify this a special variation of v4l2_ctrl_cluster was
+introduced:
+
+void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
+   u8 manual_val, bool set_volatile);
+
+The first two arguments are identical to v4l2_ctrl_cluster. The third argument
+tells the framework which value switches the cluster into manual mode. The
+last argument will optionally set the is_volatile flag for the non-auto 
controls.
+
+The first control of the cluster is assumed to be the 'auto' control.
+
+Using this function will ensure that you don't need to handle all the complex
+flag and volatile handling.
+
+
 VIDIOC_LOG_STATUS Support
 =
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 06/18] v4l2-ctrls: fix and improve volatile control handling.

[Hans Verkuil]

From: Hans Verkuil 

If you have a cluster of controls that is a mix of volatile and non-volatile
controls, then requesting the value of the volatile control would fail if the
master control of that cluster was non-volatile. The code assumed that the
volatile state of the master control was the same for all other controls in
the cluster.

This is now fixed.

In addition, it was clear from bugs in some drivers that it was confusing that
the ctrl->cur union had to be used in g_volatile_ctrl. Several drivers used the
'new' values instead. The framework was changed so that drivers now set the new
value instead of the current value.

This has an additional benefit as well: the volatile values are now only stored
in the 'new' value, leaving the current value alone. This is useful for
autofoo/foo control clusters where you want to have a 'foo' control act like a
volatile control if 'autofoo' is on, but as a normal control when it is off.

Since with this change the cur value is no longer overwritten when 
g_volatile_ctrl
is called, you can use it to remember the original 'foo' value. For example:

autofoo = 0, foo = 10 and foo is non-volatile.

Now autofoo is set to 1 and foo is marked volatile. Retrieving the foo value
will get the volatile value. Set autofoo back to 0, which marks foo as non-
volatile again, and retrieving foo will get the old current value of 10.

Signed-off-by: Hans Verkuil 
---
 drivers/media/radio/radio-wl1273.c  |2 +-
 drivers/media/radio/wl128x/fmdrv_v4l2.c |2 +-
 drivers/media/video/saa7115.c   |4 +-
 drivers/media/video/v4l2-ctrls.c|   52 ++-
 4 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 459f727..46cacf8 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1382,7 +1382,7 @@ static int wl1273_fm_g_volatile_ctrl(struct v4l2_ctrl 
*ctrl)
 
switch (ctrl->id) {
case  V4L2_CID_TUNE_ANTENNA_CAPACITOR:
-   ctrl->cur.val = wl1273_fm_get_tx_ctune(radio);
+   ctrl->val = wl1273_fm_get_tx_ctune(radio);
break;
 
default:
diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c 
b/drivers/media/radio/wl128x/fmdrv_v4l2.c
index 8701072..d50e5ac 100644
--- a/drivers/media/radio/wl128x/fmdrv_v4l2.c
+++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c
@@ -191,7 +191,7 @@ static int fm_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
 
switch (ctrl->id) {
case  V4L2_CID_TUNE_ANTENNA_CAPACITOR:
-   ctrl->cur.val = fm_tx_get_tune_cap_val(fmdev);
+   ctrl->val = fm_tx_get_tune_cap_val(fmdev);
break;
default:
fmwarn("%s: Unknown IOCTL: %d\n", __func__, ctrl->id);
diff --git a/drivers/media/video/saa7115.c b/drivers/media/video/saa7115.c
index 0db9092..f2ae405 100644
--- a/drivers/media/video/saa7115.c
+++ b/drivers/media/video/saa7115.c
@@ -757,8 +757,8 @@ static int saa711x_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_CHROMA_AGC:
/* chroma gain cluster */
-   if (state->agc->cur.val)
-   state->gain->cur.val =
+   if (state->agc->val)
+   state->gain->val =
saa711x_read(sd, R_0F_CHROMA_GAIN_CNTL) & 0x7f;
break;
}
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0b1b30f..a46d5c1 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -25,8 +25,10 @@
 #include 
 #include 
 
+#define has_op(master, op) \
+   (master->ops && master->ops->op)
 #define call_op(master, op) \
-   ((master->ops && master->ops->op) ? master->ops->op(master) : 0)
+   (has_op(master, op) ? master->ops->op(master) : 0)
 
 /* Internal temporary helper struct, one for each v4l2_ext_control */
 struct ctrl_helper {
@@ -626,6 +628,20 @@ static int new_to_user(struct v4l2_ext_control *c,
return 0;
 }
 
+static int ctrl_to_user(struct v4l2_ext_control *c,
+  struct v4l2_ctrl *ctrl)
+{
+   if (ctrl->is_volatile)
+   return new_to_user(c, ctrl);
+   return cur_to_user(c, ctrl);
+}
+
+static int ctrl_is_volatile(struct v4l2_ext_control *c,
+  struct v4l2_ctrl *ctrl)
+{
+   return ctrl->is_volatile;
+}
+
 /* Copy the new value to the current value. */
 static void new_to_cur(struct v4l2_ctrl *ctrl)
 {
@@ -1535,7 +1551,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
struct ctrl_helper helper[4];
struct ctrl_helper *helpers = helper;
int ret;
-   int i;
+   int i, j;
 
cs->error_idx = cs->count;
cs->ctrl_class = V4L2_CTRL_ID2CLASS(cs->ctrl_class);
@@ -1562,6 +1578,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,

[RFCv3 PATCH 03/18] v4l2-ctrls: drivers should be able to ignore the READ_ONLY flag

[Hans Verkuil]

From: Hans Verkuil 

When applications try to set READ_ONLY controls an error should
be returned. However, when drivers do that it should be accepted.

Those controls could reflect some driver status which the application
can't change but the driver obviously has to be able to change it.

This is needed among others for future HDMI status controls.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index d9e0439..0b1b30f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1826,9 +1826,6 @@ static int set_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
int ret;
int i;
 
-   if (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY)
-   return -EACCES;
-
v4l2_ctrl_lock(ctrl);
 
/* Reset the 'is_new' flags of the cluster */
@@ -1853,6 +1850,9 @@ int v4l2_s_ctrl(struct v4l2_ctrl_handler *hdl, struct 
v4l2_control *control)
if (ctrl == NULL || !type_is_int(ctrl))
return -EINVAL;
 
+   if (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY)
+   return -EACCES;
+
return set_ctrl(ctrl, &control->value);
 }
 EXPORT_SYMBOL(v4l2_s_ctrl);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 01/18] v4l2-ctrls: introduce call_op define

[Hans Verkuil]

From: Hans Verkuil 

Add the call_op define to safely call the control ops. This also allows
for controls without any ops such as the 'control class' controls.

Signed-off-by: Hans Verkuil 
---
 drivers/media/video/v4l2-ctrls.c |   19 +++
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..3f2a0c5 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 
+#define call_op(master, op) \
+   ((master->ops && master->ops->op) ? master->ops->op(master) : 0)
+
 /* Internal temporary helper struct, one for each v4l2_ext_control */
 struct ctrl_helper {
/* The control corresponding to the v4l2_ext_control ID field. */
@@ -1291,7 +1294,7 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler *hdl)
if (ctrl->type == V4L2_CTRL_TYPE_BUTTON ||
(ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY))
continue;
-   ret = master->ops->s_ctrl(master);
+   ret = call_op(master, s_ctrl);
if (ret)
break;
for (i = 0; i < master->ncontrols; i++)
@@ -1568,8 +1571,8 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
 
v4l2_ctrl_lock(master);
/* g_volatile_ctrl will update the current control values */
-   if (ctrl->is_volatile && master->ops->g_volatile_ctrl)
-   ret = master->ops->g_volatile_ctrl(master);
+   if (ctrl->is_volatile)
+   ret = call_op(master, g_volatile_ctrl);
/* If OK, then copy the current control values to the caller */
if (!ret)
ret = cluster_walk(i, cs, helpers, cur_to_user);
@@ -1600,8 +1603,8 @@ static int get_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
 
v4l2_ctrl_lock(master);
/* g_volatile_ctrl will update the current control values */
-   if (ctrl->is_volatile && master->ops->g_volatile_ctrl)
-   ret = master->ops->g_volatile_ctrl(master);
+   if (ctrl->is_volatile)
+   ret = call_op(master, g_volatile_ctrl);
*val = ctrl->cur.val;
v4l2_ctrl_unlock(master);
return ret;
@@ -1675,12 +1678,12 @@ static int try_or_set_control_cluster(struct v4l2_ctrl 
*master, bool set)
/* For larger clusters you have to call try_ctrl again to
   verify that the controls are still valid after the
   'cur_to_new' above. */
-   if (!ret && master->ops->try_ctrl && try)
-   ret = master->ops->try_ctrl(master);
+   if (!ret && try)
+   ret = call_op(master, try_ctrl);
 
/* Don't set if there is no change */
if (!ret && set && cluster_changed(master)) {
-   ret = master->ops->s_ctrl(master);
+   ret = call_op(master, s_ctrl);
/* If OK, then make the new values permanent. */
if (!ret)
for (i = 0; i < master->ncontrols; i++)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 PATCH 00/18] Add Control Event and autofoo/foo support

[Hans Verkuil]

This is the third (and hopefully last) patch series for control events
and autofoo/foo support. If there are no more major comments, then I will
post a pull request by the end of the week.

Main changes since the previous series:

- The original plan was to toggle the READ_ONLY flag for the manual controls
  in an autocluster if e.g. autogain was set to true. But that caused weird
  behavior, so it was changed to toggling the INACTIVE flag. See also this:
  http://www.spinics.net/lists/linux-media/msg33297.html for more background
  information regarding this decision.

  This decision also simplified some of the patches, so the v4l2_ctrl_flags
  and v4l2_ctrl_flags_lock functions in RFCv2 are no longer present in this v3.

- Added compat32 support for VIDIOC_DQEVENT. This turned out to be missing.

- Add control event support in ivtv.

- The vivi patches were cleaned up substantially. They contained some old
  stuff from earlier experiments. All that has been removed.

- Rebased everything on top of for_v3.1.

Once this is merged, then I want to look into allowing drivers to change
control values from interrupt context (this will only work for certain
types of controls) and to redo the event internals.

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 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code.

[Amber Jain]

Minor changes to remove the unused code from omap_vout driver.

Signed-off-by: Amber Jain 
Signed-off-by: Samreen 
---
 drivers/media/video/omap/omap_vout.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 25025a1..4aeea06 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1090,10 +1090,7 @@ static int vidioc_enum_fmt_vid_out_mplane(struct file 
*file, void *fh,
struct v4l2_fmtdesc *fmt)
 {
int index = fmt->index;
-   enum v4l2_buf_type type = fmt->type;
 
-   fmt->index = index;
-   fmt->type = type;
if (index >= NUM_OUTPUT_FORMATS)
return -EINVAL;
 
@@ -1268,10 +1265,7 @@ static int vidioc_enum_fmt_vid_overlay(struct file 
*file, void *fh,
struct v4l2_fmtdesc *fmt)
 {
int index = fmt->index;
-   enum v4l2_buf_type type = fmt->type;
 
-   fmt->index = index;
-   fmt->type = type;
if (index >= NUM_OUTPUT_FORMATS)
return -EINVAL;
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] V4L2: OMAP: VOUT: Changes for NV12 format support for OMAP4

[Amber Jain]

V4l2 side changes to add NV12 format supportted by OMAP4.

Signed-off-by: Amber Jain 
---
 drivers/media/video/omap/omap_vout.c|  113 ++-
 drivers/media/video/omap/omap_voutdef.h |3 +
 2 files changed, 99 insertions(+), 17 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index f0946ea..25025a1 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -138,6 +138,10 @@ const static struct v4l2_fmtdesc omap_formats[] = {
.description = "UYVY, packed",
.pixelformat = V4L2_PIX_FMT_UYVY,
},
+   {
+   .description = "NV12 - YUV420 format",
+   .pixelformat = V4L2_PIX_FMT_NV12,
+   },
 };
 
 #define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
@@ -185,12 +189,23 @@ static int omap_vout_try_format(struct 
v4l2_pix_format_mplane *pix_mp)
pix_mp->colorspace = V4L2_COLORSPACE_SRGB;
bpp = RGB32_BPP;
break;
+   case V4L2_PIX_FMT_NV12:
+   pix_mp->colorspace = V4L2_COLORSPACE_JPEG;
+   bpp = 1;
+   break;
}
 
for (i = 0; i < pix_mp->num_planes; ++i) {
int bpl = pix_mp->width * bpp;
-   pix_mp->plane_fmt[i].bytesperline = bpl;
+   pix_mp->plane_fmt[i].bytesperline = (bpl + PAGE_SIZE - 1) &
+   ~(PAGE_SIZE - 1);
+   bpl = pix_mp->plane_fmt[i].bytesperline;
+
pix_mp->plane_fmt[i].sizeimage = bpl * pix_mp->height;
+
+   /* :NOTE: NV12 has width bytes per line in both Y and UV 
sections */
+   if (V4L2_PIX_FMT_NV12 == pix_mp->pixelformat)
+   pix_mp->plane_fmt[i].sizeimage += 
pix_mp->plane_fmt[i].sizeimage >> 1;
}
 
return bpp;
@@ -292,6 +307,7 @@ static int omap_vout_calculate_offset(struct 
omap_vout_device *vout)
struct v4l2_pix_format_mplane *pix_mp = &vout->pix_mp;
int *cropped_offset = &vout->cropped_offset;
int ps = 2, line_length = 0;
+   u32 *cropped_uv_offset = &vout->cropped_uv_offset;
 
ovid = &vout->vid_info;
 
@@ -307,11 +323,17 @@ static int omap_vout_calculate_offset(struct 
omap_vout_device *vout)
ps = 4;
else if (V4L2_PIX_FMT_RGB24 == pix_mp->pixelformat)
ps = 3;
+   else if (V4L2_PIX_FMT_NV12 == pix_mp->pixelformat)
+   ps = 1;
 
vout->ps = ps;
 
*cropped_offset = (line_length * ps) *
crop->top + crop->left * ps;
+
+   if (V4L2_PIX_FMT_NV12 == pix_mp->pixelformat)
+   *cropped_uv_offset = (line_length * ps) *
+   (crop->top >> 1) + (crop->left & ~1) * ps;
}
 
v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "%s Offset:%x\n",
@@ -355,6 +377,9 @@ static int video_mode_to_dss_mode(struct omap_vout_device 
*vout)
case V4L2_PIX_FMT_BGR32:
mode = OMAP_DSS_COLOR_RGBX32;
break;
+   case V4L2_PIX_FMT_NV12:
+   mode = OMAP_DSS_COLOR_NV12;
+   break;
default:
mode = -EINVAL;
}
@@ -366,7 +391,7 @@ static int video_mode_to_dss_mode(struct omap_vout_device 
*vout)
  */
 int omapvid_setup_overlay(struct omap_vout_device *vout,
struct omap_overlay *ovl, int posx, int posy, int outw,
-   int outh, u32 addr)
+   int outh, u32 addr, u32 uv_addr)
 {
int ret = 0;
struct omap_overlay_info info;
@@ -400,7 +425,15 @@ int omapvid_setup_overlay(struct omap_vout_device *vout,
}
 
ovl->get_overlay_info(ovl, &info);
-   info.paddr = addr;
+
+   if (addr)
+   info.paddr = addr;
+
+   if (OMAP_DSS_COLOR_NV12 == vout->dss_mode)
+   info.p_uv_addr = uv_addr;
+   else
+   info.p_uv_addr = (u32) NULL;
+
info.vaddr = NULL;
info.width = cropwidth;
info.height = cropheight;
@@ -430,6 +463,9 @@ int omapvid_setup_overlay(struct omap_vout_device *vout,
info.pos_y, info.out_width, info.out_height, info.rotation_type,
info.screen_width);
 
+   v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "info.puvaddr=%x\n",
+   info.p_uv_addr);
+
ret = ovl->set_overlay_info(ovl, &info);
if (ret)
goto setup_ovl_err;
@@ -444,7 +480,7 @@ setup_ovl_err:
 /*
  * Initialize the overlay structure
  */
-int omapvid_init(struct omap_vout_device *vout, u32 addr)
+int omapvid_init(struct omap_vout_device *vout, u32 addr, u32 uv_addr)
 {
int ret = 0, i;
struct v4l2_window *win;
@@ -495,7 +531,7 @@ int omapvid_init(struct omap_vout_device *vout, u32 addr)
}
 
ret = omapvid_setup_overlay(vout

[PATCH 4/6] V4L2: OMAP: VOUT: Modifications to support 1-plane Multiplanar for RGB/YUYV formats

[Amber Jain]

The changes involved are to utilise the various structures of Multiplanar
framework.

Signed-off-by: Amber Jain 
Signed-off-by: Samreen 
---
 drivers/media/video/omap/omap_vout.c|  126 ---
 drivers/media/video/omap/omap_voutdef.h |1 +
 drivers/media/video/omap/omap_voutlib.c |   36 +-
 drivers/media/video/omap/omap_voutlib.h |6 +-
 4 files changed, 88 insertions(+), 81 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 70fb45e..f0946ea 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -145,50 +145,53 @@ const static struct v4l2_fmtdesc omap_formats[] = {
 /*
  * Try format
  */
-static int omap_vout_try_format(struct v4l2_pix_format *pix)
+static int omap_vout_try_format(struct v4l2_pix_format_mplane *pix_mp)
 {
-   int ifmt, bpp = 0;
+   int ifmt, bpp = 0, i = 0;
 
-   pix->height = clamp(pix->height, (u32)VID_MIN_HEIGHT,
+   pix_mp->height = clamp(pix_mp->height, (u32)VID_MIN_HEIGHT,
(u32)VID_MAX_HEIGHT);
-   pix->width = clamp(pix->width, (u32)VID_MIN_WIDTH, (u32)VID_MAX_WIDTH);
+   pix_mp->width = clamp(pix_mp->width, (u32)VID_MIN_WIDTH, 
(u32)VID_MAX_WIDTH);
 
for (ifmt = 0; ifmt < NUM_OUTPUT_FORMATS; ifmt++) {
-   if (pix->pixelformat == omap_formats[ifmt].pixelformat)
+   if (pix_mp->pixelformat == omap_formats[ifmt].pixelformat)
break;
}
 
if (ifmt == NUM_OUTPUT_FORMATS)
ifmt = 0;
 
-   pix->pixelformat = omap_formats[ifmt].pixelformat;
-   pix->field = V4L2_FIELD_ANY;
-   pix->priv = 0;
+   pix_mp->pixelformat = omap_formats[ifmt].pixelformat;
+   pix_mp->field = V4L2_FIELD_ANY;
 
-   switch (pix->pixelformat) {
+   switch (pix_mp->pixelformat) {
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
default:
-   pix->colorspace = V4L2_COLORSPACE_JPEG;
+   pix_mp->colorspace = V4L2_COLORSPACE_JPEG;
bpp = YUYV_BPP;
break;
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB565X:
-   pix->colorspace = V4L2_COLORSPACE_SRGB;
+   pix_mp->colorspace = V4L2_COLORSPACE_SRGB;
bpp = RGB565_BPP;
break;
case V4L2_PIX_FMT_RGB24:
-   pix->colorspace = V4L2_COLORSPACE_SRGB;
+   pix_mp->colorspace = V4L2_COLORSPACE_SRGB;
bpp = RGB24_BPP;
break;
case V4L2_PIX_FMT_RGB32:
case V4L2_PIX_FMT_BGR32:
-   pix->colorspace = V4L2_COLORSPACE_SRGB;
+   pix_mp->colorspace = V4L2_COLORSPACE_SRGB;
bpp = RGB32_BPP;
break;
}
-   pix->bytesperline = pix->width * bpp;
-   pix->sizeimage = pix->bytesperline * pix->height;
+
+   for (i = 0; i < pix_mp->num_planes; ++i) {
+   int bpl = pix_mp->width * bpp;
+   pix_mp->plane_fmt[i].bytesperline = bpl;
+   pix_mp->plane_fmt[i].sizeimage = bpl * pix_mp->height;
+   }
 
return bpp;
 }
@@ -286,7 +289,7 @@ static int omap_vout_calculate_offset(struct 
omap_vout_device *vout)
 {
struct omapvideo_info *ovid;
struct v4l2_rect *crop = &vout->crop;
-   struct v4l2_pix_format *pix = &vout->pix;
+   struct v4l2_pix_format_mplane *pix_mp = &vout->pix_mp;
int *cropped_offset = &vout->cropped_offset;
int ps = 2, line_length = 0;
 
@@ -295,14 +298,14 @@ static int omap_vout_calculate_offset(struct 
omap_vout_device *vout)
if (ovid->rotation_type == VOUT_ROT_VRFB) {
omap_vout_calculate_vrfb_offset(vout);
} else {
-   vout->line_length = line_length = pix->width;
+   vout->line_length = line_length = pix_mp->width;
 
-   if (V4L2_PIX_FMT_YUYV == pix->pixelformat ||
-   V4L2_PIX_FMT_UYVY == pix->pixelformat)
+   if (V4L2_PIX_FMT_YUYV == pix_mp->pixelformat ||
+   V4L2_PIX_FMT_UYVY == pix_mp->pixelformat)
ps = 2;
-   else if (V4L2_PIX_FMT_RGB32 == pix->pixelformat)
+   else if (V4L2_PIX_FMT_RGB32 == pix_mp->pixelformat)
ps = 4;
-   else if (V4L2_PIX_FMT_RGB24 == pix->pixelformat)
+   else if (V4L2_PIX_FMT_RGB24 == pix_mp->pixelformat)
ps = 3;
 
vout->ps = ps;
@@ -324,13 +327,13 @@ static int video_mode_to_dss_mode(struct omap_vout_device 
*vout)
 {
struct omap_overlay *ovl;
struct omapvideo_info *ovid;
-   struct v4l2_pix_format *pix = &vout->pix;
+   struct v4l2_pix_format_mplane *pix_mp = &vout->pix_mp;
enum omap_color_mode mode;
 
ovid = &vout->vid_info;
ovl = ovid->overlays[0];
 
-   swit

[PATCH 3/6] V4L2: OMAP: VOUT: Adapt to Multiplanar APIs

[Amber Jain]

Adapting the omap_vout driver for multiplanar API support.

Signed-off-by: Amber Jain 
Signed-off-by: Samreen 
---
 drivers/media/video/omap/omap_vout.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 435fe65..70fb45e 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1014,12 +1014,13 @@ static int vidioc_querycap(struct file *file, void *fh,
strlcpy(cap->driver, VOUT_NAME, sizeof(cap->driver));
strlcpy(cap->card, vout->vfd->name, sizeof(cap->card));
cap->bus_info[0] = '\0';
-   cap->capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_OUTPUT;
+   cap->capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_OUTPUT |
+   V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
 
return 0;
 }
 
-static int vidioc_enum_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_enum_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_fmtdesc *fmt)
 {
int index = fmt->index;
@@ -1038,7 +1039,7 @@ static int vidioc_enum_fmt_vid_out(struct file *file, 
void *fh,
return 0;
 }
 
-static int vidioc_g_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_g_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_format *f)
 {
struct omap_vout_device *vout = fh;
@@ -1048,7 +1049,7 @@ static int vidioc_g_fmt_vid_out(struct file *file, void 
*fh,
 
 }
 
-static int vidioc_try_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_try_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_format *f)
 {
struct omap_overlay *ovl;
@@ -1071,7 +1072,7 @@ static int vidioc_try_fmt_vid_out(struct file *file, void 
*fh,
return 0;
 }
 
-static int vidioc_s_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_s_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_format *f)
 {
int ret, bpp;
@@ -1817,10 +1818,10 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
 
 static const struct v4l2_ioctl_ops vout_ioctl_ops = {
.vidioc_querycap= vidioc_querycap,
-   .vidioc_enum_fmt_vid_out= vidioc_enum_fmt_vid_out,
-   .vidioc_g_fmt_vid_out   = vidioc_g_fmt_vid_out,
-   .vidioc_try_fmt_vid_out = vidioc_try_fmt_vid_out,
-   .vidioc_s_fmt_vid_out   = vidioc_s_fmt_vid_out,
+   .vidioc_enum_fmt_vid_out_mplane = 
vidioc_enum_fmt_vid_out_mplane,
+   .vidioc_g_fmt_vid_out_mplane= vidioc_g_fmt_vid_out_mplane,
+   .vidioc_try_fmt_vid_out_mplane  = vidioc_try_fmt_vid_out_mplane,
+   .vidioc_s_fmt_vid_out_mplane= vidioc_s_fmt_vid_out_mplane,
.vidioc_queryctrl   = vidioc_queryctrl,
.vidioc_g_ctrl  = vidioc_g_ctrl,
.vidioc_s_fbuf  = vidioc_s_fbuf,
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/6] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf

[Amber Jain]

Add support to map the buffer using dma_map_single during qbuf which inturn
calls cache flush and unmap the same during dqbuf. This is done to prevent
the artifacts seen because of cache-coherency issues on OMAP4

Signed-off-by: Amber Jain 
---
 drivers/media/video/omap/omap_vout.c |   29 +++--
 1 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 6fe7efa..435fe65 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -768,6 +769,17 @@ static int omap_vout_buffer_prepare(struct videobuf_queue 
*q,
vout->queued_buf_addr[vb->i] = (u8 *)
omap_vout_uservirt_to_phys(vb->baddr);
} else {
+   int addr, dma_addr;
+   unsigned long size;
+
+   addr = (unsigned long) vout->buf_virt_addr[vb->i];
+   size = (unsigned long) vb->size;
+
+   dma_addr = dma_map_single(vout->vid_dev->v4l2_dev.dev, (void *) 
addr,
+   (unsigned) size, DMA_TO_DEVICE);
+   if (dma_mapping_error(vout->vid_dev->v4l2_dev.dev, dma_addr))
+   printk(KERN_ERR "dma_map_single failed\n");
+
vout->queued_buf_addr[vb->i] = (u8 *)vout->buf_phy_addr[vb->i];
}
 
@@ -1549,15 +1561,28 @@ static int vidioc_dqbuf(struct file *file, void *fh, 
struct v4l2_buffer *b)
struct omap_vout_device *vout = fh;
struct videobuf_queue *q = &vout->vbq;
 
+   unsigned long size;
+   u32 addr;
+   struct videobuf_buffer *vb;
+   int ret;
+
+   vb = q->bufs[b->index];
+
if (!vout->streaming)
return -EINVAL;
 
if (file->f_flags & O_NONBLOCK)
/* Call videobuf_dqbuf for non blocking mode */
-   return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
+   ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
else
/* Call videobuf_dqbuf for  blocking mode */
-   return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+   ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+
+   addr = (unsigned long) vout->buf_phy_addr[vb->i];
+   size = (unsigned long) vb->size;
+   dma_unmap_single(vout->vid_dev->v4l2_dev.dev,  addr,
+   (unsigned) size, DMA_TO_DEVICE);
+   return ret;
 }
 
 static int vidioc_streamon(struct file *file, void *fh, enum v4l2_buf_type i)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] V4L2: OMAP: VOUT: isr handling extended for DPI and HDMI interface

[Amber Jain]

Extending the omap vout isr handling for:
- secondary lcd over DPI interface,
- HDMI interface.

Signed-off-by: Amber Jain 
---
 drivers/media/video/omap/omap_vout.c |   26 +++---
 1 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index a831241..6fe7efa 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -544,10 +544,20 @@ void omap_vout_isr(void *arg, unsigned int irqstatus)
 
spin_lock(&vout->vbq_lock);
do_gettimeofday(&timevalue);
-   if (cur_display->type == OMAP_DISPLAY_TYPE_DPI) {
-   if (!(irqstatus & DISPC_IRQ_VSYNC))
-   goto vout_isr_err;
 
+   if (cur_display->type != OMAP_DISPLAY_TYPE_VENC) {
+   switch (cur_display->type) {
+   case OMAP_DISPLAY_TYPE_DPI:
+   if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
+   goto vout_isr_err;
+   break;
+   case OMAP_DISPLAY_TYPE_HDMI:
+   if (!(irqstatus & DISPC_IRQ_EVSYNC_EVEN))
+   goto vout_isr_err;
+   break;
+   default:
+   goto vout_isr_err;
+   }
if (!vout->first_int && (vout->cur_frm != vout->next_frm)) {
vout->cur_frm->ts = timevalue;
vout->cur_frm->state = VIDEOBUF_DONE;
@@ -571,7 +581,7 @@ void omap_vout_isr(void *arg, unsigned int irqstatus)
ret = omapvid_init(vout, addr);
if (ret)
printk(KERN_ERR VOUT_NAME
-   "failed to set overlay info\n");
+   "failed to set overlay info\n");
/* Enable the pipeline and set the Go bit */
ret = omapvid_apply_changes(vout);
if (ret)
@@ -925,7 +935,7 @@ static int omap_vout_release(struct file *file)
u32 mask = 0;
 
mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
-   DISPC_IRQ_EVSYNC_ODD;
+   DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_VSYNC2;
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
vout->streaming = 0;
 
@@ -1596,7 +1606,8 @@ static int vidioc_streamon(struct file *file, void *fh, 
enum v4l2_buf_type i)
addr = (unsigned long) vout->queued_buf_addr[vout->cur_frm->i]
+ vout->cropped_offset;
 
-   mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD;
+   mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD
+   | DISPC_IRQ_VSYNC2;
 
omap_dispc_register_isr(omap_vout_isr, vout, mask);
 
@@ -1646,7 +1657,8 @@ static int vidioc_streamoff(struct file *file, void *fh, 
enum v4l2_buf_type i)
return -EINVAL;
 
vout->streaming = 0;
-   mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD;
+   mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD
+   | DISPC_IRQ_VSYNC2;
 
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/6] V4L2: OMAP: VOUT: Extend V4L2 support for OMAP4

[Amber Jain]

This patch set addresses following:
- Extend omap vout isr for secondary LCD over DPI panel.
- Extend omap vout isr for HDMI interface.
- DMA map and unmap the V4L2 buffers in qbuf and dqbuf so that they are
  properly flushed into memory before DMA starts. If this not done we were
  seeing artifacts on OMAP4.
- Adapt to V4L2 multiplanar API's.
- Add support for NV12 format to omap vout on OMAP4.
- Minor cleanup to remove unnecessary code.


Can be tested using v4l2 streaming over:
https://gitorious.org/~amber/linux-omap-dss2/amber-omap-dss2/commits/v4l2-multi-planar

Amber Jain (6):
  V4L2: OMAP: VOUT: isr handling extended for DPI and HDMI interface
  V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf
  V4L2: OMAP: VOUT: Adapt to Multiplanar APIs
  V4L2: OMAP: VOUT: Modifications to support 1-plane Multiplanar for
RGB/YUYV formats
  V4L2: OMAP: VOUT: Changes for NV12 format support for OMAP4
  V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code.

 drivers/media/video/omap/omap_vout.c|  305 +--
 drivers/media/video/omap/omap_voutdef.h |4 +
 drivers/media/video/omap/omap_voutlib.c |   36 ++--
 drivers/media/video/omap/omap_voutlib.h |6 +-
 4 files changed, 236 insertions(+), 115 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL for 3.0-rc3] media fixes

[Mauro Carvalho Chehab]

The following changes since commit 55922c9d1b84b89cb946c777fddccb3247e7df2c:

  Linux 3.0-rc1 (2011-05-29 17:43:36 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus

Antti Palosaari (1):
  [media] anysee: return EOPNOTSUPP for unsupported I2C messages

Hans Petter Selasky (1):
  [media] Make nchg variable signed because the code compares this variable 
against negative values

Ian Armstrong (3):
  [media] ivtv: Make two ivtv_msleep_timeout calls uninterruptable
  [media] ivtvfb: Add sanity check to ivtvfb_pan_display()
  [media] ivtv: Internally separate encoder & decoder standard setting

Jean-François Moine (5):
  [media] gspca - ov519: Fix a regression for ovfx2 webcams
  [media] gspca - ov519: Change the ovfx2 bulk transfer size
  [media] gspca: Remove coarse_expo_autogain.h
  [media] gspca - stv06xx: Set a lower default value of gain for hdcs 
sensors
  [media] gspca - ov519: Set the default frame rate to 15 fps

Laurent Pinchart (3):
  [media] ivtvfb: use display information in info not in var for panning
  [media] v4l: Fix media_entity_to_video_device macro argument name
  [media] media: Fix media device minor registration

Mauro Carvalho Chehab (2):
  [media] uvc_entity: initialize return value
  [media] soc_camera: preserve const attribute

Sanjeev Premi (1):
  [media] omap3isp: fix compiler warning

 drivers/media/dvb/dvb-usb/anysee.c   |   17 ++-
 drivers/media/media-devnode.c|4 +-
 drivers/media/video/gspca/coarse_expo_autogain.h |  116 ---
 drivers/media/video/gspca/ov519.c|8 +-
 drivers/media/video/gspca/sonixj.c   |2 +-
 drivers/media/video/gspca/stv06xx/stv06xx_hdcs.h |2 +-
 drivers/media/video/ivtv/ivtv-driver.c   |   10 +-
 drivers/media/video/ivtv/ivtv-firmware.c |   11 +-
 drivers/media/video/ivtv/ivtv-ioctl.c|  129 --
 drivers/media/video/ivtv/ivtv-ioctl.h|3 +-
 drivers/media/video/ivtv/ivtv-streams.c  |4 +-
 drivers/media/video/ivtv/ivtv-vbi.c  |2 +-
 drivers/media/video/ivtv/ivtvfb.c|   33 --
 drivers/media/video/omap3isp/isp.c   |2 +-
 drivers/media/video/soc_camera.c |2 +-
 drivers/media/video/uvc/uvc_entity.c |2 +-
 include/media/v4l2-dev.h |4 +-
 17 files changed, 131 insertions(+), 220 deletions(-)
 delete mode 100644 drivers/media/video/gspca/coarse_expo_autogain.h

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] marvell-cam: Basic working MMP camera driver

[Guennadi Liakhovetski]

On Tue, 7 Jun 2011, Jonathan Corbet wrote:

> On Tue, 7 Jun 2011 09:44:45 +0200 (CEST)
> Guennadi Liakhovetski  wrote:
> 
> > > +obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/  
> > 
> > Wouldn't it be better to have only one symbol, selecting the marvell-ccic 
> > directory in the Makefile and have all CAFE implementations select that 
> > symbol?
> 
> Except there's two drivers in that directory and you'll almost never want
> to build them both.  I guess I could replace one Makefile line with two
> Kconfig lines, but I'm not sure it would improve things.

Yes, indeed I meant 3 Kconfig symbols: 1 common and 1 per driver, each of 
which selects the common one. Sorry for being unclear:)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] marvell-cam: Basic working MMP camera driver

[Jonathan Corbet]

On Tue, 7 Jun 2011 09:44:45 +0200 (CEST)
Guennadi Liakhovetski  wrote:

> > +obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/  
> 
> Wouldn't it be better to have only one symbol, selecting the marvell-ccic 
> directory in the Makefile and have all CAFE implementations select that 
> symbol?

Except there's two drivers in that directory and you'll almost never want
to build them both.  I guess I could replace one Makefile line with two
Kconfig lines, but I'm not sure it would improve things.

> > +config VIDEO_MMP_CAMERA
> > +   tristate "Marvell Armada 610 integrated camera controller support"
> > +   depends on ARCH_MMP && I2C && VIDEO_V4L2
> > +   select VIDEO_OV7670  
> 
> Is ov7670 really _integrated_ with the camera controller? Can it not be 
> used with any other sensor?

It should work with other sensors, yes, modulo the format information that
now has to be kept in the controller driver.  I'd be more than happy to
see it work with something other than the ov7670, I just don't have the
hardware to test it.

Thanks,

jon
--
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 2/6] omap: iovmm: generic iommu api migration

[Ohad Ben-Cohen]

Hi Laurent,

On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart
 wrote:
>> Right now we have a BUG_ON if pa is unaligned, but that can be changed
>> if needed (do we want it to handle offsets ?).
>
> At least for the OMAP3 ISP we need to, as video buffers don't necessarily
> start on page boundaries.

Where do you take care of those potential offsets today ? Or do you
simply ignore the offsets and map the entire page ?

Seems like omap's iommu (mostly) rejects unaligned pa addresses, see:

4abb761749abfb4ec403e4054f9dae2ee604e54f "omap iommu: Reject unaligned
addresses at setting page table entry"

(this doesn't seem to cover 4KB entries though, only large pages,
sections and super sections)

> A separate patch is indeed needed, yes. As you're already working on iommu it
> might be simpler if you add it to your tree.

Sure, i'll send it.

Thanks,
Ohad.
--
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] Refactor the cafe_ccic driver and add Armada 610 support

[Jonathan Corbet]

On Tue, 7 Jun 2011 13:30:11 +0800
Kassey Lee  wrote:

>   1)  this driver is still based on cafe_ccic.c, as you said, we
> can abstract the low level register function, and use soc_camera and
> videofbu2 to manage the buff and state machine,  how do you think ?

As I said, videobuf2 is on my list of things to do.  Note that the driver
works just fine without - that code has been in the kernel and working for
years.  But it's a cleanup that needs to be done at this point, and I will
do it.

>   2) i2c_adapter, how about move this code to driver/i2c, then
> ccic driver will become clean?

The problem there is that you can't easily disentangle the two devices -
they use the same registers, the same IRQ line, etc.  One *could* turn the
whole thing into an MFD driver and split them apart, but I honestly don't
see a reason to do that.  I'd be surprised if a Cafe chip ever shows up in
anything new these days, so it's only used in the OLPC XO 1, and that i2c
will never be used for anything but the sensor.

The i2c *has* been abstracted out of the camera core, so the Cafe i2c
implementation will not get in the way of any new drivers.

>   3) in mmp_driver.c, it has the sensor name, OV7670,  we wish
> that ccic driver do not need to aware of the sensor, also we need to
> support front and back camera sensor cases.

The only reason the ov7670 dependency is there is because that's the only
sensor the driver has ever been used with.  Adding other sensors has been
complicated a bit by Hans's changes which pushed awareness of the
available video formats into the controller driver (I complained at the
time), but that can be worked around.

For front and back: I didn't wire up the second controller in the mmp
driver because I don't have a device that uses both.  I very much wrote
the driver with the idea that both controllers could be used, though;
finishing that job will be easy.

One thing I haven't done is to look at your driver closely enough to think
about whether mmp_camera can drive your hardware or not.  You'll have a
better idea of that than me, I suspect; is the hardware pretty much the
same?

Thanks,

jon
--
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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC

[Kassey Lee]

Guennadi

  thanks for your comments very much! I will update the V3 patch  later.


On Fri, Jun 3, 2011 at 6:22 PM, Guennadi Liakhovetski
 wrote:
> Ok, this will be converted to use a common "cafe" code, but I'll comment
> on this version anyway, for your future reference.
>
> On Wed, 1 Jun 2011, Kassey Lee wrote:
>
>> This driver exports a video device node per each CCIC
>> (CMOS Camera Interface Controller)
>> device contained in Marvell Mobile PXA910 SoC
>> The driver is based on soc-camera + videobuf2 frame
>> work, and only USERPTR is supported.
>>
>> Signed-off-by: Kassey Lee 
>> ---
>>  arch/arm/mach-mmp/include/mach/camera.h |   37 ++
>>  drivers/media/video/Kconfig             |    7 +
>>  drivers/media/video/Makefile            |    1 +
>>  drivers/media/video/mv_camera.c         | 1067 
>> +++
>>  4 files changed, 1112 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
>>  create mode 100644 drivers/media/video/mv_camera.c
>>
>> diff --git a/arch/arm/mach-mmp/include/mach/camera.h 
>> b/arch/arm/mach-mmp/include/mach/camera.h
>> new file mode 100644
>> index 000..ff8cde1
>> --- /dev/null
>> +++ b/arch/arm/mach-mmp/include/mach/camera.h
>> @@ -0,0 +1,37 @@
>> +/*
>> + * Copyright (C) 2011, Marvell International Ltd.
>> + *   Kassey Lee 
>> + *   Angela Wan 
>> + *   Lei Wen 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#ifndef __ASM_ARCH_CAMERA_H__
>> +#define __ASM_ARCH_CAMERA_H__
>> +
>> +#define MV_CAMERA_MASTER       1
>> +#define MV_CAMERA_DATAWIDTH_8  8
>> +#define MV_CAMERA_DATAWIDTH_10 0x20
>> +#define MV_CAMERA_PCLK_EN      0x40
>> +#define MV_CAMERA_MCLK_EN      0x80
>> +#define MV_CAMERA_PCP          0x100
>> +#define MV_CAMERA_HSP          0x200
>> +#define MV_CAMERA_VSP          0x400
>> +
>> +struct mv_cam_pdata {
>> +     int dphy[3];
>> +     unsigned long flags;
>> +     int dma_burst;
>> +     int mclk_min;
>> +     int mclk_src;
>> +     int (*init_clk) (struct device *dev, int init);
>> +     void (*enable_clk) (struct device *dev, int on);
>> +     int (*get_mclk_src) (int src);
>> +};
>> +
>> +#endif
>> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
>> index 3be180b..18ab3a5 100644
>> --- a/drivers/media/video/Kconfig
>> +++ b/drivers/media/video/Kconfig
>> @@ -891,6 +891,13 @@ config VIDEO_MX3
>>       ---help---
>>         This is a v4l2 driver for the i.MX3x Camera Sensor Interface
>>
>> +config VIDEO_MV_CCIC
>> +     tristate "Marvell CMOS Camera Interface Controller driver"
>> +     depends on VIDEO_DEV && CPU_PXA910 && SOC_CAMERA
>> +     select VIDEOBUF2_DMA_CONTIG
>> +     ---help---
>> +       This is a v4l2 driver for the Marvell CCIC Interface
>> +
>>  config VIDEO_PXA27x
>>       tristate "PXA27x Quick Capture Interface driver"
>>       depends on VIDEO_DEV && PXA27x && SOC_CAMERA
>> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
>> index 9519160..e3251c3 100644
>> --- a/drivers/media/video/Makefile
>> +++ b/drivers/media/video/Makefile
>> @@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += 
>> soc_camera_platform.o
>>  obj-$(CONFIG_VIDEO_MX1)                      += mx1_camera.o
>>  obj-$(CONFIG_VIDEO_MX2)                      += mx2_camera.o
>>  obj-$(CONFIG_VIDEO_MX3)                      += mx3_camera.o
>> +obj-$(CONFIG_VIDEO_MV_CCIC)          += mv_camera.o
>
> Ok, I still _think_, "mv_camera" is too generic a name for this driver,
> but it's up to you, really, just my thought.
>
we has mv_gadget(usb), that is Marvell's preferred name. thanks
>>  obj-$(CONFIG_VIDEO_PXA27x)           += pxa_camera.o
>>  obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2)   += sh_mobile_csi2.o
>>  obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)    += sh_mobile_ceu_camera.o
>> diff --git a/drivers/media/video/mv_camera.c 
>> b/drivers/media/video/mv_camera.c
>> new file mode 100644
>> index 000..f19c43d
>> --- /dev/null
>> +++ b/drivers/media/video/mv_camera.c
>> @@ -0,0 +1,1067 @@
>> +/*
>> + * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
>> + * (CMOS Capture Interface Controller)
>> + *
>> + * Copyright (C) 2011, Marvell International Ltd.
>> + *   Kassey Lee 
>> + *   Angela Wan 
>> + *   Lei Wen 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> 

Re: RFC: Proposal to change the way pending events are handled

[David Cohen]

On Tue, Jun 7, 2011 at 3:46 PM, Hans Verkuil  wrote:
> On Tuesday, June 07, 2011 14:30:38 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
>> > Hi Hans and David,
>> >
>> > On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
>> >> On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil  wrote:
>> >>> While working on the control events I realized that the way we handle
>> >>> pending events is rather complicated.
>> >>>
>> >>> What currently happens internally is that you have to allocate a fixed
>> >>> sized list of events. New events are queued on the 'available' list and
>> >>> when they are processed by the application they are queued on the 'free'
>> >>> list.
>> >>>
>> >>> If the 'free' list is empty, then no new events can be queued and you
>> >>> will drop events.
>> >>>
>> >>> Dropping events can be nasty and in the case of control events can cause
>> >>> a control panel to contain stale control values if it missed a value
>> >>> change event.
>> >>
>> >> I remember it was a topic I discussed with Sakari.
>> >>
>> >>> One option is to allocate enough events, but what is 'enough' events?
>> >>> That depends on many factors. And allocating more events than is
>> >>> necessary wastes memory.
>> >>
>> >> Cases where events are lost are exception and IMO "enough" events
>> >> would be almost always waste of memory.
>> >>
>> >>> But what might be a better option is this: for each event a filehandle
>> >>> subscribes to there is only one internal v4l2_kevent allocated.
>> >>>
>> >>> This struct is either marked empty (no event was raised) or contains the
>> >>> latest state of this event. When the event is dequeued by the application
>> >>> the struct is marked empty again.
>> >>>
>> >>> So you never get duplicate events, instead, if a 'duplicate' event is
>> >>> raised it will just overwrite the 'old' event and move it to the end of
>> >>> the list of pending events. In other words, the old event is removed and
>> >>> the new event is inserted instead.
>> >>
>> >> That's an interesting proposal. Currently it will have impact at least
>> >> on statistics collection OMAP3ISP driver. It brings to my mind 2
>> >> points:
>> >>  - OMAP3ISP triggers one event for each statistic buffers produced. If
>> >> we avoid events "duplication", userapp will miss a statistic buffer.
>> >> It's possible to bypass this problem, but the OMAP3 ISP statistics'
>> >> private interface should be updated as well.
>> >>  - To define a standard for statistics collection is something we need
>> >> to do to avoid new ISP's to always create custom interfaces.
>> >>
>> >>> The nice thing about this is that for each subscribed event type you will
>> >>> never lose a raised event completely. You may lose intermediate events,
>> >>> but the latest event for that type will always be available.
>> >>
>> >> I may have a suggestion. If some event is affected by the number of
>> >> times it was triggered (like the statistic ones mentioned above),
>> >> instead of a bool "empty flag", it may contain a counter. Then a
>> >> "duplicated" event will be raised and will still inform how many
>> >> intermediate events were "lost". After event is dequeued once, the
>> >> counter could be reset.
>> >
>> > A counter would help mitigate events loss issues, when an application is 
>> > not
>> > only interested in the last event "state" (like for HDMI hotplug for
>> > instance), but also on the intermediate events. This isn't a perfect 
>> > solution
>> > though, applications can still make use of detailed event informations 
>> > (such
>> > as timestamps, and event-specific data) even if they arrive "late". It 
>> > really
>> > depends on the event type.
>>
>> I agree with Laurent.
>>
>> When the interface was originally defined, the assumption was that any
>> kind of event loss would be a major nuisance and should ideally never
>> happen. It's a good question what is best when there's not enough room
>> for new events.
>>
>> Definitely your proposal does have its advantages, but also causes loss
>> of information such as timestamps much more easily in cases such as the
>> OMAP 3 ISP driver where many events are generated per frame, usually one
>> per type.
>>
>> On the other hand, the importance of timestamps generally decreases when
>> as they get older. I'm uncertain whether such a change would actually
>> break something, at least I can't say it wouldn't right now.
>>
>> I wonder if it would be too complicated to pre-allocate n events per
>> event type, n being be a small natural number. This might be wasteful,
>> however.
>
> I think this is actually the best approach. It is even possible to let the
> application select 'N' when subscribing an event. This ensures that you never
> completely miss an event: e.g. if X events of type T are raised, then you
> will at least get min(N, X) events of that type.
>
> It's much nicer that way since it gives you useful guarantees that you don't
> have today. And the allocation can be done when subscribing events instead
> o

Re: RFC: Proposal to change the way pending events are handled

[Hans Verkuil]

On Tuesday, June 07, 2011 14:30:38 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > Hi Hans and David,
> > 
> > On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
> >> On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil  wrote:
> >>> While working on the control events I realized that the way we handle
> >>> pending events is rather complicated.
> >>>
> >>> What currently happens internally is that you have to allocate a fixed
> >>> sized list of events. New events are queued on the 'available' list and
> >>> when they are processed by the application they are queued on the 'free'
> >>> list.
> >>>
> >>> If the 'free' list is empty, then no new events can be queued and you
> >>> will drop events.
> >>>
> >>> Dropping events can be nasty and in the case of control events can cause
> >>> a control panel to contain stale control values if it missed a value
> >>> change event.
> >>
> >> I remember it was a topic I discussed with Sakari.
> >>
> >>> One option is to allocate enough events, but what is 'enough' events?
> >>> That depends on many factors. And allocating more events than is
> >>> necessary wastes memory.
> >>
> >> Cases where events are lost are exception and IMO "enough" events
> >> would be almost always waste of memory.
> >>
> >>> But what might be a better option is this: for each event a filehandle
> >>> subscribes to there is only one internal v4l2_kevent allocated.
> >>>
> >>> This struct is either marked empty (no event was raised) or contains the
> >>> latest state of this event. When the event is dequeued by the application
> >>> the struct is marked empty again.
> >>>
> >>> So you never get duplicate events, instead, if a 'duplicate' event is
> >>> raised it will just overwrite the 'old' event and move it to the end of
> >>> the list of pending events. In other words, the old event is removed and
> >>> the new event is inserted instead.
> >>
> >> That's an interesting proposal. Currently it will have impact at least
> >> on statistics collection OMAP3ISP driver. It brings to my mind 2
> >> points:
> >>  - OMAP3ISP triggers one event for each statistic buffers produced. If
> >> we avoid events "duplication", userapp will miss a statistic buffer.
> >> It's possible to bypass this problem, but the OMAP3 ISP statistics'
> >> private interface should be updated as well.
> >>  - To define a standard for statistics collection is something we need
> >> to do to avoid new ISP's to always create custom interfaces.
> >>
> >>> The nice thing about this is that for each subscribed event type you will
> >>> never lose a raised event completely. You may lose intermediate events,
> >>> but the latest event for that type will always be available.
> >>
> >> I may have a suggestion. If some event is affected by the number of
> >> times it was triggered (like the statistic ones mentioned above),
> >> instead of a bool "empty flag", it may contain a counter. Then a
> >> "duplicated" event will be raised and will still inform how many
> >> intermediate events were "lost". After event is dequeued once, the
> >> counter could be reset.
> > 
> > A counter would help mitigate events loss issues, when an application is 
> > not 
> > only interested in the last event "state" (like for HDMI hotplug for 
> > instance), but also on the intermediate events. This isn't a perfect 
> > solution 
> > though, applications can still make use of detailed event informations 
> > (such 
> > as timestamps, and event-specific data) even if they arrive "late". It 
> > really 
> > depends on the event type.
> 
> I agree with Laurent.
> 
> When the interface was originally defined, the assumption was that any
> kind of event loss would be a major nuisance and should ideally never
> happen. It's a good question what is best when there's not enough room
> for new events.
> 
> Definitely your proposal does have its advantages, but also causes loss
> of information such as timestamps much more easily in cases such as the
> OMAP 3 ISP driver where many events are generated per frame, usually one
> per type.
> 
> On the other hand, the importance of timestamps generally decreases when
> as they get older. I'm uncertain whether such a change would actually
> break something, at least I can't say it wouldn't right now.
> 
> I wonder if it would be too complicated to pre-allocate n events per
> event type, n being be a small natural number. This might be wasteful,
> however.

I think this is actually the best approach. It is even possible to let the
application select 'N' when subscribing an event. This ensures that you never
completely miss an event: e.g. if X events of type T are raised, then you
will at least get min(N, X) events of that type.

It's much nicer that way since it gives you useful guarantees that you don't
have today. And the allocation can be done when subscribing events instead
of having to guess some global maximum for the total number of events.

The current approach is definitely problematic since there are no guarantees
wha

Re: RFC: Proposal to change the way pending events are handled

[David Cohen]

Hi Hans, Laurent,

On Tue, Jun 7, 2011 at 3:20 PM, Hans Verkuil  wrote:
> On Tuesday, June 07, 2011 13:51:38 David Cohen wrote:
>> Hi Hans,
>>
>> On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil  wrote:
>> > While working on the control events I realized that the way we handle 
>> > pending
>> > events is rather complicated.
>> >
>> > What currently happens internally is that you have to allocate a fixed 
>> > sized
>> > list of events. New events are queued on the 'available' list and when they
>> > are processed by the application they are queued on the 'free' list.
>> >
>> > If the 'free' list is empty, then no new events can be queued and you will
>> > drop events.
>> >
>> > Dropping events can be nasty and in the case of control events can cause a
>> > control panel to contain stale control values if it missed a value change
>> > event.
>>
>> I remember it was a topic I discussed with Sakari.
>>
>> >
>> > One option is to allocate enough events, but what is 'enough' events? That
>> > depends on many factors. And allocating more events than is necessary 
>> > wastes
>> > memory.
>>
>> Cases where events are lost are exception and IMO "enough" events
>> would be almost always waste of memory.
>
> The problem with exceptions is that they *do* happen and you need a way to
> deal with them sensibly. One way of doing that is to ensure that for each
> subscribed event you can get at least the latest raised event of that type.
>
>> >
>> > But what might be a better option is this: for each event a filehandle
>> > subscribes to there is only one internal v4l2_kevent allocated.
>> >
>> > This struct is either marked empty (no event was raised) or contains the
>> > latest state of this event. When the event is dequeued by the application
>> > the struct is marked empty again.
>> >
>> > So you never get duplicate events, instead, if a 'duplicate' event is 
>> > raised
>> > it will just overwrite the 'old' event and move it to the end of the list 
>> > of
>> > pending events. In other words, the old event is removed and the new event 
>> > is
>> > inserted instead.
>>
>> That's an interesting proposal. Currently it will have impact at least
>> on statistics collection OMAP3ISP driver. It brings to my mind 2
>> points:
>>  - OMAP3ISP triggers one event for each statistic buffers produced. If
>> we avoid events "duplication", userapp will miss a statistic buffer.
>> It's possible to bypass this problem, but the OMAP3 ISP statistics'
>> private interface should be updated as well.
>
> Two thoughts: first of all given the current internal event architecture
> there are no guarantees that the event can even be raised (e.g. if another
> event flooded the system with events). Secondly, perhaps we should allocate
> events per event type. So for the statistics collection event would might
> want to reserve X events. And if the app doesn't read events fast enough,
> then the oldest event would be lost.

Yes, the oldest event will be lost, but the driver stores N buffers
where N > 1. Currently statistics' drivers depend on event
"duplication". But it's not a hard dependence. It's possible and easy
to change it.

>
> BTW, isn't statistics associated with a frame? So if you read too slow,
> then does it matter that you lose the older statistics?

They are related but dequeued independently in userspace.

>
>>  - To define a standard for statistics collection is something we need
>> to do to avoid new ISP's to always create custom interfaces.
>>
>> >
>> > The nice thing about this is that for each subscribed event type you will
>> > never lose a raised event completely. You may lose intermediate events, but
>> > the latest event for that type will always be available.
>>
>> I may have a suggestion. If some event is affected by the number of
>> times it was triggered (like the statistic ones mentioned above),
>> instead of a bool "empty flag", it may contain a counter. Then a
>> "duplicated" event will be raised and will still inform how many
>> intermediate events were "lost". After event is dequeued once, the
>> counter could be reset.
>
> I'm not sure what you mean. If you mean that we can report the number of
> lost events in struct v4l2_event, then I agree with that.

Yes, I mean the number of lost events. But Laurent gave a good point.
So I can identify 3 different types regarding to event duplication:
1 - Event doesn't care about duplication.
2 - Event care about duplication but doesn't care about detailed information.
3 - Event care about duplication and detailed information.

For 1, to discard all older events is enough.
For 2, to discard older events but keep a counter is enough.
For 3, it can't be infinite because the driver will have a certain
limit to store old data associated to those events, so to define a max
number of queued events and discard any older one is enough.

All cases should be possible to handle without any loss of information.

>
> Regards,
>
>        Hans
>
>>
>> Regards,
>>
>> David Cohen
>>
>> >
>> >

Re: [PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC

[Kassey Lee]

response for Guennadi comments.
thanks

On Tue, Jun 7, 2011 at 1:42 PM, Kassey Lee  wrote:
> Guennadi
>
>          thanks for your comments very much! I will update the V3 patch  
> later.
>
>
> On Fri, Jun 3, 2011 at 6:22 PM, Guennadi Liakhovetski
>  wrote:
>> Ok, this will be converted to use a common "cafe" code, but I'll comment
>> on this version anyway, for your future reference.
>>
>> On Wed, 1 Jun 2011, Kassey Lee wrote:
>>
>>> This driver exports a video device node per each CCIC
>>> (CMOS Camera Interface Controller)
>>> device contained in Marvell Mobile PXA910 SoC
>>> The driver is based on soc-camera + videobuf2 frame
>>> work, and only USERPTR is supported.
>>>
>>> Signed-off-by: Kassey Lee 
>>> ---
>>>  arch/arm/mach-mmp/include/mach/camera.h |   37 ++
>>>  drivers/media/video/Kconfig             |    7 +
>>>  drivers/media/video/Makefile            |    1 +
>>>  drivers/media/video/mv_camera.c         | 1067 
>>> +++
>>>  4 files changed, 1112 insertions(+), 0 deletions(-)
>>>  create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
>>>  create mode 100644 drivers/media/video/mv_camera.c
>>>
>>> diff --git a/arch/arm/mach-mmp/include/mach/camera.h 
>>> b/arch/arm/mach-mmp/include/mach/camera.h
>>> new file mode 100644
>>> index 000..ff8cde1
>>> --- /dev/null
>>> +++ b/arch/arm/mach-mmp/include/mach/camera.h
>>> @@ -0,0 +1,37 @@
>>> +/*
>>> + * Copyright (C) 2011, Marvell International Ltd.
>>> + *   Kassey Lee 
>>> + *   Angela Wan 
>>> + *   Lei Wen 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + */
>>> +
>>> +#ifndef __ASM_ARCH_CAMERA_H__
>>> +#define __ASM_ARCH_CAMERA_H__
>>> +
>>> +#define MV_CAMERA_MASTER       1
>>> +#define MV_CAMERA_DATAWIDTH_8  8
>>> +#define MV_CAMERA_DATAWIDTH_10 0x20
>>> +#define MV_CAMERA_PCLK_EN      0x40
>>> +#define MV_CAMERA_MCLK_EN      0x80
>>> +#define MV_CAMERA_PCP          0x100
>>> +#define MV_CAMERA_HSP          0x200
>>> +#define MV_CAMERA_VSP          0x400
>>> +
>>> +struct mv_cam_pdata {
>>> +     int dphy[3];
>>> +     unsigned long flags;
>>> +     int dma_burst;
>>> +     int mclk_min;
>>> +     int mclk_src;
>>> +     int (*init_clk) (struct device *dev, int init);
>>> +     void (*enable_clk) (struct device *dev, int on);
>>> +     int (*get_mclk_src) (int src);
>>> +};
>>> +
>>> +#endif
>>> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
>>> index 3be180b..18ab3a5 100644
>>> --- a/drivers/media/video/Kconfig
>>> +++ b/drivers/media/video/Kconfig
>>> @@ -891,6 +891,13 @@ config VIDEO_MX3
>>>       ---help---
>>>         This is a v4l2 driver for the i.MX3x Camera Sensor Interface
>>>
>>> +config VIDEO_MV_CCIC
>>> +     tristate "Marvell CMOS Camera Interface Controller driver"
>>> +     depends on VIDEO_DEV && CPU_PXA910 && SOC_CAMERA
>>> +     select VIDEOBUF2_DMA_CONTIG
>>> +     ---help---
>>> +       This is a v4l2 driver for the Marvell CCIC Interface
>>> +
>>>  config VIDEO_PXA27x
>>>       tristate "PXA27x Quick Capture Interface driver"
>>>       depends on VIDEO_DEV && PXA27x && SOC_CAMERA
>>> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
>>> index 9519160..e3251c3 100644
>>> --- a/drivers/media/video/Makefile
>>> +++ b/drivers/media/video/Makefile
>>> @@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += 
>>> soc_camera_platform.o
>>>  obj-$(CONFIG_VIDEO_MX1)                      += mx1_camera.o
>>>  obj-$(CONFIG_VIDEO_MX2)                      += mx2_camera.o
>>>  obj-$(CONFIG_VIDEO_MX3)                      += mx3_camera.o
>>> +obj-$(CONFIG_VIDEO_MV_CCIC)          += mv_camera.o
>>
>> Ok, I still _think_, "mv_camera" is too generic a name for this driver,
>> but it's up to you, really, just my thought.
>>
> we has mv_gadget(usb), that is Marvell's preferred name. thanks
>>>  obj-$(CONFIG_VIDEO_PXA27x)           += pxa_camera.o
>>>  obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2)   += sh_mobile_csi2.o
>>>  obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)    += sh_mobile_ceu_camera.o
>>> diff --git a/drivers/media/video/mv_camera.c 
>>> b/drivers/media/video/mv_camera.c
>>> new file mode 100644
>>> index 000..f19c43d
>>> --- /dev/null
>>> +++ b/drivers/media/video/mv_camera.c
>>> @@ -0,0 +1,1067 @@
>>> +/*
>>> + * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
>>> + * (CMOS Capture Interface Controller)
>>> + *
>>> + * Copyright (C) 2011, Marvell International Ltd.
>>> + *   Kassey Lee 
>>> + *   Angela Wan 
>>> + *   Lei Wen 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + */
>>> +
>>

Re: RFC: Proposal to change the way pending events are handled

[Sakari Ailus]

Laurent Pinchart wrote:
> Hi Hans and David,
> 
> On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
>> On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil  wrote:
>>> While working on the control events I realized that the way we handle
>>> pending events is rather complicated.
>>>
>>> What currently happens internally is that you have to allocate a fixed
>>> sized list of events. New events are queued on the 'available' list and
>>> when they are processed by the application they are queued on the 'free'
>>> list.
>>>
>>> If the 'free' list is empty, then no new events can be queued and you
>>> will drop events.
>>>
>>> Dropping events can be nasty and in the case of control events can cause
>>> a control panel to contain stale control values if it missed a value
>>> change event.
>>
>> I remember it was a topic I discussed with Sakari.
>>
>>> One option is to allocate enough events, but what is 'enough' events?
>>> That depends on many factors. And allocating more events than is
>>> necessary wastes memory.
>>
>> Cases where events are lost are exception and IMO "enough" events
>> would be almost always waste of memory.
>>
>>> But what might be a better option is this: for each event a filehandle
>>> subscribes to there is only one internal v4l2_kevent allocated.
>>>
>>> This struct is either marked empty (no event was raised) or contains the
>>> latest state of this event. When the event is dequeued by the application
>>> the struct is marked empty again.
>>>
>>> So you never get duplicate events, instead, if a 'duplicate' event is
>>> raised it will just overwrite the 'old' event and move it to the end of
>>> the list of pending events. In other words, the old event is removed and
>>> the new event is inserted instead.
>>
>> That's an interesting proposal. Currently it will have impact at least
>> on statistics collection OMAP3ISP driver. It brings to my mind 2
>> points:
>>  - OMAP3ISP triggers one event for each statistic buffers produced. If
>> we avoid events "duplication", userapp will miss a statistic buffer.
>> It's possible to bypass this problem, but the OMAP3 ISP statistics'
>> private interface should be updated as well.
>>  - To define a standard for statistics collection is something we need
>> to do to avoid new ISP's to always create custom interfaces.
>>
>>> The nice thing about this is that for each subscribed event type you will
>>> never lose a raised event completely. You may lose intermediate events,
>>> but the latest event for that type will always be available.
>>
>> I may have a suggestion. If some event is affected by the number of
>> times it was triggered (like the statistic ones mentioned above),
>> instead of a bool "empty flag", it may contain a counter. Then a
>> "duplicated" event will be raised and will still inform how many
>> intermediate events were "lost". After event is dequeued once, the
>> counter could be reset.
> 
> A counter would help mitigate events loss issues, when an application is not 
> only interested in the last event "state" (like for HDMI hotplug for 
> instance), but also on the intermediate events. This isn't a perfect solution 
> though, applications can still make use of detailed event informations (such 
> as timestamps, and event-specific data) even if they arrive "late". It really 
> depends on the event type.

I agree with Laurent.

When the interface was originally defined, the assumption was that any
kind of event loss would be a major nuisance and should ideally never
happen. It's a good question what is best when there's not enough room
for new events.

Definitely your proposal does have its advantages, but also causes loss
of information such as timestamps much more easily in cases such as the
OMAP 3 ISP driver where many events are generated per frame, usually one
per type.

On the other hand, the importance of timestamps generally decreases when
as they get older. I'm uncertain whether such a change would actually
break something, at least I can't say it wouldn't right now.

I wonder if it would be too complicated to pre-allocate n events per
event type, n being be a small natural number. This might be wasteful,
however.

Or allow at least one event per event type in the queue. Also this
option would have the property that not all events of a specific type
would be lost.

Or, limit the number of events of certain type in queue to m, where m < n.

Regards,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Since 2.6.39.1: dib0700: tx buffer length is larger than 4. Not supported

[Eric Valette]

Hi,

I have tons of such message literally flooding the kernel log. Is there 
an easy workaround?


PS: I'm not subscribed.

-- eric
--
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 1/6] omap: iommu: generic iommu api migration

[Ohad Ben-Cohen]

On Tue, Jun 7, 2011 at 2:40 PM, Laurent Pinchart
 wrote:
> My point is that if the allocator guarantees the alignment (not as a side
> effect of the implementation, but per its API) there's no need to check it
> again. As the alignement is required, we need an allocator that guarantees it
> anyway.

I understand, but I'd still prefer to have an explicit check that the
hardware alignment requirement is met.

There's no cost in doing that (it's a cold path), and even if it would
only fail once and with an extremely broken kernel - it's worth it.
Will save huge amount of debugging pain (think of the poor guy that
will have to debug this...).

Thanks,
Ohad.
--
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] Refactor the cafe_ccic driver and add Armada 610 support

[Kassey Lee]

hi, Jon:
   thanks for your work! it is good to know that your brought up
MMP2(610) SoC with OV7670
   I have some questions:
  1)  this driver is still based on cafe_ccic.c, as you said, we
can abstract the low level register function, and use soc_camera and
videofbu2 to manage the buff and state machine,  how do you think ?
  2) i2c_adapter, how about move this code to driver/i2c, then
ccic driver will become clean?
  3) in mmp_driver.c, it has the sensor name, OV7670,  we wish
that ccic driver do not need to aware of the sensor, also we need to
support front and back camera sensor cases.

Guennadi, what is your suggestions ?

great thanks!


On Tue, Jun 7, 2011 at 6:39 AM, Jonathan Corbet  wrote:
> Hello, all,
>
> As I promised last week, here's the state of my work refactoring the Cafe
> driver and adding Armada 610 support.  I intend to have them ready for 3.1,
> but they are not ready for merging yet.  There's a couple of things I'd
> like to clean up, and I'd like to let the OLPC people test things a bit
> more.  But I figured it would be good to get it out there for comments.
>
> Essentially, Marvell has taken the camera controller from the old Cafe chip
> and dropped it into some ARM SoC setups, one of which is the Armada 610.  I
> pondered just making a new driver, but, given that the controller has
> changed very little, it made a lot more sense to reuse the existing code.
>
> The patches here split cafe_ccic.c into "platform" and "core" pieces while
> leaving functionality unchanged.  The new "mmp-camera" driver is then added
> as a second platform.
>
> This work is not done; at a minimum, I plan to convert it over to videobuf2
> and make use of the Armada's s/g DMA capabilities.  Doubtless there is
> plenty more to be done; I would also sure like to see Kassey Lee's Marvell
> driver integrated with this one if at all possible.
>
> Comments?
>
> Thanks,
>
> jon
>
>
> --
> 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
>



-- 
Best regards
Kassey
Application Processor Systems Engineering, Marvell Technology Group Ltd.
Shanghai, China.
--
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: Proposal to change the way pending events are handled

[Hans Verkuil]

On Tuesday, June 07, 2011 13:51:38 David Cohen wrote:
> Hi Hans,
> 
> On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil  wrote:
> > While working on the control events I realized that the way we handle 
> > pending
> > events is rather complicated.
> >
> > What currently happens internally is that you have to allocate a fixed sized
> > list of events. New events are queued on the 'available' list and when they
> > are processed by the application they are queued on the 'free' list.
> >
> > If the 'free' list is empty, then no new events can be queued and you will
> > drop events.
> >
> > Dropping events can be nasty and in the case of control events can cause a
> > control panel to contain stale control values if it missed a value change
> > event.
> 
> I remember it was a topic I discussed with Sakari.
> 
> >
> > One option is to allocate enough events, but what is 'enough' events? That
> > depends on many factors. And allocating more events than is necessary wastes
> > memory.
> 
> Cases where events are lost are exception and IMO "enough" events
> would be almost always waste of memory.

The problem with exceptions is that they *do* happen and you need a way to
deal with them sensibly. One way of doing that is to ensure that for each
subscribed event you can get at least the latest raised event of that type.

> >
> > But what might be a better option is this: for each event a filehandle
> > subscribes to there is only one internal v4l2_kevent allocated.
> >
> > This struct is either marked empty (no event was raised) or contains the
> > latest state of this event. When the event is dequeued by the application
> > the struct is marked empty again.
> >
> > So you never get duplicate events, instead, if a 'duplicate' event is raised
> > it will just overwrite the 'old' event and move it to the end of the list of
> > pending events. In other words, the old event is removed and the new event 
> > is
> > inserted instead.
> 
> That's an interesting proposal. Currently it will have impact at least
> on statistics collection OMAP3ISP driver. It brings to my mind 2
> points:
>  - OMAP3ISP triggers one event for each statistic buffers produced. If
> we avoid events "duplication", userapp will miss a statistic buffer.
> It's possible to bypass this problem, but the OMAP3 ISP statistics'
> private interface should be updated as well.

Two thoughts: first of all given the current internal event architecture
there are no guarantees that the event can even be raised (e.g. if another
event flooded the system with events). Secondly, perhaps we should allocate
events per event type. So for the statistics collection event would might
want to reserve X events. And if the app doesn't read events fast enough,
then the oldest event would be lost.

BTW, isn't statistics associated with a frame? So if you read too slow,
then does it matter that you lose the older statistics?

>  - To define a standard for statistics collection is something we need
> to do to avoid new ISP's to always create custom interfaces.
> 
> >
> > The nice thing about this is that for each subscribed event type you will
> > never lose a raised event completely. You may lose intermediate events, but
> > the latest event for that type will always be available.
> 
> I may have a suggestion. If some event is affected by the number of
> times it was triggered (like the statistic ones mentioned above),
> instead of a bool "empty flag", it may contain a counter. Then a
> "duplicated" event will be raised and will still inform how many
> intermediate events were "lost". After event is dequeued once, the
> counter could be reset.

I'm not sure what you mean. If you mean that we can report the number of
lost events in struct v4l2_event, then I agree with that.

Regards,

Hans

> 
> Regards,
> 
> David Cohen
> 
> >
> > E.g. supposed you subscribed to a control containing the status of the HDMI
> > hotplug. Connecting an HDMI cable can cause a bounce condition where the 
> > HDMI
> > hotplug toggles many times in quick succession. This could currently flood
> > the event queue and you may lose the last event. With the proposed change 
> > the
> > last event will always arrive, although the intermediate events will be 
> > lost.
> >
> > Comments?
> >
> > 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
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v4] V4L2 API for flash devices

[Mauro Carvalho Chehab]

Em 19-05-2011 05:12, Sakari Ailus escreveu:
> Sylwester Nawrocki wrote:

 These were mostly fixed point arithmetic numbers in [32-bit numerator/
 32-bit denominator] form carrying exposure time, shutter speed, aperture,
 brightness, flash, etc. information. The tags could be read from ISP after
 it buffered a frame in its memory and processed it.
 In case of a JPEG image format the tags can be embedded into the main
 image file. But the image processors not always supported that so we used
 to have an ioctl for the purpose of retrieving the metadata in user space.
 In some cases it is desired to read data directly from the driver rather
 than parsing a relatively large buffer.
 It would be good to have a uniform interface for passing such data to
 applications. I think in that particular use case a control id/value pair
 sequences would do.
 
> - Which formats are your rational numbers in? A kernel interface can't
> really have floating point numbers, so there would need to be a sane way
> to pass these to user space.

The V4L2 API has support for rational numbers. The frame rate is specified as a
rational number. There's a struct for that:

struct v4l2_fract {
__u32   numerator;
__u32   denominator;
};

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management

[Guennadi Liakhovetski]

On Mon, 6 Jun 2011, Sakari Ailus wrote:

> Hi Guennadi,
> 
> On Mon, Jun 06, 2011 at 03:10:54PM +0200, Guennadi Liakhovetski wrote:
> > On Wed, 18 May 2011, Sakari Ailus wrote:
> > 
> > > Hi Guennadi and Laurent,
> > > 
> > > Guennadi Liakhovetski wrote:
> > > > On Wed, 18 May 2011, Laurent Pinchart wrote:
> > > > 
> > > >> On Tuesday 17 May 2011 07:52:28 Sakari Ailus wrote:
> > > >>> Guennadi Liakhovetski wrote:
> > > > 
> > > > [snip]
> > > > 
> > > > What about making it possible to pass an array of buffer indices to 
> > > > the
> > > > user, just like VIDIOC_S_EXT_CTRLS does? I'm not sure if this would 
> > > > be
> > > > perfect, but it would avoid the problem of requiring continuous 
> > > > ranges
> > > > of buffer ids.
> > > >
> > > > struct v4l2_create_buffers {
> > > >
> > > > __u32   *index;
> > > > __u32   count;
> > > > __u32   flags;
> > > > enum v4l2_memorymemory;
> > > > __u32   size;
> > > > struct v4l2_format  format;
> > > >
> > > > };
> > > >
> > > > Index would be a pointer to an array of buffer indices and its 
> > > > length
> > > > would be count.
> > > 
> > >  I don't understand this. We do _not_ want to allow holes in indices. 
> > >  For
> > >  now we decide to not implement DESTROY at all. In this case indices 
> > >  just
> > >  increment contiguously.
> > > 
> > >  The next stage is to implement DESTROY, but only in strict reverse 
> > >  order
> > >  - without holes and in the same ranges, as buffers have been CREATEd
> > >  before. So, I really don't understand why we need arrays, sorry.
> > > >>>
> > > >>> Well, now that we're defining a second interface to make new buffer
> > > >>> objects, I just thought it should be made as future-proof as we can.
> > > >>
> > > >> I second that. I don't like rushing new APIs to find out we need 
> > > >> something 
> > > >> else after 6 months.
> > > > 
> > > > Ok, so, we pass an array from user-space with CREATE of size count. The 
> > > > kernel fills it with as many buffers entries as it has allocated. But 
> > > > currently drivers are also allowed to allocate more buffers, than the 
> > > > user-space has requested. What do we do in such a case?
> > > 
> > > That's a good point.
> > > 
> > > But even if there was no array, shouldn't the user be allowed to create
> > > the buffers using a number of separate CREATE_BUF calls? The result
> > > would be still the same n buffers as with a single call allocating the n
> > > buffers at once.
> > > 
> > > Also, consider the (hopefully!) forthcoming DMA buffer management API
> > > patches. It looks like that those buffers will be referred to by file
> > > handles. To associate several DMA buffer objects to V4L2 buffers at
> > > once, there would have to be an array of those objects.
> > > 
> > > http://www.spinics.net/lists/linux-media/msg32448.html>
> > 
> > So, does this mean now, that we have to wait for those APIs to become 
> > solid before or even implemented we proceed with this one?
> 
> No. But I think we should take into account the foreseeable future. Any
> which form the buffer id passing mechanism will take, it will very likely
> involve referring to individual memory buffers the ids of which are not
> contiguous ranges in a general case. In short, my point is that CREATE_BUF
> should allow associating generic buffer ids to V4L2 buffers.

Ok, so, first point is: yes, it can well happen, that video buffers will 
use some further buffer allocator as a back-end, that each videobuf will 
possibly reference more than one of those memory buffers, and that those 
memory buffers will have arbitrary IDs. AFAIC, this so far doesn't affect 
our design of the CREATE ioctl(), right? As you say, both indices are 
unrelated.

I can imagine, that in the future, when we implement DESTROY, videobuf 
indices can become sparse. Say, if then we have indices 3 to 5 allocated, 
and the user requests 4 buffers. We can either use indices 0-2 and 6, or 
6-9. Personally, I would go with the latter option. Maybe we'll have to 
increase or completely eliminate the VIDEO_MAX_FRAME. But otherwise I 
think, this would be the best way to handle this. Which means, our CREATE 
ioctl() with contiguous indics should be fine. As for DESTROY, the idea 
was to only allow destroying same sets of buffers, that have been 
previously allocated with one CREATE, i.e., it will also only take 
contiguous index sets. Am I still missing anything?

> If the hardware requires more than one buffer to operate, STREAMON could
> return ERANGE in a case there ane not enough queued, for example.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a m

Re: RFC: Proposal to change the way pending events are handled

[Laurent Pinchart]

Hi Hans and David,

On Tuesday 07 June 2011 13:51:38 David Cohen wrote:
> On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil  wrote:
> > While working on the control events I realized that the way we handle
> > pending events is rather complicated.
> > 
> > What currently happens internally is that you have to allocate a fixed
> > sized list of events. New events are queued on the 'available' list and
> > when they are processed by the application they are queued on the 'free'
> > list.
> > 
> > If the 'free' list is empty, then no new events can be queued and you
> > will drop events.
> > 
> > Dropping events can be nasty and in the case of control events can cause
> > a control panel to contain stale control values if it missed a value
> > change event.
> 
> I remember it was a topic I discussed with Sakari.
> 
> > One option is to allocate enough events, but what is 'enough' events?
> > That depends on many factors. And allocating more events than is
> > necessary wastes memory.
> 
> Cases where events are lost are exception and IMO "enough" events
> would be almost always waste of memory.
> 
> > But what might be a better option is this: for each event a filehandle
> > subscribes to there is only one internal v4l2_kevent allocated.
> > 
> > This struct is either marked empty (no event was raised) or contains the
> > latest state of this event. When the event is dequeued by the application
> > the struct is marked empty again.
> > 
> > So you never get duplicate events, instead, if a 'duplicate' event is
> > raised it will just overwrite the 'old' event and move it to the end of
> > the list of pending events. In other words, the old event is removed and
> > the new event is inserted instead.
> 
> That's an interesting proposal. Currently it will have impact at least
> on statistics collection OMAP3ISP driver. It brings to my mind 2
> points:
>  - OMAP3ISP triggers one event for each statistic buffers produced. If
> we avoid events "duplication", userapp will miss a statistic buffer.
> It's possible to bypass this problem, but the OMAP3 ISP statistics'
> private interface should be updated as well.
>  - To define a standard for statistics collection is something we need
> to do to avoid new ISP's to always create custom interfaces.
> 
> > The nice thing about this is that for each subscribed event type you will
> > never lose a raised event completely. You may lose intermediate events,
> > but the latest event for that type will always be available.
> 
> I may have a suggestion. If some event is affected by the number of
> times it was triggered (like the statistic ones mentioned above),
> instead of a bool "empty flag", it may contain a counter. Then a
> "duplicated" event will be raised and will still inform how many
> intermediate events were "lost". After event is dequeued once, the
> counter could be reset.

A counter would help mitigate events loss issues, when an application is not 
only interested in the last event "state" (like for HDMI hotplug for 
instance), but also on the intermediate events. This isn't a perfect solution 
though, applications can still make use of detailed event informations (such 
as timestamps, and event-specific data) even if they arrive "late". It really 
depends on the event type.

-- 
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: RFC: Proposal to change the way pending events are handled

[David Cohen]

Hi Hans,

On Tue, Jun 7, 2011 at 2:29 PM, Hans Verkuil  wrote:
> While working on the control events I realized that the way we handle pending
> events is rather complicated.
>
> What currently happens internally is that you have to allocate a fixed sized
> list of events. New events are queued on the 'available' list and when they
> are processed by the application they are queued on the 'free' list.
>
> If the 'free' list is empty, then no new events can be queued and you will
> drop events.
>
> Dropping events can be nasty and in the case of control events can cause a
> control panel to contain stale control values if it missed a value change
> event.

I remember it was a topic I discussed with Sakari.

>
> One option is to allocate enough events, but what is 'enough' events? That
> depends on many factors. And allocating more events than is necessary wastes
> memory.

Cases where events are lost are exception and IMO "enough" events
would be almost always waste of memory.

>
> But what might be a better option is this: for each event a filehandle
> subscribes to there is only one internal v4l2_kevent allocated.
>
> This struct is either marked empty (no event was raised) or contains the
> latest state of this event. When the event is dequeued by the application
> the struct is marked empty again.
>
> So you never get duplicate events, instead, if a 'duplicate' event is raised
> it will just overwrite the 'old' event and move it to the end of the list of
> pending events. In other words, the old event is removed and the new event is
> inserted instead.

That's an interesting proposal. Currently it will have impact at least
on statistics collection OMAP3ISP driver. It brings to my mind 2
points:
 - OMAP3ISP triggers one event for each statistic buffers produced. If
we avoid events "duplication", userapp will miss a statistic buffer.
It's possible to bypass this problem, but the OMAP3 ISP statistics'
private interface should be updated as well.
 - To define a standard for statistics collection is something we need
to do to avoid new ISP's to always create custom interfaces.

>
> The nice thing about this is that for each subscribed event type you will
> never lose a raised event completely. You may lose intermediate events, but
> the latest event for that type will always be available.

I may have a suggestion. If some event is affected by the number of
times it was triggered (like the statistic ones mentioned above),
instead of a bool "empty flag", it may contain a counter. Then a
"duplicated" event will be raised and will still inform how many
intermediate events were "lost". After event is dequeued once, the
counter could be reset.

Regards,

David Cohen

>
> E.g. supposed you subscribed to a control containing the status of the HDMI
> hotplug. Connecting an HDMI cable can cause a bounce condition where the HDMI
> hotplug toggles many times in quick succession. This could currently flood
> the event queue and you may lose the last event. With the proposed change the
> last event will always arrive, although the intermediate events will be lost.
>
> Comments?
>
> 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
>
--
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 1/6] omap: iommu: generic iommu api migration

[Laurent Pinchart]

Hi Ohad,

On Tuesday 07 June 2011 13:19:05 Ohad Ben-Cohen wrote:
> On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart wrote:
> >> + BUG_ON(!IS_ALIGNED((long)omap_domain->pgtable, IOPGD_TABLE_SIZE));
> > 
> > Either __get_free_pages() guarantees that the allocated memory will be
> > aligned on an IOPGD_TABLE_SIZE boundary, in which case the BUG_ON() is
> > unnecessary, or doesn't offer such guarantee, in which case the BUG_ON()
> > will oops randomly.
> 
> Curious, does it oops randomly today ?
> (i just copied this from omap_iommu_probe, where it always existed).

No that I know of :-)

> It is a bit ugly though, and thinking on it again, 16KB is not that
> big. We can just use kmalloc here, which does ensure the alignment
> (or, better yet, kzalloc, and then ditch the memset).
> 
> > In both cases BUG_ON() should probably be avoided.
> 
> I disagree; we must check this so user data won't be harmed (hardware
> requirement), and if a memory allocation API fails to meet its
> requirements - that's really bad and user data is again at stake (much
> more will break, not only the iommu driver).

My point is that if the allocator guarantees the alignment (not as a side 
effect of the implementation, but per its API) there's no need to check it 
again. As the alignement is required, we need an allocator that guarantees it 
anyway.

> > This leaks omap_domain->pgtable.
> > 
> > The free_pages() call in omap_iommu_remove() should be removed, as
> > omap_iommu_probe() doesn't allocate the pages table anymore.
> 
> thanks !
> 
> > You can also remove the the struct iommu::iopgd field.
> 
> No, I can't; it's used when the device is attached to an address space
> domain.

Right, my bad.

> > You return 0 in the bogus pte/pgd cases. Is that intentional ?
> 
> Yes, that's probably the most (if any) reasonable value to return here
> (all other iommu implementations are doing so too).

-- 
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

RFC: Proposal to change the way pending events are handled

[Hans Verkuil]

While working on the control events I realized that the way we handle pending
events is rather complicated.

What currently happens internally is that you have to allocate a fixed sized
list of events. New events are queued on the 'available' list and when they
are processed by the application they are queued on the 'free' list.

If the 'free' list is empty, then no new events can be queued and you will
drop events.

Dropping events can be nasty and in the case of control events can cause a
control panel to contain stale control values if it missed a value change
event.

One option is to allocate enough events, but what is 'enough' events? That
depends on many factors. And allocating more events than is necessary wastes
memory.

But what might be a better option is this: for each event a filehandle
subscribes to there is only one internal v4l2_kevent allocated.

This struct is either marked empty (no event was raised) or contains the
latest state of this event. When the event is dequeued by the application
the struct is marked empty again.

So you never get duplicate events, instead, if a 'duplicate' event is raised
it will just overwrite the 'old' event and move it to the end of the list of
pending events. In other words, the old event is removed and the new event is
inserted instead.

The nice thing about this is that for each subscribed event type you will
never lose a raised event completely. You may lose intermediate events, but 
the latest event for that type will always be available.

E.g. supposed you subscribed to a control containing the status of the HDMI
hotplug. Connecting an HDMI cable can cause a bounce condition where the HDMI
hotplug toggles many times in quick succession. This could currently flood
the event queue and you may lose the last event. With the proposed change the
last event will always arrive, although the intermediate events will be lost.

Comments?

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: [RFC 2/6] omap: iovmm: generic iommu api migration

[Laurent Pinchart]

Hi Ohad,

On Tuesday 07 June 2011 12:28:53 Ohad Ben-Cohen wrote:
> On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart wrote:
> > pgsz isn't used anymore, you can remove it.
> 
> Ok.
> 
> >> + order = get_order(bytes);
> > 
> > Does iommu_map() handle offsets correctly, or does it expect pa to be
> > aligned to an order (or other) boundary ?
> 
> Right now we have a BUG_ON if pa is unaligned, but that can be changed
> if needed (do we want it to handle offsets ?).

At least for the OMAP3 ISP we need to, as video buffers don't necessarily 
start on page boundaries.

> > As Russell pointed out, we should use sg->length instead of
> > sg_dma_length(sg). sg_dma_length(sg) is only valid after the scatter
> > list has been DMA-mapped, which doesn't happen in the iovmm driver. This
> > applies to all sg_dma_len(sg) calls.
> 
> I'll make sure I don't introduce such calls, but it sounds like a
> separate patch should take care of the existing ones; pls tell me if
> you want me to send one.

A separate patch is indeed needed, yes. As you're already working on iommu it 
might be simpler if you add it to your tree. Otherwise I can send it.

-- 
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: [RFC 1/6] omap: iommu: generic iommu api migration

[Ohad Ben-Cohen]

Hi Laurent,

On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart
 wrote:
>> +     BUG_ON(!IS_ALIGNED((long)omap_domain->pgtable, IOPGD_TABLE_SIZE));
>
> Either __get_free_pages() guarantees that the allocated memory will be aligned
> on an IOPGD_TABLE_SIZE boundary, in which case the BUG_ON() is unnecessary, or
> doesn't offer such guarantee, in which case the BUG_ON() will oops randomly.

Curious, does it oops randomly today ?
(i just copied this from omap_iommu_probe, where it always existed).

It is a bit ugly though, and thinking on it again, 16KB is not that
big. We can just use kmalloc here, which does ensure the alignment
(or, better yet, kzalloc, and then ditch the memset).

> In both cases BUG_ON() should probably be avoided.

I disagree; we must check this so user data won't be harmed (hardware
requirement), and if a memory allocation API fails to meet its
requirements - that's really bad and user data is again at stake (much
more will break, not only the iommu driver).

> This leaks omap_domain->pgtable.
>
> The free_pages() call in omap_iommu_remove() should be removed, as
> omap_iommu_probe() doesn't allocate the pages table anymore.

thanks !

> You can also remove the the struct iommu::iopgd field.

No, I can't; it's used when the device is attached to an address space domain.

> You return 0 in the bogus pte/pgd cases. Is that intentional ?

Yes, that's probably the most (if any) reasonable value to return here
(all other iommu implementations are doing so too).

Thanks,
Ohad.
--
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 0/6] iommu: generic api migration and grouping

[Ohad Ben-Cohen]

On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg  wrote:
> Btw, mind to split out your changes which move the iommu-api into
> drivers/iommu? I can merge them meanwhile into my iommu tree and start
> working on a proposal for the generic large page-size support.

Sure, that will be great. Thanks!
--
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 2/6] omap: iovmm: generic iommu api migration

[Ohad Ben-Cohen]

Hi Laurent,

On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart
 wrote:
> pgsz isn't used anymore, you can remove it.

Ok.

>> +             order = get_order(bytes);
>
> Does iommu_map() handle offsets correctly, or does it expect pa to be aligned
> to an order (or other) boundary ?

Right now we have a BUG_ON if pa is unaligned, but that can be changed
if needed (do we want it to handle offsets ?).

> As Russell pointed out, we should use sg->length instead of sg_dma_length(sg).
> sg_dma_length(sg) is only valid after the scatter list has been DMA-mapped,
> which doesn't happen in the iovmm driver. This applies to all sg_dma_len(sg)
> calls.

I'll make sure I don't introduce such calls, but it sounds like a
separate patch should take care of the existing ones; pls tell me if
you want me to send one.

Thanks,
Ohad.
--
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] V4L: soc-camera: remove several now unused soc-camera client operations

[Guennadi Liakhovetski]

This patch removes .enum_input(), .suspend() and .resume() soc-camera
client operations.

Functionality, provided by .enum_input(), if needed, can be implemented
using the v4l2-subdev API.

As for .suspend() and .resume(), the only client driver, implementing
these methods has been mt9m111, and the only host driver, using them
has been pxa-camera. Now that both those drivers have been converted
to the standard subdev .s_power() operation, .suspend() and .resume()
can be removed.

Signed-off-by: Guennadi Liakhovetski 
---

v2: also remove .suspend() and .resume()

 drivers/media/video/soc_camera.c |   17 +
 include/media/soc_camera.h   |3 ---
 2 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4e4d412..136326e 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -199,22 +199,15 @@ static int soc_camera_try_fmt_vid_cap(struct file *file, 
void *priv,
 static int soc_camera_enum_input(struct file *file, void *priv,
 struct v4l2_input *inp)
 {
-   struct soc_camera_device *icd = file->private_data;
-   int ret = 0;
-
if (inp->index != 0)
return -EINVAL;
 
-   if (icd->ops->enum_input)
-   ret = icd->ops->enum_input(icd, inp);
-   else {
-   /* default is camera */
-   inp->type = V4L2_INPUT_TYPE_CAMERA;
-   inp->std  = V4L2_STD_UNKNOWN;
-   strcpy(inp->name, "Camera");
-   }
+   /* default is camera */
+   inp->type = V4L2_INPUT_TYPE_CAMERA;
+   inp->std  = V4L2_STD_UNKNOWN;
+   strcpy(inp->name, "Camera");
 
-   return ret;
+   return 0;
 }
 
 static int soc_camera_g_input(struct file *file, void *priv, unsigned int *i)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 790f422..7791c0e 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -202,11 +202,8 @@ struct soc_camera_format_xlate {
 };
 
 struct soc_camera_ops {
-   int (*suspend)(struct soc_camera_device *, pm_message_t state);
-   int (*resume)(struct soc_camera_device *);
unsigned long (*query_bus_param)(struct soc_camera_device *);
int (*set_bus_param)(struct soc_camera_device *, unsigned long);
-   int (*enum_input)(struct soc_camera_device *, struct v4l2_input *);
const struct v4l2_queryctrl *controls;
int num_controls;
 };
-- 
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

[PATCH v2] V4L: mt9m111: propagate higher level abstraction down in functions

[Guennadi Liakhovetski]

It is more convenient to propagate the higher level abstraction - the
struct mt9m111 object into functions and then retrieve a pointer to
the i2c client, if needed, than to do the reverse.

Signed-off-by: Guennadi Liakhovetski 
---

v2: also convert mt9m111_setfmt_*() functions to use "struct mt9m111 
*mt9m111" as their argument.

 drivers/media/video/mt9m111.c |  167 -
 1 files changed, 82 insertions(+), 85 deletions(-)

diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index ebebed9..0495def 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -251,9 +251,10 @@ static int mt9m111_reg_clear(struct i2c_client *client, 
const u16 reg,
return mt9m111_reg_write(client, reg, ret & ~data);
 }
 
-static int mt9m111_set_context(struct i2c_client *client,
+static int mt9m111_set_context(struct mt9m111 *mt9m111,
   enum mt9m111_context ctxt)
 {
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
int valB = MT9M111_CTXT_CTRL_RESTART | MT9M111_CTXT_CTRL_DEFECTCOR_B
| MT9M111_CTXT_CTRL_RESIZE_B | MT9M111_CTXT_CTRL_CTRL2_B
| MT9M111_CTXT_CTRL_GAMMA_B | MT9M111_CTXT_CTRL_READ_MODE_B
@@ -267,10 +268,10 @@ static int mt9m111_set_context(struct i2c_client *client,
return reg_write(CONTEXT_CONTROL, valA);
 }
 
-static int mt9m111_setup_rect(struct i2c_client *client,
+static int mt9m111_setup_rect(struct mt9m111 *mt9m111,
  struct v4l2_rect *rect)
 {
-   struct mt9m111 *mt9m111 = to_mt9m111(client);
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
int ret, is_raw_format;
int width = rect->width;
int height = rect->height;
@@ -332,48 +333,50 @@ static int mt9m111_setup_pixfmt(struct i2c_client 
*client, u16 outfmt)
return ret;
 }
 
-static int mt9m111_setfmt_bayer8(struct i2c_client *client)
+static int mt9m111_setfmt_bayer8(struct mt9m111 *mt9m111)
 {
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
+
return mt9m111_setup_pixfmt(client, MT9M111_OUTFMT_PROCESSED_BAYER |
MT9M111_OUTFMT_RGB);
 }
 
-static int mt9m111_setfmt_bayer10(struct i2c_client *client)
+static int mt9m111_setfmt_bayer10(struct mt9m111 *mt9m111)
 {
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
+
return mt9m111_setup_pixfmt(client, MT9M111_OUTFMT_BYPASS_IFP);
 }
 
-static int mt9m111_setfmt_rgb565(struct i2c_client *client)
+static int mt9m111_setfmt_rgb565(struct mt9m111 *mt9m111)
 {
-   struct mt9m111 *mt9m111 = to_mt9m111(client);
-   int val = 0;
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
+   int val = MT9M111_OUTFMT_RGB | MT9M111_OUTFMT_RGB565;
 
if (mt9m111->swap_rgb_red_blue)
val |= MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr;
if (mt9m111->swap_rgb_even_odd)
val |= MT9M111_OUTFMT_SWAP_RGB_EVEN;
-   val |= MT9M111_OUTFMT_RGB | MT9M111_OUTFMT_RGB565;
 
return mt9m111_setup_pixfmt(client, val);
 }
 
-static int mt9m111_setfmt_rgb555(struct i2c_client *client)
+static int mt9m111_setfmt_rgb555(struct mt9m111 *mt9m111)
 {
-   struct mt9m111 *mt9m111 = to_mt9m111(client);
-   int val = 0;
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
+   int val = MT9M111_OUTFMT_RGB | MT9M111_OUTFMT_RGB555;
 
if (mt9m111->swap_rgb_red_blue)
val |= MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr;
if (mt9m111->swap_rgb_even_odd)
val |= MT9M111_OUTFMT_SWAP_RGB_EVEN;
-   val |= MT9M111_OUTFMT_RGB | MT9M111_OUTFMT_RGB555;
 
return mt9m111_setup_pixfmt(client, val);
 }
 
-static int mt9m111_setfmt_yuv(struct i2c_client *client)
+static int mt9m111_setfmt_yuv(struct mt9m111 *mt9m111)
 {
-   struct mt9m111 *mt9m111 = to_mt9m111(client);
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
int val = 0;
 
if (mt9m111->swap_yuv_cb_cr)
@@ -384,9 +387,9 @@ static int mt9m111_setfmt_yuv(struct i2c_client *client)
return mt9m111_setup_pixfmt(client, val);
 }
 
-static int mt9m111_enable(struct i2c_client *client)
+static int mt9m111_enable(struct mt9m111 *mt9m111)
 {
-   struct mt9m111 *mt9m111 = to_mt9m111(client);
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
int ret;
 
ret = reg_set(RESET, MT9M111_RESET_CHIP_ENABLE);
@@ -395,8 +398,9 @@ static int mt9m111_enable(struct i2c_client *client)
return ret;
 }
 
-static int mt9m111_reset(struct i2c_client *client)
+static int mt9m111_reset(struct mt9m111 *mt9m111)
 {
+   struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
int ret;
 
ret = reg_set(RESET, MT9M111_RESET_RESET_MODE);
@@ -424,11 +428,9 @@ static int mt9m111_set_bu

Re: [RFC/PATCH v3] v4l: add control definitions for codec devices.

[Hans Verkuil]

On Tuesday, June 07, 2011 11:57:22 Kamil Debski wrote:
> Hi Hans,
> 
> > From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> > 
> > Hi Kamil!
> > 
> > On Thursday, June 02, 2011 16:48:41 Kamil Debski wrote:
> > > Hi,
> > >
> > > This is a third version of the patch that adds controls for the codec
> > family of
> > > devices. I have implemented the suggestions to v1 I got from Hans Verkuil
> > on the #v4l
> > > channel. Also I have addressed comments to v2 by Jeongtae Park.
> > >
> > > Changes from v2 to v3:
> > > - added MVC anc SVC profiles to H264
> > > - some fixes in in the documentation
> > > - remove V4L2_CID_MPEG_VIDEO_INTERLACE in favour of interlace v4l2_field
> > in v4l2_pix_format
> > >
> > > Changes from v1 to v2:
> > > - rename V4L2_CID_MIN_REQ_BUFS_(CAP/OUT) to
> > V4L2_CID_MIN_BUFFERS_FOR_(CAPTURE/OUTPUT)
> > > - use existing controls for GOP size, number of frames and GOP closure
> > > - remove frame rate controls (in favour of the S_PARM call)
> > > - split level into separate controls for MPEG4 and H264
> > >
> > > I would welcome further comments.
> > 
> > I have a number of comments below, but I will need to find the actual
> > standards
> > documents at work to verify some others parts of this RFC. So I'll get back
> > with
> > more comments, hopefully on Tuesday.
> > 
> > I also have a few more generic comments:
> > 
> > 1) I understand that the MFC supports H264, MPEG4 and H263, right? How does
> > one
> > select between them? I assume that V4L2_CID_MPEG_VIDEO_ENCODING should be
> > used
> > for that, but that is missing MPEG4 and H263.
> 
> The codec used is determined by the pixelformat of the capture queue. 
> So if it is V4L2_PIX_FMT_H264 then H264 elementary stream would be produced.
> This control would only be used for multiplexed streams - when the pixelformat
> is set to V4L2_PIX_FMT_MPEG.

Of course. It slipped my mind. This really needs to be documented better in
the spec.
 
> > 2) It is sometimes hard to figure out for which video encodings certain
> > controls
> > are valid. I think all the video controls should have a list of the video
> > encodings
> > for which that control is valid (except where the name of the control makes
> > it
> > unambiguous).
> 
> You mean the documentation, yes?

Yes, documentation.

> If so it is a good idea, I could add a list of
> supported video codecs for such controls.

Please do. That would make the spec much more precise.

> 
> > 3) Is there public documentation from Samsung regarding the MFC-specific
> > controls?
> > If so, then a link to that documentation would be very handy. If not, then I
> > think
> > some of the documentation for these controls should be extended.
> 
> I am not sure whether the documentation is available for download on the web.
> I actually doubt it... So I will think which controls should have
> more documentation.
> 
> > 
> > Note that this third version of the RFC looks much better than the earlier
> > ones.
> > I think we are close to finalizing this.
> 
> Thanks.
> 
> > 
> > >
> > > Best regards,
> > > Kamil Debski
> > >
> > > Signed-off-by: Kamil Debski 
> > > Signed-off-by: Kyungmin Park 
> > > ---
> > >  Documentation/DocBook/v4l/controls.xml |  774
> > 

> > spanname="id">V4L2_CID_MPEG_VIDEO_H264_VUI_AR_IDC 
> > 
> > > + integer
> > > +   
> > > +   VUI aspect ratio IDC for H.264
> > encoding. The value is defined in VUI Table
> > > +E-1 in the standard.
> > 
> > What does IDC stand for? Shouldn't this be a menu control? How does this
> > compare
> > to V4L2_CID_MPEG_VIDEO_ASPECT?
> 
> IDC stands for 'indicator', this abbreviation is commonly used in the H264
> standard.
> If I understand correctly the meaning of this control is different than
> V4L2_CID_MPEG_VIDEO_ASPECT

It is indeed. I checked the H264 spec as well.

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: [RFC 0/6] iommu: generic api migration and grouping

[Roedel, Joerg]

On Tue, Jun 07, 2011 at 05:22:11AM -0400, Ohad Ben-Cohen wrote:
> On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg  wrote:
> > Yup. Btw, is there any IOMMU hardware which supports non-natural
> > alignment? In this case we need to expose these requirements somehow.
> 
> Not sure there are. Let's start with natural alignment, and extend it
> only if someone with additional requirements shows up.

Btw, mind to split out your changes which move the iommu-api into
drivers/iommu? I can merge them meanwhile into my iommu tree and start
working on a proposal for the generic large page-size support.

Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] V4L: mt9m111: propagate higher level abstraction down in functions

[Guennadi Liakhovetski]

On Mon, 6 Jun 2011, Robert Jarzmik wrote:

> On 06/06/2011 07:20 PM, Guennadi Liakhovetski wrote:
> > It is more convenient to propagate the higher level abstraction - the
> > struct mt9m111 object into functions and then retrieve a pointer to
> > the i2c client, if needed, than to do the reverse.
> Agreed.
> 
> One minor point, you ofter replace :
> > -   struct mt9m111 *mt9m111 = to_mt9m111(client);
> > +   struct mt9m111 *mt9m111 = container_of(sd, struct mt9m111, subdev);
> 
> Why haven't you replaced the signature of to_mt9m111() into :
> static struct mt9m111 *to_mt9m111(const struct v4l2_subdev *sd)
> {
>   return container_of(sd, struct mt9m111, subdev);
> }
> 
> This way, each to_mt9m111(client) will become to_mt9m111(sd), and the purpose
> of to_mt9m111() will be kept. Wouldn't that be better ?

Because "container_of(sd, struct mt9m111, subdev)" is still easy enough to 
write (copy-paste, of course:)) and understand, whereas 
"container_of(i2c_get_clientdata(client), struct mt9m111, subdev)" is 
already too awkward to look at, even though it is now only used at 4 
locations.

A general question to you: from your comments I haven't understood: have 
you also tested the patches or only reviewed them?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3 v2] V4L: pxa-camera: switch to using subdev .s_power() core operation

[Guennadi Liakhovetski]

soc-camera specific .suspend() and .resume() methods are deprecated
and should be replaced by the subdev standard .s_power() operation.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/video/pxa_camera.c |   16 
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 88aa1ba..3b3ad08 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1591,8 +1591,12 @@ static int pxa_camera_suspend(struct soc_camera_device 
*icd, pm_message_t state)
pcdev->save_cicr[i++] = __raw_readl(pcdev->base + CICR3);
pcdev->save_cicr[i++] = __raw_readl(pcdev->base + CICR4);
 
-   if ((pcdev->icd) && (pcdev->icd->ops->suspend))
-   ret = pcdev->icd->ops->suspend(pcdev->icd, state);
+   if (pcdev->icd) {
+   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+   ret = v4l2_subdev_call(sd, core, s_power, 0);
+   if (ret == -ENOIOCTLCMD)
+   ret = 0;
+   }
 
return ret;
 }
@@ -1613,8 +1617,12 @@ static int pxa_camera_resume(struct soc_camera_device 
*icd)
__raw_writel(pcdev->save_cicr[i++], pcdev->base + CICR3);
__raw_writel(pcdev->save_cicr[i++], pcdev->base + CICR4);
 
-   if ((pcdev->icd) && (pcdev->icd->ops->resume))
-   ret = pcdev->icd->ops->resume(pcdev->icd);
+   if (pcdev->icd) {
+   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+   ret = v4l2_subdev_call(sd, core, s_power, 1);
+   if (ret == -ENOIOCTLCMD)
+   ret = 0;
+   }
 
/* Restart frame capture if active buffer exists */
if (!ret && pcdev->active)
-- 
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

[PATCH 2/3 v2] V4L: pxa-camera: try to force progressive video format

[Guennadi Liakhovetski]

The pxa-camera driver only supports progressive video so far. Passing
down to the client the same format, as what the user has requested can
result in interlaced video, even if the client supports both. This
patch avoids such cases.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/video/pxa_camera.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index c7f84da..88aa1ba 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1502,7 +1502,8 @@ static int pxa_camera_try_fmt(struct soc_camera_device 
*icd,
/* limit to sensor capabilities */
mf.width= pix->width;
mf.height   = pix->height;
-   mf.field= pix->field;
+   /* Only progressive video supported so far */
+   mf.field= V4L2_FIELD_NONE;
mf.colorspace   = pix->colorspace;
mf.code = xlate->code;
 
-- 
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

[PATCH 0/3 v2] V4L: pxa-camera: minor updates

[Guennadi Liakhovetski]

This patch series updates the pxa-camera driver to match recent API 
changes and to better integrate into the framework. It splits the 
previously posted patch

http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/33616

that erroneously contained unrelated changes in it, thanks go to Robert 
for spotting that:)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3 v2] V4L: pxa_camera: remove redundant calculations

[Guennadi Liakhovetski]

soc_camera core now performs the standard .bytesperline and .sizeimage
calculations internally, no need to duplicate in drivers.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/video/pxa_camera.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index b42bfa5..c7f84da 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -1499,12 +1499,6 @@ static int pxa_camera_try_fmt(struct soc_camera_device 
*icd,
  &pix->height, 32, 2048, 0,
  pixfmt == V4L2_PIX_FMT_YUV422P ? 4 : 0);
 
-   pix->bytesperline = soc_mbus_bytes_per_line(pix->width,
-   xlate->host_fmt);
-   if (pix->bytesperline < 0)
-   return pix->bytesperline;
-   pix->sizeimage = pix->height * pix->bytesperline;
-
/* limit to sensor capabilities */
mf.width= pix->width;
mf.height   = pix->height;
-- 
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: [RFC/PATCH v3] v4l: add control definitions for codec devices.

[Kamil Debski]

Hi Hans,

> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> 
> Hi Kamil!
> 
> On Thursday, June 02, 2011 16:48:41 Kamil Debski wrote:
> > Hi,
> >
> > This is a third version of the patch that adds controls for the codec
> family of
> > devices. I have implemented the suggestions to v1 I got from Hans Verkuil
> on the #v4l
> > channel. Also I have addressed comments to v2 by Jeongtae Park.
> >
> > Changes from v2 to v3:
> > - added MVC anc SVC profiles to H264
> > - some fixes in in the documentation
> > - remove V4L2_CID_MPEG_VIDEO_INTERLACE in favour of interlace v4l2_field
> in v4l2_pix_format
> >
> > Changes from v1 to v2:
> > - rename V4L2_CID_MIN_REQ_BUFS_(CAP/OUT) to
> V4L2_CID_MIN_BUFFERS_FOR_(CAPTURE/OUTPUT)
> > - use existing controls for GOP size, number of frames and GOP closure
> > - remove frame rate controls (in favour of the S_PARM call)
> > - split level into separate controls for MPEG4 and H264
> >
> > I would welcome further comments.
> 
> I have a number of comments below, but I will need to find the actual
> standards
> documents at work to verify some others parts of this RFC. So I'll get back
> with
> more comments, hopefully on Tuesday.
> 
> I also have a few more generic comments:
> 
> 1) I understand that the MFC supports H264, MPEG4 and H263, right? How does
> one
> select between them? I assume that V4L2_CID_MPEG_VIDEO_ENCODING should be
> used
> for that, but that is missing MPEG4 and H263.

The codec used is determined by the pixelformat of the capture queue. 
So if it is V4L2_PIX_FMT_H264 then H264 elementary stream would be produced.
This control would only be used for multiplexed streams - when the pixelformat
is set to V4L2_PIX_FMT_MPEG.

> 2) It is sometimes hard to figure out for which video encodings certain
> controls
> are valid. I think all the video controls should have a list of the video
> encodings
> for which that control is valid (except where the name of the control makes
> it
> unambiguous).

You mean the documentation, yes? If so it is a good idea, I could add a list of
supported video codecs for such controls.

> 3) Is there public documentation from Samsung regarding the MFC-specific
> controls?
> If so, then a link to that documentation would be very handy. If not, then I
> think
> some of the documentation for these controls should be extended.

I am not sure whether the documentation is available for download on the web.
I actually doubt it... So I will think which controls should have
more documentation.

> 
> Note that this third version of the RFC looks much better than the earlier
> ones.
> I think we are close to finalizing this.

Thanks.

> 
> >
> > Best regards,
> > Kamil Debski
> >
> > Signed-off-by: Kamil Debski 
> > Signed-off-by: Kyungmin Park 
> > ---
> >  Documentation/DocBook/v4l/controls.xml |  774
> 
> >  include/linux/videodev2.h  |  149 ++
> >  2 files changed, 923 insertions(+), 0 deletions(-)
> >
> > diff --git a/Documentation/DocBook/v4l/controls.xml
> b/Documentation/DocBook/v4l/controls.xml
> > index 6880798..3c3c709 100644
> > --- a/Documentation/DocBook/v4l/controls.xml
> > +++ b/Documentation/DocBook/v4l/controls.xml
> > @@ -325,6 +325,22 @@ minimum value disables backlight
> compensation.
> >  V4L2_CID_ILLUMINATORS_2 + 1).
> >   
> >   
> > +
> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE
> > +   integer
> > +   This is a read only control that can be read by the
> application
> 
> typo: read-only
> 
> > +and used as a hint to determine the number of CAPTURE buffer to pass to
> REQBUFS.
> 
> typo: buffers
> 
> > +The value is the minimum number of CAPTURE buffer that it necessary for
> hardware
> 
> typo: 'buffers that is'
> 
> > +to work.
> > + 
> > + 
> > +
> V4L2_CID_MIN_BUFFERSS_FOR_OUTPUT
> 
> typo: BUFFERSS -> BUFFERS
> 
> > +   integer
> > +   This is a read only control that can br read by the
> application
> 
> typo: read-only
> typo: br -> be
> 
> > +and used as a hint to determine the number of OUTPUT buffer to pass to
> REQBUFS.
> 
> typo: buffers
> 
> > +The value is the minimum number of OUTPUT buffer that it necessary for
> hardware
> 
> typo: buffers that is
> 
> > +to work.
> > + 
> > + 
> > V4L2_CID_PRIVATE_BASE
> > 
> > ID of the first custom (driver specific) control.
> > @@ -1409,6 +1425,764 @@ of the video. The supplied 32-bit integer is
> interpreted as follows (bit
> >   
> > 
> >   
> > +
> > +
> > + 
> > + 
> > +spanname="id">V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE t> 
> > +   boolean
> > + 
> > + If enabled the decoder expects a
> single slice in one buffer, otherwise
> > +the decoder expects a single frame in one input buffer.
> > + 
> > +
> > + 
> > + 
> > +spanname="id">V4L2_CID_MPEG_VIDEO_H264_VUI_AR_ENABLE&nb
> sp;
> > +   boolean
> > + 
> > + Enable w

Re: [PATCH 1/2] OMAP_VOUT: CLEANUP: Move some functions and macros from omap_vout

[Archit Taneja]

Hi,

On Tuesday 07 June 2011 02:35 PM, Hiremath, Vaibhav wrote:

-Original Message-
From: Taneja, Archit
Sent: Friday, May 27, 2011 12:31 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Taneja, Archit
Subject: [PATCH 1/2] OMAP_VOUT: CLEANUP: Move some functions and macros
from omap_vout


[Hiremath, Vaibhav] You may want to give patch revision here.


I don't think it makes sense to give the old revisions anymore, this 
patch set had been dormant since last year. I'll add revisions for the 
later versions of this set.



Cosmetic comment -

Consider changing the subject line to something -

OMAP_VOUT: CLEANUP: Move generic functions and macros to common files



Move some inline functions from omap_vout.c to omap_voutdef.h and
independent
functions like omap_vout_alloc_buffer/omap_vout_free_buffer to
omap_voutlib.c.


[Hiremath, Vaibhav] Ditto here, word "some" doesn't convey anything.


Okay.









  /*
- * Return true if rotation is 90 or 270
- */
-static inline int rotate_90_or_270(const struct omap_vout_device *vout)
-{
-   return (vout->rotation == dss_rotation_90_degree ||
-   vout->rotation == dss_rotation_270_degree);
-}
-
-/*
- * Return true if rotation is enabled
- */
-static inline int rotation_enabled(const struct omap_vout_device *vout)
-{
-   return vout->rotation || vout->mirror;
-}
-

[Hiremath, Vaibhav] As part of this cleanup I would suggest to rename these 
API's to self descriptive, something like -

rotation_enabled =>  is_rotation_enabled
rotate_90_or_270 =>  is_rotation_90_or_270


This patch just moves these functions. Moving it to another file and 
then changing the names in the same patch will make things messy. I'll 
do this in a separate patch in the same patch set.






-/*





diff --git a/drivers/media/video/omap/omap_voutlib.h
b/drivers/media/video/omap/omap_voutlib.h
index a60b16e..1d722be 100644
--- a/drivers/media/video/omap/omap_voutlib.h
+++ b/drivers/media/video/omap/omap_voutlib.h
@@ -30,5 +30,7 @@ extern int omap_vout_new_window(struct v4l2_rect *crop,
  extern void omap_vout_new_format(struct v4l2_pix_format *pix,
struct v4l2_framebuffer *fbuf, struct v4l2_rect *crop,
struct v4l2_window *win);
+extern unsigned long omap_vout_alloc_buffer(u32 buf_size, u32
*phys_addr);
+extern void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size);
  #endif/* #ifndef OMAP_VOUTLIB_H */


[Hiremath, Vaibhav] We do not need to use externs here; this should be another 
cleanup candidate which can be done with this patch series.


Will fix this.

Archit
--
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 0/6] iommu: generic api migration and grouping

[Ohad Ben-Cohen]

On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg  wrote:
> Yup. Btw, is there any IOMMU hardware which supports non-natural
> alignment? In this case we need to expose these requirements somehow.

Not sure there are. Let's start with natural alignment, and extend it
only if someone with additional requirements shows up.
--
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 1/6] omap: iommu: generic iommu api migration

[Laurent Pinchart]

Hi Ohad,

Thanks for the patch.

On Friday 03 June 2011 00:27:38 Ohad Ben-Cohen wrote:
> Migrate OMAP's iommu to the generic iommu api, so users can stay
> generic, and non-omap-specific code can be removed and eventually
> consolidated into a generic framework.
> 
> Tested on both OMAP3 and OMAP4.
> 
> Signed-off-by: Ohad Ben-Cohen 

[snip]

> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index 34fc31e..f06e99c 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c

[snip]

> +static int omap_iommu_domain_init(struct iommu_domain *domain)
> +{
> + struct omap_iommu_domain *omap_domain;
> +
> + omap_domain = kzalloc(sizeof(*omap_domain), GFP_KERNEL);
> + if (!omap_domain) {
> + pr_err("kzalloc failed\n");
> + goto fail_nomem;
> + }
> +
> + omap_domain->pgtable = (u32 *)__get_free_pages(GFP_KERNEL,
> + get_order(IOPGD_TABLE_SIZE));
> + if (!omap_domain->pgtable) {
> + pr_err("__get_free_pages failed\n");
> + goto fail_nomem;
> + }
> +
> + BUG_ON(!IS_ALIGNED((long)omap_domain->pgtable, IOPGD_TABLE_SIZE));

Either __get_free_pages() guarantees that the allocated memory will be aligned 
on an IOPGD_TABLE_SIZE boundary, in which case the BUG_ON() is unnecessary, or 
doesn't offer such guarantee, in which case the BUG_ON() will oops randomly. 
In both cases BUG_ON() should probably be avoided.

> + memset(omap_domain->pgtable, 0, IOPGD_TABLE_SIZE);
> + clean_dcache_area(omap_domain->pgtable, IOPGD_TABLE_SIZE);
> + mutex_init(&omap_domain->lock);
> +
> + domain->priv = omap_domain;
> +
> + return 0;
> +
> +fail_nomem:
> + kfree(omap_domain);
> + return -ENOMEM;
> +}
> +
> +/* assume device was already detached */
> +static void omap_iommu_domain_destroy(struct iommu_domain *domain)
> +{
> + struct omap_iommu_domain *omap_domain = domain->priv;
> +
> + domain->priv = NULL;
> +
> + kfree(omap_domain);

This leaks omap_domain->pgtable.

The free_pages() call in omap_iommu_remove() should be removed, as 
omap_iommu_probe() doesn't allocate the pages table anymore. You can also 
remove the the struct iommu::iopgd field.

> +}


> +
> +static phys_addr_t omap_iommu_iova_to_phys(struct iommu_domain *domain,
> +   unsigned long da)
> +{
> + struct omap_iommu_domain *omap_domain = domain->priv;
> + struct iommu *oiommu = omap_domain->iommu_dev;
> + struct device *dev = oiommu->dev;
> + u32 *pgd, *pte;
> + phys_addr_t ret = 0;
> +
> + iopgtable_lookup_entry(oiommu, da, &pgd, &pte);
> +
> + if (pte) {
> + if (iopte_is_small(*pte))
> + ret = omap_iommu_translate(*pte, da, IOPTE_MASK);
> + else if (iopte_is_large(*pte))
> + ret = omap_iommu_translate(*pte, da, IOLARGE_MASK);
> + else
> + dev_err(dev, "bogus pte 0x%x", *pte);
> + } else {
> + if (iopgd_is_section(*pgd))
> + ret = omap_iommu_translate(*pgd, da, IOSECTION_MASK);
> + else if (iopgd_is_super(*pgd))
> + ret = omap_iommu_translate(*pgd, da, IOSUPER_MASK);
> + else
> + dev_err(dev, "bogus pgd 0x%x", *pgd);
> + }
> +
> + return ret;

You return 0 in the bogus pte/pgd cases. Is that intentional ?

> +}

-- 
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