cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Nov 16 04:00:27 CET 2013 git branch: test git hash: 80f93c7b0f4599ffbdac8d964ecd1162b8b618b9 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK apps: WARNINGS spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dw2102: Use RC Core instead of the legacy RC (second edition)
Use RC Core instead of the legacy RC.
DVBWorld, TBS, TeVii, Prof hardware decode only NEC remotes (one byte code).
Geniatech hardware decode only RC5 (two bytes).
+ New keymap for Geniatech HDStar (SU3000).
Signed-off-by: Evgeny Plehov
---
drivers/media/rc/keymaps/Makefile|3 +-
drivers/media/rc/keymaps/rc-su3000.c | 75 +
drivers/media/usb/dvb-usb/dw2102.c | 298 +-
include/media/rc-map.h |1 +
4 files changed, 152 insertions(+), 225 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-su3000.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index b1cde8c..0b8c549 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -98,4 +98,5 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-videomate-s350.o \
rc-videomate-tv-pvr.o \
rc-winfast.o \
- rc-winfast-usbii-deluxe.o
+ rc-winfast-usbii-deluxe.o \
+ rc-su3000.o
diff --git a/drivers/media/rc/keymaps/rc-su3000.c
b/drivers/media/rc/keymaps/rc-su3000.c
new file mode 100644
index 000..8dbd3e9
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-su3000.c
@@ -0,0 +1,75 @@
+/* rc-su3000.h - Keytable for Geniatech HDStar Remote Controller
+ *
+ * Copyright (c) 2013 by Evgeny Plehov
+ *
+ * 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
+
+static struct rc_map_table su3000[] = {
+ { 0x25, KEY_POWER },/* right-bottom Red */
+ { 0x0a, KEY_MUTE }, /* -/-- */
+ { 0x01, KEY_1 },
+ { 0x02, KEY_2 },
+ { 0x03, KEY_3 },
+ { 0x04, KEY_4 },
+ { 0x05, KEY_5 },
+ { 0x06, KEY_6 },
+ { 0x07, KEY_7 },
+ { 0x08, KEY_8 },
+ { 0x09, KEY_9 },
+ { 0x00, KEY_0 },
+ { 0x20, KEY_UP }, /* CH+ */
+ { 0x21, KEY_DOWN }, /* CH+ */
+ { 0x12, KEY_VOLUMEUP }, /* Brightness Up */
+ { 0x13, KEY_VOLUMEDOWN },/* Brightness Down */
+ { 0x1f, KEY_RECORD },
+ { 0x17, KEY_PLAY },
+ { 0x16, KEY_PAUSE },
+ { 0x0b, KEY_STOP },
+ { 0x27, KEY_FASTFORWARD },/* >> */
+ { 0x26, KEY_REWIND }, /* << */
+ { 0x0d, KEY_OK }, /* Mute */
+ { 0x11, KEY_LEFT }, /* VOL- */
+ { 0x10, KEY_RIGHT },/* VOL+ */
+ { 0x29, KEY_BACK }, /* button under 9 */
+ { 0x2c, KEY_MENU }, /* TTX */
+ { 0x2b, KEY_EPG }, /* EPG */
+ { 0x1e, KEY_RED }, /* OSD */
+ { 0x0e, KEY_GREEN },/* Window */
+ { 0x2d, KEY_YELLOW }, /* button under << */
+ { 0x0f, KEY_BLUE }, /* bottom yellow button */
+ { 0x14, KEY_AUDIO },/* Snapshot */
+ { 0x38, KEY_TV }, /* TV/Radio */
+ { 0x0c, KEY_ESC } /* upper Red button */
+};
+
+static struct rc_map_list su3000_map = {
+ .map = {
+ .scan= su3000,
+ .size= ARRAY_SIZE(su3000),
+ .rc_type = RC_TYPE_RC5,
+ .name= RC_MAP_SU3000,
+ }
+};
+
+static int __init init_rc_map_su3000(void)
+{
+ return rc_map_register(&su3000_map);
+}
+
+static void __exit exit_rc_map_su3000(void)
+{
+ rc_map_unregister(&su3000_map);
+}
+
+module_init(init_rc_map_su3000)
+module_exit(exit_rc_map_su3000)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Evgeny Plehov ");
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index 12e00aa..5ec7ca8 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -109,11 +109,6 @@
"Please see linux/Documentation/dvb/ for more details " \
"on firmware-problems."
-struct rc_map_dvb_usb_table_table {
- struct rc_map_table *rc_keys;
- int rc_keys_size;
-};
-
struct su3000_state {
u8 initialized;
};
@@ -128,12 +123,6 @@ module_param_named(debug, dvb_usb_dw2102_debug, int, 0644);
MODULE_PARM_DESC(debug, "set debugging level (1=info 2=xfer 4=rc(or-able))."
DVB_USB_DEBUG_STATUS);
-/* keymaps */
-static int ir_keymap;
-module_param_named(keymap, ir_keymap, int, 0644);
-MODULE_PARM_DESC(keymap, "set keymap 0=default 1=dvbworld 2=tevii 3=tbs ..."
- " 256=none");
-
/* demod probe */
static int demod_probe = 1;
module_param_named(demod, demod_probe, int, 0644);
@@ -1389,174 +1378,29 @@ static int dw3101_tuner_attach(struct dvb_usb_adapter
*adap)
return 0;
}
-static struct rc_map_table rc_map_dw210x_table[] = {
- { 0xf80a, KEY_POWER2 }, /*power*/
- { 0xf80c, KEY_MUTE }, /*mute*/
- { 0xf811, KEY
Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On 15.11.2013 21:13, Devin Heitmueller wrote: On Fri, Nov 15, 2013 at 2:11 PM, Antti Palosaari wrote: When I do it inside Kernel, in URB completion handler at the same time when copying data to videobuf2, using pre-calculated LUTs and using mmap it eats 0.5% CPU to transfer stream to app. When I do same but using libv4lconvert as that patch, it takes ~11% CPU. How are you measuring? Interrupt handlers typically don't count toward the CPU performance counters. It's possible that the cost is the same but you're just not seeing it in "top". Yes, using top and it is URB interrupt handler where I do conversion. So any idea how to measure? I think I can still switch LUT to float and see if it makes difference. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On Fri, Nov 15, 2013 at 2:11 PM, Antti Palosaari wrote: > When I do it inside Kernel, in URB completion handler at the same time when > copying data to videobuf2, using pre-calculated LUTs and using mmap it eats > 0.5% CPU to transfer stream to app. > > When I do same but using libv4lconvert as that patch, it takes ~11% CPU. How are you measuring? Interrupt handlers typically don't count toward the CPU performance counters. It's possible that the cost is the same but you're just not seeing it in "top". Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] libv4lconvert: SDR conversion from U8 to FLOAT
On 11.11.2013 15:40, Antti Palosaari wrote: On 11.11.2013 15:14, Hans Verkuil wrote: On 11/10/2013 06:16 PM, Antti Palosaari wrote: Convert unsigned 8 to float 32 [-1 to +1], which is commonly used format for baseband signals. I am also going to make some tests to find out if actual float conversion is faster against pre-calculated LUT, in Kernel or in libv4lconvert and so. Worst scenario I have currently is Mirics ADC with 14-bit resolution => 16384 quantization levels => 32-bit float LUT will be 16384 * 4 = 65536 bytes. Wonder if that much big LUT is allowed to library - but maybe you could alloc() and populate LUT on the fly if needed. Or maybe native conversion is fast enough. That integer to float conversion uses quite much CPU still, even I use only 2M sampling rate. When I do it inside Kernel, in URB completion handler at the same time when copying data to videobuf2, using pre-calculated LUTs and using mmap it eats 0.5% CPU to transfer stream to app. When I do same but using libv4lconvert as that patch, it takes ~11% CPU. And it was only 2M sampling rate, Mirics could go something like 15M. I wonder if I can optimize libv4lconvert to go near in Kernel LUT conversion... CPU: AMD Phenom(tm) II X4 955 Processor regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [early RFC] Device Tree bindings for OMAP3 Camera Subsystem
On Sun, Nov 03, 2013 at 10:03:15PM +, Sebastian Reichel wrote:
> Hi,
>
> This is an early RFC for omap3isp DT support. For now i just created a
> potential DT
> binding documentation based on the existing platform data:
>
> Binding for the OMAP3 Camera subsystem with the image signal processor (ISP)
> feature.
>
> omap3isp node
> -
>
> Required properties:
>
> - compatible : should be "ti,omap3isp" for OMAP3;
> - reg : physical addresses and length of the registers set;
> - clocks : list of clock specifiers, corresponding to entries in
> clock-names property;
> - clock-names : must contain "cam_ick", "cam_mclk", "csi2_96m_fck",
> "l3_ick" entries, matching entries in the clocks property;
> - interrupts : must contain mmu interrupt;
> - ti,iommu: phandle to isp mmu;
s/;/./ (or s/;//)
>
> Optional properties:
>
> - VDD_CSIPHY1-supply : regulator for csi phy1
> - VDD_CSIPHY2-supply : regulator for csi phy2
I'd make these lower-case. Upper case is unusual, and lower-case is
preferred.
> - ti,isp-xclk-1 : device(s) attached to ISP's first external
> clock
> - ti,isp-xclk-2 : device(s) attached to ISP's second external
> clock
If the ISP is acting as a clock controller, it should have #clock-cells,
and export clocks to the consumers. They can in turn refer to th ISP via
the standard clocks property.
>
> device-group subnode
>
>
> Required properties:
> - ti,isp-interface-type : Integer describing the interface type, one of
> the following
>* 0 = ISP_INTERFACE_PARALLEL
>* 1 = ISP_INTERFACE_CSI2A_PHY2
>* 2 = ISP_INTERFACE_CCP2B_PHY1
>* 3 = ISP_INTERFACE_CCP2B_PHY2
>* 4 = ISP_INTERFACE_CSI2C_PHY1
Are these PHYs always present?
Are they external to the ISP?
It's not possible for several of these to be valid simultaneously?
> - ti,isp-devices : Array of phandles to devices connected via the
> interface
Which devices are these? This looks backwards to me...
> - One of the following configuration nodes (depending on
> ti,isp-interface-type)
> - ti,ccp2-bus-cfg: CCP2 bus configuration (needed for ISP_INTERFACE_CCP*)
> - ti,parallel-bus-cfg: PARALLEL bus configuration (needed for
> ISP_INTERFACE_PARALLEL)
> - ti,csi2-bus-cfg: CSI bus configuration (needed for ISP_INTERFACE_CSI*)
>
> ccp2-bus-cfg subnode
>
>
> Required properties:
> - ti,video-port-clock-divisor : integer; used for video port output clock
> control
>
> Optional properties:
> - ti,inverted-clock : boolean; clock/strobe signal is inverted
> - ti,enable-crc : boolean; enable crc checking
Why can't this be a run-time option?
> - ti,ccp2-mode-mipi : boolean; port is used in MIPI-CSI1 mode
> (default: CCP2 mode)
> - ti,phy-layer-is-strobe : boolean; use data/strobe physical layer
> (default: data/clock physical layer)
> - ti,data-lane-configuration : integer array with position and polarity
> information for lane 1 and 2
> - ti,clock-lane-configuration : integer array with position and polarity
> information for clock lane
In what precise format?
>
> parallel-bus-cfg subnode
>
>
> Required properties:
> - ti,data-lane-shift : integer; shift data lanes by
> this amount
>
> Optional properties:
> - ti,clock-falling-edge : boolean; sample on
> falling edge (default: rising edge)
> - ti,horizontal-synchronization-active-low: boolean; default: active high
> - ti,vertical-synchronization-active-low : boolean; default: active high
> - ti,data-polarity-ones-complement: boolean; data polarity is
> one's complement
>
> csi2-bus-cfg subnode
>
>
> Required properties:
> - ti,video-port-clock-divisor : integer; used for video port output clock
> control
>
> Optional properties:
> - ti,data-lane-configuration : integer array with position and polarity
> information for lane 1 and 2
> - ti,clock-lane-configuration : integer array with position and polarity
> information for clock lane
> - ti,enable-crc : boolean; enable crc checking
Similarly, run-time selectable?
>
> Example for Nokia N900
> --
>
> omap3isp: isp@480BC000 {
> compatible = "ti,omap3isp";
> reg = <
> /* OMAP3430+ */
> 0x480BC000 0x070/* base */
> 0x480BC100 0x078/* cbuf */
> 0x480BC400 0x1F0/* cpp2 */
> 0x480BC600 0x0A8/* ccdc */
> 0x480BCA00 0x048/* hist */
> 0x480BCC00 0x060/* h3a */
> 0x480BCE00 0x0A0/* prev */
> 0x480BD000 0x0AC/* resz */
> 0x480BD200 0x0FC/* sbl */
> 0x480BD400 0x070/* mmu */
> >;
The bin
Re: [PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Hi, On 09/19/2013 11:41 PM, Russell King wrote: > Replace the following sequence: > > dma_set_mask(dev, mask); > dma_set_coherent_mask(dev, mask); > > with a call to the new helper dma_set_mask_and_coherent(). > > Signed-off-by: Russell King > --- > arch/powerpc/kernel/vio.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c > index 78a3506..96b6c97 100644 > --- a/arch/powerpc/kernel/vio.c > +++ b/arch/powerpc/kernel/vio.c > @@ -1413,8 +1413,7 @@ struct vio_dev *vio_register_device_node(struct > device_node *of_node) > > /* needed to ensure proper operation of coherent allocations >* later, in case driver doesn't set it explicitly */ > - dma_set_mask(&viodev->dev, DMA_BIT_MASK(64)); > - dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64)); > + dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); > } > > /* register with generic device framework */ > The new helper routine dma_set_mask_and_coherent() breaks the initialization of the pseries vio devices which do not have an initial dev->dma_mask. I think we need to use dma_coerce_mask_and_coherent() instead. Signed-off-by: Cédric Le Goater --- arch/powerpc/kernel/vio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index e7d0c88f..76a6482 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); } /* register with generic device framework */ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
Antti Palosaari wrote: > >> I guess I need to check the tuner writes too. > > > >>From dvbsky: > > > > TUNER_write(10, [0a]) > > TUNER_write(11, [40]) > > > > and from your driver: > > > > TUNER_write(10, [0b40]) > > > > That would appear to be some sort of tuner frequency setting? > > ... and the result is same, reg 10 will be 0a and reg 11 40. It is register > write using register address auto-increment. The later one is I/O optimized. Yes, I understand that. However, reg 10 is set to 0a in one driver and 0b in the other. David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH]: v4l2: Introducing the property API
Just to show how it would look like...
Regards,
Hans
Signed-off-by: Hans Verkuil
---
drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +-
drivers/media/v4l2-core/videobuf2-core.c | 2 +-
include/uapi/linux/v4l2-controls.h| 15 ++
include/uapi/linux/videodev2.h| 69 +--
5 files changed, 83 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c
b/drivers/media/usb/cpia2/cpia2_v4l.c
index d5d42b6..51b7759 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -952,7 +952,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct
v4l2_buffer *buf)
buf->sequence = cam->buffers[buf->index].seq;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
buf->length = cam->frame_size;
- buf->reserved2 = 0;
+ buf->config_store = 0;
buf->reserved = 0;
memset(&buf->timecode, 0, sizeof(buf->timecode));
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 8f7a6a4..829eed0 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -322,7 +322,7 @@ struct v4l2_buffer32 {
__s32 fd;
} m;
__u32 length;
- __u32 reserved2;
+ __u32 config_store;
__u32 reserved;
};
@@ -487,7 +487,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, &up->timestamp.tv_usec) ||
copy_to_user(&up->timecode, &kp->timecode, sizeof(struct
v4l2_timecode)) ||
put_user(kp->sequence, &up->sequence) ||
- put_user(kp->reserved2, &up->reserved2) ||
+ put_user(kp->config_store, &up->config_store) ||
put_user(kp->reserved, &up->reserved))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 91412d4..4021b39 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -414,7 +414,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
/* Copy back data such as timestamp, flags, etc. */
memcpy(b, &vb->v4l2_buf, offsetof(struct v4l2_buffer, m));
- b->reserved2 = vb->v4l2_buf.reserved2;
+ b->config_store = vb->v4l2_buf.config_store;
b->reserved = vb->v4l2_buf.reserved;
if (V4L2_TYPE_IS_MULTIPLANAR(q->type)) {
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 1666aab..586467f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -61,6 +61,9 @@
#define V4L2_CTRL_CLASS_DV 0x00a0 /* Digital Video
controls */
#define V4L2_CTRL_CLASS_FM_RX 0x00a1 /* FM Receiver controls
*/
+/* Property classes */
+#define V4L2_PROP_CLASS_USER 0x0898 /* Generic properties */
+
/* User-class control IDs */
#define V4L2_CID_BASE (V4L2_CTRL_CLASS_USER | 0x900)
@@ -886,4 +889,16 @@ enum v4l2_deemphasis {
#define V4L2_CID_RDS_RECEPTION (V4L2_CID_FM_RX_CLASS_BASE + 2)
+/* Generic properties */
+#define V4L2_PID_USER_BASE (V4L2_PROP_CLASS_USER | 0x10)
+
+#define V4L2_PID_CAPTURE_CROP (V4L2_PID_USER_BASE + 0)
+#define V4L2_PID_CAPTURE_COMPOSE (V4L2_PID_USER_BASE + 1)
+#define V4L2_PID_OUTPUT_CROP (V4L2_PID_USER_BASE + 2)
+#define V4L2_PID_OUTPUT_COMPOSE(V4L2_PID_USER_BASE + 3)
+
+/* TODO: use a Motion Detection property class */
+#define V4L2_PID_MD_REGION (V4L2_PID_USER_BASE + 4)
+#define V4L2_PID_MD_THRESHOLD (V4L2_PID_USER_BASE + 5)
+
#endif
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..9faba79 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -640,7 +640,7 @@ struct v4l2_plane {
* @length:size in bytes of the buffer (NOT its payload) for single-plane
* buffers (when type != *_MPLANE); number of elements in the
* planes array for multi-plane buffers
- * @input: input number from which the video data has has been captured
+ * @config_store: this buffer should use this configuration store
*
* Contains data exchanged by application and driver using one of the Streaming
* I/O methods.
@@ -664,7 +664,7 @@ struct v4l2_buffer {
__s32 fd;
} m;
__u32 length;
- __u32 reserved2;
+ __u32 config_s
RFC: Properties, Configuration Storage, Selections and Matrices
Properties, Configuration Storage, Selections and Matrices
==
This proposal is an attempt to solve multiple issues with one single solution.
There have been various discussions in the past regarding a property-based
API. Basically similar to the way controls are handled but without having
to deal with the GUI-related aspects of controls and with more flexibility
with regards to supported types.
Another discussion is about how to atomically set certain pipeline
configurations,
selections in particular. And for Android's camera3 library we also need to
switch configuration on a per-buffer or per-frame basis, so we need some
sort of configuration store.
Also, I proposed an API extension for matrices:
http://www.spinics.net/lists/linux-media/msg67326.html
This would fit better in a property-based API.
Recent discussions regarding multi-selection also ran into the same atomicity
problems and unhappiness about the impact of the API changes necessary to
support multi-selection.
It is quite easy to extend the control framework to support pretty much all
of the requirements stated above. It already satisfies the atomicity
requirements
(by far the hardest to implement), and extending it to support compound,
array and matrix types isn't hard either. Neither is implementing a
configuration
store.
One important observation regarding configuration stores: the information it
can contain should be information that can change while streaming. If it
can't be changed while streaming, then there is no reason to put it in a
config store. Looking at all the ioctls we have there are really only a few
types of ioctls for which this requirement is true: controls and selections
being the primary ones.
S_PARM for setting the timeperframe is another. S_INPUT/OUTPUT might be
useful as well for surveillance apps to switch input/output between frames.
That's not many and it wouldn't be hard to implement that functionality as
properties.
Property API Proposal
=
Step 1: Property IDs
All properties have bit 27 (0x0800) set. So V4L2_CTRL_ID2CLASS(propid)
will always return a value between 0x0800 and 0x0fff.
For controls that range is 0x0098 - 0x07ff. It starts at 0x0098
due to historical reasons.
The existing V4L2_CTRL_FLAG_NEXT_CTRL flag will only enumerate controls.
A new flag V4L2_CTRL_FLAG_NEXT_PROP (0x4000) is added to enumerate
properties. If you want to enumerate both, then both flags need to be set.
Question: should we still use classes to group properties as we do with
controls? Personally I like classes as it enforces a system on what
otherwise will be a big pile of random IDs.
If we keep using classes, then we can decide on making a 1-to-1 mapping
between the classes used for controls and the classes used for properties:
e.g. you have V4L2_CTRL_CLASS_MPEG (0x0099) and V4L2_PROP_CLASS_MPEG
(0x0899).
Properties have a V4L2_PID_ prefix instead of _CID_.
Step 2: Property Types
The enum v4l2_ctrl_type can be extended with new property types. The matrix
proposal referred to above requires u8 and u16 matrix types in order to
implement the motion detection API:
struct v4l2_prop_type_matrix_u8 {
struct v4l2_rect r;
__u8 data[];
};
struct v4l2_prop_type_matrix_u16 {
struct v4l2_rect r;
__u16 data[];
};
V4l2_PROP_TYPE_MATRIX_U8 = 0x100,
V4l2_PROP_TYPE_MATRIX_U16,
All property types start at 0x100, 0x01-0xff is reserved for control types.
The v4l2_rect in the matrix type allows you to set only a subset of a matrix.
Note that an array is a one-dimensional matrix, so I do not see any need to
add specific array support. Yes, higher-dimensions are possible but I have
never seen it in any hardware related to video capture. Should we ever see
that, then we can add a new property type for that.
In order to support compound or matrix types the v4l2_ext_control struct
has to be extended:
struct v4l2_ext_control {
__u32 id;
__u32 size;
__u32 reserved2[1];
union {
__s32 value;
__s64 value64;
char *string;
void *prop;
};
} __attribute__ ((packed));
All types >= 0x100 are assumed to use the prop field and the 'size' field
contains
the total size of the data prop points to. If a property fits one of the
existing
control types, then those should be used of course.
Step 3: Querying Properties
You need to be able to query the properties as well. v4l2_queryctrl is no
longer sufficient, so we add a struct v4l2_query_ext_ctrl and
VIDIOC_QUERY_EXT_CTRL
instead.
I thought about naming it v4l2_queryprop, but it can be used with extended
controls as well, and since all the existing naming is centered around _ext_ctrl
I think this is more consistent.
struct v4l2_query_ext_ctrl {
__u32config_store;
__u32id;
__u
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
Antti Palosaari wrote: > > But you don't give me the option of _not_ setting it. The dvbsky driver > > sets it to 0x35 in its init_tab[] - as does yours - and then leaves it > > alone. > > So what? Do you understand meaning of init tables? Yes. You misunderstand what I'm saying. You unconditionally write cfg->agc to port 0x33 in m88ds3103_set_frontend() after loading the init tables. Why do you need to do that at all if the default is fine? You don't give me the option of saying that I want to stick with the default and not change it. > Just set correct value there and it should be OK. > + .agc = 0x99, Why is 0x99 correct? The default is 0x35 and the dvbsky driver does not alter it from that. Btw, setting it to 0x99 has no obvious effect over leaving it as the default. > > Whilst that may be so, something clears it between one call to > > m88ds3103_set_frontend() and the next, so you probably need to > > unconditionally reload the program init table. > > It is programmed conditionally to avoid I/O. Obviously. Nonetheless, register 0x76 seems to change its value between passes through your code without you touching it inbetween:-/ David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
David Howells wrote: > > I guess I need to check the tuner writes too. > > From dvbsky: > > TUNER_write(10, [0a]) > TUNER_write(11, [40]) > > and from your driver: > > TUNER_write(10, [0b40]) > > That would appear to be some sort of tuner frequency setting? Setting it to 0x0a in the driver doesn't seem to help. David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On 15.11.2013 15:56, David Howells wrote: David Howells wrote: I guess I need to check the tuner writes too. From dvbsky: TUNER_write(10, [0a]) TUNER_write(11, [40]) and from your driver: TUNER_write(10, [0b40]) That would appear to be some sort of tuner frequency setting? ... and the result is same, reg 10 will be 0a and reg 11 40. It is register write using register address auto-increment. The later one is I/O optimized. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
David Howells wrote: > I guess I need to check the tuner writes too. >From dvbsky: TUNER_write(10, [0a]) TUNER_write(11, [40]) and from your driver: TUNER_write(10, [0b40]) That would appear to be some sort of tuner frequency setting? David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On 15.11.2013 15:32, David Howells wrote: Antti Palosaari wrote: demod_write(33, [00]) YES That is config option already. Did you set value? If yes, then there is driver bug. If not, then add value. But you don't give me the option of _not_ setting it. The dvbsky driver sets it to 0x35 in its init_tab[] - as does yours - and then leaves it alone. So what? Do you understand meaning of init tables? If you look those demod drivers about everyone has init tables and it is used just to set some reasonable default values to registers. After that you could change those or leave as is, it is just driver logic. Just set correct value there and it should be OK. + .agc = 0x99, demod_write(76, [38]) YES on init table Whilst that may be so, something clears it between one call to m88ds3103_set_frontend() and the next, so you probably need to unconditionally reload the program init table. It is programmed conditionally to avoid I/O. Loading logic is simply and relies to S/S2/sleep mode change. If there is bug then it should be fixed, but I suspect it is just OK as my device is working. If that logic is broken then result is likely very dramatic - you will be able to view only DVB-S or DVB-S2 channels. So hard code those bugs, if you already didn't, 0x33=0x99, 0x56=0x00, 0xfd=0x46 and make test. Do that same to find out all buggy registers until it performs as it should. I've made my version of your driver now set up the demod regs as per the dvbsky driver for: S 11919000 V 2750 3/4 but: ./scan-s2/scan-s2 -a1 ./e.1 >/tmp/s -O S9.0E -D S2 still doesn't work for your driver, despite two goes at tuning. I guess I need to check the tuner writes too. These bugs sounds more like a demod bugs. Have you tried simple tune using szap/s2-szap to single channel? Don't try scan before it works for single S and S2 channel using zap. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On Fri, Nov 15, 2013 at 8:32 AM, David Howells wrote: > Whilst that may be so, something clears it between one call to > m88ds3103_set_frontend() and the next, so you probably need to unconditionally > reload the program init table. Check your GPIO config for the specific board in the cx23885 driver. Registers unexpectedly resetting to their default value between tunes could very well be because your GPIO setup is incorrect and the demodulator chip's reset line is being strobed between tuning requests. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
Antti Palosaari wrote: > > demod_write(33, [00]) YES > > That is config option already. Did you set value? If yes, then there is driver > bug. If not, then add value. But you don't give me the option of _not_ setting it. The dvbsky driver sets it to 0x35 in its init_tab[] - as does yours - and then leaves it alone. > > demod_write(76, [38]) YES > > on init table Whilst that may be so, something clears it between one call to m88ds3103_set_frontend() and the next, so you probably need to unconditionally reload the program init table. > So hard code those bugs, if you already didn't, 0x33=0x99, 0x56=0x00, > 0xfd=0x46 and make test. Do that same to find out all buggy registers until it > performs as it should. I've made my version of your driver now set up the demod regs as per the dvbsky driver for: S 11919000 V 2750 3/4 but: ./scan-s2/scan-s2 -a1 ./e.1 >/tmp/s -O S9.0E -D S2 still doesn't work for your driver, despite two goes at tuning. I guess I need to check the tuner writes too. David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On 15.11.2013 13:33, David Howells wrote: I think I've isolated the significant part of the demod register setup. Discarding the reads and sorting them in address order, I see ANTTI DVBSKY DIFFER? === === === demod_write(22, [ac]) demod_write(22, [ac]) no demod_write(24, [5c]) demod_write(24, [5c]) no demod_write(25, [8a]) YES seems to be on init table demod_write(29, [80]) demod_write(29, [80]) no demod_write(30, [08]) demod_write(30, [08]) no demod_write(33, [00]) YES That is config option already. Did you set value? If yes, then there is driver bug. If not, then add value. demod_write(4d, [91]) demod_write(4d, [91]) no demod_write(56, [00]) YES driver bug demod_write(61, [5549]) demod_write(61, [55]) no " " demod_write(62, [49]) no demod_write(76, [38]) YES on init table demod_write(c3, [08]) demod_write(c3, [08]) no demod_write(c4, [08]) demod_write(c4, [08]) no demod_write(c7, [00]) demod_write(c7, [00]) no demod_write(c8, [06]) demod_write(c8, [06]) no demod_write(ea, [ff]) demod_write(ea, [ff]) no demod_write(fd, [46]) demod_write(fd, [06]) YES driver bug demod_write(fe, [6f]) demod_write(fe, [6f]) no Two clear driver bugs, 1 case unclear and the rest should be programmed earlier. So hard code those bugs, if you already didn't, 0x33=0x99, 0x56=0x00, 0xfd=0x46 and make test. Do that same to find out all buggy registers until it performs as it should. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] media: i2c: Add ADV761X support
This adds ADV7611/ADV7612 Xpressview HDMI Receiver base
support. Only one HDMI port is supported on ADV7612.
The code is based on the ADV7604 driver, and ADV7612 patch by
Shinobu Uehara
Changes in version 2:
* Used platform data for I2C addresses setup. The driver
should work with both SoC and non-SoC camera models.
* Dropped unnecessary code and unsupported callbacks.
* Implemented IRQ handling for format change detection.
Signed-off-by: Valentine Barshak
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/adv761x.c | 1009 +++
include/media/adv761x.h | 38 ++
4 files changed, 1059 insertions(+)
create mode 100644 drivers/media/i2c/adv761x.c
create mode 100644 include/media/adv761x.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 75c8a03..2388642 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -206,6 +206,17 @@ config VIDEO_ADV7604
To compile this driver as a module, choose M here: the
module will be called adv7604.
+config VIDEO_ADV761X
+ tristate "Analog Devices ADV761X decoder"
+ depends on VIDEO_V4L2 && I2C
+ ---help---
+ Support for the Analog Devices ADV7611/ADV7612 video decoder.
+
+ This is an Analog Devices Xpressview HDMI Receiver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv761x.
+
config VIDEO_ADV7842
tristate "Analog Devices ADV7842 decoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index e03f177..d78d627 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_ADV761X) += adv761x.o
obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o
obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o
diff --git a/drivers/media/i2c/adv761x.c b/drivers/media/i2c/adv761x.c
new file mode 100644
index 000..95939f5
--- /dev/null
+++ b/drivers/media/i2c/adv761x.c
@@ -0,0 +1,1009 @@
+/*
+ * adv761x Analog Devices ADV761X HDMI receiver driver
+ *
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ADV761X_DRIVER_NAME "adv761x"
+
+/* VERT_FILTER_LOCKED and DE_REGEN_FILTER_LOCKED flags */
+#define ADV761X_HDMI_F_LOCKED(v) (((v) & 0xa0) == 0xa0)
+
+/* Maximum supported resolution */
+#define ADV761X_MAX_WIDTH 1920
+#define ADV761X_MAX_HEIGHT 1080
+
+/* Use SoC camera subdev desc private data for platform_data */
+#define ADV761X_SOC_CAM_QUIRK 0x1
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+struct adv761x_color_format {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+/* Supported color format list */
+static const struct adv761x_color_format adv761x_cfmts[] = {
+ {
+ .code = V4L2_MBUS_FMT_RGB888_1X24,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+
+/* ADV761X descriptor structure */
+struct adv761x_state {
+ struct v4l2_subdev sd;
+ struct media_padpad;
+ struct v4l2_ctrl_handlerctrl_hdl;
+
+ u8 edid[256];
+ unsignededid_blocks;
+
+ struct rw_semaphore rwsem;
+ const struct adv761x_color_format *cfmt;
+ u32 width;
+ u32 height;
+ enum v4l2_field scanmode;
+ u32 status;
+
+ int gpio;
+ int irq;
+
+ struct workqueue_struct *work_queue;
+ struct delayed_work enable_hotplug;
+ struct work_struct interrupt_service;
+
+ struct i2c_client
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
I think I've isolated the significant part of the demod register setup. Discarding the reads and sorting them in address order, I see ANTTI DVBSKY DIFFER? === === === demod_write(22, [ac]) demod_write(22, [ac]) no demod_write(24, [5c]) demod_write(24, [5c]) no demod_write(25, [8a]) YES demod_write(29, [80]) demod_write(29, [80]) no demod_write(30, [08]) demod_write(30, [08]) no demod_write(33, [00]) YES demod_write(4d, [91]) demod_write(4d, [91]) no demod_write(56, [00]) YES demod_write(61, [5549]) demod_write(61, [55]) no " " demod_write(62, [49]) no demod_write(76, [38]) YES demod_write(c3, [08]) demod_write(c3, [08]) no demod_write(c4, [08]) demod_write(c4, [08]) no demod_write(c7, [00]) demod_write(c7, [00]) no demod_write(c8, [06]) demod_write(c8, [06]) no demod_write(ea, [ff]) demod_write(ea, [ff]) no demod_write(fd, [46]) demod_write(fd, [06]) YES demod_write(fe, [6f]) demod_write(fe, [6f]) no David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
