[PATCH] staging: media: lirc: adjust boolean assignments

2015-01-26 Thread Heba Aamer 
This patch adjusts boolean assignments from 0/1 to false/true.
And accordingly, it also adjusts the if conditions. 

Signed-off-by: Heba Aamer heba93aa...@gmail.com
---
 drivers/staging/media/lirc/lirc_serial.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_serial.c 
b/drivers/staging/media/lirc/lirc_serial.c
index eb4ccb8..19628d0 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -107,7 +107,7 @@ static int io;
 static int irq;
 static bool iommap;
 static int ioshift;
-static bool softcarrier = 1;
+static bool softcarrier = true;
 static bool share_irq;
 static bool debug;
 static int sense = -1; /* -1 = auto, 0 = active high, 1 = active low */
@@ -266,7 +266,7 @@ static unsigned long space_width;
 /* fetch serial input packet (1 byte) from register offset */
 static u8 sinp(int offset)
 {
-   if (iommap != 0)
+   if (iommap)
/* the register is memory-mapped */
offset = ioshift;
 
@@ -276,7 +276,7 @@ static u8 sinp(int offset)
 /* write serial output packet (1 byte) of value to register offset */
 static void soutp(int offset, u8 value)
 {
-   if (iommap != 0)
+   if (iommap)
/* the register is memory-mapped */
offset = ioshift;
 
@@ -799,10 +799,10 @@ static int lirc_serial_probe(struct platform_device *dev)
 * For memory mapped I/O you *might* need to use ioremap() first,
 * for the NSLU2 it's done in boot code.
 */
-   if (((iommap != 0)
+   if (((iommap)
  (devm_request_mem_region(dev-dev, iommap, 8  ioshift,
 LIRC_DRIVER_NAME) == NULL))
-  || ((iommap == 0)
+  || ((!iommap)
(devm_request_region(dev-dev, io, 8,
   LIRC_DRIVER_NAME) == NULL))) {
dev_err(dev-dev, port %04x already in use\n, io);
-- 
1.7.9.5

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

[PATCH 0/3] Media controller changes to support DVB

2015-01-26 Thread Mauro Carvalho Chehab 
This patch series change the media controller API to allow adding
support for DVB media controller support.

I removed the actual implementation from this series, in order to
better identify the API bits required to add media controller support
to DVB. They'll be sent o a separate patch series, after we agree
with the API needs.

If this gets accepted, the other patches will be basically the ones
already sent at:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg83895.html

With one small change at the patch that adds media controller support
at dvbdev, replacing info.dvb by info.dev, due to a change at the
media controller's representation for all devnodes.

As a reference, a typical analog/digital TV hardware looks like:
http://linuxtv.org/downloads/presentations/typical_hybrid_hardware.png

And the media controller representation for it is:
http://linuxtv.org/downloads/presentations/cx231xx.dot
http://linuxtv.org/downloads/presentations/cx231xx.ps

The full patch series with the DVB controller implementation is at:

http://git.linuxtv.org/cgit.cgi/mchehab/experimental.git/log/?h=dvb-media-ctl

Mauro Carvalho Chehab (3):
  media: Fix ALSA and DVB representation at media controller API
  media: add new types for DVB devnodes
  media: add a subdev type for tuner

 drivers/media/v4l2-core/v4l2-dev.c|  4 ++--
 drivers/media/v4l2-core/v4l2-device.c |  4 ++--
 include/media/media-entity.h  | 12 +---
 include/uapi/linux/media.h| 26 +-
 4 files changed, 30 insertions(+), 16 deletions(-)

-- 
2.1.0

--
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] media: add new types for DVB devnodes

2015-01-26 Thread Mauro Carvalho Chehab 
Most of the DVB subdevs have already their own devnode.

Add support for them at the media controller API.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 418f4fec391a..4c8f26243252 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
 #define MEDIA_ENT_T_DEVNODE_V4L(MEDIA_ENT_T_DEVNODE + 1)
 #define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
 #define MEDIA_ENT_T_DEVNODE_ALSA   (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB(MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX  (MEDIA_ENT_T_DEVNODE + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR(MEDIA_ENT_T_DEVNODE + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET(MEDIA_ENT_T_DEVNODE + 8)
+
+/* Legacy symbol. Use it to avoid userspace compilation breakages */
+#define MEDIA_ENT_T_DEVNODE_DVBMEDIA_ENT_T_DEVNODE_DVB_FE
 
 #define MEDIA_ENT_T_V4L2_SUBDEV(2  MEDIA_ENT_TYPE_SHIFT)
 #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR (MEDIA_ENT_T_V4L2_SUBDEV + 1)
-- 
2.1.0

--
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] media: add a subdev type for tuner

2015-01-26 Thread Mauro Carvalho Chehab 
Add MEDIA_ENT_T_V4L2_SUBDEV_TUNER to represent the V4L2
(and dvb) tuner subdevices.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4c8f26243252..52cc2a6b19b7 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -66,6 +66,8 @@ struct media_device_info {
 /* A converter of analogue video to its digital representation. */
 #define MEDIA_ENT_T_V4L2_SUBDEV_DECODER(MEDIA_ENT_T_V4L2_SUBDEV + 4)
 
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER  (MEDIA_ENT_T_V4L2_SUBDEV + 5)
+
 #define MEDIA_ENT_FL_DEFAULT   (1  0)
 
 struct media_entity_desc {
-- 
2.1.0

--
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] media: Fix ALSA and DVB representation at media controller API

2015-01-26 Thread Mauro Carvalho Chehab 
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.

This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.

This is enough to uniquely identify a devnode, no matter what
API it implements.

So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.

As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index 86bb93fd7db8..d89d5cb465d9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev, int 
type, int nr,
vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
-   vdev-entity.info.v4l.major = VIDEO_MAJOR;
-   vdev-entity.info.v4l.minor = vdev-minor;
+   vdev-entity.info.dev.major = VIDEO_MAJOR;
+   vdev-entity.info.dev.minor = vdev-minor;
ret = media_device_register_entity(vdev-v4l2_dev-mdev,
vdev-entity);
if (ret  0)
diff --git a/drivers/media/v4l2-core/v4l2-device.c 
b/drivers/media/v4l2-core/v4l2-device.c
index 015f92aab44a..204cc67c84e8 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device 
*v4l2_dev)
goto clean_up;
}
 #if defined(CONFIG_MEDIA_CONTROLLER)
-   sd-entity.info.v4l.major = VIDEO_MAJOR;
-   sd-entity.info.v4l.minor = vdev-minor;
+   sd-entity.info.dev.major = VIDEO_MAJOR;
+   sd-entity.info.dev.minor = vdev-minor;
 #endif
sd-devnode = vdev;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..d6d74bcfe183 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -87,17 +87,7 @@ struct media_entity {
struct {
u32 major;
u32 minor;
-   } v4l;
-   struct {
-   u32 major;
-   u32 minor;
-   } fb;
-   struct {
-   u32 card;
-   u32 device;
-   u32 subdevice;
-   } alsa;
-   int dvb;
+   } dev;
 
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..418f4fec391a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -78,6 +78,20 @@ struct media_entity_desc {
struct {
__u32 major;
__u32 minor;
+   } dev;
+
+#if 1
+   /*
+* DEPRECATED: previous node specifications. Kept just to
+* avoid breaking compilation, but media_entity_desc.dev
+* should be used instead. In particular, alsa and dvb
+* fields below are wrong: for all devnodes, there should
+* be just major/minor inside the struct, as this is enough
+* to represent any devnode, no matter what type.
+*/
+   struct {
+   __u32 major;
+   __u32 minor;
} v4l;
struct {
__u32 major;
@@ -89,6 +103,7 @@ struct media_entity_desc {
__u32 subdevice;
} alsa;
int dvb;
+#endif
 
/* Sub-device specifications */
/* Nothing needed yet */
-- 
2.1.0

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

Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API

2015-01-26 Thread Mauro Carvalho Chehab 
Em Mon, 26 Jan 2015 09:00:46 -0500
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

  For media-ctl, it is easier to handle major/minor, in order to identify
  the associated devnode name. Btw, media-ctl currently assumes that all
  devnode devices are specified by v4l.major/v4l.minor.
 
 I suspect part of the motivation for the id that corresponds to the
 adapter field was to make it easier to find the actual underlying
 device node. 

Yes, that was the reason why, back in 2007, we believed that just id
would be enough. Yet, we never tried to implement it, until the end
of the last year.

 While it's trivial to convert a V4L device node from
 major/minor to the device node (since for major number is constant and
 the minor corresponds to the X in /dev/videoX), that's tougher with
 DVB adapters because of the hierarchical nature of the DVB device
 nodes.  Having the adapter number makes it trivial to open
 /dev/dvb/adapterX.
 
 Perhaps my POSIX is rusty -- is there a way to identify the device
 node based on major minor without having to traverse the entire /dev
 tree?

It is actually trivial to get the device nodes once you have the
major/minor. The media-ctl library does that for you. See:

$ media-ctl --print-dot
digraph board {
rankdir=TB
n0001 [label={{port0 0} | cx25840 19-0044 | {port1 1 | port2 
2}}, shape=Mrecord, style=filled, fillcolor=green]
n0001:port1 - n0003
n0001:port2 - n0004
n0002 [label={{} | NXP TDA18271HD | {port0 0}}, shape=Mrecord, 
style=filled, fillcolor=green]
n0002:port0 - n0005 [style=dashed]
n0002:port0 - n0001:port0
n0003 [label=cx231xx #0 video\n/dev/video0, shape=box, 
style=filled, fillcolor=yellow]
n0004 [label=cx231xx #0 vbi\n/dev/vbi0, shape=box, style=filled, 
fillcolor=yellow]
n0005 [label=Fujitsu mb86A20s\n/dev/dvb/adapter0/frontend0, 
shape=box, style=filled, fillcolor=yellow]
n0005 - n0006
n0006 [label=demux\n/dev/dvb/adapter0/demux0, shape=box, 
style=filled, fillcolor=yellow]
n0006 - n0007
n0007 [label=dvr\n/dev/dvb/adapter0/dvr0, shape=box, 
style=filled, fillcolor=yellow]
n0008 [label=dvb net\n/dev/dvb/adapter0/net0, shape=box, 
style=filled, fillcolor=yellow]
}

There are two routines inside the media-ctl libraries to convert from
major/minor into a devnode name like: /dev/dvb/adapter0/demux0.

The first one uses sysfs:

 $ ls -la /sys/dev/char|grep dvb
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:0 - 
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.frontend0
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:1 - 
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.demux0
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:2 - 
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.dvr0
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:3 - 
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.net0

Unfortunately, the sysfs nodes are dvb0 for adapter0, so a patch is needed 
to fix it:

http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/commit/?h=dvb-media-ctlid=d854a9bb24706dbfc878484e4538d79b1ac52aae

The second (and better) approach is to require udev to return the name of the
devnode. The logic, implemented at utils/media-ctl/libmediactl.c, inside
v4l-utils, is:

devnum = makedev(entity-info.v4l.major, entity-info.v4l.minor);
media_dbg(entity-media, looking up device: %u:%u\n,
  major(devnum), minor(devnum));
device = udev_device_new_from_devnum(udev, 'c', devnum);

Right now, by default, media-ctl will use the sysfs approach, except
if an extra option is called at ./configure, in order to enable it to
use the udev library.

IMHO, we should make udev the default behavior, if libudev-dev(el) is 
there at compilation time.

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

Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API

2015-01-26 Thread Devin Heitmueller 
 It is actually trivial to get the device nodes once you have the
 major/minor. The media-ctl library does that for you. See:

No objection then.

On a related note, you would be very well served to consider testing
your dvb changes with a device that has more than one DVB tuner (such
as the hvr-2200/2250).  That will help you shake out any edge cases
related to ensuring that the different DVB nodes appear in different
groups.

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] media: am437x: fix sparse warnings

2015-01-26 Thread Lad, Prabhakar 
This patch fixes following spare warnings:

drivers/media/platform/am437x/am437x-vpfe.c:66:28: warning: symbol 
'vpfe_standards' was not declared. Should it be static?
drivers/media/platform/am437x/am437x-vpfe.c:2202:57: warning: incorrect type in 
argument 2 (different address spaces)
drivers/media/platform/am437x/am437x-vpfe.c:2202:57:expected void [noderef] 
asn:1*params
drivers/media/platform/am437x/am437x-vpfe.c:2202:57:got void *param
include/linux/spinlock.h:364:9: warning: context imbalance in 
'vpfe_start_streaming' - unexpected unlock

Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
 drivers/media/platform/am437x/am437x-vpfe.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
b/drivers/media/platform/am437x/am437x-vpfe.c
index e01ac22..349bd06 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -63,7 +63,7 @@ struct vpfe_standard {
int frame_format;
 };
 
-const struct vpfe_standard vpfe_standards[] = {
+static const struct vpfe_standard vpfe_standards[] = {
{V4L2_STD_525_60, 720, 480, {11, 10}, 1},
{V4L2_STD_625_50, 720, 576, {54, 59}, 1},
 };
@@ -2024,7 +2024,6 @@ err:
list_del(buf-list);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_QUEUED);
}
-   spin_unlock_irqrestore(vpfe-dma_queue_lock, flags);
 
return ret;
 }
@@ -2199,7 +2198,7 @@ static long vpfe_ioctl_default(struct file *file, void 
*priv,
 
switch (cmd) {
case VIDIOC_AM437X_CCDC_CFG:
-   ret = vpfe_ccdc_set_params(vpfe-ccdc, param);
+   ret = vpfe_ccdc_set_params(vpfe-ccdc, (void __user *)param);
if (ret) {
vpfe_dbg(2, vpfe,
Error setting parameters in CCDC\n);
-- 
1.9.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

Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API

2015-01-26 Thread Mauro Carvalho Chehab 
Em Mon, 26 Jan 2015 14:11:50 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:

 On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
  The previous provision for DVB media controller support were to
  define an ID (likely meaning the adapter number) for the DVB
  devnodes.
  
  This is just plain wrong. Just like V4L, DVB devices (and ALSA,
  or whatever) are identified via a (major, minor) tuple.
  
  This is enough to uniquely identify a devnode, no matter what
  API it implements.
  
  So, before we go too far, let's mark the old v4l, dvb and alsa
  devnode info as deprecated, and just call it as dev.
  
  As we don't want to break compilation on already existing apps,
  let's just keep the old definitions as-is, adding a note that
  those are deprecated at media-entity.h.
  
  Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
  
  diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
  b/drivers/media/v4l2-core/v4l2-dev.c
  index 86bb93fd7db8..d89d5cb465d9 100644
  --- a/drivers/media/v4l2-core/v4l2-dev.c
  +++ b/drivers/media/v4l2-core/v4l2-dev.c
  @@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev, 
  int type, int nr,
  vdev-vfl_type != VFL_TYPE_SUBDEV) {
  vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
  vdev-entity.name = vdev-name;
  -   vdev-entity.info.v4l.major = VIDEO_MAJOR;
  -   vdev-entity.info.v4l.minor = vdev-minor;
  +   vdev-entity.info.dev.major = VIDEO_MAJOR;
  +   vdev-entity.info.dev.minor = vdev-minor;
  ret = media_device_register_entity(vdev-v4l2_dev-mdev,
  vdev-entity);
  if (ret  0)
  diff --git a/drivers/media/v4l2-core/v4l2-device.c 
  b/drivers/media/v4l2-core/v4l2-device.c
  index 015f92aab44a..204cc67c84e8 100644
  --- a/drivers/media/v4l2-core/v4l2-device.c
  +++ b/drivers/media/v4l2-core/v4l2-device.c
  @@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct 
  v4l2_device *v4l2_dev)
  goto clean_up;
  }
   #if defined(CONFIG_MEDIA_CONTROLLER)
  -   sd-entity.info.v4l.major = VIDEO_MAJOR;
  -   sd-entity.info.v4l.minor = vdev-minor;
  +   sd-entity.info.dev.major = VIDEO_MAJOR;
  +   sd-entity.info.dev.minor = vdev-minor;
   #endif
  sd-devnode = vdev;
  }
  diff --git a/include/media/media-entity.h b/include/media/media-entity.h
  index e00459185d20..d6d74bcfe183 100644
  --- a/include/media/media-entity.h
  +++ b/include/media/media-entity.h
  @@ -87,17 +87,7 @@ struct media_entity {
  struct {
  u32 major;
  u32 minor;
  -   } v4l;
  -   struct {
  -   u32 major;
  -   u32 minor;
  -   } fb;
  -   struct {
  -   u32 card;
  -   u32 device;
  -   u32 subdevice;
  -   } alsa;
 
 I don't think the alsa entity information can be replaced by major/minor.
 In particular you will loose the subdevice information which you need as
 well. In addition, alsa devices are almost never referenced via major and
 minor numbers, but always by card/device/subdevice numbers.

For media-ctl, it is easier to handle major/minor, in order to identify
the associated devnode name. Btw, media-ctl currently assumes that all
devnode devices are specified by v4l.major/v4l.minor.

Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
interface (with seems to be doubtful).

 
  -   int dvb;
  +   } dev;
   
  /* Sub-device specifications */
  /* Nothing needed yet */
  diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
  index d847c760e8f0..418f4fec391a 100644
  --- a/include/uapi/linux/media.h
  +++ b/include/uapi/linux/media.h
  @@ -78,6 +78,20 @@ struct media_entity_desc {
  struct {
  __u32 major;
  __u32 minor;
  +   } dev;
  +
  +#if 1
  +   /*
  +* DEPRECATED: previous node specifications. Kept just to
  +* avoid breaking compilation, but media_entity_desc.dev
  +* should be used instead. In particular, alsa and dvb
  +* fields below are wrong: for all devnodes, there should
  +* be just major/minor inside the struct, as this is enough
  +* to represent any devnode, no matter what type.
  +*/
  +   struct {
  +   __u32 major;
  +   __u32 minor;
  } v4l;
  struct {
  __u32 major;
  @@ -89,6 +103,7 @@ struct media_entity_desc {
  __u32 subdevice;
  } alsa;
  int dvb;
 
 I wouldn't merge all the v4l/fb/etc. structs into one struct. That will make 
 it
 difficult in the future if

[linuxtv-media:master 66/93] drivers/media/platform/am437x/am437x-vpfe.c:2202:57: sparse: incorrect type in argument 2 (different address spaces)

2015-01-26 Thread kbuild test robot 
tree:   git://linuxtv.org/media_tree.git master
head:   e32b31ae45c18679c186e67aa41d0e2318cae487
commit: 417d2e507edcb5cf15eb344f86bd3dd28737f24e [66/93] [media] media: 
platform: add VPFE capture driver support for AM437X
reproduce:
  # apt-get install sparse
  git checkout 417d2e507edcb5cf15eb344f86bd3dd28737f24e
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by )

 drivers/media/platform/am437x/am437x-vpfe.c:2202:57: sparse: incorrect type 
 in argument 2 (different address spaces)
   drivers/media/platform/am437x/am437x-vpfe.c:2202:57:expected void 
[noderef] asn:1*params
   drivers/media/platform/am437x/am437x-vpfe.c:2202:57:got void *param
 include/linux/spinlock.h:364:9: sparse: context imbalance in 
 'vpfe_start_streaming' - unexpected unlock

vim +2202 drivers/media/platform/am437x/am437x-vpfe.c

  2186  
  2187  vpfe_dbg(2, vpfe, vpfe_ioctl_default\n);
  2188  
  2189  if (!valid_prio) {
  2190  vpfe_err(vpfe, %s device busy\n, __func__);
  2191  return -EBUSY;
  2192  }
  2193  
  2194  /* If streaming is started, return error */
  2195  if (vb2_is_busy(vpfe-buffer_queue)) {
  2196  vpfe_err(vpfe, %s device busy\n, __func__);
  2197  return -EBUSY;
  2198  }
  2199  
  2200  switch (cmd) {
  2201  case VIDIOC_AM437X_CCDC_CFG:
 2202  ret = vpfe_ccdc_set_params(vpfe-ccdc, param);
  2203  if (ret) {
  2204  vpfe_dbg(2, vpfe,
  2205  Error setting parameters in CCDC\n);
  2206  return ret;
  2207  }
  2208  ret = vpfe_get_ccdc_image_format(vpfe,
  2209   vpfe-fmt);
  2210  if (ret  0) {

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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] media: adv7604: CP CSC uses a different register on adv7604 and adv7611

2015-01-26 Thread Jean-Michel Hautbois 
The bits are the same, but register is 0xf4 on ADV7611 instead of 0xfc.
When reading back the value in log_status, differentiate both.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/media/i2c/adv7604.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e43dd2e..32e53e0 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2310,8 +2310,12 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
(reg_io_0x02  0x04) ? (16-235) : (0-255),
((reg_io_0x02  0x04) ^ (reg_io_0x02  0x01)) ?
enabled : disabled);
-   v4l2_info(sd, Color space conversion: %s\n,
+   if (state-info-type == ADV7604)
+   v4l2_info(sd, Color space conversion: %s\n,
csc_coeff_sel_rb[cp_read(sd, 0xfc)  4]);
+   else
+   v4l2_info(sd, Color space conversion: %s\n,
+   csc_coeff_sel_rb[cp_read(sd, 0xf4)  4]);
 
if (!is_digital_input(sd))
return 0;
-- 
2.2.2

--
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: PCTV 800i

2015-01-26 Thread Steven Toth 
On Mon, Jan 26, 2015 at 12:50 AM, John Klug ski.brim...@gmail.com wrote:
 I have a new PCTV card with CX23880 (not CX23883 as shown in the picture):

 http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_(800i)

 The description is out of date with respect to my recent card.

 It did not work in 3.12.20, 3.17.7, and I finally downloaded the
 latest GIT of media_build to no avail (I have a 2nd card that is CX18,
 which is interspersed in the output).

The error messages suggest one or more of the components on the board,
or their I2C addresses have changed, or that your hardware is bad.

Other than the Conexant PCI bridge, do the other components listed in
the wiki page match the components on your physical device?

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API

2015-01-26 Thread Devin Heitmueller 
 For media-ctl, it is easier to handle major/minor, in order to identify
 the associated devnode name. Btw, media-ctl currently assumes that all
 devnode devices are specified by v4l.major/v4l.minor.

I suspect part of the motivation for the id that corresponds to the
adapter field was to make it easier to find the actual underlying
device node.  While it's trivial to convert a V4L device node from
major/minor to the device node (since for major number is constant and
the minor corresponds to the X in /dev/videoX), that's tougher with
DVB adapters because of the hierarchical nature of the DVB device
nodes.  Having the adapter number makes it trivial to open
/dev/dvb/adapterX.

Perhaps my POSIX is rusty -- is there a way to identify the device
node based on major minor without having to traverse the entire /dev
tree?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API

2015-01-26 Thread Hans Verkuil 
On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
 The previous provision for DVB media controller support were to
 define an ID (likely meaning the adapter number) for the DVB
 devnodes.
 
 This is just plain wrong. Just like V4L, DVB devices (and ALSA,
 or whatever) are identified via a (major, minor) tuple.
 
 This is enough to uniquely identify a devnode, no matter what
 API it implements.
 
 So, before we go too far, let's mark the old v4l, dvb and alsa
 devnode info as deprecated, and just call it as dev.
 
 As we don't want to break compilation on already existing apps,
 let's just keep the old definitions as-is, adding a note that
 those are deprecated at media-entity.h.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
 
 diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
 b/drivers/media/v4l2-core/v4l2-dev.c
 index 86bb93fd7db8..d89d5cb465d9 100644
 --- a/drivers/media/v4l2-core/v4l2-dev.c
 +++ b/drivers/media/v4l2-core/v4l2-dev.c
 @@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev, 
 int type, int nr,
   vdev-vfl_type != VFL_TYPE_SUBDEV) {
   vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
   vdev-entity.name = vdev-name;
 - vdev-entity.info.v4l.major = VIDEO_MAJOR;
 - vdev-entity.info.v4l.minor = vdev-minor;
 + vdev-entity.info.dev.major = VIDEO_MAJOR;
 + vdev-entity.info.dev.minor = vdev-minor;
   ret = media_device_register_entity(vdev-v4l2_dev-mdev,
   vdev-entity);
   if (ret  0)
 diff --git a/drivers/media/v4l2-core/v4l2-device.c 
 b/drivers/media/v4l2-core/v4l2-device.c
 index 015f92aab44a..204cc67c84e8 100644
 --- a/drivers/media/v4l2-core/v4l2-device.c
 +++ b/drivers/media/v4l2-core/v4l2-device.c
 @@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device 
 *v4l2_dev)
   goto clean_up;
   }
  #if defined(CONFIG_MEDIA_CONTROLLER)
 - sd-entity.info.v4l.major = VIDEO_MAJOR;
 - sd-entity.info.v4l.minor = vdev-minor;
 + sd-entity.info.dev.major = VIDEO_MAJOR;
 + sd-entity.info.dev.minor = vdev-minor;
  #endif
   sd-devnode = vdev;
   }
 diff --git a/include/media/media-entity.h b/include/media/media-entity.h
 index e00459185d20..d6d74bcfe183 100644
 --- a/include/media/media-entity.h
 +++ b/include/media/media-entity.h
 @@ -87,17 +87,7 @@ struct media_entity {
   struct {
   u32 major;
   u32 minor;
 - } v4l;
 - struct {
 - u32 major;
 - u32 minor;
 - } fb;
 - struct {
 - u32 card;
 - u32 device;
 - u32 subdevice;
 - } alsa;

I don't think the alsa entity information can be replaced by major/minor.
In particular you will loose the subdevice information which you need as
well. In addition, alsa devices are almost never referenced via major and
minor numbers, but always by card/device/subdevice numbers.

 - int dvb;
 + } dev;
  
   /* Sub-device specifications */
   /* Nothing needed yet */
 diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
 index d847c760e8f0..418f4fec391a 100644
 --- a/include/uapi/linux/media.h
 +++ b/include/uapi/linux/media.h
 @@ -78,6 +78,20 @@ struct media_entity_desc {
   struct {
   __u32 major;
   __u32 minor;
 + } dev;
 +
 +#if 1
 + /*
 +  * DEPRECATED: previous node specifications. Kept just to
 +  * avoid breaking compilation, but media_entity_desc.dev
 +  * should be used instead. In particular, alsa and dvb
 +  * fields below are wrong: for all devnodes, there should
 +  * be just major/minor inside the struct, as this is enough
 +  * to represent any devnode, no matter what type.
 +  */
 + struct {
 + __u32 major;
 + __u32 minor;
   } v4l;
   struct {
   __u32 major;
 @@ -89,6 +103,7 @@ struct media_entity_desc {
   __u32 subdevice;
   } alsa;
   int dvb;

I wouldn't merge all the v4l/fb/etc. structs into one struct. That will make it
difficult in the future if you need to add a field for e.g. v4l entities.

So I would keep the v4l, fb and alsa structs, and just add a new struct for
dvb. I wonder if the dvb field can't just be replaced since I doubt anyone is
using it. And even if someone does, then it can't be right since a single
int isn't enough and never worked anyway.

Regards,

Hans

 +#endif
  
   /* Sub-device specifications */
   /* Nothing needed yet */
 

--
To unsubscribe from this

Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API

2015-01-26 Thread Hans Verkuil 
On 01/26/2015 02:34 PM, Mauro Carvalho Chehab wrote:
 Em Mon, 26 Jan 2015 14:11:50 +0100
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
 On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
 The previous provision for DVB media controller support were to
 define an ID (likely meaning the adapter number) for the DVB
 devnodes.

 This is just plain wrong. Just like V4L, DVB devices (and ALSA,
 or whatever) are identified via a (major, minor) tuple.

 This is enough to uniquely identify a devnode, no matter what
 API it implements.

 So, before we go too far, let's mark the old v4l, dvb and alsa
 devnode info as deprecated, and just call it as dev.

 As we don't want to break compilation on already existing apps,
 let's just keep the old definitions as-is, adding a note that
 those are deprecated at media-entity.h.

 Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

 diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
 b/drivers/media/v4l2-core/v4l2-dev.c
 index 86bb93fd7db8..d89d5cb465d9 100644
 --- a/drivers/media/v4l2-core/v4l2-dev.c
 +++ b/drivers/media/v4l2-core/v4l2-dev.c
 @@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev, 
 int type, int nr,
 vdev-vfl_type != VFL_TYPE_SUBDEV) {
 vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
 vdev-entity.name = vdev-name;
 -   vdev-entity.info.v4l.major = VIDEO_MAJOR;
 -   vdev-entity.info.v4l.minor = vdev-minor;
 +   vdev-entity.info.dev.major = VIDEO_MAJOR;
 +   vdev-entity.info.dev.minor = vdev-minor;
 ret = media_device_register_entity(vdev-v4l2_dev-mdev,
 vdev-entity);
 if (ret  0)
 diff --git a/drivers/media/v4l2-core/v4l2-device.c 
 b/drivers/media/v4l2-core/v4l2-device.c
 index 015f92aab44a..204cc67c84e8 100644
 --- a/drivers/media/v4l2-core/v4l2-device.c
 +++ b/drivers/media/v4l2-core/v4l2-device.c
 @@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct 
 v4l2_device *v4l2_dev)
 goto clean_up;
 }
  #if defined(CONFIG_MEDIA_CONTROLLER)
 -   sd-entity.info.v4l.major = VIDEO_MAJOR;
 -   sd-entity.info.v4l.minor = vdev-minor;
 +   sd-entity.info.dev.major = VIDEO_MAJOR;
 +   sd-entity.info.dev.minor = vdev-minor;
  #endif
 sd-devnode = vdev;
 }
 diff --git a/include/media/media-entity.h b/include/media/media-entity.h
 index e00459185d20..d6d74bcfe183 100644
 --- a/include/media/media-entity.h
 +++ b/include/media/media-entity.h
 @@ -87,17 +87,7 @@ struct media_entity {
 struct {
 u32 major;
 u32 minor;
 -   } v4l;
 -   struct {
 -   u32 major;
 -   u32 minor;
 -   } fb;
 -   struct {
 -   u32 card;
 -   u32 device;
 -   u32 subdevice;
 -   } alsa;

 I don't think the alsa entity information can be replaced by major/minor.
 In particular you will loose the subdevice information which you need as
 well. In addition, alsa devices are almost never referenced via major and
 minor numbers, but always by card/device/subdevice numbers.
 
 For media-ctl, it is easier to handle major/minor, in order to identify
 the associated devnode name. Btw, media-ctl currently assumes that all
 devnode devices are specified by v4l.major/v4l.minor.
 
 Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
 should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
 interface (with seems to be doubtful).

The card/device tuple can likely be mapped to major/minor, but not subdevice.
And since everything inside alsa is based on card/device I wouldn't change
that.

 

 -   int dvb;
 +   } dev;
  
 /* Sub-device specifications */
 /* Nothing needed yet */
 diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
 index d847c760e8f0..418f4fec391a 100644
 --- a/include/uapi/linux/media.h
 +++ b/include/uapi/linux/media.h
 @@ -78,6 +78,20 @@ struct media_entity_desc {
 struct {
 __u32 major;
 __u32 minor;
 +   } dev;
 +
 +#if 1
 +   /*
 +* DEPRECATED: previous node specifications. Kept just to
 +* avoid breaking compilation, but media_entity_desc.dev
 +* should be used instead. In particular, alsa and dvb
 +* fields below are wrong: for all devnodes, there should
 +* be just major/minor inside the struct, as this is enough
 +* to represent any devnode, no matter what type.
 +*/
 +   struct {
 +   __u32 major;
 +   __u32 minor;
 } v4l;
 struct {
 __u32 major;
 @@ -89,6 +103,7 @@ struct media_entity_desc {
 __u32 subdevice;
 } alsa;
 int dvb;

RE: [PATCH v4 08/10] v4l: xilinx: Add Xilinx Video IP core

2015-01-26 Thread Chris Kohn 
Hans and Laurent,

 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Thursday, January 22, 2015 1:44 AM
 To: Laurent Pinchart; Chris Kohn
 Cc: linux-media@vger.kernel.org; Michal Simek; Hyun Kwon;
 devicet...@vger.kernel.org
 Subject: Re: [PATCH v4 08/10] v4l: xilinx: Add Xilinx Video IP core

 On 01/22/15 04:01, Laurent Pinchart wrote:
  Hi Hans and Chris,
 
  On Monday 01 December 2014 22:13:38 Laurent Pinchart wrote:
  Xilinx platforms have no hardwired video capture or video processing
  interface. Users create capture and memory to memory processing
  pipelines in the FPGA fabric to suit their particular needs, by
  instantiating video IP cores from a large library.
 
  The Xilinx Video IP core is a framework that models a video pipeline
  described in the device tree and expose the pipeline to userspace
  through the media controller and V4L2 APIs.
 
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  Signed-off-by: Hyun Kwon hyun.k...@xilinx.com
  Signed-off-by: Radhey Shyam Pandey radh...@xilinx.com
  Signed-off-by: Michal Simek michal.si...@xilinx.com
 
  [snip]
 
  diff --git a/Documentation/devicetree/bindings/media/xilinx/video.txt
  b/Documentation/devicetree/bindings/media/xilinx/video.txt new file
  mode
  100644
  index 000..15720e4
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/media/xilinx/video.txt
  @@ -0,0 +1,52 @@
  +DT bindings for Xilinx video IP cores
  +-
  +
  +Xilinx video IP cores process video streams by acting as video sinks
  +and/or sources. They are connected by links through their input and
  +output ports, creating a video pipeline.
  +
  +Each video IP core is represented by an AMBA bus child node in the
  +device tree using bindings documented in this directory. Connections
  +between the
  IP
  +cores are represented as defined in ../video-interfaces.txt.
  +
  +The whole  pipeline is represented by an AMBA bus child node in the
  +device tree using bindings documented in ./xlnx,video.txt.
  +
  +Common properties
  +-
  +
  +The following properties are common to all Xilinx video IP cores.
  +
  +- xlnx,video-format: This property represents a video format
  +transmitted on
  an
  +  AXI bus between video IP cores. How the format relates to the IP
  + core is  decribed in the IP core bindings documentation. The
  + following formats are  supported.
  +
  +  rbg
  +  xrgb
  +  yuv422
  +  yuv444
  +  rggb
  +  grbg
  +  gbrg
  +  bggr
  +
  +- xlnx,video-width: This property qualifies the video format with
  +the
  sample
  +  width expressed as a number of bits per pixel component. All
  + components
  must
  +  use the same width.
 
  Hans, last time we've discussed this on IRC you were not happy with
  the format description used in these DT bindings. Your argument was,
  if I remember correctly, that as the formats map directly to media bus
  codes, it would be better to use the media bus codes (or a string
  representation of them) in the bindings instead of creating a new format
 description. Is that correct ?

 Correct. Where possible I think the names should map to the mediabus names.
 So uyvy instead of yuv422, srggb instead of rggb, etc.

A string representation of the mediabus names sounds good to me.

Cheers,
Chris

 
  Chris, what's your opinion on that ? The RGB and YUV formats in the
  table below describe the hardware and come from table 1-4 on page 8 of
 
 http://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/
 v1_0/ug934_axi_videoIP.pdf.
  The Bayer formats are not standardized in the document, and I don't
  think we need them at the moment.
 
  +The following table lists the supported formats and widths
  +combinations,
  along
  +with the corresponding media bus pixel code.
  +
  ++---+---
  ++---+---
  +Format| Width | Media bus code
  ++---+---
  ++---+---
  +rbg   | 8 | V4L2_MBUS_FMT_RBG888_1X24
  +xrgb  | 8 | V4L2_MBUS_FMT_RGB888_1X32_PADHI
  +yuv422| 8 | V4L2_MBUS_FMT_UYVY8_1X16
  +yuv444| 8 | V4L2_MBUS_FMT_VUY888_1X24
  +rggb  | 8 | V4L2_MBUS_FMT_SRGGB8_1X8
  +grbg  | 8 | V4L2_MBUS_FMT_SGRBG8_1X8
  +gbrg  | 8 | V4L2_MBUS_FMT_SGBRG8_1X8
  +bggr  | 8 | V4L2_MBUS_FMT_SBGGR8_1X8
  ++---+---
  ++---+---
  diff --git
  a/Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt
  b/Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt new
  file mode 100644 index 000..5a02270
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt
  @@ -0,0 +1,55 @@
  +Xilinx Video IP Pipeline (VIPP)

Strange behaviour of sizeof(struct v4l2_queryctrl)

2015-01-26 Thread Francesco Marletta 

Hello to anyone,
I'm working on a problem with V4L2 on Linux Kernel 2.6.37.

The problem arise when I try to query a video device to list the 
controls it provides.


When is call
ioctl(fd, VIDIOC_QUERYCTRL, queryctrl)

the function doesn't return 0 and errno is set to EINVAL

This happen for every control, even for the controls that the driver 
provides (checked in the code) like brightness.


After adding a lot of printk in the videodev.ko module I found that the 
problem is caused by a wrong value of VIDIOC_QUERYCTRL, that in the 
kernel module is 0xC0485624 while in userspace application is 0xC0445624.


I digged the kernel source to understand what's happening, and 
discovered the definition of VIDIOC_QUERYCTRL:
#define VIDIOC_QUERYCTRL_IOWR('V', 36, struct 
v4l2_queryctrl)


dove:
#define _IOWR(type,nr,size) \
_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))

with
#define _IOC(dir,type,nr,size) \
(((dir)   _IOC_DIRSHIFT)  | \
((type)   _IOC_TYPESHIFT) | \
((nr) _IOC_NRSHIFT)   | \
((size)   _IOC_SIZESHIFT))

and
#define _IOC_NRSHIFT0
#define _IOC_TYPESHIFT  (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT  (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT   (_IOC_SIZESHIFT+_IOC_SIZEBITS)

#define _IOC_NRBITS 8
#define _IOC_TYPEBITS   8
#define _IOC_SIZEBITS   14

#define _IOC_NONE   0U
#define _IOC_WRITE  1U
#define _IOC_READ   2U

#define _IOC_TYPECHECK(t) (sizeof(t))

thus, the _IOC definition means:
_IOC(dir,type,nr,size)   =   [dir|size|type|nr]

that, for the aftermentioned values means:
0xC0445624 = [3|044|56|24]  == size = 0x44 = 68
0xC0485624 = [3|048|56|24]  == size = 0x48 = 72

To be sure that the number 68 and 72 are correct, I added a printk() in 
the videodev.ko module and a println() in the userspace application to 
print sizeof(struct v4l2_queryctrl), and the outputs are:


Kernel module:
printk([DBG] %s() ~ sizeof(struct v4l2_queryctrl): %u\n, 
__func__, sizeof(struct v4l2_queryctrl));

= [DBG] videodev_init() ~ sizeof(struct v4l2_queryctrl): 72

Userspace application:
printf([dbg] sizeof(struct v4l2_queryctrl): %u\n, 
sizeof(struct v4l2_queryctrl));

= [dbg] sizeof(struct v4l2_queryctrl): 68

In both cases (module and application), there is the inclusion of 
linux/videodev2.h.


When I compiled the application I istructed the compiler to pick the 
same kernel header of the module, with a proper CFLAGS += -IPATH in 
the Makefile.


Any idea about this strangeness?

Regards
Francesco
--
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/2] media: rcar_vin: move buffer management to .stop_streaming handler

2015-01-26 Thread William Towle 
This commit moves the buffer in use logic from the .buf_cleanup
handler into .stop_streaming, based on advice that this is its
proper logical home.

By ensuring the list of pointers in priv-queue_buf[] is managed
as soon as possible, we avoid warnings concerning buffers in ACTIVE
state when the system cleans up after streaming stops. This fixes a
problem with modification of buffers after their content has been
cleared for passing to userspace.

After the refactoring, the buf_init and buf_cleanup functions were
found to contain only initialisation/release steps as are carried out
elsewhere if omitted; these functions and references were removed.

Signed-off-by: William Towle william.to...@codethink.co.uk
---
 drivers/media/platform/soc_camera/rcar_vin.c |   62 ++
 1 file changed, 13 insertions(+), 49 deletions(-)

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 89c409b..aa25a3b 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -480,72 +480,36 @@ static void rcar_vin_wait_stop_streaming(struct 
rcar_vin_priv *priv)
}
 }
 
-static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
+static void rcar_vin_stop_streaming(struct vb2_queue *vq)
 {
-   struct soc_camera_device *icd = soc_camera_from_vb2q(vb-vb2_queue);
+   struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct rcar_vin_priv *priv = ici-priv;
-   unsigned int i;
-   int buf_in_use = 0;
+   struct list_head *buf_head, *tmp;
+   int i;
 
spin_lock_irq(priv-lock);
+   rcar_vin_wait_stop_streaming(priv);
 
-   /* Is the buffer in use by the VIN hardware? */
for (i = 0; i  MAX_BUFFER_NUM; i++) {
-   if (priv-queue_buf[i] == vb) {
-   buf_in_use = 1;
-   break;
-   }
-   }
-
-   if (buf_in_use) {
-   rcar_vin_wait_stop_streaming(priv);
-
-   /*
-* Capturing has now stopped. The buffer we have been asked
-* to release could be any of the current buffers in use, so
-* release all buffers that are in use by HW
-*/
-   for (i = 0; i  MAX_BUFFER_NUM; i++) {
-   if (priv-queue_buf[i]) {
-   vb2_buffer_done(priv-queue_buf[i],
+   if (priv-queue_buf[i]) {
+   vb2_buffer_done(priv-queue_buf[i],
VB2_BUF_STATE_ERROR);
-   priv-queue_buf[i] = NULL;
-   }
+   priv-queue_buf[i] = NULL;
}
-   } else {
-   list_del_init(to_buf_list(vb));
}
 
-   spin_unlock_irq(priv-lock);
-}
-
-static int rcar_vin_videobuf_init(struct vb2_buffer *vb)
-{
-   INIT_LIST_HEAD(to_buf_list(vb));
-   return 0;
-}
-
-static void rcar_vin_stop_streaming(struct vb2_queue *vq)
-{
-   struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
-   struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
-   struct rcar_vin_priv *priv = ici-priv;
-   struct list_head *buf_head, *tmp;
-
-   spin_lock_irq(priv-lock);
-
-   rcar_vin_wait_stop_streaming(priv);
-   list_for_each_safe(buf_head, tmp, priv-capture)
+   list_for_each_safe(buf_head, tmp, priv-capture) {
+   vb2_buffer_done(list_entry(buf_head,
+   struct rcar_vin_buffer, list)-vb,
+   VB2_BUF_STATE_ERROR);
list_del_init(buf_head);
-
+   }
spin_unlock_irq(priv-lock);
 }
 
 static struct vb2_ops rcar_vin_vb2_ops = {
.queue_setup= rcar_vin_videobuf_setup,
-   .buf_init   = rcar_vin_videobuf_init,
-   .buf_cleanup= rcar_vin_videobuf_release,
.buf_queue  = rcar_vin_videobuf_queue,
.stop_streaming = rcar_vin_stop_streaming,
.wait_prepare   = soc_camera_unlock,
-- 
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

rcar_vin video buffer management fixes, v3

2015-01-26 Thread William Towle 
  This is version 3 of the hotfix patchset for video support on Lager,
in which we aim to fix the kernel's warnings about unexpected buffer
states. It replaces the following series:

http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/87009

  This version of the series contains two patches which add a helper
function and then refactors the code where it is called, respectively.
Based on recent feedback, further modification is included in the
second patch where initialise/cleanup routines are removed due to
all significant content having moved elsewhere.

  The series comprises:
[PATCH 1/2] media: rcar_vin: helper function for streaming stop
[PATCH 2/2] media: rcar_vin: move buffer management to

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

[PATCH 1/2] media: rcar_vin: helper function for streaming stop

2015-01-26 Thread William Towle 
From: Ian Molton ian.mol...@codethink.co.uk

The code that tests that capture from a stream has stopped is
presently insufficient and the potential for a race condition
exists where frame capture may generate an interrupt between
requesting the capture process halt and freeing buffers.

This patch refactors code out of rcar_vin_videobuf_release() and
into rcar_vin_wait_stop_streaming(), and ensures there are calls
in places where we need to know that capturing has finished.

Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Signed-off-by: William Towle william.to...@codethink.co.uk
---
 drivers/media/platform/soc_camera/rcar_vin.c |   41 +-
 1 file changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 8d8438b..89c409b 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -458,6 +458,28 @@ error:
vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
 }
 
+/*
+ * Wait for capture to stop and all in-flight buffers to be finished with by
+ * the video hardware. This must be called under priv-lock
+ *
+ */
+static void rcar_vin_wait_stop_streaming(struct rcar_vin_priv *priv)
+{
+   while (priv-state != STOPPED) {
+   /* issue stop if running */
+   if (priv-state == RUNNING)
+   rcar_vin_request_capture_stop(priv);
+
+   /* wait until capturing has been stopped */
+   if (priv-state == STOPPING) {
+   priv-request_to_stop = true;
+   spin_unlock_irq(priv-lock);
+   wait_for_completion(priv-capture_stop);
+   spin_lock_irq(priv-lock);
+   }
+   }
+}
+
 static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
 {
struct soc_camera_device *icd = soc_camera_from_vb2q(vb-vb2_queue);
@@ -477,20 +499,8 @@ static void rcar_vin_videobuf_release(struct vb2_buffer 
*vb)
}
 
if (buf_in_use) {
-   while (priv-state != STOPPED) {
-
-   /* issue stop if running */
-   if (priv-state == RUNNING)
-   rcar_vin_request_capture_stop(priv);
-
-   /* wait until capturing has been stopped */
-   if (priv-state == STOPPING) {
-   priv-request_to_stop = true;
-   spin_unlock_irq(priv-lock);
-   wait_for_completion(priv-capture_stop);
-   spin_lock_irq(priv-lock);
-   }
-   }
+   rcar_vin_wait_stop_streaming(priv);
+
/*
 * Capturing has now stopped. The buffer we have been asked
 * to release could be any of the current buffers in use, so
@@ -524,8 +534,11 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
struct list_head *buf_head, *tmp;
 
spin_lock_irq(priv-lock);
+
+   rcar_vin_wait_stop_streaming(priv);
list_for_each_safe(buf_head, tmp, priv-capture)
list_del_init(buf_head);
+
spin_unlock_irq(priv-lock);
 }
 
-- 
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: Hauppage HVR-2250 - No Free Sequences

2015-01-26 Thread David Harty 
Kyle Sanderson kyle.leet at gmail.com writes:

 
  [585870.001641] saa7164_cmd_send() No free sequences
  [585870.001645] saa7164_api_i2c_write() error, ret(1) = 0xc
  [585870.001650] tda10048_writereg: writereg error (ret == -5)
 
  Any tips? I've tried a couple horrible kernel patches but didn't get
anywhere.
  Kyle.
 


I simply wanted to add the I have also started seeing this error recently so
Kyle is not alone in this.

I have tried combinations of all of the firmwares on the steventoth site in
conjunction with the saa7164 driver in the vanilla 3.11.10-25 kernel.

It requires a reboot to effectively reload the firmware.

Regards,


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

Re: [RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

2015-01-26 Thread Sumit Semwal 
Hi Russell!

On 21 January 2015 at 23:01, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote:
 +static int calc_constraints(struct device *dev,
 + struct dma_buf_constraints *calc_cons)
 +{
 + struct dma_buf_constraints cons = *calc_cons;
 +
 + cons.dma_mask = dma_get_mask(dev);

 I don't think this makes much sense when you consider that the DMA
 infrastructure supports buses with offsets.  The DMA mask is th
 upper limit of the _bus_ specific address, it is not a mask per-se.

 What this means is that = is not the right operation.  Moreover,
 simply comparing masks which could be from devices on unrelated
 buses doesn't make sense either.

 However, that said, I don't have an answer for what you want to
 achieve here.

Thanks for your comments! I suppose in that case, I will leave out the
*dma_masks from this constraints information for now; we can re-visit
it when a specific use case really needs information about the
dma-masks of the attached devices.

I will post an updated patch-set soon.

 --
 FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
 according to speedtest.net.



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
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: SPI interface camera sensor driver for soc_camera framework

2015-01-26 Thread Kassey 
Guennadi:
  I am working on a SPI interface camera sensor now, trying to
work out a patch for soc_camera for you to review.

 thanks.

Kassey

2014-11-07 5:55 GMT+08:00 Guennadi Liakhovetski g.liakhovet...@gmx.de:
 Hi Kassey,

 On Mon, 27 Oct 2014, Kassey wrote:

 hi, Dmitri:
 is there any sample driver for SPI interface camera sensor driver
 base don soc_camera framework, other than the i2c interface ?

 Currently there are no SPI drivers, used with the soc-camera framework.
 There is however an example of a non-I2C subdevice driver in soc-camera:
 the soc_camera_platform.c driver. You'll see handling of non-I2C
 subdevices in soc_camera_probe() in soc_camera.c. However, that driver
 hasn't been used since a long time and might well be broken by now. Also,
 many newer code paths in soc-camera core unfortunately began to assume,
 that I2C is the only way to access subdevices. So, I suspect fixes might
 be needed when adding support for SPI subdevices.

 Thanks
 Guennadi



-- 
Best regards
Kassey
--
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

Fwd: PCTV 800i

2015-01-26 Thread John Klug 
I moved it to a dual boot system, and it works in windows, and the
same error in Linux.

The chips are marked:
Conexant CX23880
Samsung S5H1411
Cirrus   CS5340CZZ
Atmel   ATMLH138

three out of four are a different part number than the Wiki.

It is Board T1213044 stamped on back
PCTV 800i Rev 1.1
Shield over tuner says pctv systems

There are 5 APL1117 on both sides of the board.

Since the tuner is probably under the shield I don't know a
non-destructive method to get the part number.

From: Steven Toth st...@kernellabs.com
Date: Mon, Jan 26, 2015 at 6:44 AM
Subject: Re: PCTV 800i
To: John Klug ski.brim...@gmail.com
Cc: Linux-Media linux-media@vger.kernel.org


On Mon, Jan 26, 2015 at 12:50 AM, John Klug ski.brim...@gmail.com wrote:
 I have a new PCTV card with CX23880 (not CX23883 as shown in the picture):

 http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_(800i)

 The description is out of date with respect to my recent card.

 It did not work in 3.12.20, 3.17.7, and I finally downloaded the
 latest GIT of media_build to no avail (I have a 2nd card that is CX18,
 which is interspersed in the output).

The error messages suggest one or more of the components on the board,
or their I2C addresses have changed, or that your hardware is bad.

Other than the Conexant PCI bridge, do the other components listed in
the wiki page match the components on your physical device?

--
Steven Toth - 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] [media] V4L: soc-camera: add SPI device support

2015-01-26 Thread Kassey 
This adds support for spi interface sub device for soc_camera.

Signed-off-by: Kassey Li kass...@nvidia.com
---
 drivers/media/platform/soc_camera/soc_camera.c |   51 
 include/media/soc_camera.h |   11 +
 2 files changed, 62 insertions(+)

diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..6db2d89 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1599,6 +1599,49 @@ static void scan_async_host(struct soc_camera_host *ici)
 #define soc_camera_i2c_free(icd)   do {} while (0)
 #define scan_async_host(ici)   do {} while (0)
 #endif
+static int soc_camera_init_spi(struct soc_camera_device *icd,
+   struct soc_camera_desc *sdesc)
+{
+   struct spi_device   *spi;
+   struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+   struct soc_camera_host_desc *shd = sdesc-host_desc;
+   struct spi_master *spi_master =
+   spi_busnum_to_master(shd-spi_bus_id);
+   struct v4l2_subdev *subdev;
+
+   if (!spi_master) {
+   dev_err(icd-pdev, Cannot get spi master #%d. No driver?\n,
+   shd-spi_bus_id);
+   goto espind;
+   }
+
+   shd-board_info_spi-platform_data = sdesc-subdev_desc;
+
+   subdev = v4l2_spi_new_subdev(ici-v4l2_dev, spi_master,
+   shd-board_info_spi);
+   if (!subdev)
+   goto espind;
+
+   spi = v4l2_get_subdevdata(subdev);
+
+   /* Use to_i2c_client(dev) to recover the i2c client */
+   icd-control = spi-dev;
+
+   return 0;
+espind:
+   return -ENODEV;
+}
+
+static void soc_camera_free_spi(struct soc_camera_device *icd) {
+   struct spi_device   *spi;
+   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+
+   spi = v4l2_get_subdevdata(sd);
+   icd-control = NULL;
+   v4l2_device_unregister_subdev(sd);
+   spi_unregister_device(spi);
+}

 #ifdef CONFIG_OF

@@ -1762,6 +1805,10 @@ static int soc_camera_probe(struct soc_camera_host *ici,
ret = soc_camera_i2c_init(icd, sdesc);
if (ret  0  ret != -EPROBE_DEFER)
goto eadd;
+   } else if (shd-board_info_spi) {
+   ret = soc_camera_init_spi(icd, sdesc);
+   if (ret  0)
+   goto eadd;
} else if (!shd-add_device || !shd-del_device) {
ret = -EINVAL;
goto eadd;
@@ -1803,6 +1850,8 @@ static int soc_camera_probe(struct soc_camera_host *ici,
 efinish:
if (shd-board_info) {
soc_camera_i2c_free(icd);
+   } else if (shd-board_info_spi) {
+   soc_camera_free_spi(icd);
} else {
shd-del_device(icd);
module_put(control-driver-owner);
@@ -1843,6 +1892,8 @@ static int soc_camera_remove(struct
soc_camera_device *icd)

if (sdesc-host_desc.board_info) {
soc_camera_i2c_free(icd);
+   } else if (sdesc-host_desc.board_info_spi) {
+   soc_camera_free_spi(icd);
} else {
struct device *dev = to_soc_camera_control(icd);
struct device_driver *drv = dev ? dev-driver : NULL;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 2f6261f..6d495f8 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -180,6 +180,12 @@ struct soc_camera_host_desc {
const char *module_name;

/*
+* Add SPI device support.
+*/
+   struct spi_board_info *board_info_spi;
+   int spi_bus_id;
+
+   /*
 * For non-I2C devices platform has to provide methods to add a device
 * to the system and to remove it
 */
@@ -243,6 +249,11 @@ struct soc_camera_link {
int i2c_adapter_id;
struct i2c_board_info *board_info;
const char *module_name;
+   /*
+* Add SPI device support.
+*/
+   struct spi_board_info *board_info_spi;
+   int spi_bus_id;

/*
 * For non-I2C devices platform has to provide methods to add a device
--
1.7.9.5

-- 
Best regards
Kassey
--
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: media_tree daily build: ERRORS

2015-01-26 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Jan 27 04:01:01 CET 2015
git branch: test
git hash:   e32b31ae45c18679c186e67aa41d0e2318cae487
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-41-g6c2d743
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:3.18.0-1.slh.1-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: ERRORS
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.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.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16-i686: OK
linux-3.17.8-i686: OK
linux-3.18-i686: OK
linux-3.19-rc4-i686: 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.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18-x86_64: OK
linux-3.19-rc4-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: 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 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

[linuxtv-media:master 66/93] drivers/media/platform/am437x/am437x-vpfe.c:2027 vpfe_start_streaming() error: double unlock 'spin_lock:vpfe-dma_queue_lock'

2015-01-26 Thread Dan Carpenter 
tree:   git://linuxtv.org/media_tree.git master
head:   e32b31ae45c18679c186e67aa41d0e2318cae487
commit: 417d2e507edcb5cf15eb344f86bd3dd28737f24e [66/93] [media] media: 
platform: add VPFE capture driver support for AM437X

drivers/media/platform/am437x/am437x-vpfe.c:2027 vpfe_start_streaming() error: 
double unlock 'spin_lock:vpfe-dma_queue_lock'
drivers/media/platform/am437x/am437x-vpfe.c:2027 vpfe_start_streaming() error: 
double unlock 'irqsave:flags'

git remote add linuxtv-media git://linuxtv.org/media_tree.git
git remote update linuxtv-media
git checkout 417d2e507edcb5cf15eb344f86bd3dd28737f24e
vim +2027 drivers/media/platform/am437x/am437x-vpfe.c

417d2e50 Benoit Parrot 2014-12-09  2011  
417d2e50 Benoit Parrot 2014-12-09  2012 vpfe_pcr_enable(vpfe-ccdc, 1);
417d2e50 Benoit Parrot 2014-12-09  2013  
417d2e50 Benoit Parrot 2014-12-09  2014 ret = 
v4l2_subdev_call(sdinfo-sd, video, s_stream, 1);
417d2e50 Benoit Parrot 2014-12-09  2015 if (ret  0) {
417d2e50 Benoit Parrot 2014-12-09  2016 vpfe_err(vpfe, Error 
in attaching interrupt handle\n);
417d2e50 Benoit Parrot 2014-12-09  2017 goto err;
417d2e50 Benoit Parrot 2014-12-09  2018 }
417d2e50 Benoit Parrot 2014-12-09  2019  
417d2e50 Benoit Parrot 2014-12-09  2020 return 0;
417d2e50 Benoit Parrot 2014-12-09  2021  
417d2e50 Benoit Parrot 2014-12-09  2022  err:
417d2e50 Benoit Parrot 2014-12-09  2023 list_for_each_entry_safe(buf, 
tmp, vpfe-dma_queue, list) {
417d2e50 Benoit Parrot 2014-12-09  2024 list_del(buf-list);
417d2e50 Benoit Parrot 2014-12-09  2025 
vb2_buffer_done(buf-vb, VB2_BUF_STATE_QUEUED);
417d2e50 Benoit Parrot 2014-12-09  2026 }
417d2e50 Benoit Parrot 2014-12-09 @2027 
spin_unlock_irqrestore(vpfe-dma_queue_lock, flags);
417d2e50 Benoit Parrot 2014-12-09  2028  
417d2e50 Benoit Parrot 2014-12-09  2029 return ret;
417d2e50 Benoit Parrot 2014-12-09  2030  }
417d2e50 Benoit Parrot 2014-12-09  2031  
417d2e50 Benoit Parrot 2014-12-09  2032  /*
417d2e50 Benoit Parrot 2014-12-09  2033   * vpfe_stop_streaming : Stop the DMA 
engine
417d2e50 Benoit Parrot 2014-12-09  2034   * @vq: ptr to vb2_queue
417d2e50 Benoit Parrot 2014-12-09  2035   *

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
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 V1] [media] V4L: soc-camera: add SPI device support

2015-01-26 Thread Kassey Li 
From: Kassey Li kass...@nvidia.com

This adds support for spi interface sub device for
soc_camera.

Signed-off-by: Kassey Li kass...@nvidia.com
---
 drivers/media/platform/soc_camera/soc_camera.c |   51 
 include/media/soc_camera.h |   10 +
 2 files changed, 61 insertions(+)

diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..6db2d89 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1599,6 +1599,49 @@ static void scan_async_host(struct soc_camera_host *ici)
 #define soc_camera_i2c_free(icd)   do {} while (0)
 #define scan_async_host(ici)   do {} while (0)
 #endif
+static int soc_camera_init_spi(struct soc_camera_device *icd,
+   struct soc_camera_desc *sdesc)
+{
+   struct spi_device   *spi;
+   struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+   struct soc_camera_host_desc *shd = sdesc-host_desc;
+   struct spi_master *spi_master =
+   spi_busnum_to_master(shd-spi_bus_id);
+   struct v4l2_subdev *subdev;
+
+   if (!spi_master) {
+   dev_err(icd-pdev, Cannot get spi master #%d. No driver?\n,
+   shd-spi_bus_id);
+   goto espind;
+   }
+
+   shd-board_info_spi-platform_data = sdesc-subdev_desc;
+
+   subdev = v4l2_spi_new_subdev(ici-v4l2_dev, spi_master,
+   shd-board_info_spi);
+   if (!subdev)
+   goto espind;
+
+   spi = v4l2_get_subdevdata(subdev);
+
+   /* Use to_i2c_client(dev) to recover the i2c client */
+   icd-control = spi-dev;
+
+   return 0;
+espind:
+   return -ENODEV;
+}
+
+static void soc_camera_free_spi(struct soc_camera_device *icd)
+{
+   struct spi_device   *spi;
+   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+
+   spi = v4l2_get_subdevdata(sd);
+   icd-control = NULL;
+   v4l2_device_unregister_subdev(sd);
+   spi_unregister_device(spi);
+}
 
 #ifdef CONFIG_OF
 
@@ -1762,6 +1805,10 @@ static int soc_camera_probe(struct soc_camera_host *ici,
ret = soc_camera_i2c_init(icd, sdesc);
if (ret  0  ret != -EPROBE_DEFER)
goto eadd;
+   } else if (shd-board_info_spi) {
+   ret = soc_camera_init_spi(icd, sdesc);
+   if (ret  0)
+   goto eadd;
} else if (!shd-add_device || !shd-del_device) {
ret = -EINVAL;
goto eadd;
@@ -1803,6 +1850,8 @@ static int soc_camera_probe(struct soc_camera_host *ici,
 efinish:
if (shd-board_info) {
soc_camera_i2c_free(icd);
+   } else if (shd-board_info_spi) {
+   soc_camera_free_spi(icd);
} else {
shd-del_device(icd);
module_put(control-driver-owner);
@@ -1843,6 +1892,8 @@ static int soc_camera_remove(struct soc_camera_device 
*icd)
 
if (sdesc-host_desc.board_info) {
soc_camera_i2c_free(icd);
+   } else if (sdesc-host_desc.board_info_spi) {
+   soc_camera_free_spi(icd);
} else {
struct device *dev = to_soc_camera_control(icd);
struct device_driver *drv = dev ? dev-driver : NULL;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 2f6261f..7530893 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -178,6 +178,11 @@ struct soc_camera_host_desc {
int i2c_adapter_id;
struct i2c_board_info *board_info;
const char *module_name;
+   /*
+* Add SPI device support.
+*/
+   struct spi_board_info *board_info_spi;
+   int spi_bus_id;
 
/*
 * For non-I2C devices platform has to provide methods to add a device
@@ -243,6 +248,11 @@ struct soc_camera_link {
int i2c_adapter_id;
struct i2c_board_info *board_info;
const char *module_name;
+   /*
+* Add SPI device support.
+*/
+   struct spi_board_info *board_info_spi;
+   int spi_bus_id;
 
/*
 * For non-I2C devices platform has to provide methods to add a device
-- 
1.7.9.5

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

Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors

2015-01-26 Thread Baluta, Teodora 
Hi Florian,

Thanks for the reply!

On Vi, 2015-01-23 at 17:46 +0100, Florian Echtler wrote:
 Hello Teodora,
 
 On 23.01.2015 14:05, Baluta, Teodora wrote:
  The fingerprint sensor acts more like a scanner device, so the
  closest type is the V4L2_CAP_VIDEO_CAPTURE. However, this is not a
  perfect match because the driver only sends an image, once, when
  triggered. Would it be a better alternative to define a new
  capability type? Or it would be acceptable to simply have a video
  device with no frame buffer or frame rate and the user space
  application to read from the character device /dev/videoX?
 Sorry if I jump in here right in the middle of this discussion, but some
 time ago, I wrote a fingerprint sensor driver for the Siemens ID Mouse
 (still part of the kernel AFAICT) which acts as a misc device and just
 creates a character device node that can be used to directly read a PGM
 file.

I agree that it would be the simplest approach if you want a USB
fingerprint driver in kernel space, but I was looking for a way to
support fingerprint devices regardless of bus (there's also fingerprint
devices that use SPI) and provide a common interface for user space
applications.

The actual driver for UPEK's TouchChip sensor is just a proof of concept
on how the interface would work, rather than the final goal. There's
already a library that enables USB-only fingerprint devices (libfprint).
 
 Maybe this would be a slightly simpler approach than pulling in all the
 streaming-optimized features of V4L2?

I agree that for a fingerprint device, the V4L2 subsystem offers too
much (the initial RFC is for IIO).

Thanks,
Teodora

Re: [RFC v2 3/7] cec: add new framework for cec support.

2015-01-26 Thread Hans Verkuil 
On 01/23/2015 12:07 PM, Sean Young wrote:
 On Thu, Jan 22, 2015 at 05:04:35PM +0100, Kamil Debski wrote:
 Add the CEC framework.
 -snip-
 +Remote control handling
 +---
 +
 +The CEC framework provides two ways of handling the key messages of remote
 +control. In the first case, the CEC framework will handle these messages and
 +provide the keypressed via the RC framework. In the second case the messages
 +related to the key down/up events are not parsed by the framework and are
 +passed to the userspace as raw messages.
 +
 +Switching between these modes is done with a special ioctl.
 +
 +#define CEC_G_KEY_PASSTHROUGH   _IOR('a', 10, __u8)
 +#define CEC_S_KEY_PASSTHROUGH   _IOW('a', 11, __u8)
 +#define CEC_KEY_PASSTHROUGH_DISABLE 0
 +#define CEC_KEY_PASSTHROUGH_ENABLE  1
 
 This is ugly. This ioctl stops keypresses from going to rc-core. The cec 
 device is still registered with rc-core but no keys will be passed to it. 
 This could also be handled by loading an empty keymap; this way the input 
 layer will still receive scancodes but no keypresses.
 
 +static ssize_t cec_read(struct file *filp, char __user *buf,
 +size_t sz, loff_t *off)
 +{
 +struct cec_devnode *cecdev = cec_devnode_data(filp);
 +
 +if (!cec_devnode_is_registered(cecdev))
 +return -EIO;
 +return 0;
 +}
 +
 +static ssize_t cec_write(struct file *filp, const char __user *buf,
 +size_t sz, loff_t *off)
 +{
 +struct cec_devnode *cecdev = cec_devnode_data(filp);
 +
 +if (!cec_devnode_is_registered(cecdev))
 +return -EIO;
 +return 0;
 +}
 
 Both read and write do nothing; they should either -ENOSYS or the fuctions
 should be removed.

These can be removed. These are leftovers from the very first cec driver I
wrote. The idea at the time was to use read and write to handle CEC messages,
but in the end that never happened and ioctls were used instead,


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] media: gspca_vc032x - wrong bytesperline

2015-01-26 Thread Luca Bonissi 

Hi!

I found a problem on vc032x gspca usb webcam subdriver: bytesperline 
property is wrong for YUYV and YVYU formats.
With recent v4l-utils library (=0.9.1), that uses bytesperline for 
pixel format conversion, the result is a wrong jerky image.


Patch tested on my laptop (USB webcam Logitech Orbicam 046d:0892).

--- drivers/media/usb/gspca/vc032x.c.orig   2014-08-04 
00:25:02.0 +0200

+++ drivers/media/usb/gspca/vc032x.c2015-01-12 00:28:39.423311693 +0100
@@ -68,12 +68,12 @@

 static const struct v4l2_pix_format vc0321_mode[] = {
{320, 240, V4L2_PIX_FMT_YVYU, V4L2_FIELD_NONE,
-   .bytesperline = 320,
+   .bytesperline = 320 * 2,
.sizeimage = 320 * 240 * 2,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 1},
{640, 480, V4L2_PIX_FMT_YVYU, V4L2_FIELD_NONE,
-   .bytesperline = 640,
+   .bytesperline = 640 * 2,
.sizeimage = 640 * 480 * 2,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 0},
@@ -97,12 +97,12 @@
 };
 static const struct v4l2_pix_format bi_mode[] = {
{320, 240, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
-   .bytesperline = 320,
+   .bytesperline = 320 * 2,
.sizeimage = 320 * 240 * 2,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 2},
{640, 480, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
-   .bytesperline = 640,
+   .bytesperline = 640 * 2,
.sizeimage = 640 * 480 * 2,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = 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

Re: [PATCH/RFC v10 01/19] leds: Add LED Flash class extension to the LED subsystem

2015-01-26 Thread Bryan Wu 
On Fri, Jan 9, 2015 at 9:37 AM, Pavel Machek pa...@ucw.cz wrote:
 On Fri 2015-01-09 16:22:51, Jacek Anaszewski wrote:
 Some LED devices support two operation modes - torch and flash.
 This patch provides support for flash LED devices in the LED subsystem
 by introducing new sysfs attributes and kernel internal interface.
 The attributes being introduced are: flash_brightness, flash_strobe,
 flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault,
 flash_sync_strobe and available_sync_leds. All the flash related
 features are placed in a separate module.

 The modifications aim to be compatible with V4L2 framework requirements
 related to the flash devices management. The design assumes that V4L2
 sub-device can take of the LED class device control and communicate
 with it through the kernel internal interface. When V4L2 Flash sub-device
 file is opened, the LED class device sysfs interface is made
 unavailable.

 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Bryan Wu coolo...@gmail.com
 Cc: Richard Purdie rpur...@rpsys.net

 Acked-by: Pavel Machek pa...@ucw.cz


Applied to my tree. Thanks for pushing this.

-Bryan
--
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 v10 02/19] Documentation: leds: Add description of LED Flash class extension

2015-01-26 Thread Bryan Wu 
On Mon, Jan 12, 2015 at 12:04 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
 Hi Pavel,

 Thanks for the review.

 On 01/09/2015 06:40 PM, Pavel Machek wrote:

 Hi!

 The documentation being added contains overall description of the
 LED Flash Class and the related sysfs attributes.

 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Bryan Wu coolo...@gmail.com
 Cc: Richard Purdie rpur...@rpsys.net


 +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol
 +must be defined in the kernel config. A flash LED driver must register
 +in the LED subsystem with led_classdev_flash_register function to gain
 flash
 +related capabilities.
 +
 +There are flash LED devices which can control more than one LED and
 allow for
 +strobing the sub-leds synchronously. A LED will be strobed synchronously
 with
 +the one whose identifier is written to the flash_sync_strobe sysfs
 attribute.
 +The list of available sub-led identifiers can be read from the


 sub-LED?


 Indeed, this naming will be more consistent.

 +   - flash_fault - bitmask of flash faults that may have occurred
 +   possible flags are:
 +   * 0x01 - flash controller voltage to the flash LED has
 exceeded
 +the limit specific to the flash controller
 +   * 0x02 - the flash strobe was still on when the timeout
 set by
 +the user has expired; not all flash controllers
 may
 +set this in all such conditions
 +   * 0x04 - the flash controller has overheated
 +   * 0x08 - the short circuit protection of the flash
 controller
 +has been triggered
 +   * 0x10 - current in the LED power supply has exceeded the
 limit
 +specific to the flash controller
 +   * 0x20 - the flash controller has detected a short or
 open
 +circuit condition on the indicator LED
 +   * 0x40 - flash controller voltage to the flash LED has
 been
 +below the minimum limit specific to the flash
 +   * 0x80 - the input voltage of the flash controller is
 below
 +the limit under which strobing the flash at full
 +current will not be possible. The condition
 persists
 +until this flag is no longer set
 +   * 0x100 - the temperature of the LED has exceeded its
 allowed
 + upper limit


 Did not everyone agree that text strings are preferable to bitmasks?


 Pavel


 I just forgot to update the flash_fault documentation. Will fix in the
 next version.

Please provide an updated version. I will merge them.

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